Algorithmen zur Bahnplanung

Druckbare Version

40 Beiträge dieses Themas auf einer Seite anzeigen

08.08.2008, 12:23
oberallgeier

Zitat:

Zitat von mare_crisium

...
2. ... Bei 10-Bit-Wandlung immer erst ADCL, dann ADCH auslesen (Abs 2, S.198). ...

Das Datenblattgerechte Auslesen sollte der Compiler erledigen. Auszug aus meiner *.lls :

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

Es wird also zuerst 0x0078, das lowbyte und danach 0x0079 gelesen.

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.
08.08.2008, 14:04
jeffrey

Zitat:

Zitat von oberallgeier

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.

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
09.08.2008, 03:51
Sternthaler

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
10.08.2008, 04:11
Sternthaler

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):

Zitat:

Zitat von mare_crisium

1. Frequenz der ADC-Wandlung tiefer als Auslesefrequenz

Auslesen erfolg nur im ADC-Interrupt nach der einen Wandlung.
Frequenz ist somit identisch.

Zitat:

Zitat von mare_crisium

2. Störfreies Auslesen nur, wenn zuvor vorheriges Ergebnis vollständig ausgelesen wurde

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.

Zitat:

Zitat von mare_crisium

3. ADMUX schaltet nie vor letztem Takt der laufenden ADC-Wandlung um

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.

Zitat:

Zitat von mare_crisium

4. Mess-Spannung höher als Vref

--> 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.

Zitat:

Zitat von mare_crisium

5. Versehentliche Anwahl von ADMUX-Kanal 0b1110=0x0E

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.
10.08.2008, 16:32
mare_crisium

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
10.08.2008, 18:02
oberallgeier

Hallo Ihr,

Zitat:

Zitat von mare_crisium

... Interrupts mit niedriger Adresse Vorrang vor denen mit höherer ... Ober sticht Unter...

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.

Zitat:

Zitat von mare_crisium

... Weil sich der freche Timer-Interrupt immer ...

... 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.

Zitat:

Zitat von mare_crisium

... radikales Abspecken der Interruptdienste gibt's dort jetzt viel weniger zu tun. ...

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] .
11.08.2008, 00:26
Sternthaler

Liste der Anhänge anzeigen (Anzahl: 2)

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:

Code:

if (! sens.aktiv & SENS_RAD) LED_RAD_OFF; // Sensor deaktiviert; Strom sparen

Man beachte den Kommentar!
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.
11.08.2008, 11:01
mare_crisium

Buon giorno, alle zusammen,

Zitat:

Zitat von oberallgeier

...Da sag ich jetzt mal ganz pingelig: bei den Interrupten sticht der Unter (die untere Adresse) den Ober...

da hast Du recht. - Es gibt offenbar noch Bereiche wo' anders läuft, als in der Firma :-). Und mit dieser Feststellung liegst Du auch goldrichtig:

Zitat:

Zitat von oberallgeier

...
b) Alle ISR müssen in kürzerer Zeit abzuarbeiten sein, als der kürzeste Interruptabstand...

@SternThaler,

prima, dass Du den Fehler gefunden hast: Ich meine, bei einem Befehl wie

Zitat:

Zitat von sternthaler

...LED_RAD_OFF...

= "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
11.08.2008, 13:10
oberallgeier

Hallo Sportsfreunde und asurofahrer,

Zitat:

Zitat von Sternthaler

... Nun ist folgender Stand erreicht: Alles ist gut ...

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.

Zitat:

Zitat von mare_crisium

... Dann bleibt uns nur zu hoffen, dass Oberallgeier (äusserlich!) trocken nach hause kam ....

Er kam.

Zitat:

Zitat von mare_crisium

... bei einem Befehl wie

Zitat:

Zitat von sternthaler

...LED_RAD_OFF...

= "LED-Rad-ab" ...

... und ich dachte, dass es dabei um eine persönliche Schreibweise von OFF_ROAD ginge.

@Sternthaler: nur um (pingeligerweise) ganz sicher zu gehen: die Spikes sind wirklich weg? Alle? Komplett (soweit Du es bisher kontrolliert hast)?

Zitat:

Zitat von Sternthaler

... Das mit cli(); und sei(); kann ich dir beschreiben, wenn du magst.

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.
11.08.2008, 20:30
Sternthaler

Hallo ihr Erfinder,

Zitat:

Zitat von oberallgeier

Zitat:

Zitat von mare_crisium

... bei einem Befehl wie

Zitat:

Zitat von sternthaler

...LED_RAD_OFF...

= "LED-Rad-ab" ...

... und ich dachte, dass es dabei um eine persönliche Schreibweise von OFF_ROAD ginge.

Ja, lacht ihr nur. Aber da kann ich zum Glück, vor allem über euren Reichtum an Alternativ-Funktionalität, natürlich mitlachen. :cheesy:

Zitat:

Zitat von oberallgeier

@Sternthaler: nur um (pingeligerweise) ganz sicher zu gehen: die Spikes sind wirklich weg? Alle? Komplett (soweit Du es bisher kontrolliert hast)?

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

40 Beiträge dieses Themas auf einer Seite anzeigen