Ansteuerung eines TLC5971 über ein Bitfeld in einer union

@ Thomas (Gast)

>um einen TLC5971 (LED Treiber) komfortabel anzusteuern habe ich ein
>struct mit den Parametern des Treibers erstellt und das Ganze
>anschließend in eine union gepackt um es dann byte-weise verschicken zu
>können.

Kann man machen, ist aber compilerabhängig.

>Ich verwende AtmelStudio 6 und dort ist die Option -fpack-struct
>standardmäßig dabei. Die Optimierungen habe ich abgeschaltet und nun
>erhalte ich trotzdem die Daten wie sie im Bild dargestellt sind.

>Bereits das erste Byte ist also nicht korrekt. In bytes[0] müsste ja
>schon 0xA4 stehen.

Nö. Bitfelder sind ne windige Sache und in der C-Praxis nicht sehr 
häufig.
Der Compiler darf die nahezu beliebig auf mehrere Bytes aufteilen, auch 
mit Leerbits. Wie das genau im C-Standard geregelt ist, weiß ich nicht, 
ist mir als Pragmatiker auch herzlich egal.

>Hat jemand einen Tipp wie man es sauber lösen könnte?

Nimm ein normales Feld und schreib dir eine handvoll Funktionen, welche 
die jeweileigen Bits per Bitmanipulation setzen. Das ist eindeutig 
und ggf. auch portabel.

Thomas schrieb:

> Bereits das erste Byte ist also nicht korrekt. In bytes[0] müsste ja
> schon 0xA4 stehen.

versteh ich nicht.
Warum soll da 0xA4 drinnen stehen.

Du hast offenbar 0x29 ins command member geschrieben, die beiden oberen 
Bits in diesem Byte sind 0 und daher steht im Byte insgesamt auch 0x29 
drinnen.


Die Bits werden vom Compiler beginnend mit dem LSB, also Bit 0 
allokiert! Also von unten nach oben und nicht von oben nach unten.

> Hat jemand einen Tipp wie man es sauber lösen könnte?

Man kann es mit einer struct und Bitfeld machen. Man muss aber nicht. 
IMHO bringt hier ein Bitfeld nicht viel, auch nicht an Klarheit. Denn 
die Bitpositionen sind sowieso fix und ändern sich nicht. Es kommt auch 
in den nächsten 100 Jahren kein Bit dazu oder weg. D.h. ganz klassisch 
mit Funktionen bzw Makros, die die jeweiligen Werte zurecht schieben und 
mit UND bzw. ODER Operationen in die Bytes einbauen.
Was anderes kann auch der Compiler nicht machen. Schreibst du

1

  par.outtmg = 1;

dann muss der Compiler das auch (konzeptionell) in

1

  par.bytes[0] = par.bytes[0] | 0x40;

aufdröseln.
Geschwindigkeitsmässig ist das ziemlich egal ob du daher das eine oder 
das andere schreibst.
Nur: Mit der Schreibweise, in der du selber die Bits setzt, hast du alle 
nicht definierten Dinge von Bitfeldern erst mal aussen vor und alles 
funktioniert so, wie du das haben willst. Wenn die Syntax nicht gefällt 
... verstecken in einer Funktion bzw. einem Makro kann man das immer 
noch.

Und sowas

1

  blue_0

2

  green_0

3

  red_0

4

5

  blue_1

6

  green_1

7

  red_1

8

9

  ...

wirst du eher verfluchen als das es dir nützt.
Damit wird die Ansteuerung nämlich zur Qual.
Wieviel simpler ist es in der Verwendung wenn du ganz einfach sagen 
kannst: Die 3. LED auf die und die RGB Werte setzen.
Klar, mit einem switch-case ist das natürlich möglich. Aber es besteht 
ein ganz simpler Zusammenhang zwischen der LED-Nummer und dem Byte im 
Array, wo die Bits rein müssen.
Dann geht das auch mal mit 200 LED an 48 Bausteinen problemlos ohne dass 
du erst mal 86 Fallunterscheidungen im Vorfeld brauchst.

Wann immer du versucht bist, konzeptionell gleiche Variablennamen zur 
Unterscheidung durchzunummerieren, dann sollten deine Alarmglocken 
anfangen zu klingeln und du darüber nachdenken ob nicht eine Array-Sicht 
der Dinge samt Berechnung des Index die bessere Lösung wäre.

Falk Brunner schrieb:
> Der Compiler darf die nahezu beliebig auf mehrere Bytes
> aufteilen, auch mit Leerbits.

Das ist im ABI (Application Binary Interface) beschrieben.

Der Compiler übersetzte den Code nicht beliebig, sondern wie im ABI 
spezifiziert.

Thomas schrieb:

> Der eigentliche Fehler von mir war aber , dass ich die Bytes falschrum
> aufgebaut habe. Wenn man nun beachtet, dass jedes Byte quasi von hinten
> aufgefüllt wird, dann funktioniert es. Das macht das Ganze dann aber
> extrem hässlich, weil man die Bitfelder dann trennen muss, damit man die
> Bytegrenzen kontrollieren kann :(

Oder beim SPI ganz einfach am anderen Ende anfangen (bzw. anfangen 
lassen)
Anstatt MSB zuerst, LSB zuerst (bzw. umgekehrt) :-)