Serielle Daten Senden von mehr als 2 Byte

[A. R. (and)]

Hallo,

ich möchte gerne eine Integer Zahl die gröer als 255 spricht mehr als 
2Byte hat über UART senden.

Ich Schreibe die Zaheln über eine Varibale und einen Aufruf in das UDR 
register. Ist der Wert kleiner 256 spricht hat nur zwei Byte kommen die 
entsprechend beim Empfänger an.
Ist die Zahl größer 255 also 3 Byte so kommen beim Empfänger (HTERM) nur 
die letzten beiden Stellen Hexadezimal an.

Beispiel:
Sende: 99 (INT) Empfänger: 63 (HEX)
Sende: 255 Empfänger: FF
Sende: 300 Empfänger: 2C statt 12C
Sende: 1222 Empfänger: C6 statt 4C6

Controller: Atmega 1284P

........

int uart_putc (int16_t sende) {
    while (!(UCSR0A & (1<<UDRE0)))  /* warten bis Senden moeglich */
    {
    }                             
 
    UDR0 = sende;                      /* sende Zeichen */
    return 0;
}
 
.........

int main (void) {  

int16_t s1=0, s2=0, s3=0, s4=0;
uart_init();

    while (1){
  
        s1 = 99;        

        uart_putc (s1);
    }
....
}

[Karl H. (kbuchegg)]

A. R. schrieb:

> int uart_putc (int16_t sende) {

Das kannst du dir gleich wieder abschminken.
Über die UART geht 1 Byte raus. 1 Byte und nicht mehr als 1 Byte.

Wenn du mehr Bytes brauchst, dann musst du eben uart_putc mit den 
entsprechenden EInzelteilen entsprechend oft aufrufen.

Du gibst ja auch einen String (Text) so aus, dass du nacheinander 
Buchstabe für Buchstabe ausgibst. Das ist hier auch nicht anders.

...
         uart_putc (s1 & 0xFF);   // zuerst das Low-byte
         uart_putc (s1 >> 8 );    // dann das High-byte
...

[Karl H. (kbuchegg)]

Daher baut man sich vernünftigerweise auch ein paar Hilfsfunktionen, die 
einem das immer gleiche Aufbrechen in die einzelnen Bytes zentralisieren 
und abnehmen

zb:

// Ausgabe eines Textes
void uart_puts( const char* txt )
{
  while( *txt )
    uart_putc( *txt++ );
}

// Ausgabe einer Zahl in Textform
void uart_puti( int16_t zahl )
{
  char txt[8];

  itoa( txt, zahl, 10 );
  uart_puts( txt );
}

oder eben bei dir

// Ausgabe einer Zahl in binärer Form (2 Bytes)
void uart_puti_bin( int16_t zahl )
{
  uart_putc( zahl );
  uart_putc( zahl >> 8 );
}

[n.b. (Gast)]

A. R. schrieb:
> ich möchte gerne eine Integer Zahl die gröer als 255 spricht mehr als
> 2Byte hat über UART senden.

Dir ist schon klar, dass 2 Byte für den Zahlenraum bis 65535 ausreicht 
und dass ein UART nur einzelne Bytes versenden kann. Guck mal in ein 
Datenblatt von einem µC, der ein UART hat.

[A. R. (and)]

Mit 4Byte HEX bekomm ich auch Zahlen bis 65535 dargestellt.
Wenn ich jetzt eine 2Byte Zahl, also bis 255 in das UDR lade wie in 
meinem Quelltext wird das auch korrekt übertragen.
Ich hääte jetzt gerne aber meine Zahl größer 255 als HEX gesendet. So 
das ich den z.B. in Hterm eine "12C" für meine Zahl 300 erhalte.

[Karl H. (kbuchegg)]

A. R. schrieb:
> Mit 4Byte HEX bekomm ich auch Zahlen bis 65535 dargestellt.

Das kommt jetzt drauf an.
4 Bytes binär oder 4 Zeichen (also in Textform)?

Binär brauchst du für unsigned Zahlen bis 65535 nur 2 Bytes. Denn genau 
so gross ist ein uint16_t: 2 Bytes.

[vloki (Gast)]

Ich glaube da ist was durcheinander geraten ;-)

Ein "Hex Zeichen" in HTerm entspricht nur 4 Bit.
x12C ist eigentlich "x012C" oder b0000 0001 0010 1100

[A. R. (and)]

Karl Heinz schrieb:
> ...
>          uart_putc (s1 & 0xFF);   // zuerst das Low-byte
>          uart_putc (s1 >> 8 );    // dann das High-byte
> ...

Habe jetzt das veruscht und festgestellt das es in etwas ander 
Reihenfolge funktioniert:

So bekomme ich jetzt in meienr Endhardware richtig angezeigt:

    uart_putc (s1 >> 8 );    // dann das High-byte
    uart_putc (s1 & 0xFF);   // zuerst das Low-byte

[vloki (Gast)]

oder anders gesagt - in einem Byte stecken zwei Hex-Zeichen

[vloki (Gast)]

A. R. schrieb:
> abe jetzt das veruscht und festgestellt das es in etwas ander
> Reihenfolge funktioniert:

http://de.wikipedia.org/wiki/Byte-Reihenfolge
(ich habe es jetzt nicht gelesen, aber wird vermutlich schon halbwegs 
stimmen)

[Karl H. (kbuchegg)]

A. R. schrieb:
> Karl Heinz schrieb:
>> ...
>>          uart_putc (s1 & 0xFF);   // zuerst das Low-byte
>>          uart_putc (s1 >> 8 );    // dann das High-byte
>> ...
>
> Habe jetzt das veruscht und festgestellt das es in etwas ander
> Reihenfolge funktioniert:

:-)

Ja ja, die Endianess.

Wie ich immer sage:
Wenn es 2 Möglichkeiten gibt, dann hat man eine 80% Chance sich zuerst 
für die Falsche zu entscheiden ;-)

[A. R. (and)]

Karl Heinz schrieb:
> Wenn es 2 Möglichkeiten gibt, dann hat man eine 80% Chance sich zuerst
> für die Falsche zu entscheiden ;-)

wie berechnet man das ??? ;)

[Volker S. (vloki)]

A. R. schrieb:
> wie berechnet man das ??? ;)

Empirisch, oder über den Empirismus ;-)

[Karl H. (kbuchegg)]

A. R. schrieb:
> Karl Heinz schrieb:
>> Wenn es 2 Möglichkeiten gibt, dann hat man eine 80% Chance sich zuerst
>> für die Falsche zu entscheiden ;-)
>
> wie berechnet man das ??? ;)

Formel nach Murphy
http://de.wikipedia.org/wiki/Murphys_Gesetz

auch bekannt als die 'Karl Heinzsche Gleichverteilung'

[Volker S. (vloki)]

Karl Heinz schrieb:
> Formel nach Murphy

Müssten es dann nicht 100% sein ?

Egal, 20% Optimismus kann ja nicht schaden ...

[Karl H. (kbuchegg)]

Volker SchK schrieb:
> Karl Heinz schrieb:
>> Formel nach Murphy
>
> Müssten es dann nicht 100% sein ?
>
> Egal, 20% Optimismus kann ja nicht schaden ...

Ja, so bin ich halt. Immer optimistisch.

Der Wikipedia Eintrag ist fad. Der hier ist besser
http://murphyslaws.net/german.htm

[n.b. (Gast)]

A. R. schrieb:
> Mit 4Byte HEX bekomm ich auch Zahlen bis 65535 dargestellt.

Das was du da als HEX bezeichnest, ist eine Textdarstellung. Dir 
scheinen noch ein paar Grundlagen zu Binärzahlen und deren Darstellung 
zu fehlen.

Mit n Byte kannst du den Zahlenraum von 0 bis 2^(8*n)-1 abbilden.

[dummschwaetzer (Gast)]

> So bekomme ich jetzt in meienr Endhardware richtig angezeigt:
>
>    uart_putc (s1 >> 8 );    // dann das High-byte
>    uart_putc (s1 & 0xFF);   // zuerst das Low-byte

mit Sicherheit nicht! Mit s1 >> 8 shiftest du deine unteren 8Bit ins 
nirvana.

[Tom Thomsen (Gast)]

dummschwaetzer schrieb:
> mit Sicherheit nicht! Mit s1 >> 8 shiftest du deine unteren 8Bit ins
> nirvana.

... deshalb auch High-Byte ;-)

[Karl H. (kbuchegg)]

dummschwaetzer schrieb:
>> So bekomme ich jetzt in meienr Endhardware richtig angezeigt:
>>
>>    uart_putc (s1 >> 8 );    // dann das High-byte
>>    uart_putc (s1 & 0xFF);   // zuerst das Low-byte
>
> mit Sicherheit nicht! Mit s1 >> 8 shiftest du deine unteren 8Bit ins
> nirvana.

Jep. Das ist auch so gewollt.

[A. R. (and)]

Funktioniert aber einwandfrei so wie ich es gemacht habe.
Habe kompletten WErtebereich bis 65.000 getestet. und gerade läuft 
dauertest

[Karl H. (kbuchegg)]

A. R. schrieb:
> Funktioniert aber einwandfrei so wie ich es gemacht habe.

Das passt schon.

> Habe kompletten WErtebereich bis 65.000 getestet. und gerade läuft
> dauertest

:-)
Das eigentliche Problem kommt noch.

[dummschwaetzer (Gast)]

Karl Heinz schrieb:
> Jep. Das ist auch so gewollt.

Das must du mir erklären:
Zerstöre durch shiften das low-byte, das vorherige high-byte ist das 
neue low-byte
sende dieses low-byte
verodere das low-byte mit FF
sende es noch mal

mit
So bekomme ich jetzt in meienr Endhardware richtig angezeigt:

    uart_putc (s1 >> 8 );
    uart_putc (s1 & 0xFF);

sendet nur das high-byte von s1 doppelt

[Volker S. (vloki)]

dummschwaetzer schrieb:
> Zerstöre durch shiften das low-byte, das vorherige high-byte ist das
> neue low-byte

Da steht nicht s1 = s1 >> 8 !

[dummschwaetzer (Gast)]

danke