Hallo,
nachdem ich mal alles durchblickt hab, wollte ich mal eine relativ simple Routine testen. Dafür habe ich mir den Linienfolger in der ersten Version aus dem repository ausgesucht. Leider bleibt der immer irgendwann hängen und behält seinen letzten Zustand bei. Also habe ich mal die Leds benutzt um mir jeden momentanen Zustand anzeigen zu lassen. Das hat mir leider auch nicht geholfen. Also mal ct-bot-test-analog.hex drauf geladen. Die anderen Sensoren scheinen bis jetzt noch nicht so richtig zu funktionieren aber die Linienerkennung funktioniert einwandfrei. Funktioniert der Linienfolger bei euch richtig und der Bot kann immer weiter fahren? Der Fehler ist leider sehr sporadisch. Mal läuft er 2-3min. manchmal aber auch nur Sekunden bis der Fehler eintritt. Dachte erst vielleicht würde ein Stack voll laufen aber das kann ich ausschließen oder?
Überlauf?
Hi,
also mit Version zwei fährt der Linienfolger endlos weiter, ich meine, das war bei Version eins und drei auch so, aber so ganz genau weiß ich das nicht mehr.
Wenn die Laufzeit (bei gleicher Linie) unterschiedlich ist, liegt es vermutlich eher an einem Hardware-Bug, als am Linienfolger.
Der Stack kann in den Heap (oder noch "weiter") wachsen, wenn zu viel RAM benötigt wird. Nach dem Build-Vorgang wird deshalb ausgegeben, wie viel Programmspeicher und RAM das übersetzte Programm belegt, poste doch bitte mal diese Daten und welchen Prozessor (mitgeliefert wird ein ATmega32) du auf dem Bot verwendest.
Es kann auch sein, dass dein Bot einen Hardware-Reset ausführt auf Grund einer instabilen Spannungsversorgung. Dagegen helfen die Hardware-Mods 3 und 4.
Ob es einen Reset gibt, kannst du recht einfach testen, indem du auf einen anderen Display-Screen umschaltest. Zeigt der Bot nach dem Fehler wieder den ersten Screen an, gab es vermutlich einen Reset.
Gruß,
Timo
also mit Version zwei fährt der Linienfolger endlos weiter, ich meine, das war bei Version eins und drei auch so, aber so ganz genau weiß ich das nicht mehr.
Wenn die Laufzeit (bei gleicher Linie) unterschiedlich ist, liegt es vermutlich eher an einem Hardware-Bug, als am Linienfolger.
Der Stack kann in den Heap (oder noch "weiter") wachsen, wenn zu viel RAM benötigt wird. Nach dem Build-Vorgang wird deshalb ausgegeben, wie viel Programmspeicher und RAM das übersetzte Programm belegt, poste doch bitte mal diese Daten und welchen Prozessor (mitgeliefert wird ein ATmega32) du auf dem Bot verwendest.
Es kann auch sein, dass dein Bot einen Hardware-Reset ausführt auf Grund einer instabilen Spannungsversorgung. Dagegen helfen die Hardware-Mods 3 und 4.
Ob es einen Reset gibt, kannst du recht einfach testen, indem du auf einen anderen Display-Screen umschaltest. Zeigt der Bot nach dem Fehler wieder den ersten Screen an, gab es vermutlich einen Reset.
Gruß,
Timo
-
SHS
Hallo,
erst mal danke für die Hilfe!
Ja er bricht bei gleicher Linie an unterschiedlichen Stellen ab.
Die Hardware Mods bin ich am einbauen. Zumindest liegen die Teile schon parat
Ich dachte aber eher weniger, dass es an der Hardware liegt, wenn die Test-Files laufen... Mein Bot ist leider noch von der älteren Generation ohne die Umbauten. Habe also kein Display, Kompass und was sich sonst noch so geändert hat. Eingesetzt ist der ATmega32. Falls es aber Resets wärn, würde sich doch der Bot um 45° drehen oder? Also die Drehung macht er schon mal nicht.
Das Eclipse so schlau ist wusst ich gar nicht
Guter Tipp! Dachte das bekomm ich wenn nur über die ct-bot.elf heraus. Aber wenn ich das richtig sehe sollte doch auch hier alles in Ordnung sein. Also kann ich von ausgehen, dass es ein Hardware Problem ist?
Hier noch der Teil der Ausgabe, welcher wohl von Interesse ist:
Post-build for AVR
avr-objcopy -O ihex -R .eeprom ct-Bot.elf ct-Bot.hex; avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex ct-Bot.elf ct-Bot.eep; avr-size -C --mcu=atmega32 ct-Bot.elf | grep "bytes"; avr-objdump -t ct-Bot.elf | grep "O \.eeprom" > eeprom_mcu.map
Program: 24514 bytes (74.8% Full)
Data: 728 bytes (35.5% Full)
EEPROM: 160 bytes (15.6% Full)
erst mal danke für die Hilfe!
Ja er bricht bei gleicher Linie an unterschiedlichen Stellen ab.
Die Hardware Mods bin ich am einbauen. Zumindest liegen die Teile schon parat
Ich dachte aber eher weniger, dass es an der Hardware liegt, wenn die Test-Files laufen... Mein Bot ist leider noch von der älteren Generation ohne die Umbauten. Habe also kein Display, Kompass und was sich sonst noch so geändert hat. Eingesetzt ist der ATmega32. Falls es aber Resets wärn, würde sich doch der Bot um 45° drehen oder? Also die Drehung macht er schon mal nicht.
Das Eclipse so schlau ist wusst ich gar nicht
Guter Tipp! Dachte das bekomm ich wenn nur über die ct-bot.elf heraus. Aber wenn ich das richtig sehe sollte doch auch hier alles in Ordnung sein. Also kann ich von ausgehen, dass es ein Hardware Problem ist?Hier noch der Teil der Ausgabe, welcher wohl von Interesse ist:
Post-build for AVR
avr-objcopy -O ihex -R .eeprom ct-Bot.elf ct-Bot.hex; avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex ct-Bot.elf ct-Bot.eep; avr-size -C --mcu=atmega32 ct-Bot.elf | grep "bytes"; avr-objdump -t ct-Bot.elf | grep "O \.eeprom" > eeprom_mcu.map
Program: 24514 bytes (74.8% Full)
Data: 728 bytes (35.5% Full)
EEPROM: 160 bytes (15.6% Full)
Hi,
Hast du denn am Code irgendetwas geändert / hinzugefügt?
Ich würde dir übrigens empfehlen, das Display zu ergänzen, weil es damit deutlich einfacher ist, den Bot zu debuggen.
Ja, wenn TEST_AVAILABLE_MOTOR an ist (sonst nicht), dreht sich der Bot bei jedem Reset ein Stück nach rechts und wieder zurück. Das kannst du natürlich genauso gut als Reset-Indikator nehmen, völlig richtig.SHS hat geschrieben:Ich dachte aber eher weniger, dass es an der Hardware liegt, wenn die Test-Files laufen... Mein Bot ist leider noch von der älteren Generation ohne die Umbauten. Habe also kein Display, Kompass und was sich sonst noch so geändert hat. Eingesetzt ist der ATmega32. Falls es aber Resets wärn, würde sich doch der Bot um 45° drehen oder? Also die Drehung macht er schon mal nicht.
Also da ist auf jeden Fall noch genug Platz im RAM für den Stack. Wenn es keine Resets gibt, sollte es aber auch kein Hardware-Problem sein.SHS hat geschrieben:Das Eclipse so schlau ist wusst ich gar nicht
Hast du denn am Code irgendetwas geändert / hinzugefügt?
Ich würde dir übrigens empfehlen, das Display zu ergänzen, weil es damit deutlich einfacher ist, den Bot zu debuggen.
-
SHS
Hallo,
also das war jetzt die Ausgabe von meinem selbst geschriebenen Linienfolger. Aber beim unveränderten passiert das gleiche.
Leider kann ich den Bot nicht um das Display erweitern. Der Bot war ein Fund im Labor welchen ich jetzt für eine Studienarbeit nutze.
Ich habe eben in einem älteren Beitrag von dem selben Problem gelesen. Titel: Bot friert ein. Da haben Sie geschrieben dass es auch an der falschen WinAVR Version liegen kann. Ich habe Version 20100110, wie auf der Seite der ct empfohlen. Sind da fehler bekannt?
Wo könnte ich noch nach Fehlern suchen?
Werde morgen die Hardware Mods einbauen und nochmal berichten.
also das war jetzt die Ausgabe von meinem selbst geschriebenen Linienfolger. Aber beim unveränderten passiert das gleiche.
Leider kann ich den Bot nicht um das Display erweitern. Der Bot war ein Fund im Labor welchen ich jetzt für eine Studienarbeit nutze.
Ich habe eben in einem älteren Beitrag von dem selben Problem gelesen. Titel: Bot friert ein. Da haben Sie geschrieben dass es auch an der falschen WinAVR Version liegen kann. Ich habe Version 20100110, wie auf der Seite der ct empfohlen. Sind da fehler bekannt?
Wo könnte ich noch nach Fehlern suchen?
Werde morgen die Hardware Mods einbauen und nochmal berichten.
-
SHS
Hallo,
das Problem ist gelöst! Vielen Dank nochmal!
Nachdem ich die Serielle Schnittstelle gegen Störungen gesichert hab, läuft er jetzt ohne Probleme. Jetzt habe ich nur leider noch nicht so ganz durchblickt was ich da eigentlich genau gemacht habe...Ist das die gleiche Schnittstelle mit der ich auch Programmiere? Habe ich da jetzt einfach WriteEnable oder sowas in der Art auf Masse gezogen damit nichts mehr empfangen werden kann?
das Problem ist gelöst! Vielen Dank nochmal!
Nachdem ich die Serielle Schnittstelle gegen Störungen gesichert hab, läuft er jetzt ohne Probleme. Jetzt habe ich nur leider noch nicht so ganz durchblickt was ich da eigentlich genau gemacht habe...Ist das die gleiche Schnittstelle mit der ich auch Programmiere? Habe ich da jetzt einfach WriteEnable oder sowas in der Art auf Masse gezogen damit nichts mehr empfangen werden kann?
Hi,
Wenn an der seriellen Schnittstelle nichts angeschlossen ist (wie ein USB-2-Bot-Adapter oder (W)LAN-Modul), hängt der Eingangspin in der Luft und wechselt ständig zwischen low und high hin und her. Das interpretiert der Prozessor u.U. als Eingangsdaten, die dann nicht verarbeitet werden können.
Ein Widerstand gegen Masse zieht den Pin auf (weak) low, solange nichts an der Schnittstelle angeschlossen ist. Damit hat der Eingangspin einen definierten Zustand (immer 0) und produziert keine (fehlerhaften) Eingangsdaten.
Gruß,
Timo
das ist schnell erklärt:SHS hat geschrieben:Hallo,
das Problem ist gelöst! Vielen Dank nochmal!
Nachdem ich die Serielle Schnittstelle gegen Störungen gesichert hab, läuft er jetzt ohne Probleme. Jetzt habe ich nur leider noch nicht so ganz durchblickt was ich da eigentlich genau gemacht habe...
Wenn an der seriellen Schnittstelle nichts angeschlossen ist (wie ein USB-2-Bot-Adapter oder (W)LAN-Modul), hängt der Eingangspin in der Luft und wechselt ständig zwischen low und high hin und her. Das interpretiert der Prozessor u.U. als Eingangsdaten, die dann nicht verarbeitet werden können.
Ein Widerstand gegen Masse zieht den Pin auf (weak) low, solange nichts an der Schnittstelle angeschlossen ist. Damit hat der Eingangspin einen definierten Zustand (immer 0) und produziert keine (fehlerhaften) Eingangsdaten.
Nein, außer du verwendest den Bootloader zum Programmieren.SHS hat geschrieben:Ist das die gleiche Schnittstelle mit der ich auch Programmiere?
Die serielle Schnittstelle hat bloß einen Eingang und einen Ausgang. Da es keine Enable-Leitung gibt, ist der Eingang immer "aktiv", wenn der Prozessor entsprechend konfiguriert ist.SHS hat geschrieben: Habe ich da jetzt einfach WriteEnable oder sowas in der Art auf Masse gezogen damit nichts mehr empfangen werden kann?
Gruß,
Timo