Archiv verlassen und diese Seite im Standarddesign anzeigen : ASURO bidirektionale IR Kommunikation Problem
Hallo Miteinander,
ich habe ein kleines Testprogramm für eine schnelle bidirektionale Kommunikation zwischen ASURO und PC geschrieben.
Drückt man die Space-Taste im Terminalprogramm, liefert der ASURO bei jedem Dastendruck einen aufsteigenden Zählerwert zurück. Wird eine andere Taste gedrückt, schickt der Asuro das Zeichen 'E' für Error zurück.
Beim Einschalten des Asuro meldet sich der Asuro mit
-- ASURO Ready --
Connection OK
und jetzt das Problem:
sendet man die Einschaltmeldungen 3 Mal hintereinander, hängt sich der ASURO auf. Ich habe alles probiert, aber jetzt fällt mir nichs mehr ein. Gibt es Probleme mit dem mitgelieferten Makefile ? Ich habe keine Idee mehr.
Hier das Programm:
#include "asuro.h"
typedef unsigned char byte;
/************************************************** *****************************
Kommandos zur Ansteuerung der Test-LED
************************************************** *****************************/
void toggle_led()
{
static byte k=0;
if (k==0)
{
StatusLED(GREEN);
k=1;
}
else
{
StatusLED(YELLOW);
k=0;
}
}
void blink_led(byte n)
{
int k;
do
{
for (k=1;k<10000;k++); /* Verz�erung */
toggle_led();
}while(n--);
}
void chputchar(byte zeichen)
{
UCSRB = 0x08; // enable transmitter
UCSRA=UCSRA | TXC; // clear transmitter flag
while (!(UCSRA & 0x20)); // wait for empty transmit buffer
UDR = zeichen;
while (!(UCSRA & 0x40));
}
byte receive()
{
byte c;
/* Warten auf ein Zeichen von der seriellen Schnittstelle */
// c=ser_getchar();
SerRead(&c, 1, 0);
toggle_led();
return c;
}
void send(byte zeichen)
{
SerWrite(&zeichen,1);
// chputchar(zeichen);
}
#define TEST 0x20 /* Space als Testzeichen */
unsigned int uiBuffer[10];
int main(void)
{
byte command,n;
byte temp=0,temp2,temp3;
Init();
SerWrite("\n\r-- ASURO Ready --\n\r",21);
SerWrite("Connection OK\n\r",15);
// SerWrite("\n\r-- ASURO Ready --\n\r",21);
// SerWrite("Connection OK\n\r",15);
// SerWrite("\n\r-- ASURO Ready --\n\r",21);
// SerWrite("Connection OK\n\r",15);
while(1)
{
/* Warten auf ein Kommando der seriellen Schnittstelle */
command = receive();
switch(command)
{
case TEST:
{
/* sehr ntzliches Testkommando, sendet bei jedem 'Space' drcken
einen um Eins erh�ten Wert */
send(n++);
}
break;
default:
{
StatusLED(RED);
send('E'); /* Falls kein bekanntes Kommando, 'E' fr Error senden */
}break;
}
}
return 0;
}
Arexx-Henk
18.06.2005, 15:10
Hallo stochri
Ich hab dein program ausprobiert, bei mir das gleiche problem.
Dann hab ich die zeile
SerRead(&c,1,0);
erzatzt durch
c=4;
Und da gings gut.
Wenn ich spater dein original program wieder compilierte lief dass AUCH OHNE PROBLEME!!! Vielleicht war die bestimmte Zeile nicht die Uhrsache.
Jeztz zerbricht mir die Klumpe. (Hollandische Aussage...)
Die Akku-spannung betragt 5.0V wenn ausgeschaltet und 4.5V wenn eingeschaltet.
Die IR-empfanger functioniert nur ab 4.5V.
Damit ist es vielleicht ein Akku problem aber ich bin mir nicht sicher denn bei mir sendete der Asuro am anfang nur eine vom 3 begrussungszeilen und dass senden sollte doch unabhangig vom IR-empfanger sein.
Gruss,
Henk (such mir ein anderen hobby...) :mrgreen:
Hallo Storchi,
dein ASURO ist einer von AREXX, also mit blauer Platine und nicht eine der limitierten Uralt-Versionen aus den School_Lab mit grüner Platine, oder?
CU, Robin
Und nochmal:
habe die Software inzwischen mal getestet. Klappt einwandfrei, auch mit 3x Statusmeldung schicken. Hab's aber nur unter Linux ausprobiert. Wie äußert sich das "Aufhängen" denn?
CU, Robin
Hallo Arexx Henk, hallo Archi,
vielen Dank für eure Kommentare.
Mein Asuro Platine ist Blau. Heute habe ich die beiden Programmversionen noch einmal geflasht.
Nach dem ersten Flashen mit der Version 1 kam die Begrüßungsmeldung der Asuro ist aber ca. sekündlich in einen Reset gefallen und hat die Begrüßungsmeldung dann wieder geschickt.
Danach habe ich genau die selbe Version noch einmal geflasht und sie hat einwandfrei funtktioniert.
Dann habe ich die Version 2 geflasht und sie hat im Gegensatz zu gestern auch einwandfrei funktioniert.
Ich habe meine Batteriespannung überprüft ( NiMh Accus, Fabrikat Emmerich 700mAh ) 5.11 Volt im Leerlauf, 5.08 V bei laufendem Programm. Dann habe ich den Akkujumper abgezogen, die ASURO Spannung ist dann auf 4.35 V das Programm hat aber immer noch einwandfrei funktoniert.
Hier meine Thesen:
- Das ASURO System besitzt eine eingebaute Sperre für überarbeitete Bastler, wenn man sich länger als 4 Stunden damit beschäftigt geht das Flashen nicht merhr
- wird der Flash-Speicher innerhalb von 1 Stunde 10 mal reprogrammiert, brauch er einen Tag Erholung
- Die Fehlerkorrektur der IR-Datenübertragung für die Flash-Daten arbeitet nicht zuverlässig und der ASURO merkt nicht, wenn er falsche Daten programmiert.
- Der Bastler arbeitet nach 4 Stunden selber nicht mehr zuverlässig und macht Fehler, die er selbst nicht merkt.
Beste Grüße,
Stochri
zur Nomenklatur:
Version 1: Ausgabe der Begrüßungmeldung einmal
Version 2: Ausgabe der Begrüßungsmeldung dreimal
By the way: Kennt sich von euch jemand mit dem AVR-Simulator aus ?
linux_80
19.06.2005, 10:52
Hier meine Thesen:
- Das ASURO System besitzt eine eingebaute Sperre für überarbeitete Bastler, wenn man sich länger als 4 Stunden damit beschäftigt geht das Flashen nicht merhr
- [....]
das ist mir auch schon aufgefallen, nach stundenlangem flashen ohne probleme, anfangs fast keine c und t's, machts anscheinend irgendwo click (evtl. auch nur virtuell) und das flashen geht nicht mehr, es hilft nur den ASURO stromlos (Batterie raus) in die Ecke zu stellen, und auch das IR-modul vom PC abzustecken, nach 'ner Stunde, früher hab ich's noch nicht probiert, gehts dann wieder :-k
Hallo,
Kennt sich von euch jemand mit dem AVR-Simulator aus ?
Welchen Simulator meinst du?
AVR-Studio für Windows, oder avr_simulator für Linux?
Das erste ist gut (wobei ich es nicht so oft benutze, weil ich kein Win hab) und das zweite ist zum abwinken, der Entwickler hat wohl kein Bock mehr drauf, schade
Gruß Sebastian
Hallo linux_80,
sehr interessant, dass Du ähnlicher Erfahrungen gemacht hast. Allerdings hätte ich da die Frage, ob sich nur die c's und die t's häufen, oder ob der Programmiervorgang am Schluss als erfolgereich abgeschlossen angezeigt wird und das Programm dann ein seltsames Verhalten an den Tag legt.
Das würde nämlich darauf hindeuten, dass die Fehlererkennung der Programmübertragung unzuverlässig arbeitet.
Gruss,
Stochri
Hallo Izaseba,
unter Windows habe ich den Gnu-Simulator beschrieben wie in
https://www.roboternetz.de/phpBB2/viewtopic.php?t=10205
ausprobiert.
Das AVR-Studio von Atmel geht meines Wissens nach nur für Assembler. Oder kann man beim Debugging auch C-Sourcecode debuggern ?
Gruss,
Stochri
Noch eine Linux Frage, falls sich jemand damit auskennt:
Ich würde gerne als Gegenstück zum Programm am Anfang dieses Threads ein Scriptfile zur Kommunikation mit dem ASURO benutzen.
Das Scribt müsste ein Zeichen ('Space')über die serielle Schnittstelle senden dann eines Empfangen, abspeichern
... und dann das ganze immer wieder wiederholen ...
Weiss jemand wie das geht ?
linux_80
19.06.2005, 19:49
@stochri,
bei mir hats dann immer ganz abgebrochen, den Fall, dass das flashen durchgelaufen ist, und trotzdem nicht ging hatte ich noch nicht.
Ich hatte da mal ein Progamm gebraten das laut Flash ca. 50 Seiten hatte, nach den paar Stunden fings dann etwa ab Seite 26 an mit c und t's bei ca. 28 wars dann vorbei.
Ich hab ja auch noch den USB-adapter, damit gings da dann auch nicht.
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
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
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]
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 :-b
Ich glaube, daß bei cat EOF am Ende stehen muß, damit es beendet wird.
:-k
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
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
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)
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
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.