Zwar konnte man sich 'value' im Debugger nie anschauen (das war der
eigentliche Grund dafür) aber es hat funktioniert.
Jetzt wurde das Ganze um die Helligkeit erweitert:
Und ich seh im Debugger, das zwar die erste Zeile (brightness_pwm_val)
aufgerufen wird, er aber sofort weiter auf die if Bedingung springt und
der brightnessFactor 0 ist. Heißt für mich, dass er den Wert ausm
Speicher nicht lesen kann.
Ich versteh nicht, wieso das der Fall ist - wie gesagt ist der Code
mittlerweile zu 99% identisch mit dem WordClock Beispiel - aber trotzdem
geht was schief... Außerdem läuft die erste Version ja auch...
Kann mich einer mal drauf hindeuten...
Achso, testen tu ich aktuell mit red/ green/ blue = 100 und brightness =
20, also alles im 'normalen' Bereich
Danke
Nico
Warum benutzt du read_word wenn doch nur Bytes in der Tabelle stehen?
Ein uint8_t ist immer >= 0, den Test kannste also sparen → Warnungen
aktivieren und beachten.
Warum ich damals read_word genommen hatte weiß ich ehrlich gesagt nicht
mehr - da es funktioniert hatte hab ich mir nie Gedanken drüber gemacht.
Compiler Warnungen sind aber alle an (-Wall) - allerdings sind die auf
0.
Ich bin mittlerweile auf dem AVR Studio 5 - hier kann ich leider die
Parameter nicht händisch ändern. Und -Wextra ist bei den Warnings nicht
dabei... Aber auch pedantisch bringt keine anderen/ neuen Warnings
(naja, zwei Stück - die haben aber hiermit nix zu tun).
Ich hab oben nebenbei mittlerweile auch auf pgm_read_byte gewechselt -
macht aber keinen Unterschied...
Nico B. schrieb:> Jetzt wurde das Ganze um die Helligkeit erweitert:> Und ich seh im Debugger, das zwar die erste Zeile (brightness_pwm_val)> aufgerufen wird, er aber sofort weiter auf die if Bedingung springt und> der brightnessFactor 0 ist. Heißt für mich, dass er den Wert ausm> Speicher nicht lesen kann.
Es kann genauso heißen, daß er brightnessFactor wegoptimiert und
stattdessen direkt brightness_pwm_val nimmt, weil das eh den gleichen
Wert hat.
Wie sehen denn die Werte PWM_RED u.s.w aus? passen die zu den
übergebenen Parameterwerten?
Ja, die übergebenen Werte passen alle...
Wie gesagt, mit der alten Version (ohne Helligkeit und dem pgm_read_word
Fehler) lief es ja, deswegen hatte ich mir nie Gedanken drum gemacht...
Bezüglich des wegoptimieren - das hatte ich auch schon mal überlegt und
deswegen schonmal einfach um 1 inkrementiert etc - mit dem gleichen
Resultat.
Markus C. schrieb:> value = pgm_read_byte(&pwm_table[green])
Das nur eine andere Schreibweise, macht aber genau das gleiche wie:
1
value=pgm_read_byte(pwm_table+green);
Das folgt daraus, daß pwm_table[green] das gleiche ist wie
*(pwm_table+green).
Nico B. schrieb:> Ja, die übergebenen Werte passen alle...
Meine Frage war aber, ob die Ergebniswerte zu diesen passen, oder ob
trotz sinnvoller Eingabewerte ein falsches Ergebnis rauskommt.
> Bezüglich des wegoptimieren - das hatte ich auch schon mal überlegt und> deswegen schonmal einfach um 1 inkrementiert etc - mit dem gleichen> Resultat.
Nun, so leicht kannst du den Optimizer nicht austricksen. Der Compiler
hat ja keine Notwendigkeit, den alten Wert zu behalten, da er danach
nirgends mehr benutzt wird.
Du kannst brightnessFactor zum Testen mal volatile machen. Dann muß er
die Variable in realem Speicher anlegen.
Anstatt weig mit einem Debugger rumzufutscheln wo man nur sieht, daß
irgendwas schief läuft, tut es ofmals ein Blick in den erzeugten Code.
Da sieht man dann, warum es nicht so läuft wie andedacht, und die
Fehlerquelle ist rasch beseitigt.
Im Beispiel verhalten sich rot und grün richtig - blau macht Murks...
Bitte nicht über das viele Gerümpel motzen - das war rein für mich zum
testen. Trotzdem bleibt: via volatile bekomm ich endlich meinen Debugger
Output und die Werte passen. Ohne funzt es nicht - zumindest ist das
Verhalten an der TestLED nicht das 'erwartete' (weiß net, wie ichs
anders beschreiben soll).
@Rolf: damit auch die Antwort auf die falsch verstandene Frage: nein,
das setzen der PWM hatte nicht funktioniert. Die Eingabeparameter waren
korrekt - aber das Leuchtverhalten aka Pulsbreite der PWM war falsch.
Deswegen hatte ich mitm debuggen angefangen.
@Johann: ich hab beim AVR Studio 5 mal nachm ASM Output gesucht - bisher
aber nicht gefunden. Weißt du ausm Stehgreif, wo ich die Settings dafür
finde (hab noch nicht nach gegoogelt).
Nico B. schrieb:> @Johann: ich hab beim AVR Studio 5 mal nachm ASM Output gesucht - bisher> aber nicht gefunden. Weißt du ausm Stehgreif, wo ich die Settings dafür> finde (hab noch nicht nach gegoogelt).
Ich verwende kein AStudio. Braucht kein Mensch ;-)
Compiler-Optionen: -save-temps -fverbose-asm -g0
Nico B. schrieb:> volatile uint8_t value_green = ((brightnessFactor * green)/256);> uint8_t value_blue = ((brightnessFactor * blue)/256);Nico B. schrieb:> Im Beispiel verhalten sich rot und grün richtig - blau macht Murks...
Ich hab' mir nicht alles durchgelesen. Aber warum muss value_blue nicht
als volatile deklariert werden?
Ralf G. schrieb:> Nico B. schrieb:>> volatile uint8_t value_green = ((brightnessFactor * green)/256);>> uint8_t value_blue = ((brightnessFactor * blue)/256);>> Nico B. schrieb:>> Im Beispiel verhalten sich rot und grün richtig - blau macht Murks...>> Ich hab' mir nicht alles durchgelesen. Aber warum muss value_blue nicht> als volatile deklariert werden?
Im Grunde muss gar nichts davon als volatile definiert werden, ess ei
denn man möchte die Variblen unbegindt im Debugger sehen und daher den
Compiler daran hindern sie einfach wegzuoptimieren.
Entweder das ist ein sauberer Bug im Compiler, oder aber da ist im
Programm noch ganz was anderes faul, was man aber an den Ausschnitten
nicht erkennen kann. Ein komplettes Programm wäre gut, damit das mal wer
nachvollziehen kann.
@Ralf: Das hatte ich nur fürs testen so gemacht, ums einfacher
unterscheiden zu können bzw. um zu gucken wie sichs im Debugger verhält.
Eigentlich wars setzen des Timers via pgm_read, via volatile
Variablenzuweisung und einmal wie vorher (blau). So wars für mich
einfacher, die Unterschiede zu sehen...
@Werner: Ich check mal die Compilersettings bezüglich C++ - und änder
das array zu const. Macht ja auch Sinn...
Super, danke generell für die vielen Hinweise...
