Hallo Zusammen,
Ich habe ein kleines Programm, das über UART eine Anfrage schickt und
diese Empfangen soll, klappt auch soweit, zu mindest mit den einzelnen
Bytes.
Mein UART Slave schickt die daten so:
0x06,0x00,0x02,0x43,0x34,0x31,0x33,0x03
(0x06 ACK, 0x02 = STX , 0x03 = ETX, etc)
Die einzelne Ausgabe funktioniert auf UART1 da kann ich alles lesen,
sobald ich aber die Daten in einen Buffer schreibe, kommt auf dem UART1
aus dem Buffer nur müll und wirre zeichen.
Die While-Schleife wird korrekt beendet, da alle Zeichen empfangen und
ausgegeben werden.
Aber ich möchte meine Empfangenen Daten in einem String haben und weiter
verarbeiten können, was so nicht funktioniert. In diesem Falle sind die
Daten einfach nur Zahlen.
Ist das denn so überhaupt korrekt?
Das wär die nächste Frage gewesen: und wo wird count erhöht.
Es macht relativ wenig Spass, wenn du nicht den Code postest, der
tatsächlich läuft. Denn dann suchen wir nicht existente Fehler.
Hast du auch aus deinen Charactern einen String gemacht, indem du noch
ein '\0' anhängst? Oder ist das auch wieder in deinem richtigen Code
enthalten und nur hier im Forum sehen wir das nicht?
Ja, wenn die gelesene Daten mit 0x06,0x00,0x02 anfangen wirst du nicht
viel sehen da:
1) 0x00 den auszugebenen String terminiert
2) 0x06 und 0x02 non-printable ASCII sind.
Das ist mein ganzer Code den ich habe, nein die Daten kommen so wie Sie
mir von der Fleury übergeben werden in den Buffer, da ich in meinen
Daten ein NULL Charakter habe, ist der denn nötig um den Buffer zu
füllen?
Ich möchte mir ja nur den Buffer als ganzes ausgeben, anstatt in Bytes..
Grüße,
Daniel
Eric B. schrieb:> Ja, wenn die gelesene Daten mit 0x06,0x00,0x02 anfangen wirst du> nicht viel sehen da:>> 1) 0x00 den auszugebenen String terminiert> 2) 0x06 und 0x02 non-printable ASCII sind.
Jupp ist mir klar, die sehe ich lediglich im hTerm und im Logic Analyzer
:-)
Aber da sind ja auch Zahlen wie auch printable ASCII Codes drin
Was passiert mit count nach 32 Zeichen? Es wird nur einmal am
Programmanfang mit 0 initialisiert. Wäre es nicht sinnvoller, das nach
dem Senden von buffer erneut zu machen? So zeigt buffer[count] sehr
schnell ins Nirwana.
Georg G. schrieb:> Was passiert mit count nach 32 Zeichen? Es wird nur einmal am> Programmanfang mit 0 initialisiert. Wäre es nicht sinnvoller, das nach> dem Senden von buffer erneut zu machen? So zeigt buffer[count] sehr> schnell ins Nirwana.
Hallo,
Ja ist schon klar das es sinnvoller ist, Problem ist aber das im Buffer
nur Mist steht, der Counter bleibt immer unter 32, da die Länge nicht
größer wie 16 Bytes wird und nur einmal aktuell zum test gesendet wird.
Aber ich ändere das gleich im Code :-)
Mach doch (wie von Eric bereits gesagt) noch kleine Änderungen:
IST
Buffer[count] = (unsigned char)response;
WIRD
Buffer[count] = (unsigned char)(response & 0xff);
Dann bist du sicher, dass der "Flag Anteil" von response sauber
abgetrennt wurde.
IST
> if(response == ETX)> break;
WIRD
if(response == ETX) {
buffer[count] = 0x00;
break;
}
Dann hat uart_puts() ein sauberes String Ende.
Und zeig doch mal, was du als Ausgabe bekommst. Ist die Ausgabe immer
die gleiche?
So, mein hTerm sagt mir folgendes:
45 6D 70 66 61 6E 67 65 6E 0D 0A => Empfangen<\r><\n>
Mit NICHT auskommentiertem (uart1_putc((unsigned char) response)):
00 02 43 34 31 33 34 30 33 35 34 32 30 44 03 => <\0><2>C4134035420D<3>
Sobald es aber aus dem Buffer kommen soll, kommt mit dem Code jetzt
aktuell nichts mehr...
Hallo,
So bin etwas weiter gekommen, habe nun ein bischen hin und her debuggt,
das Problem an der Ausgabe des Buffers liegt wohl an dieser Funktion:
1
void uart1_puts(const char *s)
2
{
3
while(*s)
4
uart1_putc(*s++);
5
}
Wenn ich anstatt uart1_puts(Buffer); / uart1_putc(Buffer[3]) ausführe,
kriege ich ein C in Putty.
Dann fiel mir beim durch steppen auf, das in der puts funktion
uart1_putc niemals erreicht wird.
grübel
>Dann fiel mir beim durch steppen auf, das in der puts funktion>uart1_putc niemals erreicht wird.
Buffer selber plattgemacht würde ich da mal behaupten;)
if(response == ETX)
{
count = 0;
Buffer[count] = 0x00;
Dani schrieb:> Hallo,>> So bin etwas weiter gekommen, habe nun ein bischen hin und her debuggt,> das Problem an der Ausgabe des Buffers liegt wohl an dieser Funktion:
Nope. Das Problem liegt in deinem Code bzw. darin, dass du etwas
versuchst als String anzusehen, was kein String ist.
> *grübel*
Anstatt zu grübeln solltest du vielleicht erst mal die C Grundlagen
lernen. Insbesondere wie Strings in C funktionieren. Sobald in deinen
Datenbytes ein Byte mit dem Wert 0x00 vorkommt, kannst du das nicht mehr
als String ansehen. Denn genau diese 0x00 bedeuten in einem String: hier
ist der Text zu Ende.
Wenn das also die empfangenen Bytes sind:
1
00 02 43 34 31 33 34 30 33 35 34 32 30 44 03
dann ist für uart_puts der 'String' bereits hier
1
00 02 43 34 31 33 34 30 33 35 34 32 30 44 03
2
^
3
|
4
|
zu Ende. Den hier findet sich der Bytewert, der in einem String das
Textende kennzeichnet. Selbst wenn du dir hier
1
if(response==ETX)
2
{
3
count=0;
4
Buffer[count]=0x00;
5
break;
nicht selbst mutwillig deinen String zerstört hättest, würde trotzdem
das erste Byte im Buffer immer noch ein '\0' (mit dem COde 0x00) sein
und damit dort der String zu Ende sein.
Deine ganze Auswertung ist so ziemlicher Mist. WEnn die Daten mit einem
Byte von 0x02 anfangen, dann wird alles vor diesem 0x02 ignoriert. Und
das 0x02 brauchst du auch nicht speichern. Deine Empfangsroutine muss
also zuallererst mal einen Status haben: Bin ich gerade beim EMpfang
einer Antwort oder bin ich das nicht. Der Übergang von 'nicht' auf
'Nachricht wird empfangen, Bytes müssen gespeichert werden' erfolgt
genau dadurch, dass ein 0x02 aus der UART rauskommt. Erst dann wird
alles nachfolgende gespeichert. Alles vorhergehende ist dagegen
uninteressant.
Die Fleury Funktionen können da genau gar nichts dafür, wie nicht anders
zu erwarten war. Dieses Nicht-Funktionieren ist schon auf deinem Mist
gewachsen.
Versuch es doch mal so:
(ganz oben einfügen "int i;")
if(response == ETX)
{
for (i = 0; i < count; i++) {
uart_putc(Buffer[i]);
}
uart1_puts("Empfangen"CR);
count = 0;
break;
}
}
}
}
Karl Heinz schrieb:> Deine ganze Auswertung ist so ziemlicher Mist.
Nicht nur das. Bevor wir es vergessen: für einen uC sollte die
Hauptschleife niemals ein Ende haben. Was sollte er denn nach Ablauf
des Programms machen?
@Dani
Ich weiß, was er macht. Aber weißt du es auch?