I think this bahaviour caused me a confusing question.
I wont call this a bug, as the resulting glow may very well be a result of how it was wired, and how PWM is accomplished. Or even a bug in my code.. ??
While I do think a Esplora.writeRGB(0,0,0) should result in the LED being in the same state as after a reset (no glow at all), my first instinct was not to come here damanding it be changed - tho it would be nice; instead I started thinking/poking around (blindly) and it occurred to me the 'Esplora' part of that func call, may be causing the execution of code that's not apparent to me.
For instance, perhaps some constructor like code is executed? Now I realize the Serial lib has the 'begin' func, that seems to be the constructor like code I am talking about, but there is no 'Esplora.begin()'. As it seems the Esplora lib is just 'helper' funcs to make it easier to read the onboard peripheral sensors and use one function to set 3 IO pins (red, green and blue). But I have made wrong assumptions before.
Why am I asking.?
I imagine very different impacts from my doing things like - using pinmode to set those RGB LED PWM outputs to inputs for the purpose of extinguishing the LED completely - depending on how the lib was written (always verifying a pins mode prior to using it - vs - assuming it was set once before, and trust its the same)
Am I correct in that assumption, that it could be anything from benign to catastrophic to do things like setting a pins mode 'behind the libs back' so to speak? And - Am I correct in presuming - because of memory limitations, as a general rule, presume 'catastrophe' as 'trust' in previous settings takes no memory, like verifying does.?
Simple question: How safe is it for me to play with pinmodes on the Esplora (setting that pin to input - and still be able to use writeRGB() as is - and how did you figure out how to answer that previous Q?
However, an Input pin will float, and there may be sufficient current for the LEDs to appear on, more so if the internal pullup resistors have been enabled as well.
If you really want to control the levels, the pins should be Outputs and set either High or Low.
Yes, this much was apparent that the language allows this - tho not-obvious from the pin labels hiding pin#'s within the lib. I presume this may not be an accident - to keep the less informed (like me) away from doing such things.
However, an Input pin will float, and there may be sufficient current for the LEDs to appear on, more so if the internal pullup resistors have been enabled as well.
If you really want to control the levels, the pins should be Outputs and set either High or Low.
I thought I seen elsewhere - set to input for high impedance - but ok, I think this can work too. Tho, when I was asking - I had in mind using input as an my example - as I am considering attempting bi-directional coms using an RGB LED. Like;
I do not want to muddy the waters, but I discovered a similar issue a while back.
I wonder if the underlying timers are in FastPWM mode? There is a known condition in the ATMega that could cause your LEDs to remain dimly lit if you set the Output Compare Register (AnalogWrite) value to 0 and the timer operating in FastPWM mode.
Here's a note from the ATMega328 datasheet:
The extreme values for the OCR0A Register represents special cases when generating a PWM
waveform output in the fast PWM mode. If the OCR0A is set equal to BOTTOM, the output will
be a narrow spike for each MAX+1 timer clock cycle. Setting the OCR0A equal to MAX will result
in a constantly high or low output (depending on the polarity of the output set by the COM0A1:0
bits.)
Good catch decep, I figured it was because of something like this...
Which sorta still leads to the crux of my question, how would my changing this affect the rest of the lib or (perhaps the arduino has a runtime lib it uses - and this could have an affect on - like delay() or millis() from changing that from fastPWM.)
Ive been looking for warnings (no success), so I guess I am a bit paranoid/misunderstanding the differences between C on a PC and what gets uploaded when uploading my sketches... so much verbosity during the compilation offering many warnings that are OK (compiling completes, sketch operates as expected) - these are new 'its not quite right, but its still ok' scenarios that differ from those I am more familiar with.
When programing C for AVR/Arduino, it is probably more akin to "driver development" than "software development". Instead of writing a program which the OS executes and manages, you are running directly on hardware. And, as you have pointed out, debugging is extremely difficult since there are no true debugging facilities (technically there are, but requires additional hardware).
Regarding millis() and delay(), you just have to understand the operation of the timers. Fast PWM, the timer counts from 0 to 255 and then resets to 0 (256 steps). Regular PWM counts from 0 to 255 and then counts back down to 0 (512 steps).
There is also a prescaler setting for the timer. The timer will increment every X number of CPU ticks the prescaler setting is set.
"64" is for the prescaler. "256" is due to FastPWM.
The timer used for millis() and delay() has a /64 prescaler by default and FastPWM mode. If you were able to change the timer to Regular PWM mode, you would change the above code to
This seems like a really dickish thing to say, but RTFM. Arduino does a good job of getting you started, but if you ever want to know the "whys" get really intimate with the hardware, the datasheet is the only place to go.
Personally, I wish the Arduino code was documented a little better. I also wish the code were a little less implicit in nature. Arduino originally targeted and assumes the ATMega8 MCU family by default and then there are a bunch of if/else statements to support other MCUs like ATMega1280/2560 and now ATMega32u4.
I will also add that changing that code does not change the timers. That code just needs to match the timer settings so the millis() and delay() will operate properly.
Arduino does a good job of getting you started, but if you ever want to know the "whys" get really intimate with the hardware, the datasheet is the only place to go.