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.
Das ist klar, aber nicht einfach wenn man bei Projektstart erst zu Programmieren anfing.Abhilfe: Sauberer Code von Anfang an
Jetzt den gleichen Funktionsumfang von Null weg zu starten wäre ein enormer Aufwand
einen davon zu nennen wäre hilfreich!enthält meist ziemlich viele Fehler
Der Compiler ist extra scharf gestellt und meldet schon die AVR GCC Erweiterungen, aber keine echten Fehler.
alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)
Hier sind ein paar Warnungen und Fehler rein über statische Analyse des Codes.
Unintialisierte Variable führen bsp. zu undefiniertem Verhalten. manchmal geht's .. Manchmal nicht ....
Hallo!
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.Zitat von damfino
MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!
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
alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)
Bei meinen Anfängen (Teillösungen zusammengeschnitten und auf einen Controller gebracht) hatte ich auch Probleme mit der Motorsteuerung.... schön langsam denke ich eher in Richtung Hardware defekt da es nur die Steuerung der Fahrmotoren betrifft
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 ================================================= = // ============================================================================= =
Ciao sagt der JoeamBerg
Genau solche Funktionen habe ich ja:
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.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; }
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
alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)
Hmmm, schön zu sehen, dass andere ähnliche Softwareaufbauten haben.Genau solche Funktionen habe ich ja ... Bis dahin läuft alles korrekt ... Nur die Fahrmotoren nicht ..
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).
Ciao sagt der JoeamBerg
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
alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)
Fehler lag in der Funktion Warten(); darin war eine Regelung etwas zu aktiv.
alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)
Berechtigungen
Zitieren
Lesezeichen