I’m not entirely sure how to use Launchpad’s revision control tools (bzr) in Windows or MacOS, but those are both supported platforms. I think both have a few GUIs available too, but I’m not familiar with them.
I just “bzr branch lp:flashlight-firmware” to get a copy of the code, and then otherwise use bzr at the command line to check in new versions or do other common operations. The only GUI part I use is “bzr vis” from bzr-gtk, which is handy for viewing the revision history. It looks like this:
This is all optional though. I’m happy to accept patches and such via email and do all the revision control and publishing steps myself.
This is not email, but wanted to post the enhanced _delay_ms() function here so that it won't get buried to another thread as OT post..
I have seen this "_delay_ms() can't take variables" so many times that it's time to do something for it:
// Having own _delay_ms() saves some bytes AND adds possibility to use variables as input
static void _delay_ms(uint16_t n)
while(n-- > 0)
uint16_t randTime; #endif
// turn the emitter on at a random level,
// for a random amount of time between 1ms and 20ms (* 4/3)
PWM_LVL = rand() % 190 + 10; #ifdef OWN_DELAY
_delay_ms(rand() % 19 + 1); #else
randTime = rand() % 19 + 1;
while(randTime–) // _delay_ms() can’t take variables that can change, make loop with variable instead
_delay_ms(1); // and delay_ms with fixed value within loop #endif
// turn the emitter off,
// for a random amount of time between 1ms and 1000ms (* 4/3)
PWM_LVL = 0; #ifdef OWN_DELAY
_delay_ms(rand() % 999 + 1); #else
randTime = rand() % 999 + 1;
In this example, using own delay saved us 16 bytes (with -Os) and made the code cleaner.
This is good stuff. It should probably replace the standard _delay_ms() in every firmware which calls _delay_ms() more than once. On one of my STAR derivatives, this delay function saved me at least 140 bytes.
The parameter sent to _delay_loop_2() is also a handy thing to change per-driver if you want more accurate timing, since it can be calibrated for each individual chip. I’ve tried it on three now, and the value has been anywhere from 890 to 950 if I want _delay_ms(1000) to be reasonably close to one second.
I suppose I should probably update STAR with this. I may need to upgrade my avr-gcc first though, since what I have now compiles STAR to about 1060 bytes instead of 1024.
I posted this in the random flash thread, but can post it here too:
I did a shorter one some time ago so you don’t even have to include delay_basic.h. I basically just ripped out one of the assembler loops from delay_basic.h. The variable entered does not resemble a nice even millisecond value, like 1 or 10 ms or similar, but I don’t need exact millisecond numbers, I only have to adjust the value until I like what I see.
By the way, how did you post your code? It looks like code, when I try to paste in my code it looks like garbage so I post images instead. How did you get it formatted nicely like that?
Helios made me a kewl Roche F6 driver (momentary switch) with two battery level indicators, but I have zero clue how to add whatever to the FW to make them work. They're run by MCU pin 3 & pin 5, circuits for both are totally separate so it's possible to use them one at a time or both together, to get a third color. Any suggestions for what the LEDs should do? Keep the original low voltage behavior (blink + ramp down) or ditch it?
Depends on your preference I suppose. In order to get the most mileage out of those indicators it seems that removing the ramp/step-down makes sense. Replace that with warning indications… but really I probably wouldn’t do it unless I could make the indicators pretty visible.
OTOH there’s nothing wrong with having both systems in place - a red indicator is just a confirmation that the stepdown is due to LVP.
Bump. I could still use some help with this. Even if I hookup PB1 to the PWM input on the LD-29, I would still like to know about how this would be done. I have another project (17mm DD+7135 — linear regulated driver w/ FET turbo) which would benefit from the ability to use two PWM outputs (not simultaneously). The PCB for that project is already laid out for using both PB0 and PB1.
Dunno, but I’ll be quite happy if anyone has an answer… because when I get time I’d rather like to make a RGBW light with each color controlled individually… and I’m hoping I can use PWM arbitrarily on any two colors at the same time (most likely will need a better MCU though, with two PWM channels).
It might be a while before I can start on that though… too many other projects.
Sorry guys, was hoping someone else would chime in ;)
I've never changed the PWM from PB1 to PB0, but it looks like, along with what you changed already, you need to change TCCR0A to this...
TCCR0A = 0x83; // phase corrected PWM is 0x81 for PB0, fast-PWM is 0x83
That's my guess looking at the datasheet, which I've never been the best at reading. I just searched for TCCR0A and the first two bits relate to COM0A (PB0), and the next two bits relate to COM0B (PB1). So instead of it being "0010", it's "1000".
An outstanding thing for me to look into for RMM is the ability to change the PWM output pin based on the mode selected (so you could have a single 7135 on one pin, the rest on the other), and/or be able to change the PWM mode between phase correct and fast PWM based on the mode as phase correct does a better job with lower levels. I'm sure this was discussed before, I just haven't been paying attention lately :(
Thanks JonnyC, I’ll try that and continue to poke around in that vein if it doesn’t work by itself.
If there was a discussion about the minimum level that Fast PWM vs Phase Correct PWM could sustain, I missed it too.
I was thinking of using a 2D array to store pin states (including PWM levels) for modes. I think that could be implemented in a reasonably flexible way in order to facilitate drivers which need to do various pin sequences for modes. We currently have drivers with one PWM pin, plus drivers which operate like the DQG 26650 driver (a run pin + several pins which should be turned on exclusively for different modes), and in the future I’d really like to have a driver which operates the way I described here (#32). I think it might be possible for us to describe the modes for each of those drivers (plus the DD+7135 one I linked to before) using the same array format.
OK, so, what did you copy it from? Notepad? Was 'word wrap' enabled in notepad when you copied it? Atmel Studio chokes on the line breaks if you paste in source that's using 'word wrap'. That frequently causes those kind of errors - some variable ends up being placed on a new line by itself when it really belongs at the end of the previous line. 'Word wrap' is the cause of that.
Also, your screenshot is not showing the line with the error in it (line 59), please take another shot showing what's on line 59 (double click the entry in the 'errors' list at the bottom, it will scroll the upper window to the problem line automatically).