- LiFePO4 Speicher Test         
Seite 4 von 7 ErsteErste ... 23456 ... LetzteLetzte
Ergebnis 31 bis 40 von 63

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

  1. #31
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.645
    Anzeige

    LiFePo4 Akku selber bauen - Video
    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.

  2. #32
    HaWe
    Gast
    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!

  3. #33
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.645
    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.


  4. #34
    HaWe
    Gast
    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.

  5. #35
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.645
    Da habe ich noch byte gefunden:

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

  6. #36
    HaWe
    Gast
    das ist doch wurscht, byte == uint8_t

    bitte testen und Serial Meldungen posten!

  7. #37
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.645
    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

  8. #38
    HaWe
    Gast
    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.

  9. #39
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.645
    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”
    Geändert von Moppi (10.09.2018 um 21:56 Uhr)

  10. #40
    HaWe
    Gast
    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...

Seite 4 von 7 ErsteErste ... 23456 ... LetzteLetzte

Ähnliche Themen

  1. String nach Array umwandeln (?)
    Von slavezero im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 3
    Letzter Beitrag: 07.06.2012, 17:21
  2. Chips die nach Seriell umwandeln
    Von dundee12 im Forum Elektronik
    Antworten: 13
    Letzter Beitrag: 12.08.2010, 09:08
  3. word nach byte umwandeln
    Von magic33 im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 10
    Letzter Beitrag: 21.02.2007, 16:04
  4. C-Code in hex umwandeln
    Von elkokiller im Forum C - Programmierung (GCC u.a.)
    Antworten: 2
    Letzter Beitrag: 16.02.2006, 09:41
  5. PAL-Videosignal irgendwie nach seriell umwandeln?
    Von Trabukh im Forum Elektronik
    Antworten: 39
    Letzter Beitrag: 14.09.2005, 13:15

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

12V Akku bauen