Forum: Mikrocontroller und Digitale Elektronik USART -> Senden LF empfängt CR + LF


von Furioso (Gast)


Lesenswert?

Hallo zusammen

Hab ein Problem beim Senden eines Datenstrings:

Ich habe Daten welche an Servos gesendet werden (Die Daten werden 
byte-weise übertragen). Leider funktioniert ein Servo nicht. Bei der 
Kontrolle des Protokolls am PC hab ich festgestellt, dass bei Daten 0xa 
(LF) jedesmal zusätzlich ein 0xd (CR) übertragen wird (Analyse mit 
HTerm). Da alle anderen Servos funktionieren und genau das Servo mit der 
ID 10 nicht, gehe ich davon aus, dass dieses zusätzliche CR vom uC 
gesendet wird.

Daher meine Frage:
Gibt es irgend eine Einstellung im uC (AVR32  UC3A1512  AVR Studio 2) 
um das senden des zusätzlichen CR zu verhindern?

Danke schonmal

Gruss
Ivo

von spess53 (Gast)


Lesenswert?

Hi

>Hab ein Problem beim Senden eines Datenstrings:

Willst du nun Daten (beliebige Hexzahlen) oder Strings senden. Es ist 
durchaus möglich, das der Compiler 0xa (=10D) als Stringende 
interpretiert und das CR automatisch anfügt. Zum Senden von Daten 
dürften Stringroutinen ziemlich ungeeignet sein.

MfG Spess

von Furioso (Gast)


Lesenswert?

Nein, will nur Daten Senden.
Die Daten werden byte für byte aus einem Char-Array gesendet, also nicht 
als String (und im Array ist ein 0xd definitiv nicht enthalten)

von holger (Gast)


Lesenswert?

>jedesmal zusätzlich ein 0xd (CR) übertragen wird (Analyse mit
>HTerm).

Vieleicht hängt HTerm dir das 0xd automatisch an?

von Mano W. (Firma: ---) (manow)


Lesenswert?

Hmm, so ganz verstehe ich nicht wieso es genau das Servo mit der ID 10 
sein soll? Bekommen alle die gleichen Char-Arrays oder unterschiedliche? 
Servos schon mal getauscht? Quellcode schon mal disembeld um nach den 
0x0D zu suchen?

von Furioso (Gast)


Lesenswert?

HTerm funktioniert soweit korrekt. Hab gerade mal testweise die TX und 
RX pins zusammengehängt und die entsprechenden Zeichen gesendet. 0xa 
kommt ohne 0xd an!

Durch das zusätzliche 0xd im Protokoll wird der Befehl vom Servo nicht 
verarbeitet, dass heisst das Servo macht keinen Wink, egal was ich 
schicke (Länge und Checksumme stimmen nicht).
Vermutlich werden bei den anderen Servos Daten mit 0xa durch das 
zusätzliche 0xd auch nicht verarbeitet (z.B. Position 10). Dies fällt 
aber nicht auf, da die Daten mit 50Hz gesendet werden und die Daten 
jedesmal ändern.

Ich habe mit dem Debugger die Daten kontrolliert und diese stimmen 
soweit (es werden auch nur 10 bytes gesendet, es kommen aber 11 bytes 
an). Servo funktionieren definitiv richtig

von Furioso (Gast)


Lesenswert?

Problem gelöst!
Das zusätzliche 0xd wird im Framework des AVR32 hinzugefügt.
Trotzdem Danke für die Hilfe!

Gruss
Ivo

von Markus W. (mark-169)


Lesenswert?

Hallo zusammen,

Ist zwar schon länger her aber vielleicht schaut ja noch jemand rein!

Ich habe das selbe Problem mit einem Atmega32, AVR Studio, AVR-GCC und 
einem seriellen Display.

Ich lege die Befehle mit PORGMEM ab und dort steht auch nur ein 0x0A 
kein 0x0D!! Raus kommt 0x0D 0x0A was das Display dann ignoriert.

Weiß jemand wo genau das in den Libraries passiert???

Danke

Gruß

von Karl H. (kbuchegg)


Lesenswert?

Markus W. schrieb:
> Hallo zusammen,
>
> Ist zwar schon länger her aber vielleicht schaut ja noch jemand rein!
>
> Ich habe das selbe Problem mit einem Atmega32, AVR Studio, AVR-GCC und
> einem seriellen Display.
>
> Ich lege die Befehle mit PORGMEM ab und dort steht auch nur ein 0x0A
> kein 0x0D!! Raus kommt 0x0D 0x0A was das Display dann ignoriert.
>
> Weiß jemand wo genau das in den Libraries passiert???


Zeig mal dein Programm.
m.W. hält sich hier der AVR-GCC bzw. dessen Libraries komplett raus.

von Markus W. (mark-169)


Angehängte Dateien:

Lesenswert?

Hallo Karl Heinz,

Vielen Dnak für die Antwort.

Hier mal die relevanten Funktionen:

Also es handelt sich um ein RGB-Grafik-LCD. Die Ansteuerung erfolgt 
seriell.

In der angehängten Datei speicher ich alle gewünschten Befehle. Mein 
Problem entsteht bei "Marker 90":
1
// Marker 90  [266,119;272,119];[266,120;272,120];[266,121;272,121] 
2
0xAA, 0x56, 0x01, 0x0A, ....

Gelesen und über UART geschrieben wird folgendermaßen:

Hier wird gelesen und die UART Senefunktion aufgerufen
1
// ------------------------------------
2
// Sende eigene Kommando-Liste
3
// ------------------------------------
4
void lcd_command_list(uint8_t* bitmap)
5
{  
6
  uint16_t byte=0;
7
  uint16_t i;
8
  for (i=0;i<380;i++) //366
9
  {
10
    uart_putchar(pgm_read_byte(bitmap+(byte++)));        
11
  }  
12
}

und hier wird über UART raus geschickt.
1
//############################################################################
2
//Routine für die Serielle Ausgabe
3
int uart_putchar (char c)
4
//############################################################################
5
{
6
  if (c == '\n')
7
    uart_putchar('\r');
8
  //Warten solange bis Zeichen gesendet wurde
9
  loop_until_bit_is_set(USR, UDRE);
10
  //Ausgabe des Zeichens
11
  UDR = c;
12
  return (0);
13
}

Also was den UART betrifft sind wirklich keine Libraries eingebunden, 
ich kann mir nur vorstellen, dass es schon falsch abgespeichert wird 
oder falsch aus PROGMEM gelesen wird.

Gruß Markus

von Markus W. (mark-169)


Lesenswert?

Hat sich erledigt! Da stehts ja direkt vor meiner Nase und ich seh es 
nicht...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.