OSC, float32 und AVR gcc

[Patrick (Gast)]

Hallo!

Ich versuche gerade ein Interface zu programmieren, welches per UDP 
empfangene OSC (http://opensoundcontrol.org) Kommandos in definierte 
Aktionen im DMX-Universum umsetzt.

Dabei kommt z.B. ein Kommando /1/fader1 ,f xxxx zustande, dieses wird 
durch das Android/Iphone/Ipad-Tool TouchOSC 
(http://hexler.net/docs/touchosc) erzeugt.

Soweit ist das kein Problem, ich bekomm es aber nicht hin, die vier Byte 
lange Float zu einem ein Byte großem Integer zu wandeln, welches von DMX 
benötigt wird.

Ih habe also in 4 chars den per UDP empfangenen Wert
Buffer[0] bis Buffer[3]

die in
uint8_t dmx_value gewandelt werden müssen.

Dabei soll 0 der kleinste Float-Wert sein und 255 der größte. Ich weiß 
leider auch nicht, welche Werte TouchOSC liefert, meine aber das geht 
von 0.1 bis 1.0.

Kann mir jemand dabei helfen? Ich stehe auf dem Schlauch und komme 
einfach nicht mehr weiter...

Viele Grüße
Patrick

[Patrick (Gast)]

Schade, hat keine eine Idee?

[Stefan E. (sternst)]

Patrick schrieb:
> Ih habe also in 4 chars den per UDP empfangenen Wert

Wieso 4 Zeichen? Auf der verlinkten Web-Seite sieht es eher nach 8 
Zeichen aus (z.B. "0.588608"). Allerdings habe ich dort auf die Schnelle 
keine eindeutige Definition des Nachrichten-Formats gefunden. Als erstes 
musst du also mal 100%ig sicher abklären, in welchem Format du den 
Float-Wert denn nun tatsächlich geliefert bekommst.

[Patrick (Gast)]

Hallo Stefan,

per Wireshark habe ich am Ende der UDP-Nachricht 4 Zeichen, die sich je 
nach Faderposition in der App verändern, der Rest ist 0x00. Ich werde 
allerdings aus den 4 Zeichen bzw. der zugehörigen Hex-Werte nicht 
schlau, nur das bei Fader = unten alle Zeichen 0x00 sind.

Viele Grüße
Patrick

[Patrick (Gast)]

Folgende Werte werden gesendet

/  1  /  f  a  d  e  r  1           ,  f
2f:31:2f:66:61:64:65:72:31:00:00:00:2c:66:00:00:00:00:00:00  ganz unten 0
2f:31:2f:66:61:64:65:72:31:00:00:00:2c:66:00:00:3f:80:00:00  ganz oben 1.0
2f:31:2f:66:61:64:65:72:31:00:00:00:2c:66:00:00:3f:0a:da:2c  ca. mitte ~0.5

[Stefan E. (sternst)]

Die letzten 4 Bytes sind der Float-Wert im Binär-Format (IEEE 754) in 
Big-Endian.

[Patrick (Gast)]

Danke! Hast du vielleicht einen Tipp zur Umsetzung auf dem Atmega? Ich 
bekomme leider nur wild springende Zahlen oder 0 raus :(

[Stefan E. (sternst)]

Big-Endian:
Du musst erst mal die Reihenfolge der Bytes umdrehen, denn der AVR ist 
Little-Endian.

Binär-Format:
Du kannst das dann direkt als Float interpretieren. Eine Konvertierung 
ist nicht nötig, ein simpler Type-Cast reicht.

[Patrick (Gast)]

Danke! Habs wie folgt gelöst, hatte ich auch schon mindestens zweimal 
so, war nur die ganze Zeit ein Zeichen daneben :(

uint8_t osc_float_read(uint8_t startbyte)
{
  union U8f
  {
      uint8_t byte[4];
      float f;
  };

  union U8f u8f;
  u8f.byte[0] = eth_buffer[startbyte+3];
  u8f.byte[1] = eth_buffer[startbyte+2];
  u8f.byte[2] = eth_buffer[startbyte+1];
  u8f.byte[3] = eth_buffer[startbyte];

  uint8_t tmp = u8f.f/0.00392;

  return tmp;
}

[Stefan E. (sternst)]

"/0.00392"?
"* 255" wäre wohl zu offensichtlich gewesen. ;-)

[Patrick (Gast)]

Ja...

[my2cent (Gast)]

Was für eine blöde Idee, solche Parameter als Float zu übertragen. Warum 
nicht unsigned int in der erforderlichen Bitzahl

[Patrick (Gast)]

Wäre mir auch lieber gewesen, aber wurde nun mal so umgesetzt... Ih 
möchte ja nur von vorhandenen Applikationen empfangen.