Wer findet den Fehler, Belohnung

[damfino]

Genau solche Funktionen habe ich ja:

inline void Motor_re_ru(void)
{    M_rechts_Relais_ein; 
    _delay_ms(15);
    M_rechts_SD_ein;
    if (status_motor_re==M_stop)
        {
        status_motor_re=M_aktiv;
        status_motor_re_count=0;
        }
    
    }
inline void Motor_re_vor()
{    M_rechts_Relais_aus;
    M_rechts_SD_ein;
    if (status_motor_re==M_stop)
        {
        status_motor_re=M_aktiv;
        status_motor_re_count=0;
        }

}

inline void Motor_re_stop(void)
{
status_motor_re=M_stop;
M_rechts_SD_aus;
}


inline void Motor_re_faststop(void)
{
status_motor_re=M_stop;
M_rechts_SD_aus;
}

Erster Test mit neuer Hardware waren die Motoren, hatte ein eigenes Testprogramm erst linker Motor, dann rechter Motor, jeweils vor und zurück, mit verschiedenen PWM Werten, dann beide Motoren zusammen, etc. Funktioniert.

Nur werden jetzt die Motoren angesteuert obwohl diese Funktionsaufrufe nicht im entsprechendem Programmabschnitt enthalten sind.
Paradebeispiel Funktion Messerstart, seit 2 Jahren unverändert, dort werden zu Beginn die Fahrmotoren gestoppt. Dann erst der Messermotor gestartet, das kann ein paar Sekunden dauern bis der im Gras die Solldrehzahl erreicht. Dann wird noch ein paar Sekunden gewartet bis sich der Drehzahlregler eingeschwungen hat. Es kommen keine weiteren Funktionsaufrufe an die Fahrmotoren vor.
Trotzdem werden ca 3s nach Start des Messermotors auch die Fahrmotoren vorwärts aktiv.
Korrekt wäre abwarten der Solldrehzahl Mähantrieb, ca 2s warten, rückwärts fahren und dann nach links drehen.
Warum???
Bis dahin läuft alles korrekt.
Auch danach ist wie erwähnt GPS, Bluetooth, Messerdrehzahl, Erkennung Bumper usw korrekt. Nur die Fahrmotoren nicht.

LG Werner

[oberallgeier]

Genau solche Funktionen habe ich ja ... Bis dahin läuft alles korrekt ... Nur die Fahrmotoren nicht ..

Hmmm, schön zu sehen, dass andere ähnliche Softwareaufbauten haben.

Andere Sichtweise. Ich hab mal in den Parametertabellen nachgesehen: die 1284er haben 128 K Flash, 4K EEPROM und 16K (!!) SRAM - JEDER, der 2560er hat 256 K Flash, 4 K EEPROM und 8 K SRAM. Fazit: früher insgesamt 32K SRAM, jetzt 8 K.

Warum ich das nachlese? Es war, glaub ich, Hubert.G der mich mal an Stack und so erinnert/hingewiesen hatte. Das war mein Übergang von 328ern auf 1284er *gg*.

So - nun bei Dir. Was meint der Compiler in der Speicherplatzstatistik? VIELLEICHT könnte es ja sein, dass Du bei dem Zusammenschluss der zweimalsechzehn K SRAM auf 1x8 K SRAM ein bisschen in die Enge gekommen bist? Ich habe zwar keine wirkliche Kenntnis über Speicherplatzverbrauch des Stacks - aber der eben genannte Hinweis meinte, dass in der Gegend von 80..90% SRAMVerbrauch der Platz für den Stack eng würde. WENN das so wäre, könntest Du ja die LCD-Meldungen ins EEPROM auslagern.

Nachtrag: LCD-Ausgaben hat der Teufel erfunden. Ich habe bei mir etliche gekürzt oder ganz gestrichen, weil das LCD soooo lange braucht bis es Daten übernimmt ! ! ! Das führte bei mir in wenigen Fällen zu massiven Störungen meiner interruptverseuchten Codes. Vor allem wohl weil ich solche Ausgaben auch in ISR habe (brrrrrrrrrrrrrrrrrrrr).

[damfino]

Mit Ram wird es eng, stimmt. Fix sind 4600 Byte, bei A-Stern Berechnung kommen nochmal 3x800 Byte dazu. Lasse mir mit Mem-chec den freien Speicher laufend ausgeben, bisher waren >3kB frei (zum Fahren nach A-Stern ist er dieses Jahr nie gekommen). Der Hauptkontroller von den 1284 hatte 9kB frei, der andere benötige nur ein paar Bytes, damals wichtig waren vor allem die 2 Uarts des 1284. Sonst wäre ich gar nicht auf den 2560 umgestiegen.
Vor allem mit der Miniversion vom Code die nur 107 Byte Ram benötigt sollte so ein Stack Fehler nicht mehr auftreten.

In den ISR kommen die PI Regler vor, aber keine LCD Ausgaben

[oberallgeier]

Mit Ram wird es eng, stimmt. Fix sind 4600 ... nochmal 3x800 Byte dazu ... 1284 hatte 9kB frei ...

Ok, dann sind wir bei satt 7K SRAM, evtl. deutlich drüber - der Controller wird irgendwas bei 10..12% errechnen. Eine Onlinemessung des RAMbedarfs - hmmm, ob ich der glauben kann? Denn wenns da mal ein paar hunderstel Sekunden zuu knapp wird - - kannst oder könntest Du das erkennen? Ich habe so etwas nie gemacht, weiß also nicht Bescheid.

Neu :
- Wieviel ISR laufen denn so ?
- Wie sieht der Zeitbedarf aller ISR insgesamt aus (der worst case *ggg*). Evtl. mit LED an bei Beginn und off beim Ende - für jede ISR gesondert; den Overhead halt dazuschummeln - siehe *.lls. ODER aus der *.lls den Zeitbedarf rausrechnen (LED sind für mich "einfacher").
- Hast Du nested Interrupts?
- Regelfrequenz (also Zeitablauf von beiden Regelroutinen - MOTre und MOTli) ? Laufen die ISR zur Motorregelung wenigstens "auf Lücke" - also ENTWEDER die ISR-li ist aktiv oder die ISR-re. Dann dauert ein Regelvorgang nicht sooo lang.

Hmmm - meine Fragen und Ratschläge klingen mir nu nicht wirklich planvoll, aber ich habe ein paar solche Abenteuer hinter mir und eigentlich immer geschafft (Komplex ist aktuell Archie - ein Hauptcontroller - I²C-Master, aktuell vier I²C-Sklaven und zwei UART-Satelliten, die Slaves haben selbst noch "Satelliten").

[Wsk8]

Der 2560 hat ein JTAG-Interface! Und der Debugger ist nach dem Compiler dein 2t bester Freund.

mfg

[damfino]

ISR:
Timer 3: alle 10ms
Messerdrehzahl: max 200 Impulse/s, Regelung in ISR von Timer 3 alle 0.25s
2x Fahrmotoren je max 166 Impulse/s, Regelung in ISR von Timer 3 alle 0.125s, Regelung beider Fahrmotoren gleichzeitig aber zeitlich versetzt zu Messerdrehzahl
1 UART über ISR bei 9200Baud
1x Kontrolle vom Vorderrad, ca 2 Impulse/s

I2C und zweiter UART werden gepollt.

Ich hatte die Zeiten im Simulator gemessen, bzw Anzahl der Takte verglichen. Die Regelungen und 90% aller Funktionen sind unter 1ms erledigt. Die Positionsberechnung liegt bei 2.7ms.
Bis auf 2 mathematischen Operationen sind alle in Fixkommaarithmetik.
Wirklich lange (bis 1-3s) dauert die A-Stern Berechnung, da wird der Roboter gestoppt.

Timer 3 regelt alle zeitkritischen Funktionen, dort werden Flags gesetzt wann die Messerdrehzahl, die Fahrmotoren, Daten über Bluetooth raus, oder wann die Odometrie berechnet wird, praktisch der Taktgeber fürs gesamte Programm.
Standard Zeiteinheit dafür ist 0.25s, dh 1x in 0.25s werden alle regelmäßigen Funktionen abgearbeitet. Ausgenommen Fahrmotoren mit 0.125s und Positionsberechnung mit 1s. Aber auch die haben ihr freies Zeitfenster im 0.25s Abschnitt.

Da ist noch einiges an freier Rechenleistung übrig.



Debugger ist leider keiner vorhanden, bisher kam ich immer mit Anzeigen im LCD und setzen der LEDs als Ablaufkontrolle aus.

LG!

[oberallgeier]

... Da ist noch einiges an freier Rechenleistung übrig ...

Klingt gut - ausser, dass es nicht so läuft wie es soll. Zumal ich da meine Bedenken hatte, weil der 2560 nur mit 16 MHz kann, der 1284er dagegen mit 20 MHz. Also 25% mehr Tempo.

Dumme Frage: MUSS denn der 2560er sein? Wenn die "alte" Version mit I²C und zwei 1284ern störungsfrei läuft und der Umbau auf eine Platine nicht klappt - und diese ziemlich zähe Fehlersuche - da würde ich bei der Zwei-Platinen-Lösung bleiben. Nebenher (während der Robby läuft) kannst Du ja die Sache vielleicht interessehalber mit zwei Minimotörchen weiter treiben. "Vieles vom Code ist praktisch identisch zum Referenzcode..." - kenn ich auch. Und dann läufts nicht wie "immer". Sorry, dass ich momentan keine Idee habe wie es weitergeht.

Jedenfalls viel Erfolg. Sozusagen mit einer oder mit zwei Platinen.

Nachtrag zum letzten Post:
UART pollen dauert mir viel zu lange, nochdazu mit 9600 Bd. ISR mit FIFO und Ringspeicher für RX und TX, läuft bei mir vom 328er zum 1284er selbst mit 1,25 MBd (UBRR = 1) - weil beide mit 20 MHz tickern und da wirken sich Zeitfehler nur in der Höhe der Quarztoleranzen aus *gg*.

[damfino]

Die 2 Stück 1284 hatten ein paar Nachteile:
1) Der Datenaustausch wurde immer umfangreicher und bremste schließlich das System aus. So ist vorgesehen das man den Roboter übers Tablet/Smartphone fernsteuern kann. Mit den zusätzlichen Daten wäre es kritisch geworden
2) Konnte nicht so viel wie erwartet auf den 2. Kontroller auslagern, erstens wegen Punkt 1 noch mehr Daten, zweitens hatte ich sicherheitskritische Bereiche wie Motorsteuerung lieber direkt angesteuert. Wenn man den Motor stoppen will und gerade dann geht das I2C nicht ist es weniger lustig.
3) Debuggen vom Hauptkontroller war sehr schwer, der hatte direkt nur 2 Leds, die LCD Anzeige lief über den Nebenkontroller. Es waren zwar schon einige Standard Debug Anzeigen vorgesehen, aber es fehlte immer etwas.

Bei einem großen Kontroller geb ich einfach eine Zeile für LCD Ausgabe rein und fertig, muss nicht jedesmal 2 Programme aufeinander abstimmen.
Es war eigentlich nur eine Zwischenlösung da mir die Pins ausgegangen sind, und die liefen beide auch nur mit 16Mhz.
Die Arduino Platine war dann auch billiger als der Neukauf der 1284.

Zurückgehen auf den alten Stand hatte ich mir schon überlegt, müsste die alte Platine aber erst reparieren.
Wahrscheinlich liegt der Fehler an irgendeiner Kleinigkeit

LG Werner