wie peinlich...
Ich hab diesen Satz mindestens 10 mal gelesen und doch falsch verstanden:Wir sind uns einig, die Schleife ist unnötig.The user is thus advised not to write new channel or reference selection values
to ADMUX until one ADC clock cycle after ADSC is written. (Datasheet at90can*
Ich habs mit volatile geschrieben darum optimiert er das garnichtmehr weg
Muss ich/man das jetzt verstehen?Zitat von Gock
Hmmm, eine seltsame Reihenfolge. Das mag ja stimmen, dass das Ergebnis theoretisch drin bleibt, aber ich mache das aber immer genau anders: erst lesen, z.B. so: "inwert = ADC;" und danach sofort die nächste Wandlung starten. Dies ist dann auch unempfindlich gegen laufende ISR. Denn wenn man erst startet und danach ausliest - und genau dazwischen kommt eine ISR . . . . . trallalallala
Ciao sagt der JoeamBerg
Die Betonung liegt auf EINER Funktion, die den Text 8-mal enthält und NICHT 8 mal aufgerufen wird, weil das ja viel Zeit kostet...Muss ich/man das jetzt verstehen?
Normalerweise mache ich es auch anders, denn das ist sicherer und besser.Hmmm, eine seltsame Reihenfolge. Das mag ja stimmen, dass das Ergebnis theoretisch drin bleibt, aber ich mache das aber immer genau anders: erst lesen, z.B. so: "inwert = ADC;" und danach sofort die nächste Wandlung starten. Dies ist dann auch unempfindlich gegen laufende ISR. Denn wenn man erst startet und danach ausliest - und genau dazwischen kommt eine ISR . . . . . trallalallala
Um ganz sicher zu gehen müsste man ohnehin in jedem Fall vorher die IRQs abschalten, weil ADC ein 16BitRegister ist und soweit ich weiß puffert das weder der µC doppelt, noch erledigt das der Compiler für mich. Aber da es in diesem Fall scheinbar um nichts anderes geht, als besonoders schnell zu sein, sollten ohnehin keine anderen IRQs anktiviert sein, sonst ist die Geschwindigkeit schnell wieder dahin und dann kann man diesen Trick schon mal wagen.
Gruß
Das 16 Bit breite ADC Register wird hardwaremäßig gepufert. Um das richtige auslesen kümmert sich der Compiler schon. Solange da keine ISR dabei ist, der auch noch den AD ausließt, passiert da also nichts.
Die Geschwindigkeit wird ohnehin im wesentlichen vom AD Wandler vorgegeben. Die eigentlichen Rechenzeiten sind dagegen ziehmlich nebensächlich, solange man nicht gerade ne Division oder Fließkomma hat. Da wäre der kontinuierliche AD mode wirklich die einfachste Lösung das zu beschleunigen. Wenn man von Hand startet wird man wohl jeweils mindestens 14 Zyken des AD taktes brauchen, automatisch halt nur 13.
Mit einem zwischenzeitlichen Interrupt sollte man normalerweise keine Probleme haben, selbst wenn man den AD erst startet und dann ausliest. Man hat da immer noch rund 1600 Zyklen (13x12an Zeit bis der AD-wert überschrieben wird. So lange sollte eine ISR eigentlich nicht sein.
Nächste woche kommt die Leiterplatte und dann kann ich probieren ob die bisherige Lösung schnell genug ist oder nicht.
Falls es nicht, muss ich auf die Tricks zurückgreifen.
also von mir noch ein paar tipps um rechenzeit zu sparen, nachteil es geht auflösung flöten 10bit -> 8bit (mit ADLAR flag)
nurnoch das high byte auslesen, spart schonmal satt speicher aus 2 byte mach 1, das verrechnen der werte für die mittelwertbildung muss dann aber geändert werden(!!!)
ADC ruhig etwas übertakten, die auflösung haben wir ja schon auf 8bit reduziert sollte also keinen großen unterschied machen
vermeide arrayzugriffe ala array[index] versuch dir nen pointer anzulegen den du inkrementierst, meine persönliche erfahrung war, bei zeitkritischen abläufen geht der pointer erheblich schneller
vermeide interruptgesteuertes auslesen nach kräften, das kostet noch mehr rechenleistung .... im freerun solltest du die ersten 2 werte nach einem schannelwechsel wegwerfen, weil nciht sicher ist ob der erste wert noch zum alten channel gehört oder schon vom neuen ist und der erste wert nciht unbedingt der stabilste ist, mit single conversion solltest du auch eventuell das erste ergebnis wegwerfen
wenn du mit pointern und einer geschickten schleife arbeitest kannst du rechenzeit im vergleich zum prozeduralen ablauf sparen UND das programm sieht ordentlich aus
Das Kanalumschalten macht eigentlich nur Probleme, wenn die Signalquelle zu hochohmig ist. Wenn man den AD Wadnler schneller taktet wird man quellen wahrscheinlich noch niederohmiger als die empfohlenen 10 KOhm machen müssen.
Auch im Freilaufenden Modus ist die Kanalumschaltung eigentlich kein Problem, den die Umschaltung wird intern gepuffert. Es gilt immer die Kanaleinstellung die anliegt wenn die Wandlung startet. Wenn man also den Kanal im freilaufenden Modus nach dem AD-ready signal wechselt, Wird auch die laufende Wandlung noch mit der alten Einstellung gemacht. Der Wert im den ADC Registen kann sogar zu noch einem andernen Kanal gehören. Werte auslassen braucht man nur, wenn man den Überblick verloren hat.
du solltest im freerun das ADCF flag benutzen, da das ADSC permanent 1 bleibt, wenn ADCF 1 wird musst du dann auch wieder eine 1 reinschreiben um es zu löschen (hab am anfang immer versucht ne 0 reinzuschreiben XD)damit du den nächsten wert mitbekommst mitbekommst
@besserwessi im freerun magts du recht haben aber wenn mans gaaaanz genau nimmt, musst du den ersten wert dennoch wegwerfen, denn
[klugscheisser] wenn du umschaltest läuft zu 99% noch die wandlung auf dem letzten kanal und erst das 2te ADCF gilt für den neuen kanal!
[/klugscheisser]
Wenn man es richtig macht, schaltet man den Kanal um während die letzte Messung für den vorherigen Kanal läuft. Man muß also nur das Kanalumschalten etwas vorher positionieren, dann kann man jede Wandlung nutzen. Wenn man im schnellen Wechsel 3 Kanäle mißt, kann das schon recht verwirrend werden: Im ADC register ist das Ergebnis von Kanal A, und die Wandlung für Kanal B läuft gerade, wenn man auf Kanal C umschaltet.
Bei der ersten Messung halt den Kanal wählen bevor man den Free running mode wählt.
Berechtigungen
Zitieren
Lesezeichen