ASURO bidirektionale IR Kommunikation Problem

[izaseba]

Hallo stochri,
ja AVR-Studio ist für Assembler gedacht, Du wirst zwar Deine .hex Dateien einlesen und Debuggen können, aber nur im Assembler, es zeigt Dir kein C Code.
Und Insight ist nur ein Frontend für gdb dem Du wiederum simulavr als Target angeben mußt, aber das hast Du schon gemacht, wie ich gelesen habe.

Zu deinem Script unter Linux, das geht ganz einfach, leite die Ausgabe einfach mal auf den /dev/ttyS0 um in etwa so : echo 0x20 > /dev/ttyS0 , hiermit hast Du Leerzeichen an die Serielle Schnittstelle gesendet.

Andersherum ist es ja genauso einfach : cat /dev/ttyS0 >> logfile , hiermit empfängst Du alles was über /dev/ttyS0 ankommt und speicherst es in logfile.
Du kannst es auch über ein Pipe mit z.B grep verbinden oder weiß was ich, es gibt viele Möglichkeiten das in der Bash auszuwerten.

Eventuell mußt Du noch am Anfang die serielle Schnittstelle mit stty auf die Baudrate usw. einstellen.

Gruß Sebastian

[Archi]

Hallo zusammen,

also soweit ich weiß ist in der Flash-Soft oder -Firmware kein User-Timeout nach 4 Studen drin - 8 Stunden wären ja auch das mindeste. Dass bei der Übertragung ein Fehler nicht entdeckt wird ist natürlich möglich (pro Seite ein 16 bit CRC) aber unwahrscheinlich und ist mir (auch im Rahmen vom School_Lab) noch nie nachweislich passiert.
Einige Theorien:
* Der Resonator driftet nach einer Weile bei Temperaturerhöhung weg. IOst aber kleiner 0.1% und sollte nciht stören.
* Durch leichte Veränderungen der Batteriespannung ändert sich die Empfindlichkeit des IR-Empfängers
* Windoof wird bei dauerndem Betrieb immer langsamer, sodass es häufiger zu Verzögerungen in der Datenübertragung kommt.

CU, Robin

[stochri]

Izaseba:
Zu deinem Script unter Linux, das geht ganz einfach, leite die Ausgabe einfach mal auf den /dev/ttyS0 um in etwa so : echo 0x20 > /dev/ttyS0 , hiermit hast Du Leerzeichen an die Serielle Schnittstelle gesendet.
Andersherum ist es ja genauso einfach : cat /dev/ttyS0 >> logfile , hiermit empfängst Du alles was über /dev/ttyS0 ankommt und speicherst es in logfile.


Hallo Izaseba,
Vielen Dank für den Tip. Beim Empang hätte ich die Frage, ob es möglich ist, nur ein Zeichen zu empfangen, mit "at /dev/ttyS0 >> logfile" Bleibt das Scribt ja im Empfangsmodus hängen.
Das Scribt müßte aber in einer Art while-Schleife immer wierder ein Zeichen an den Asuro senden und dann auf das Empfangszeichen warten.

Gruss,
Stochri[/i]

[izaseba]

Hallo Stochri,
In der Tat, kann man sich mit cat /dev/ttyS0 die Daten anzeigen, die an der seriellen Schnittstelle ankommen, aber für Deine Zwecke ist es eher ungeeignet
Ich glaube, daß bei cat EOF am Ende stehen muß, damit es beendet wird.


Was hälst Du davon, das in C zu schreiben ?
Bei Linux ist es ja wohl kein großes Problem, wenn Du Anregungen brauchst, wie das geht, kann ich Dir ein paar Schnipsel zukommen lassen.

Gruß Sebastian

[stochri]

Hallo Archi,
vielen Dank für Dein Angebot mit den Codeschnipseln. Ich habe auch schon daran gedacht, sowas in C zu probieren. Aber dann kam mir die Idee mit dem Scriptfile. Ich hätte gedacht, dass es damit auch gehen müsste und es ja wesentliche einfacher zu debuggen wäre.
Die nächste Zeit werde ich mich wohl nicht mit dem Problem beschäftigen können, aber vielleicht werde ich noch auf Dein Angebot zurückkommen.

Beste Grüße,
Stochri

[neoeon]

Hallo zusammen,

8 Stunden wären ja auch das mindeste.
Dass bei der Übertragung ein Fehler nicht entdeckt wird ist natürlich möglich (pro Seite ein 16 bit CRC) aber unwahrscheinlich und ist mir (auch im Rahmen vom School_Lab) noch nie nachweislich passiert.

CU, Robin

Hmm, mir ist schonmal sowas in der Richtung passiert, als ich meinen ASURO zusammengebastelt hatte.
Der Selbsttest war gerade zu meiner reinsten Freude komplett erfolgreich, und ich habe ein Testprogramm geschrieben, aber das flashen dauerte, und es gab keine Seite die nicht mit ein paar c und t wiederholt werden musste.

Irgendwann gings dann doch, aber keins der Programme lief, der ASURO bootete zwar, aber führte das Programm nur zur hälfte oder garnicht aus (endlosschleifen, komische Effekte usw.)

Die Ursache war, dass ich in meiner Freude keine frischen Batterien, sondern halbvolle benutzt habe. Mit richtig vollen Batterien ging das flashen dann auch besser. --> Bei halbvollen Batterien, (oder eher viertel-leeren) kann nach genügend Wiederholungen ein Fehler durch den CRC rutschen .... denke ich

(natürlich ist auch nicht ganz ausgeschlossen, dass der uC mit der Batteriespannung nicht richtig gearbeitet hat, aber das glaube ich nicht so recht - weil die Kontroll-LED zumindest grünes Licht gegeben hat)

[stochri]

Hallo neoeon,
bei mir gibt es eigentlich immer irgendwelche c's und t's, seltsamerweise gehäuft beim 2.ten Block. Falls das Programm nach dem Flashen nicht läuft, habe ich mir angewöhnt, das ganze einfach noch mal zu wiederholen, dann geht es oft. Beim Batteriewechsel hatte ich auch schon den Eindruck, dass es etwas besser geht.

Gruss,
stochri