[ERLEDIGT] Wer findet den Fehler, Belohnung

Liste der Anhänge anzeigen (Anzahl: 1)

Wer findet den Fehler, Belohnung

Ich komme einfach nicht weiter und finde den Fehler nicht, also wer den Fehler findet und den Roboter einwandfrei zum laufen bringt kriegt 50€.

Im Anhang der aktuelle Code, und der Referenzcode vom letzten Jahr mit alter Hardware. Aus dem Referenzcode von 2 mit I2C verbundenen Atmega1284 ist der aktuelle Code für einen Atmega2560 entstanden.

Nur letztes Jahr ist der Roboter einwandfrei gefahren (>200 Betriebsstunden), dieses Jahr nicht:mad:.

Fehlerbild:
Reagiert selten auf Bumper oder Schleifensensoren
Bei Vorwärtsfahrt wird auf einmal für 1/2s auf Rückwärts geschalten, dann wieder vorwärts weiter (normalerweise werden immer Pausen bei Richtungswechsel gesetzt damit die Fahrmotoren auslaufen können)
Während Messerstart fährt der Roboter auf einmal los
Im Fahren zeigt er auf einmal am LCD den Modus Zurücksetzen an, auch Speed für rückwärts wird gesetzt, fährt aber ohne Halt ruhig vorwärts weiter.

Was funktioniert: im Einzeltest eigentlich alles, Menüs funktionieren, Kompass geht, GPS kommt an, Daten gehen über Bluetooth raus, Messerdrehzahl wird eingeregelt, wird gestoppt wenn Messerdrehzahl zu niedrig ist, Sensoren und Bumper werden auch immer super erkannt:confused:. Auffällig nur bei Einzeltest Messerstart drehen sich dann auch die Fahrmotoren mit, was nie vorkommen sollte.
Für Einzeltests gibt es die Funktion testsbeieinschalten, die bei Tastendruck gleich nach dem Hauptschalter an ausgeführt wird.

Fuses:
Ext Crytall OSc 8- 65ms (16Mhz Quarz)
EESave on
Brownout 4.3V

Bootloader vorbereitet und getestet, derzeit nicht verwendet.
Akkuauswertung nicht verwendet da der LiIon ja defekt ist, verwende zum Testen einen anderen alten Akku.

Code ist noch großteils ins Spaghettiform, fange gerade an in einzelne Module aufzusplitten, aber das geht auch nur wenn es mal funktioniert, sonst baue ich vielleicht noch zusätzliche Fehler ein.
Vieles vom Code ist praktisch identisch zum Referenzcode, nur angepasst an zB neue Anzahl Impulse/Radumdrehung oder Umstellung von Winkel Radiant auf Grad und der Integration GPS/Bluetooth. Dafür ist der Datentransfer zum Slave entfallen.

Programmiert wird mit Atmel Studio 6.2

LG Werner

Es scheint mir das die ansteurung von die H-brucke fehl schlagt. Irgendwo has das Signal von Messer motor einfluss auf die Antriebsmotoren. Ich sollte erstmal in diese Richtung suchen. Hast du ein Schaltplan von das System ?

Motorsteuerung ist 3x diese: http://www.mikrocontroller.net/artic..._Mosfettreiber
Fahrmotoren haben Relais für die Fahrtrichtung nachgeschaltet.

Die Platine mit den Treibern war schon letztes Jahr im Einsatz und blieb unverändert. SD Pins haben Pulldown.

LG Werner

Ich hatte sowas ähnliches in meinen AVR-Programmen: Alle Module funktionierten im Einzeltest fehlerfrei, nach dem Flashen des Gesamtprogramms (in Assembler aus AVR-Studio 4.18 mit MKII) stürzte es aber aus unerfindlichen Gründen ab. Per Zufall habe ich dann gemerkt, dass die Stabilität des Programms von der Reihenfolge der .includes abhing, mit denen ich die Module einband. Das Gesamtprogramm funktionierte fehlerfrei, wenn ich das TWI-Modul als letztes einband.
Spiel' doch mal mit der Reihenfolge der includes. Fände es schade, wenn Dein soweit fortgeschrittenes Projekt noch scheitern sollte.
Ciao, mare_crisium

Na super, das wäre ein Compiler Fehler. Hatte schon mal so einen Verdacht als ich ein paar Zeilen Code 1:1 kopierte und nichts mehr ging. Habe deswegen extra auf das neue Studio 6.2 gewechselt.
Werde mit den includes herumspielen auch wenn es da 100erte mögliche Reihenfolgen gibt.

LG Werner

Spagetti Code ... nachträglich aufräumen ..... unwahrscheinlich....

Spagetti Code enthält meist ziemlich viele Fehler. Ich denke dass sich deine Module über Variablen die in mehreren Funktionen/Modulen verwendet werden stören.

Abhilfe: Sauberer Code von Anfang an.

Zitat:

Abhilfe: Sauberer Code von Anfang an

Das ist klar, aber nicht einfach wenn man bei Projektstart erst zu Programmieren anfing.

Jetzt den gleichen Funktionsumfang von Null weg zu starten wäre ein enormer Aufwand

Zitat:

enthält meist ziemlich viele Fehler

einen davon zu nennen wäre hilfreich!
Der Compiler ist extra scharf gestellt und meldet schon die AVR GCC Erweiterungen, aber keine echten Fehler.

Liste der Anhänge anzeigen (Anzahl: 1)

Hier sind ein paar Warnungen und Fehler rein über statische Analyse des Codes.

Anhang 30529

Unintialisierte Variable führen bsp. zu undefiniertem Verhalten. manchmal geht's .. Manchmal nicht ....

Hallo!

Zitat:

Zitat von damfino

Jetzt den gleichen Funktionsumfang von Null weg zu starten wäre ein enormer Aufwand.

Aus eigener Erfahrung: ich habe bisher sehr umfangreiche ASM Programme (praktisch wie bei Hochsprache) aus bis dahin archievierten geprüften Programteilen (z.B. Unterprogrammen basierten auf Programmablaufdiagrammen) sehr schnel gewünscht in neues Programm zusammen kopiert. Ich mache immernoch alles in kleinen leicht durchschaubaren Schritten und kenne "Spagetti Code" gar nicht. ;)

Bin nach längerer Zeit wieder zum testen gekommen:
1x Vollprogramm Atmelstudio 6.2 und 1x Vollprogramm mit dem letzten WinAVR:
WinAVR benötigt 200 Byte mehr SRam umd 5kB mehr Flash (gleiche Compiler Einstellung -0s) trotzdem in beiden Fällen starten die Fahrmotoren zu früh, und die Fahrtrichtung stimmt nicht mit der Anzeige (zb rückwärts) überein.

Dann das Programm auf das Minumum reduziert, Positionsberechnung weg, GPS weg, Bluetooth, diverse Fahrprogramme, Menüs, Daten im EEPROM etc. Er soll nur mehr Fahren, bei Hindernissen drehen und natürlich die Drehzahl der Fahrmotoren und Mähwerk regeln Mähwerk hat wie immer PI Regler, Fahrmotoren anstatt des Reglers auf feste Umrechung Vorgabe zu PWM umgestellt.

Anstatt 55kB Flash sind es noch 15kB (viele Texte fürs LCD), Ram nur 107Byte anstatt 4606Byte.
Aber immer noch gleich, bei Messerstart beginnen nach ein paar Sekunden auch die Fahrmotoren zu drehen, und die Drehrichtung wird nicht eingehalten. Display zeigt zurückfahren, Motoren drehen aber vorwärts.
Der Motortreiber ist der vom letztem Jahr, der Enable Eingang hat einen Pulldown damit bei zB Kabelbruch die Motoren sind eben nicht drehen.
Also geht diese Leitung auf high obwohl sie lt Code nicht gesetzt wird. Ebenso die beiden Leitungen für die Relais zum Fahrtrichtungswechsel, die werden beim zurückfahren oft nicht geschalten.

Beim Vollprogramm funktioniert GPS und Bluetooth auch bei laufenden Motoren, kann mir die Bluetooth Daten zum PC schicken. Also kann es kein totaler Programmausfall sein wenn diese Punkte funktionieren. Die Messerdrehzahl wird auch perfekt geregelt.
Die Bumper und Schleifensensoren werden im Voll und Minimalprogramm erkannt und am Display angezeigt. zB Bumper vorne erkannt, Anzeige am Display, es die Funktion zurückfahren ausgeführt, am Display der Fahrmodus für zurückfahren angezeigt, lt Anzeige ist die PWM Vorgabe an die Fahrmotoren bei korrekten 52%, nur die Motoren drehen fröhlich vorwärts weiter, gehen nie auf stop wie es bei den Richtungswechsel sein sollte...

Keine Ahnung wo ich noch suchen könnte, schön langsam denke ich eher in Richtung Hardware defekt da es nur die Steuerung der Fahrmotoren betrifft

Zitat:

... schön langsam denke ich eher in Richtung Hardware defekt da es nur die Steuerung der Fahrmotoren betrifft

Bei meinen Anfängen (Teillösungen zusammengeschnitten und auf einen Controller gebracht) hatte ich auch Probleme mit der Motorsteuerung.
Was half dann:
- Leitungstest Motorausgang vom Treiberbaustein zum Motoreingang auf Platine und Verdrahtung
- Leitungstest von Kurzschlüssen (Übersprechen) von einer Motorleitung zur andern
- GENAUE Inspektion der Schaltbefehle - also Testprogramm dass nacheinander für je 30 sec einen Motorpin nach dem andern schaltet - und das Ganze mit dem DMM nachverfolgen.
- Prüfung der PWM-Funktion statt Nur-Motorpinne-ein-aus
- GENAUE, aufmerksame (umständliche *gg*) Programmiererei, gut kommentierte Motoransteuerung, siehe Beispiel unten
- Zusammenbau der Grundfunktionen Motoransteuerung und NUR die in einem Test prüfen in der Art Mot1 vor, Mot1 zurück, Mot2 ...
- Die Motoren werden softwareseitig NUR über diese Funktionen geschaltet!!

Nur so, als (m)ein Beispiel - und das läuft und läuft. BTW: die Motoren werden softwareseitig NUR über diese Funktionen geschaltet!!

Code:

// ============================================================================= = // Motoransteuerung mit RN VN2 MotorControl, hier werden die Drehrichtungen gesetzt // Anschlüsse am mega1284 auf MoCo4 (eigne Platine, Stand Anfang Sep14 ) : // Motor12 ist in Fahrtrichtung rechts, Rad rechts vom Motor // Motor34 ist in Fahrtrichtung links, Rad links vom Motor // Motorbefehle: Mxxxxvor => Rad bewegt Gefährt VORwärts etc. // A C H T U N G : Motoranschlüsse der VN haben (+) "innen" und GND/(-) "aussen" // ############### ########## ############ // - - - - - - - - - - // XTAL1 PB6___9 20___VCC // XTAL2 PB7 10 19 PB5, SCK, _|-- 3,4 Guz // PD5 11 18 PB4, MISO // Mot12 _|-- 1,2 uz, PD6__12 17___PB3, MOSI, Reserve 2 // Mot12 _|-- 1,2 Guz, PD7 13 16 PB2, OC1B => PWM4 für Mot34 // Mot34 _|-- 3,4 uz, PB0 14 15 PB1, OC1A => PWM1 für Mot12 // - - - - - - - - - - - - - - - - - - - - - - - - - - // vgl. Erklärung von Hubert.G (zu L293D) // https://www.roboternetz.de/community/threads/59146 //-Wieso-benötigt-RN-Control-(1-4-)-für //-integrierten-Motortreiber-gleich-3-freie-Ports?p=558716&viewfull=1#post558716 // Zitat Mit Setzen von Kanal 1 und 2 auf 0 ist der Motor im Freilauf // Werden beide Kanäle auf 1 gesetzt wird der Motor gebremst // - - - - - - - - - - - - - - - - - - - - - - - - - - // ----------------------- // Drehrichtungsbefehle für Motor 1,2 = "rechter" Motor // r r r r r r r Motor 1,2 = rechter Motor r r r r r r // ============================================================================= = void Mrechtsvor (void) // Recht Mot12 dreht rechts=Uhrzeiger=math-negativ { // dann fährt recht. Rad "vorwärts" = Mrechtsvor TCCR1A |= (1<<COM1A1); // Clear/set OC1A on Cmp Match enabled 132 PORTD |= (1<<M11); // => 1; Setze M1-IN1 high PORTD &= ~(1<<M12); // => 0; Setze M1-IN2 low m12dir = 1; // m12dir ist positiv, weil Antrieb VORWÄRTS } // // ============================================================================= = void Mrechtszur (void) // ReMot12 dreht links=Gegenuhrzeigersinn=math-pos { // .. dann fährt rechtes Rad "rückwärts" TCCR1A |= (1<<COM1A1); // Clear/set OC1A on Cmp Match enabled 132 PORTD &= ~(1<<M11); // => 0; Setze M1-IN1 low PORTD |= (1<<M12); // => 1; Setze M1-IN2 high m12dir = -1; // m12dir ist negativ, weils Antrieb RÜCKWÄRTS } // // ============================================================================= = void Mrechtsaus (void) // Motor 12 aus { // TCCR1A &= ~(1<<COM1A1); // Disable clear/set OC0B on Compare Match OCR1A = 0; // PWM-Wert Mot12 auf Null setzen PORTD &= ~(1<<M11); // Setze M1-IN1 low PORTD &= ~(1<<M12); // Setze M1-IN2 low => beide low => Freilauf m12dir = 0; // } // // ============================================================================= = void Mrechtsbrms (void) // Motor 12 BREMSEN { // TCCR1A &= ~(1<<COM1A1); // Disable clear/set OC0B on Compare Match OCR1A = 0; // PWM-Wert Mot12 auf Null setzen PORTD |= (1<<M11); // Setze M1-IN1 high PORTD |= (1<<M12); // Setze M1-IN2 high => beide high => Bremsen m12dir = 0; // } // // ----------------------- // Drehrichtungsbefehle für Motor 3,4 = "linker" Motor // l l l l l l l Motor 3,4 = linker Motor l l l l l l // ============================================================================= = void Mlinksvor (void) // LiMot34 dreht im Gegenuhrzeigersinn = math. neg { // dann fährt linkes Rad "vorwärts" = Mlinksvor TCCR1A |= (1<<COM1B1); // Enable clear/set OC0B on Compare Match PORTC &= ~(1<<M41); // => 0; Setze M4-IN1 low PORTC |= (1<<M42); // => 1; Setze M4-IN2 high m34dir = 1; // m34dir ist positiv, weils Antrieb VORÄRTS } // // ============================================================================= = void Mlinkszur (void) // Linkr Mot34 dreht im Uhrzeig=math-pos. { // .. dann fährt linkes Rad "rückwärts" TCCR1A |= (1<<COM1B1); // Enable clear/set OC0B on Compare Match PORTC |= (1<<M41); // => 1; Setze M4-IN1 high PORTC &= ~(1<<M42); // => 0; Setze M4-IN2 low m34dir = -1; // m34dir ist negativ, weil Antrieb RÜCKWÄRTS } // ============================================================================= = void Mlinksaus (void) // Motor 34 aus { // TCCR1A &= ~(1<<COM1B1); // Disable clear/set OC1B on Compare Match OCR1B = 0; // PWM-Wert Mot34 auf Null setzen PORTC &= ~(1<<M41); // => 0; Setze M4-IN1 low PORTC &= ~(1<<M42); // => 0; Setze M4-IN2 low m34dir = 0; // } // // ============================================================================= = void Mlinksbrms (void) // Motor 34 BREMSEN { // TCCR1A &= ~(1<<COM1B1); // Disable clear/set OC1B on Compare Match OCR1B = 0; // PWM-Wert Mot12 auf Null setzen PORTC |= (1<<M41); // => 1; Setze M4-IN1 high PORTC |= (1<<M42); // => 1; Setze M4-IN2 high => beide high = Bremsen m34dir = 0; // } // // ============================================================================= = // Wahrheitstabelle für die Motoren gemäß VN2 und Drehsinn-Definitionen // #define M11 PD6 // M1-IN1 auf PD6 Motor 1 (12) weil er auf // #define M12 PD7 // M1-IN2 auf PD7 den Anschlüssen 12 liegt // #define M41 PC4 // M4-IN1 auf PC4 Motor 4 (34) weil er auf // #define M42 PC5 // M4-IN2 auf PC5 den Anschlüssen 34 liegt // - - - - - - - - - - - - - - - // MoRe "vor" =: Vorwärtsfahrt "rechts" =: Drehsinn Mot // Beispiel mot12 dreht mathematisch negativ bei Befehl "vor" = "rechts" // vor/re zur/li stop brems vor/zur = Rad-/Fortbewegung // M11= 1 0 0 1 re / li = Motordrehrichtung // M12= 0 1 0 1 // - - - - - - - - - - - - - - - - // MoLi =: Mot34, "vor/links" dreht Motor mathematisch positiv // vor/li zur/re stop brems vor/zur = Rad-/Fortbewegung // M41= 1 0 0 1 re / li = Motordrehrichtung // M42= 0 1 0 1 // - - - - - - - - - - - - - - - // ============================================================================= = // ===== ENDE Subroutinen ================================================= = // ============================================================================= =

Genau solche Funktionen habe ich ja:

Code:

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

Zitat:

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

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

Zitat:

Zitat von damfino

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

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

mfg

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!

Zitat:

Zitat von damfino

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

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

LG Werner

Liste der Anhänge anzeigen (Anzahl: 1)

Noch ein Versuch der Sache auf den Grund zu gehen:
Habe die Pins der Motorsteuerung am Atmega gewechselt, einfach mal um einen Defekt oder übersprechen vom Steuerung Mähmotor auf die Antriebsmotoren auszuschließen.

Erster Test: Alles natürlich angesteckt, aber noch die alten Motorpins konfiguriert: Fahrmotoren werden nicht angesteuert => Kein Übersprechen der Leitungen per Hardware.

Zweiter Test: Jetzt werden die richtigen Motorpins konfiguriert: Fahrmotoren laufen schon wieder bei Messerstart an, bei Rückwärtsfahrt wird schon nach 1s das Relais auf vorwärts geschalten, Anzeige am Display und PWM bleibt immer noch im Modus für Rückwärts.
Also Fehler wie immer, gleiches Verhalten im vollen und mini Programm.

Im Anhang das Mini Programm, braucht nur mehr 106 Bytes Ram, dass da der Stack übergeht kann man wohl ausschließen.

Wie schon erwähnt scheint alles andere zu funktionieren, auch bei Fahrfunktion Spiralfahrt wird die PWM der Motoren richtig geregelt, Bumper, Sensoren erkannt, zumindest lt Display daraufhin gedreht, etc.
Es sind nur diese 4 Ausgänge (2x Relais für Fahrtrichtung Rückwärts, 2x SD Enable am Motortreiber) die nicht richtig geschalten werden.
Könnte ja noch verstehen dass zB wegen Überlast der Ports die Relais nicht geschalten werden können und deswegen nach 1s die Relais abfallen, aber warum gehen die Enable Leitungen zum falschen Zeitpunkt auf high?

Braucht wer einen zu 99% funktionierenden Rasenroboter?? Erst 440 Betriebsstunden alt

LG Werner

Fehler lag in der Funktion Warten(); darin war eine Regelung etwas zu aktiv.