www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RGB LED Treiber


Autor: Tobias Tetzlaff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich plane so etwa 32 RGB LEDs mit einem ATmega8 oder Tiny2313 per
SPI und HC595 anzusteuern.

Mein Problem sind aber die 3x4 (=12) HCs und die dazugehörigen Treiber.
Mächtig viel ICs und Verdrahtung.

Gibt es evtl. ein 24 Bit LED Treiber?
Ich kenne bislang nur 8 oder 16 Bit Treiber.

Wie sieht es bei einem 16 Bit Treiber MAX7221 mit der Geschwindigkeit
aus?
Wäre es möglich, damit drehende LED anzusteuern?
Die LEDs drehen mit max 2500 U/min, und erzeugen 256 (evtl. mehr)
Spalten.

Wie einige schon wissen, habe ich eine Art Propeller Uhr, nur mit 32
LEDs (einfarbig).
Das ganze Projekt soll nun als RGB Version gebaut werden.

Danke für euere Hilfe...

Gruß Toby

Autor: Pete Nerlinger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gibts bei conrad.

Autor: Tobias Tetzlaff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo mal wieder,

da ich immer noch nichts Neues weiß,
hat vielleicht jamand noch eine Idee.

Ich dachte schon daran, 3 AVRs zu nehmen, um 3x SPi zu haben.
Für jede Farbe einen.

Wie siehts mit diesen aus : TLC5940 / TLC5941  ???

Kann mir dazu evtl. mal jemand eine Funktionsbeschreibung geben?

Vor/Nachteile, Ansteuerung, Geschwindigkeit,.....

Gruß Toby

Autor: tk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wiso 3 mal SPI ? 3 mal Chip Select reichen...Einfach alle SPI 
leitungen(ausser dem CS) parrallel anschliessen und fertig..der chip 
wird dann mittels CS (chip select) ausgewählt

Autor: Tobias Tetzlaff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das mit dem 3x CS ist mir schon klar.

Nur muß ich ja bei 32 RGB LEDs 12 Schieberegister hintereinander 
schalten.
Ich muß also 12 byte per SPI senden.
Dabei ist es egal, ob ich einen, oder 3 CS Pinne habe.

Mir ging es ja darum, schneller zu werden, also 3x4 Schieberegister zu 
verwenden.

Evtl. habe ich ja mal wieder ein Brett vorm Kopf.

Gruß Toby

Autor: Tobias Tetzlaff (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

ich habs nun kappiert! ;-)

Ich habe 3x 4 Schieberegister und wähle je 4 davon mit einem eigenen CS 
Pin aus.

So ähnlich wie im Anhang.

Gruß Toby

Autor: maxerl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: maxerl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry hab das mit der probelleruhr überlesen.
denke mal es wär einen versuch wert.

schöne festtage

Autor: Tobias Tetzlaff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Maxer,

wie schnell Multiplexen denn diese MAX7221?

Interessannt sind die ja schon, da man auch die Helligkeit einstellen 
kann,
und wohl nur einen Wiederstand für alle angesteuerten LEDs benötigt.

Wünsche auch ein frohes Fest.

Gruß Toby

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zu langsam ;) 32 RGB LEDs, sinnvoll ist dann eine "Display" Auflösung 
von 8 * 32 = 256 Spalten. Statt nun die Helligkeit per PWM einstellen zu 
wollen kann man auch einfach die Anzahl der Spalten erhöhen. Für zb. 64 
Farben = 6 Bits = 2 Bit pro Farbe ergibt sich ein "PWM" Muster von 3 
Bits ->
Farbe   PWM
  00    000  
  01    010
  10    101
  11    111

Das heist dann 256 Spalten * 9 PWM Bits = 2304 PWM Zyklen pro Umdrehung. 
Bei 3600 U/min -> 60 U/sec -> 16.7ms pro Umdrehung / 2304 = 7.23 µs pro 
PWM Cyclus. Macht eine Ansteruerungfrequenz von 138KHz. Der Max Baustein 
müsste also minimal 138KHz PWM machen damit du 256 Pixelspalten in 64 
Farben darstellen kannst, schafft er glaube ich nicht. Du wirst bei 
immmer größeren Frequenzen auch Probleme mit den LEDs selber bekommen 
(brauchst höheren Strom), da die Kapazitäten der LEDs nichts zu 
vernachlässigen sind.

Die TLCxxx Teile haben so hohe PWMs -> bis 2Mhz glaube ich. Aber auch 
hier macht es im Grunde wenig Sinn, denn du musst ja sowieso die 
Farbbytes aus dem Speicher dekodieren, auf die RGB LEDs austeilen nach 
Farbe und für jede Pixelspalte immer wieder erneut diese Daten senden. 
Die TLC Teile haben 3 Vorteile:

1.) man kann den LEDs Strom per Sowftware feinjustieren, sprich LEDs 
untereinander abgleichen. Das sparrt die Vorwiderstände. Höhere Ströme 
möglich bis zu 80mA pro LED
2.) 16 Ausgänge statt nur 8 wie bei normalen Shiftregistern
3.) kleine Bauformen

Für die Dekodierung der Farbbytes und die Ansteuerung der Shiftregister 
wird folgendes die einfachste Lösung auf einem AVR sein:

Ein 6 Bit Port des AVRs, hier mal PortD
  PD5 -|
  PD4 -|-- Input Rot Shiftregister

  PD3 -|
  PD2 -|-- Input Grün Shiftregister
 
  PD1 -|
  PD0 -|-- Input Blau Shiftregister

Wie man sieht werden die Shiftregister nach Farbe getrennt kaskadiert. 
Es gibt dann 1 Shiftregister Takt für alle Register, 1 Shiftregister 
Enable für Alle, und 3 Shiftregister Dateneingänge pro Farbe einer. Man 
schiebt also alle 3 Farben in parallel raus.

Die Pins des PortD sind die Datenausgänge. Dabei wird aber zb. PD1 auf 
Input und PD0 auf Output oder PD1 auf Output und PD0 auf Input 
geschaltet. Wir haben also einen 2 zu 1 Multiplexer aufgebaut. Und über 
DDRD-> Datenrichtungsregister selektieren wir.

Unser Farbbyte -> 6 Bits -> 64 Farben wird nun einfach auf PortD 
ausgegeben. Über DDRD bestimmen wir welches der 2 Bits pro Farbe 
gesendet wird. Ist PD0/PD1 auf Output/Input gesetzt senden wir das 
unterste Farbbit pro Farbe, bei Input/Output senden wir das obere 
Fabrbit.

Die ISR die nun deine Daten sendet muß 2 Dinge machen:

- Datenrichtungsregister -> DDRD entspechend setzen 
(Multiplexer/Farbbitdekoder)
- 32 Bytes der Pixelspalte X auf PortD ausgeben
- nach jedem Byte logischerweise den Shiftregistertakt toggeln
- nach den 32 Bytes Shiftregister Enable/Store/Latch wieder toggeln

Das macht dann 32*3 + 2, minimal 98 MCU Takte in dieser ISR. Zur 
Verfügung hast du 7µs Pro ISR.

Nochmal:
- du hast 256 Pixelspalten, 64 Farben pro Byte/Pixel
- jede Pixelspalte wird 3 mal hintereinander ausgegeben
- über DDRD bestimmst du welches Pixelbit dabei angezeigt wird
- mit Hilfe vom DDRD und den extern zusammengeschalteten PINs des PortD 
bauen wir 3 2 zu 1 Multiplexer auf und sparen so enorm viel MCU Takte in 
Software die ansonsten nötig wären für die Farbdekodierung.
Klar dürfte sein das du DDRD niemals falsch einstellen darfst, von den 2 
zusammengeschateten Pins sollte immer einer auf Input und der andere auf 
Output sein.
- legst du den Takt der Shiftregister ebenfalls auf PortD so kommst du 
auf minimal 100 MCU Takte pro Pixelspalte in deiner ISR


Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Das heist dann 256 Spalten * 9 PWM Bits = 2304 PWM Zyklen pro Umdrehung.
>>Bei 3600 U/min -> 60 U/sec -> 16.7ms pro Umdrehung / 2304 = 7.23 µs pro
>>PWM Cyclus.

Sorry kleiner Fehler drinnen. Wir steuern ja alle 3 Farben gleichzeitig 
an. Für 2 Bits pro Farbe also 3 mal. Macht dann nur 3 Ansteuerungen pro 
Pixelspalte.

256 Spalten * 3 = 768 Zyklen pro Umdrehung -> 1  60  768 = 22µs pro 
Zyklus. Also alle 22µs wird deine ISR aufgerufen, und 3 mal 
hintereinander wird die gleiche Pixelspalte ausgegeben. Das erste mal 
DDRD so gesetzt das das unterset Farbbit multiplext wird, das nächste 
mal das oberste Farbbit und dann nochmal das unterset Farbbit. Fertig 
ist deine Pixelspalte in 64 Farben pro Pixel.

Bei 16MHz Takt hast du 347 Takte Zeit in der ISR, das heist der AVR ist 
zu rund 33% ausgelastet mit der Darstellung des Displays/Füllen der 
Shiftregister.

Gruß Hagen

Autor: Tobias Tetzlaff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

prinzipiell würden mir 8 Bit Farben reichen!
Also LED an/aus.

Könnte so was mit den HC595/TPIC6C595 funktionieren?

Des weiteren spiele ich ja noch mit dem Gedanken, die Anzeige auf bis zu 
64 LEDs zu erweitern.
Immerhin soll es in einem RC Heli platz finden, und da es diese in 
mehreren Größen gibt, muß ich wohl oder übel mehr LEDs verwenden.

Aber trotz Allem, das sind schon geniale Überlegungen, die Du da machst!
Wie weit bist Du mit deiner Planung einer PropUhr????

Gruß Toby

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
liegt auf Eis. Das Problem ist nicht die Software sondern die Hardware 
der LEDs. Mit den TLCxxxx Teilen hat man zwar schön kleine Treiber, aber 
das Layout des Armes auf denen die LEDs sitzen ist meiner Meinung nach 
nur 4 lagig hinzubekommen. Viel zu kompliziert für mich. Ausserdem hat 
man bei zb. ab 32 RGB-LEDs mit einem AVR nicht mehr genügend 
Rechenpower. In der Ausbaustufe die ich mir vorstellte bekommt man an 
jeder Ecke Probleme. Stromversorgung geht in mehrere Ampere, LEDs sind 
teuer wenn man saubere Farben haben möchte, Layout ist kompliziert und 
das wird teuer, Software braucht viel RAM usw. usw. Also alles Sachen 
die mich überfordern. Wenn ich mal genügend Kohle übrig habe, und die 
Zeit, packe ich das aber nochmal an.
Dann aber nicht mit einem AVR.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei 8 Farben == 3 Bit pro Pixel brauchst du nur den PortD anders 
verdrahten. Zb.

  PD0--------|---------- Blau
  PD1--------+--|------- Grün
  PD2--------+--+--|---- Rot
             |  |  |
  PD3 -> NC  |  |  |
             |  |  |
  PD4--------|  |  |   
  PD5-----------|  |
  PD6--------------|

  PD7 -> NC


in einem Byte stehen dann 2 Pixel der Display Spalten. Zuerst setzt DDRD 
so das PD0 bis PD2 auf Ausgang sind, und PD4 bis PD6 auf Input. Nun 
gibts du auf PORTD das Byte aus. Danach Takt toggeln und dann DDRD so 
setzen das PD0 bis PD2 aug Input und PD4 bis PD6 auf Output sind. Nun 
noch mal Takt toggeln. Schwups hast du 2 Pixel kodiert in einem Byte an 
die 3 Shiftregister gesendet.

Die selber Dekoder/Multiplexer Logik funktioniert auch hier. Wenn du die 
TLC Teile benutzt dann kannst du ja über RExt den Strom einstellen. Hast 
du nun deine Shiftregister pro Farbe kaskadiert kannst du über diese 
RExt Widerstände also die Farben Blau,Rot,Grün nachjustieren. Die 
Trennung der Register hat also Vorteile, mal abgesehen davon das der 
Verdrahtungsaufwand eben leicht komplexer ist.

Gruß Hagen

Autor: Tobias Tetzlaff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

ich gehe mal von den TLC5923 aus.
Habe mir 3 Samples geordert.

Nehme ich also den ON/Off Mode, muß ich für 16 RGB LEDs, 3x TLC,
8 Byte Bilddaten erzeugen und übertragen.
Jedes Byte beinhaltet 2 Pixel.
Also jedes Byte 2x schieben, erst das obere Halbbyte, dann das untere 
Halbbyte.

So weit richtig?

Nun könnte man auch den Dot-Correcton Mode nutzen,
dann müsste man allerdings pro Pixel 3x7 Bit übertragen.
Da in einem Byte ja 2 Pixel stehen, macht das 7Byte für 2 Pixel
im Dot Correction Mode.

Sehe ich das so richtig?

Wenn ich es richtig verstanden habe, bauen wir hiermit ja eine Software 
SPI.Wäre es nicht irgendwie möglich, das Ganze per Hardware SPI hin zu 
bekommen? Wahrescheinlich nicht, da die HW SPI nur einen Daten Pin hat.
Vorteil der HW SPI, die macht ja alles im Hintergrund.
Daher auch meine Frage, ob man 3 AVRs nimmt, für jede Farbe einen.

Ich frag mich nur, wie die von Wall-/Fan Screen, iBall und Co. das 
machen.
Die haben 85 RGB LEDs und bis zu 3000 Spalten.

Da sollte man wohl doch auf einen anderen Prozessor wechseln!?

So weit...

Gruß Toby

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Nehme ich also den ON/Off Mode, muß ich für 16 RGB LEDs, 3x TLC,

korrekt

>> 8 Byte Bilddaten erzeugen und übertragen.

Korrekt.

>> Jedes Byte beinhaltet 2 Pixel.

Korrekt.

>>Also jedes Byte 2x schieben, erst das obere Halbbyte, dann das untere
>>Halbbyte.

Ja korrekt. Allerdings lädst du diese Byte nur einmalig in PORTD und 
ändert das DDRD Register damit du entweder das Low- oder Hi-Nibble 
multiplext. Dazwischen taktest du die Register.

Das ist Software SPI, dürfte in ASM circa 6 Takte pro Byte a 2 Pixel a 6 
Datenbits benötigen. Damit bist du dann schneller als das Hardware SPI 
des AVRs ! (doppelt so schnell als per HW SPI möglich und in den obigen 
6 Takten habe ich schon den Speicherzugriff auf den SRAM mit 2 Takten 
eingerechnet)

>> Nun könnte man auch den Dot-Correcton Mode nutzen,

korrekt.

>> dann müsste man allerdings pro Pixel 3x7 Bit übertragen.

Nöö, macht keinen Sinn. Dann wäre es besser pro Byte im SRAM einen 
FarbPixel zu speichern. Du kannst also pro FarbLED 128 Helligkeiten 
speichern. 3 Bytes ergeben dann einen RGB Pixel. Insgesamt also 2Mio 
Farben. Wenn du das nicht so machst musst du deine Pixel im SRAM auf die 
7 Bit im Dot-Correction Register umrechnen. Du bräuchtest dann am besten 
eine große Lookup Tabelle im Speicher. Zb. bei 256 Farben, würdest du 
pro Pixel 1 Byte SRAM verbrauchen. Das dient dann als direkter Index in 
eine Tabelle mit jeweils 3 Bytes pro Eintrag. In diesen 3 Bytes stehen 
dann die Dot-Correction-Werte a 7 Bit für Rot/Grün/Blau drinnen.

Auf alle Fälle unterstützt das HW-SPI im AVR nur 8 Bit SPI. Du nusst 
also deine 7 Bit Dot-Correction-Werte zusammenschieben. Auch das kostet 
Zeit in der Software.

Ich meine das du dann besser ein Soft-SPI machst aber 3 Datenleitungen 
in parallel fütterst. Eben Rot,Grün,Blau Shift-Register getrennt 
kaskadiert. Das erhöht aber den Verdrahtungsaufwand.


Die "Stabiliserungszeit" für die Konstantstromquellen dauert -> 
Datenblatt -> tpd5 = 1000ns = 1µs. Bei einem Propeller mit 30cm Radius 
und 3600U/min werden in 1µs rund 0.12 Millimeter an den Rotorspitzen 
zurückgelegt, bzw. pro Millimeter braucht man 8.8µs. Das könnte also 
noch funktionieren.

>>Wenn ich es richtig verstanden habe, bauen wir hiermit ja eine Software
>>SPI.Wäre es nicht irgendwie möglich, das Ganze per Hardware SPI hin zu
>>bekommen?

Ja würde gehen hat Nach- und Vorteile. Nachteil ist eben das man nur 8 
Bit HW-SPI kann wir aber 7 Bit SPI bräuchten. Vorteil ist es das du alle 
3 Register seriell schaltest und an deren Ausgängen jeweil LED1 R-G-B, 
LED2 R-G-B, LED3 R-G-B usw. verdrahten kannst. Das reduziert also enorm 
den Verdrahtungsaufwand. Wenn du aus den 128 möglichen 
Dot-Correction-Register zb. nur 4 Bits als Farbe benutzten würdest so 
hättest du noch einen Wertebereich übrig um einen allgemeinen 
Farbabgleich der LEDs zu machen. Es soll ja alles schön gleichmäßig 
leuchten. Diesen Abgleich pro Farbe R-G-B würdest du bei der anderen 
Methode ja über RExt der Register machen. Bei der letzten Methode 
könntest du dafür wiederum jede LED einzeln justieren.


>> Wahrescheinlich nicht, da die HW SPI nur einen Daten Pin hat.

Doch doch, du musst dann eben alle Register seriell verdrahten.

>> Daher auch meine Frage, ob man 3 AVRs nimmt, für jede Farbe einen.

Nee das ist meiner Meinung nach schlecht. Entweder nimmst dann eine 
ordentlich leistungsstarke MCU, wie zb. einen ARM7. Oder bleibst bei 
einem AVR, da er mit 16/20 MHz Takt eigentlich ausreichend schnell sein 
sollte für 16 RGB LEDs. Bei mehreren AVR bekommst du rießige Problem mit 
der Synchronisation. Denn du musst ja das Bild das du darstellen 
möchtest auf 3 AVRs separieren. Langfristig wird das sehr kompliziert, 
es sei denn du möchtest wirklich nur dummpf das gleiche hardcoded Muster 
anzeigen. Wenn du aber bewegte Texte, kleine Bilder, Animationen 
darstellen möchtest so musst du dann das alles auf 3 AVRs aufteilen und 
synchron halten.


>>Ich frag mich nur, wie die von Wall-/Fan Screen, iBall und Co. das
>>machen.
>>Die haben 85 RGB LEDs und bis zu 3000 Spalten.

Kannste dir ausrechnen. 60 Frames pro Sekunde  3000  85 * 3 / 8 = 5,47 
Mega Bytes pro Sekunde an Daten, wobei dann nur 8 Farben darstellbar 
sind.

Das lässt sich nur reduzieren durch Interleaving, sprich Halbbilder oä. 
Zb. stellt man pro Umdrehung nur jede 2'te Pixelspalte dar, oder pro 
Umdrehung immmer nur eine Farbe Rot/Grün oder Blau.

>>Da sollte man wohl doch auf einen anderen Prozessor wechseln!?

Ab einer gewissen Größe muss man den Prozessor wechseln. Das ist eine 
einfache Rechnung um das festzustellen.

Ich hatte an CPLDs gedacht und sogar schon in VHDL einige Lösungen 
erarbeitet und simuliert. Essentiell wieder 3 Shiftregister-Ketten 
jeweils rot/grün/blaue LEDs getrennt. Der CPLD liest ein 20ns SRAM 
selbstständig aus und sendet die Daten an die Register. Transparent 
stellt der CPLD auch noch einen Zugriffsweg für den AVR zur Verfügung. 
Dh. der CPLD und AVR können quasi-parallel auf den SRAM zugreifen 
(deshalb das schnelle 20ns SRAM). Der AVR kann über sein ExtMEM 
Interface also direkt auf den SRAM zugreifen und somit auf den 
Display-Speicher. Der CPLD übernimmt die komplette Ansteuerung der LEDs 
mit der Ausnahme der Sychronisation des Rotors (das sollte der AVR 
machen). Leider reichte ein 128FF CPLD nicht mehr aus. Projekt 
gestorben, da mir FPGAs dafür zu kompliziert sind.

Gruß Hagen

Autor: Tobias Tetzlaff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin mal wieder dazu gekommen, mich meinen RGB LEDs zu widmen.

Ich habe nun folgende Schaltung mit 3 TPIC6C595 aufgebaut.

  PD0--------|---------- Blau
  PD1--------+--|------- Grün
  PD2--------+--+--|---- Rot
             |  |  |
  PD3 -> CS  |  |  |
             |  |  |
  PD4--------|  |  |
  PD5-----------|  |
  PD6--------------|

  PD7 -> SCK

Nun habe ich zwei Fragen:

Wie kann ich die Routine "SPI_Transfer_RGB_Byte" kürzen,
da ich ja vier mal das gleiche tue,
es ändern sich nur die Daten.
Mit einer Schleife, schon klar, aber wie bekomme ich die aten in die 
Schleife?

Wie sollte man bei der Beschaltung vorgehen, um die Daten vernünftig 
auszugeben, damit der Atmel nicht allzuviel umrechnen muss?

Danke für die Hilfe,...

Gruß Toby

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Toby,
ich habe mit LED Treibern jetzt schon viel Erfahrung gesammelt und auch 
schon eine RGB Propellerclock mit den TLC5922 gebaut (sind eigentlich 
die gleichen wie die TLC5923)
ich weiß jetzt zwar nicht wofür du dich am Ende entschieden hast, aber 
wenn du da Unterstützung, Code, Schaltpläne oder Eagle Layouts brauchst, 
sag Bescheid.
Gruß
Kai

Autor: Tobias Tetzlaff (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe gestern in der Eile ganz den Anhang vergessen.

Kai, ich nutze TPIC6C595 Schieberegister, wie schon Beschrieben.
Die TLC Teile sind mir noch zu kompliziert.
Müsste erst damit etwas Testen. ;-)

Gruß Toby

Autor: Tobias Tetzlaff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal, Hallo.

Im Anhang gibt es einmal die "SPI_Transfer_RGB_Byte".
Damit werden 4 Bytes an die Schieberegister üergeben,
Kodiert, wie Hagen es vorgeschlagen hat.
(Dazu auch die Frage, wie man die Funktion kürzen kann,
da ich ja 4x das gleiche tue)

Dann gibt es noch die "SPI_Transfer_RGB_Bytes".
Hier wollte ich die 3 Bytes Red,Gren,Blue übergeben.
Daraus sollten eigentlich 4 Bytes werden,
in etwa so:

Blue:  0000 0000
Green: 0000 0000
Red:   1111 1111
       |||| ||||
       |||| ||Byte4: 00100010
       |||| Byte3: 00100010
       ||Byte2: 00100010
       Byte1: 00100010

Natürlich ist das eine ganz schöne Rechnerei,
aber so hätte man je Farbe ein Byte.

Gruß Toby

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.