Binärwert einer Variable per UART senden

[Andi (Gast)]

Guten Morgen,
Ich hab ein vmtl dummes Problem.. Ich will meinen Atmega dazu bringen 
mit meinem Motorsteuergerät über CAN zu kommunizieren. Nachrichten 
empfangen geht, jedoch passen meine Bit-Shifting Operationen offenbar 
nicht, ich krieg nur Müll aus der ID raus.
Jetzt hab ich mir gedacht lass ich mir den Header in Binär über UART am 
PC schicken, dann seh ich ja warums net geht.. aber das is irgentwie 
nicht so einfach.

Nachdem msg[i] ja blöderweis net geht dacht ich mir ich mach einen 
Pointer auf meine Variable, vergleich jeweils ob der Wert dort 1 oder 0 
ist und schick dementsprechend eine 1 oder 0 übern Uart.

for(int i=0;i<32;i++)
{
 uint8_t* id= &msg.id;
 if(*id & 0b1)
    transmit_string_USART0("1");
 else
    transmit_string_USART0("0");
 id++;
}
transmit_string_USART0("\n\r");

Aber so gehts nicht... kann mir vlt jmd helfn? Bin ma sicher dass ich da 
einfach an groben Denkfehler drinnen hab.

lg andi

[Peter II (Gast)]

sicher das du eine '1' oder ein '0' über UART übertragen willst? Das ist 
text der eine Binärzahl darstellt aber keine Binärwert.

Ich glaube nicht das CAN damit etwas anfangen kann.

[Peter II (Gast)]

Nachtrag:

du kannst auch nicht mit einen Pointer über bits gehen. Bits haben keine 
Adresse. Du liest mit deinen Code als 31byte irgendwo aus dem Speicher, 
das kann so nicht gehen.

Vermutlich geht es so:

transmit_string_USART0(msg.id     & 0xff );
transmit_string_USART0(msg.id>>8  & 0xff );
transmit_string_USART0(msg.id>>16 & 0xff );
transmit_string_USART0(msg.id>>24 & 0xff );

jetzt müsste man nur noch die Reihenfolge wissen, wie die Bits gebraucht 
werden.

[Dr. Sommer (Gast)]

Und deswegen, Kinder, wurde der Debugger erfunden...

[Peter II (Gast)]

Dr. Sommer schrieb:
> Und deswegen, Kinder, wurde der Debugger erfunden...

ein Debugger ist wenig hilfreich, wenn man gar nicht versteht wie 
Binärdaten gesendet werden.

[Karl H. (kbuchegg)]

Peter II schrieb:
> Dr. Sommer schrieb:
>> Und deswegen, Kinder, wurde der Debugger erfunden...
>
> ein Debugger ist wenig hilfreich, wenn man gar nicht versteht wie
> Binärdaten gesendet werden.

Ich bin mir gar nicht sicher, ob er das überhaupt will.
Ich interpretiere mal frei

> Jetzt hab ich mir gedacht lass ich mir den Header in Binär über UART
> am PC schicken, dann seh ich ja warums net geht.. aber das is
> irgentwie nicht so einfach.

Ich denke, er denkt über Debug-Möglichkeiten nach.
Er will sich am PC (in einem Terminalprgramm) die 8 Bytes aus der CAN 
Nachricht in Bitform anzeigen lassen (um zu erkennen, welche Bits gestzt 
sind und welche nicht).

D.h was er wirklich will, ist sich die Daten die er vom CAN bekommt, 
aufgedröselt in 0-en und 1-en in Textform anzeigen lassen.

Ist wie gesagt nur meine Interpretation. Vielleicht liege ich auch 
komplett falsch, die Fragestellung bzw. das Erraten wonach eigentlich 
gefragt wird, ist zumindest für mich nicht ganz eindeutig. AUf jeden 
Fall dürfte aber wieder der Fall vorliegen, dass nach etwas gefragt 
wird, was schon von der Idee her der komplett falsche Ansatz ist.

Wenn ich richtig liege, dann würde ich mir erst mal eine kleine 
Hilfsfunktion bauen. Eine Funktion, die 1 Byte aufgedröselt in Bits in 
Textform ausgibt.

void transmit_uint8_string_USART0( uint8_t value )
{
  char str[9];
  utoa( value, str, 2 );
  transmit_string_USART0( str );
}

Die Funktion gibt den Byte-Wert in seiner Binärdarstellung in Textform 
aus.
Damit sollte es dann eigentlich recht leicht sein, die gewünschte 
Funktionalität, nämlich alle Bytes einer CAN-Msg in lesbarer Form aufs 
Terminal zu kriegen, bzw. darauf aufbauend sich weitere Hilfsfunktionen 
zu machen, die nicht nur 1 Byte ausgeben können, sondern dasselbe mit 
einem 16 Bit Wert bzw. einem 32 Bit Wert zu machen

void transmit_uint16_string_USART0( uint16_t value )
{
  transmit_uint8_string_USART0( value >> 8 );
  transmit_uint8_string_USART0( value );
}

void transmit_uint32_string_USART0( uint32_t value )
{
  transmit_uint16_string_USART0( value >> 16 );
  transmit_uint16_string_USART0( value );
}

Wenn ich jetzt richtig liege, dann 'vereinfacht' sich damit die 
ursprüngliche Aufgabenstellung zu einem simplen

  transmit_string_USART0( "Id = " );
  transmit_uint32_string_USART0( msg.id );
  transmit_string_USART0( "\n" );

um die gewünschte Einsicht in das per CAN Empfangene zu erhalten.

[Andi (Gast)]

KarlHeinz, dankedankedankedanke!

Ich wusst ja das muss viel einfacher gehn :D
du hasts erkannt, ich will wirklich die Register in lesbarem Binärcode 
sehen, damit ich das ganze eben einfach debuggen kann.

beste grüße,
andi

[Andi (Gast)]

also ich hab das jetzt eingefügt, jetzt hab ich nur mehr das Problem das 
nicht alle 0en ausgegeben werden.. Deswegen hab ichs gesplittet mit 
Zwischenzeichen:

void transmit_uint32_string_USART0( uint32_t value )
{
  transmit_string_USART0("|");
  transmit_uint8_string_USART0(value >> 24);
  transmit_string_USART0("-");
  transmit_uint8_string_USART0(value >> 16);
  transmit_string_USART0("-");
  transmit_uint8_string_USART0(value >> 8);
  transmit_string_USART0("-");
  transmit_uint8_string_USART0(value);
  transmit_string_USART0("|");
}

Jetzt krieg ich folgende Sachen raus:
|0-1000-10000010-10110000|
|0-0-0-0|
|0-0-10-10001001|

Hier sind jetzt einfach nur die führenden nullen weggelassen, oder?

beste Grüße,
Andi

[Claude M. (stoner)]

Andi schrieb:
> Hier sind jetzt einfach nur die führenden nullen weggelassen, oder?

Ja, utoa() liefert keine führenden Nullen.

[Karl H. (kbuchegg)]

Andi schrieb:

> Hier sind jetzt einfach nur die führenden nullen weggelassen, oder?

Mist.
Daran hatte ich nicht gedacht, dass die ja bei utoa wegfallen.

OK. Dann eben Plan B
Entweder die führenden 0-en beim Versenden ergänzen oder gleich eine 
eigene Version von utoa schreiben, die die führenden 0-en erzeugt.