I don’t know how much time anyone else put into it, but I know I worked on it quite a bit. I did a major refactor of the entire code base, rewrote half the FSM code, built an entire new system for handling multiple MCU support, and of course also added a new MCU. I’m not even done yet, really… there are still some pretty major changes to do for proper support, like rewriting the timer and scheduling systems and button handling. But what it has now is at least good enough in the short term.
FSM has always been a big pile of spaghetti code, as it says in the name… it’s a F’ing spaghetti monster. Each previous MCU was kind of just kludged in. But for adding AVR DD, I rewrote all that, untangled large amounts of spaghetti, and I’m working on making the whole thing a lot cleaner and more robust.
I hope to see more lights using AVR DD in the future. It’s a really nice MCU and works quite a bit better than older models.
… are almost always the first thing people bring up when they haven’t really looked into the details and thus don’t realize that the power use is orders of magnitude too high.
On the primary light I use daily, the aux LEDs can run nonstop for about 6 years per charge. With neopixels though, they probably wouldn’t physically fit due to size, and they would drain the battery in just a few days.
To be viable for a torch’s always-on aux LEDs, a proposed solution needs to have less than 0.100 mA of overhead beyond what the LEDs use, and the LEDs need to go down as low as 0.050 mA. That means a total standby power of 0.200 mA or less, while the aux LEDs are lit up. The solution I’m using right now is just 0.086 mA total.
There are small ones of the same size as the RGB LEDs commonly used (1.6x1.5mm), and other branded ones even smaller like 1x1mm, but they all have the same high power consumption, so like you said it’s not a viable solution.
I didnt mean the individual neopixels but theres a neopixel driver thingy that can be connected to normal rgb leds… but that orobably still has a lot of power draw. Also did i just read multi-mcu support?
Oh i thought multiple mcus at the same time. Some flashlights use a secondary mcu in the tailswitch so the tube doesnt need a double wall. Its cool if you can implement it in a small enough design.
Oh thats nice. I started learning how to use kicad properly a short while ago. I ran into a little problem as it crashes my compositor on linux but yeah.
Usually I’ve found Eneloops give better run-times than 14500, interesting to see that that’s not the case with this driver. Will have to order a couple of 14500s!
Self taught mostly: online electronic courses, articles and app notes…etc.
For Kicad I found it pretty easy to get the hang of it, and there are a lot of online resources, tutorials etc.
