This forum has moved to forum.jeelabs.net - this read-only archive is for reference only!
I have a question about this sketch:
Specifically about the masking part:
// which setting affects which I/O pin: // bits 0..3 = AIO1 .. AIO4 // bits 4..7 = DIO1 .. DIO4 static const byte masks[NVALUES] = { 0x01, 0x10, 0x80, 0x08 };
Can someone explain those pin numbers? I must be overlooking something.. the i/o pins defined translate to weird pin numbers for example 128. What am I missing?
It's a complex mapping.
DIO1..DIO4 are Arduino digital pins 4..7, are ATmega PORTD pins 4..7, are bits 4..7 in the PORTD I/O register, are 0x10, 0x20, 0x40, 0x80 as bit masks.
AIO1..AIO4 are Arduino analog pins 0..3, are ATmega PORTC pins 0..3, are bits 0..3 in the PORTC I/O register, are 0x01, 0x02, 0x04, 0x08 as bit masks.
These 0x01..0x80 values are not pin numbers but bit masks in the ATmega ports.
As it so happens, these bits all fit together into a single byte. When you take the top 4, you get the bit masks to use for PORTD, while the lower 4 are bit masks for PORTC.
Perhaps this example helps clarify: to set DIO3, you can do "Port(3).digiWrite(1)", which is the same as using Ardiuno's digitalWrite(), i.e. "digitalWrite(6, 1)" since DIO3 is Arduino digital pin 6. Internally, that translates to setting pin 6 of Port D, i.e. "bitSet(PORTD, 6)", which in turn is the same as "PORTD |= bit(6)". That's the same as "PORTD |= 1<<6". Which is also the same as "PORTD |= 0x40". So "DIO3 equates to 0x40" as bit mask, loosely speaking.
Maybe all this just confuses even more. All I can say is: I didn't invent the Arduino pins, I just use them. I want to have 4 equivalent interfaces on a JeeNode, so I assigned one digital and one analog pin to each one (and another digital pin to IRQ, but it's the same pin on all the interfaces). But this means that the Arduino's pin numbering conventions are a bad match for JeeNodes.
Somewhat tangential note: calling those 4 interfaces on the JeeNode "ports" is a bit confusing, given that the ATmega also calls its hardware I/o registers ports. The two are not related.
The reason for all this trickery, is that I can't use digitalWrite() for software PWM on 4 channels, since that would be too slow and cause the LEDs to flicker. Then again, maybe it's more convenient to start off with digitalWrite() anyway, and implement what you need. Once it all works as intended, you can optimize it to get rid of the digitalWrite's. See
Thanks JC! Really clear explanation.. this also helped
Blue LED permanently on sounds like a serious problem. Don't have enough experience with the latest JU v3 to understand what it could be.
(new batch of JU's coming in on Monday)
I'm witnessing some flickering of leds when using the software rgb pwm control. Besides jcw's cats, I wonder if anyone else is having the same situation?
I know I could measure the PWM with a scope and test other things, but instead decided to get the dimmer plug that surely solves the slight flickering situation.
Yes, I've had comments about that here too - although I can't see it (perhaps a certain dim setting brings it out?).
My plan is to keep the same scan frequency, but lower the max value to 100, i.e. cycle from 0 to 100 i.s.o. 0 to 255. I have no need for brightness adjustments finer than 1% and this will automatically increase the refresh rate by 2.5 times.
A Dimmer Plug definitely would work too, as it uses much higher rates.
I boosted the power supply, changed to different FETs but still not acceptable due to flickering.
Ordered the dimmer plug right after jcw's summer break but tested the plug with the strips just today. WOOOT, my brain feels soo good with the high-frequency PWM. Just very very pleasing.
I don't know if you all have something different in your setups, I just could get it right with the software PWM.
It would be interesting to find out whether your high freq PWM setup generates more heat in the MOSFETs, due to switching losses.
Bringing the max brightness value down to 100 solved it for me - refresh rate is now some 300 Hz, I think. FWIW, I can't see any flickering, no matter how quick I make my eyes/head move to try and get a moving POV pattern. More in this in the upcoming weblog post.
Hmm, haven't considered changes in the efficiency of the MOSFETs due to switching frequency. That must also depend on the specifics of each model.
Still about the flickering with the software PWM code: I noticed that I have been testing this with an older JN that has an ATMEGA168. Is is somehow slower than 328s and could this cause some flickering, perhaps due to interrupts of the radio code?
Just wondering, at the moment I'm more than happy with the dimmer plug, only need to learn a bit more about the capabilities of the chip and how to control it beyond the examples given.
> older JN that has an ATMEGA168. Is is somehow slower than 328s
Exact same speed: 16 MHz. It's not a 486 vs Pentium vs Core change :) - just more memory.
Yes, interrupts do interfere with the software PWM. But you'd have to have very very constant traffic to even see it, I suspect.
But you're right, hardware PWM will have none of these artifacts.