C Lauflicht mit nach gedimmten LED´s

[Dirk]

... Genau das selbe

Du castest das Resultat, gerechnet wird wahrscheinlich in int. Da d vom Typ uint ist, ändert sich nichts.

Interessant wäre: caste einmal die einzelnen Operanden mit uint8_t


Ich habe das mal im Simulator gestestet. Alle Variable vom Typ uint8_t.
d hat zum Schluss den Wert 247, also 8bit Überlauf.



CodeBox C

   a = 5;
   b = 14;
   
   d = a-b;  // 5 - 14 = - 9

 

[Janiiix3]

Wie castet man denn einen Operanden? Habe ich noch nie gesehen?

 

[Dirk]

Vor jeden Operanden in Klammern den Typ.

Aber wie schon geschrieben, im Simulator erhalte ich ganz normal einen 8bit Überlauf.
Wenn die Differenz kleiner 0 ergibt, dürfte dein oberer Code nicht funktionieren?!

 

[Janiiix3]

Das ist es ja... Es funktioniert aber...

 

[Dirk]

Ich weiß dazu im Moment auch keine Antwort.

Ich mach mir dazu später nochmal Gedanken.

 

[Janiiix3]

Und zum Casting meinst du - >



CodeBox C

 Uint8_t(-)? 

 

[Dirk]

Du hast das doch schon gemacht ...

(uint8_t)variable

 

[Janiiix3]

Vor jeden Operanden in Klammern den Typ

Unter Operanden verstehe ich...

+, -, & usw.

 

[Dirk]

Unter Operanden verstehe ich...

+, -, & usw.

Das sind Operatoren. Diese verküpfen die Operanden (zum Beispiel deine Variablen a und b).

 

[Janiiix3]

Es ist Freitag.
Die habe ich ja schon alle einzelnd gecastet... Funktioniert trotzdem.

Vielleicht, fällt dir irgendwann noch mal was dazu ein.

 

[Dirk]

Vielleicht, fällt dir irgendwann noch mal was dazu ein.

Es könnte an folgendem liegen ...

Du bildest die Differenz d in Abhängigkeit der Rotation, also der Richtung. Das könnte jetzt so gut passen, dass der Effekt (Schweif hinter der aktiven LED) weiter vorhanden ist. Wenn es einen 8bit Überlauf gibt, ist die Differenz d hoch. Alle LEDs mit dieser Differenz (255, 254 ...) haben dann die Helligkeit 2. Das wären dann ggf. alle LEDs vor der hellsten LED, die sowieso 2 haben sollen.

Um das besser nachvollziehen zu können, müsste ich den anderen Code auch haben ... aber vielleicht kannst du das ja selber mal prüfen.

 

[LotadaC]

Das sieht aus wie ein "Schweif".

Das könnte man ja vielleicht auch so lösen:

Eine Funktion setzt den maximalen Helligkeitswert für einen bestimmten Index.
Eine weitere Funktion (siehe unten) kümmert sich um Dimmen der anderen Helligkeitswerte ausserhalb des Index.

(So etwas ähnliches hatte ich mal bei einem FFT Spektrum mit Peek Hold Werten gemacht, die sich vom Maximum nach einer Wartezeit langsam wieder zum aktuellen Wert bewegt haben)
...

Ich hab quasi den Index mit drin gehabt...

Sollte der Effekt nicht eher so sein, daß man quasi eine LED hin und herwandernd (sagen wir 2 Schritte pro Sekunde) voll an hat, und alle anderen LEDs dimmen je für sich selbst kontinuierlich runter?

Quick'nDirty zählt man Timerüberläufe, bei jedem davon werden alle PWM-Vorgabewerte dekrementiert bis sie Null sind, nur der aktive Kanal wird auf max gesetzt. Läuft der Überlaufszähler über, wandert der aktive Kanal eins weiter oder zurück.

[fehlender Highfive-Smiley]

 

[Dirk]

Sollte der Effekt nicht eher so sein, daß man quasi eine LED hin und herwandernd (sagen wir 2 Schritte pro Sekunde) voll an hat, und alle anderen LEDs dimmen je für sich selbst kontinuierlich runter?

Quick'nDirty zählt man Timerüberläufe, bei jedem davon werden alle PWM-Vorgabewerte dekrementiert bis sie Null sind, nur der aktive Kanal wird auf max gesetzt. Läuft der Überlaufszähler über, wandert der aktive Kanal eins weiter oder zurück.

Ja, nach dem Video von Tommy sieht das so aus. Im Prinzip wie lang nachleuchtende Glühbirnen.
Einen simplen Code hatte ich dazu auch schon mal gepostet.

Im Moment hat Janiiix ja eine andere Lösung. Das mit "kontinuierlich runterdimmen" finde ich besser.

 

[LotadaC]

@me findet wegfaden trotzdem besser

 

[Janiiix3]

Das war einfach nur mal ein Test, sollte für kein Projekt oder sonstiges sein... Hier mal ein kleines Video, damit man das Ergebniss mal sehen kann.

https://www.dropbox.com/s/eb6us8rigqarktb/20161203_114035.mp4?dl=0