Farben nach R,G,B umwandeln in 4-stell. hex-code?

Schau noch mal im letzten Beitrag vor Deinem. Habe es geändert.

Allerdings glaube ich auch, dass das

Code:

---

R = (uint8_t)R;

---

überflüssig ist. Weil der kleinste Typ, den der Arduino kennt, ist: integer
Er würde den von Dir geglaubten 8-Bit-Wert vermutlich als Integer ablegen/speichern. So, wie er nach der Berechnung schon vorliegt.

das habe ich verstanden und auch so gemacht.
aber nein, der kleinste Wert ist uint16_t , nicht int, denn int ist bei mir int32_t (ARM Cortex M0 = Arduino M0/Zero), deshalb ist es immer explizit auf uint16_t oder uint8_t gecastet.

Tipps sind wirklich sehr willkomen, aber bitte immer vorher selber testen!

Na ja, ich hatte geschrieben: "vermutlich" und vorher schon, dass ich mich mit den Typen nicht so genau bei den Teilen auskenne.

Aber um das aufzuklären: Gibt es noch ein Problem?
Und welchen Tipp sollte ich testen - was soll ich da testen? - k.A.

:-)

Der Code soll mit dem expliziten Casting damit eben auch auf 8bit Arduinos lauffähig sein.

Teste einfach meinen Testcode, in den du deine Algorithmen einsetzt, du bekommst dann ja über Serial die Debug-Informationen zur Kontrolle.

Da habe ich noch byte gefunden:

Code:

---

  R = byte((color16 / 2048)*8);
  G = byte((color16 & 2016)/8);
  B = byte((color16 & 31)*8);

---

das ist doch wurscht, byte == uint8_t

bitte testen und Serial Meldungen posten!

Spuckt genau dasselbe aus.

Falls der Controller nur 8 Bit beherrschen würde, müsste man die 16-Bit-Farbwerte getrennt in Low- und High-Byte (MSB und LSB) ablegen und anders rechnen.

Code:

---

Hauptprogramm vor Aufruf:
col16=0
r=255
g=102
b=78

Hauptprogramm nach rgb zu col16-Berechnung (rgb gelöscht):
col16=64297
r=0
g=0
b=0

Unterprogramm color16 zu RGB:
color16=64297
R=248
G=100
B=72

Hauptprogramm nach col16 zu rgb:
col16=64297
r=248
g=100
b=72

---

Der Grund ist doch klar:
ein 16bit Integer dividiert durch 2048 ist gleich >>11, und damit immer ein 5bit Wert, und passt damit immer in ein 8bit Byte.

warum sollte die MCU nur 8 bit beherrschen? die 8bit AVRs rechnen bis zu int32_t, und die 32bit MCUs bis int64_t.
Ich bin mal auf Ceos' Lösung gespannt, aber ist ja eh nicht so schrecklich eilig.

Im Übrigen war es die falsche Schreibweise, die zu den merkwürdigen Ergebnissen führte:

Code:

---

     
  R = (uint8_t)(color16 / 2048)*8; ;
  G = (uint8_t)(color16 & 2016)/8;;
  B = (uint8_t)(color16 & 31)*8;

---

was immer die Schreibweise (uint8_t) bewirken sollte. Hier hast Du offenbar uint8_t nur auf die Folgeausdrücke angewandt. Also:

Code:

---

uint8_t(color16 & 2016)

---

und das dann durch 8 dividiert. Du stampfst

Code:

---

(color16 & 2016)

---

auf 8 Bit ein (obwohl Du an der Stelle noch 16 Bit brauchst - eigentlich nur 11). Richtig wäre die Schreibweise und Funktion, die Du wolltest, so:

Code:

---

  R = uint8_t((color16 / 2048)*8);
  G = uint8_t((color16 & 2016)/8);
  B = uint8_t((color16 & 31)*8);

---

Allerdings habe ich woanders gelesen, dass man statt uint8_t() lieber byte() verwenden soll. Wäre der bessere Stil (kann man sehen wie man möchte):

"An unsigned char data type that occupies 1 byte of memory. It is the same as the byte datatype. The unsigned char datatype encodes numbers from 0 to 255. For consistency of Arduino programming style, the byte data type is to be preferred."
Arduino: Difference in “Byte” VS “uint8_t” VS “unsigned char”

nein, das stimmt doch nicht, was du schreibst:
ich habe deine gesammelten Codes in allen erdenklichen Klammerungen getestet, auch der obigen, und es hat nie funktioniert. Da du nie vollständigen Code gepostet hast, habe ich das tatsächlich hier und da ggf missverstanden, aber deine andere Klammerung von oben per
R = uint8_t((color16 / 2048 )*8 );
G = uint8_t((color16 & 2016)/8 );
B = uint8_t((color16 & 31)*8 );
hat ja auch nicht funktioniert.

Wenn du allerdings einen funktionierenden, kompilierfähigen Arduino-Sketch hast, selber von dir getestet, stelle ihn gerne ein, ich bin sehr gespannt.

byte ist i.Ü.auch nicht "besser", es ist einfach nur Arduino Kauderwelsch,
hingegen uin8_t usw. sind die stdint-Dateitypen u.a. auch für C++11 ,
und weil Arduino den gpp mit C++11 verwendet, funktioniert das selbstverständlich 100% standardgemäß.

Und das funktioniert dann auch ohne weiteres auf dem Raspi mit gcc/g++, wenn man will - im Gegensatz zu byte, das müsste man dann erst mal neu definieren als #define byte uint8_t.

übrigens heißt es nicht
uint8_t ((color16 / 2048 )*8 );
sondern
(uint8_t) ((color16 / 2048 )*8 );
denn für type casting schreibt man in C den Ziel-Datentyp in runde Klammern.
Aber auch DAS habe ich getestet, ebenfalls leider mit falschem Ergebnis, aber trotzdem herzlichen Dank für deine Ideen!

Und wie gesagt, ich freue mich auf einen funktionierenden, kompilierfähigen Arduino-Sketch von dir, vorher selber von dir getestet... 8)