Zitierenja, das stimmt. aber bei Bascom z.b. wird das bei entsprechender einstellungen für den adc direkt von der routine gemacht. ka wie das in c ist.Zitat von oberallgeier
mfg jeffrey
Das Datenblattgerechte Auslesen sollte der Compiler erledigen. Auszug aus meiner *.lls :...
2. ... Bei 10-Bit-Wandlung immer erst ADCL, dann ADCH auslesen (Abs 2, S.19. ...
Es wird also zuerst 0x0078, das lowbyte und danach 0x0079 gelesen.Code:adc3_sum = adc3_sum + ADC; // ADC-Werte aufsummieren 8aa: 80 91 db 01 lds r24, 0x01DB 8ae: 90 91 dc 01 lds r25, 0x01DC 8b2: 20 91 78 00 lds r18, 0x0078 8b6: 30 91 79 00 lds r19, 0x0079 8ba: 82 0f add r24, r18 8bc: 93 1f adc r25, r19 8be: 90 93 dc 01 sts 0x01DC, r25 8c2: 80 93 db 01 sts 0x01DB, r24
Ich dachte (was man so alles denkt - *kopfschüttel*) ich hätte irgendwann irgendwo gelesen, dass das erste Ergebnis nach dem Umschalten von einem ADC-Kanal auf den anderen von zweifelhafter Güte ist. Leider weiss ich die Quelle nicht mehr. Daher hatte ich das oben nicht erwähnt.
Ciao sagt der JoeamBerg
ja, das stimmt. aber bei Bascom z.b. wird das bei entsprechender einstellungen für den adc direkt von der routine gemacht. ka wie das in c ist.
mfg jeffrey
Nur ganz kurz.
@mare_crisium
Oh je, wer auch immer FMEA erfunden hat. Den soll der Teufel holen.
Da muss ich noch ein wenig grübeln.
@oberallgeier
Dein ".. adc3_sum + ADC;" erinnert mich daran, dass ich meinen Code wieder umstellen muss.
Ich hatte da auch schon mit der Reihenfolge gespielt und tatsächlich massives Fehlverhalten festgestellt, wenn die Reihenfolge nicht stimmt.
Hier scheint deine Vermutung, dass der C-Compiler sich drum kümmert, bestätigt zu sein. Beim Nutzen von ADC anstatt ADCL und ADCH hatte ich noch nie (weiter) Probleme.
@jeffrey
Hmmm, in Bascom kann man da etwas einstellen? Dann kann das ja bei Unwissenheit zu fatalen Problem führen.
Wie ich zu oberallgeiers Beitrag schrieb, scheint es bei C immer richtig zu sein. Für C ist es mir nicht bekannt, ob da etwas einstellbar ist.
Dann wäre es ja in Summe interessant, tatsächlich die von mare_crisium vorgeschlagen Variante zum 8-Bit messen zu testen.
Damit würde sich auf alle Fälle eine 'versehentliche' falsche Reihenfolge wohl umgehen lassen.
Bis die Nächte
Gruß Sternthaler
Lieber Asuro programieren als arbeiten gehen.
Hallo mare_crisium, und natürlich an alle anderen Unterstützer auch ein Hallo.
Da es auch heute kurz bleiben soll, nur kleine Anmerkungen zu deinen Punkten (die natürlich nur aus meiner Sicht, und damit schon fehlerhaft sein können):
Auslesen erfolg nur im ADC-Interrupt nach der einen Wandlung.
Frequenz ist somit identisch.
Auch hier, wie bei 1., wird nur im ADC-Interrupt genau einmal ausgelesen.
'Vorheriges Ergebnis' entstand somit durch vorherige Wandlung und muss dann natürlich schon vorher ausgelesen worden sein.
Da dies aber für alle Messungen die identische Codestelle ist, müssten dann alle, bzw. viel mehr, Ergebnisse falsch sein.
Da ich ja durch eine belegte "Logische-Kanal-Variable" != 'frei' nicht zum setzen von ADMUX komme, dürfte dies nicht zu einer weiteren Wandlung mit noch nicht umgeschaltetn MUX kommen.
--> Noch nicht richtig bedacht ob dies der Fall sein könnte.
Bei den Messungen müssten es dann ja ADC-Werte größer als 1023 ergeben.
Ob dann der fast konstante Wert von meinen fehlerhaften ca. 450 entstehen kann, ist mir nicht bekannt.
Das hätte ich nie im Leben geprüft.
Hier sollte dann aber ein ADC-Wert von 1024 / 5V * 1,23V = ca. 252 gemessen werden.
Und nun etwas Erfreuliches.
Umgekehrt proportional zu meiner durchschnittlichen Beitragslänge ist nun das Programm radikal gekürzt worden.
Soll heissen, dass ich alles aus den beiden Interrupts entsorgt habe, was nicht zur Messung der beiden Räder mit LED-Beleuchtung gehört.
- Batterie, Taster, Rad-Dunkelmessung und Liniensensoren weg
So geht es wieder!
- Taster, Rad-Dunkelmessung und Liniensensoren weg
So geht es immer noch.
Nun aber erst einmal Feierabend, da ich sonst die Nacht duchmachen würde um meinen Fehler genau eingekreist zu haben.
Hier schon einmal vielen Dank für alle eure Anregungen und seelischen Unterstützungen. Ohne euch hätte ich es wahrscheinlich nicht durchgehalten mittlerweile 108 Messreihen aufgenommen und ausgewertet zu haben.
Gruß Sternthaler
P.S.: Daten und 'Kurz-Programm' bei Bedarf bitte anfordern.
Lieber Asuro programieren als arbeiten gehen.
Buon giorno, SternThaler,
na, da hast Du ja zu später Stunde noch einen grossen Schritt vorwärts gemacht!
Nach Datenblatt Seite 10, Abs. 7 haben Interrupts mit niedriger Adresse Vorrang vor denen mit höherer. D.h. wenn ein Timer-Interrupt eintritt, während der ADC-Interruptdienst noch läuft, dann unterbricht er ihn erbarmungslos. Ober sticht Unter, kennen wir ja.
Weil sich der freche Timer-Interrupt immer vordrängelt und das laufenden ADC-Interrupt-Dienstprogramm unterbricht, kann er auch den Beginn einer neuen ADC-Wandlung starten, auch wenn die Abfrage des alten noch in Gange ist! Und wenn der Timer-Interruptdienst besonders viel zu tun hat und es deshalb lange dauert bis der ADC-Interruptdienst wieder zum Zuge kommt, kann es sogar vorkommen, dass ein ADC-Interrupt den noch laufenden ADC-Dienst unterbricht. Was dann passiert, ist im Datenblatt nicht spezifiziert.
Durch Dein radikales Abspecken der Interruptdienste gibt's dort jetzt viel weniger zu tun. Damit ist die Wahrscheinlichkeit gross, dass die Interrupts und -dienste sich zeitlich nicht mehr die Quere kommen.
Ciao, bis heut' nacht!
mare_crisium
Hallo Ihr,
Da sag ich jetzt mal ganz pingelig: bei den Interrupten sticht der Unter (die untere Adresse) den Ober. Einfacher ausgedrückt: wer zuerst (in der Vektorliste) kommt, mahlt zuerst.
... deshalb bin ich bei meinem Programm bemüht:
a) Hohe Quarzfrequenz. Ist bei mir ein Entscheidungskriterium für den m168! Damit kann ich in einer Zeiteinheit 25 % mehr Arbeitstakte erledigen als mit einem M16 oder M32 *gggg* - und noch etwas mehr, als mit dem doch sehr pfiffigen asuro-Controller.
b) Alle ISR müssen in kürzerer Zeit abzuarbeiten sein, als der kürzeste Interruptabstand. Ausserdem: meine sehr hoch priorisierten extINT0 und ~1 sind theoretisch garnicht in der Lage, den Timerinterrupt - Mittelfeld der Priorisierung - zu überholen; sonst wäre ja bei denen die Zeitmessung fehlerebehaftet. Wobei ich als Zeitbasis den Timer2 genommen hatte - das ist der höchstpriorisierte Timer!
c) Meine Interruptroutinen (derzeit bis auf die CIR) habe ich zeitlich ausgemessen als Nicht-ISR und zwar: Pin(x=test) einschalten, Routine aufrufen, Pin(x=test) ausschalten. Das heisst, ich messe die Zeitdauer mit dem kompletten "Routinen-Register-Rettungs-Aufwand". Das in einer for( ; ; ) gibt ein hübsches Flimmern im Oskar *ggggg*.
d) Schließlich habe ich noch ein ungutes Gefühl und noch keine klare Meinung über die Verwendung von cli(); und sei();. Wenn ich diese Kombination verwende und vorher war kein sei(); - dann sind die jetzt die Interrupts global zugelassen . . . . . ich glaube, dass müsste ich mit einem eigenen Verwaltungsflag abfangen. Derzeit versuche ich, ohne diese Kombination auszukommen.
Die ISR sollte doch immer nur gerade das Allernötigste machen!? Der "Rest" muss anderswie organisiert sein. Ok, ich bin noch nicht so sehr in die ganze µC-Technik eingestiegen, aber ich glaube diese Regel ist sehr wichtig.
Sternthaler - viel Glück, ich halte Dir die Daumen [OT] - auch wenn ich jetzt auf eine Löwenfete gehe (beim Segelklub - oh jeeee, hoffentlich falle ich nicht ins Wasser) [/OT] .
Ciao sagt der JoeamBerg
Hallo ihr Ober-Unter-Ober-Stecher,
@oberallgeier
lass den Ober beim Segelclub in Ruhe, sonst drückt er dich ins Wasser Unter
Kleines Zurechtrücken der ISR-Unterbrechbarkeit in meinem Programm bzw. i.d.R. beim Asuro.
Die ISR-Funktionen werden nicht durch andere ISR-Anforderungen unterbrochen. Dies ist bewusst durch die Funktionsangabe über "SIGNAL (SIG_Name)" gemacht worden.
=> In meinem Asuro wird nicht vorgedrängelt! <= (Sag ich immer zu ihm im gleichen Ton wie bei der Kindererziehung.)
Nun ist folgender Stand erreicht: Alles ist gut
Schuld sind Medien-Markt und KOkg.
"Ich bin doch blöd" und "Geiz ist Schrill" hat sich in meinem Hirn so weit eingebrannt, dass folgender Code entstand:Man beachte den Kommentar!Code:if (! sens.aktiv & SENS_RAD) LED_RAD_OFF; // Sensor deaktiviert; Strom sparen
Zu finden ist das Desaster im Timer-Interrupt recht weit vorne.
Hier noch kurz die nun aufgenommenen Geschwindigkeit mit:
- nicht drehen
- langsam drehen
- nicht drehen
- schnell drehen
- nicht drehen
- langsam drehen
- nicht drehen
-- und dann auch mal für das linke Rad
Die 'wackelnden' Geschwindigkeiten kommen vor allem durch das Aufbocken des Asuros. Kein Rollwiderstand und somit 'flatternde' Raddrehungen in den Lagern.
Danke für eure Mühe, und wartet mal ab, was als nächstes Problem noch kommen wird
Gruß Sternthaler
@oberallgeier
Das mit cli(); und sei(); kann ich dir beschreiben, wenn du magst.
Lieber Asuro programieren als arbeiten gehen.
Buon giorno, alle zusammen,
da hast Du recht. - Es gibt offenbar noch Bereiche wo' anders läuft, als in der Firma
@SternThaler,
prima, dass Du den Fehler gefunden hast: Ich meine, bei einem Befehl wie
= "LED-Rad-ab"
da kann ja nur ein Asuro mit appem Rad 'rauskommen
Wenn ich die Periodendauer zwischen zwei Sektorflanken an meinem Eigenbau-Motor messe, kommt ein ganz ähnliches Diagramm heraus. Das ist in sofern bemerkenswert, als ich nur 0- und 1-Pegel unterscheide und dazu den ADC nicht bemühe. Das "Leerlauf-Geflatter" sehe ich auch.
Dann bleibt uns nur zu hoffen, dass Oberallgeier (äusserlich!) trocken nach hause kam...
Ciao,
mare_crisium
Hallo Sportsfreunde und asurofahrer,
Herzlichen Glückwunsch. Manchmal sind ja die Details, in denen der sprichwörtliche Teufel steckt, so klein oder der ist so versteckt - sagenhaft! Aber schön, dass wieder ein Fehler ausgemerzt ist.
Er kam.
... und ich dachte, dass es dabei um eine persönliche Schreibweise von OFF_ROAD ginge.... bei einem Befehl wie
= "LED-Rad-ab" ...
@Sternthaler: nur um (pingeligerweise) ganz sicher zu gehen: die Spikes sind wirklich weg? Alle? Komplett (soweit Du es bisher kontrolliert hast)?
Erstmal vielen Dank. Ich habe praktisch alles aufgeräumt und es läuft und läuft . . . . never change a .... Aber ich werde das noch mal durchgehen und mich dann melden. Danke.
Ciao sagt der JoeamBerg
Hallo ihr Erfinder,
Ja, lacht ihr nur. Aber da kann ich zum Glück, vor allem über euren Reichtum an Alternativ-Funktionalität, natürlich mitlachen.... und ich dachte, dass es dabei um eine persönliche Schreibweise von OFF_ROAD ginge.... bei einem Befehl wie
= "LED-Rad-ab" ...
Im Anhang habe ich (natürlich) ein EXCEL-Blättchen mit allen mittlerweile 142 Testfällen. Du kannst ja mal nachsehen.
Im Ernst: Es sind nur noch Testfälle mit korrigierter Software vorhanden, und da kann ich bei allen per ISR ermittelten ADC-Werten keine Spikes mehr finden.
Die ADC-Werte der Tasten lassen sich mit dem Testprogramm allerdings nicht in den Daten nachweisen. Dass sie funktionieren, habe ich noch mit einem anderen Programm und dem korrigierten asuro_st.c getestet.
Ich gehe jetzt erst mal nach Hause. Mal sehen, ob ich heute noch am Asuro weitermache.
Gruß Sternthaler
Lieber Asuro programieren als arbeiten gehen.
Berechtigungen
Lesezeichen