Sounds good in theory, but that’s not how electronics work unfortunately. AVR ISP is pretty good in comparison to all the other interfaces out there. You also have to account for the limitations of the hardware. We’re talking about pretty generic, powerful, low-cost microcontrollers without the resources for a separate management unit. Also the old ATtiny series is more than 20 years old, building on top of much older architecture.
4 Thanks
Sounds really bad in practice 
But then it’s one more nail in the coffin of MCUs not supporting UPDI, specially since the AT1616 (that, in addition to UPDI, also has a internal calibrated-from-factory thermal sensor) can in practice be had for less than even the sorry-old AVR PICs.
In practice we are still using all kind of serial or parallel busses with protocols more than 50 years old. From that perspective ISP is modern. On the other hand we could come up with much better protocols, but keep in mind that products are used for more than a few years and you have to maintain everything.
I don’t really care whether it’s AVR ISP or UPDI. Both are very special, low-level serial busses for some AVR microcontrollers, more specifically for configuring and programming them. I think you are worrying about details that don’t really matter.
1 Thank
Yeah, sorry, those lights have unique driver styles which require hardware-specific code, and the code fork is really old, so it would take a bunch of non-trivial adapting and I’ve never been able to obtain hardware to use for development and testing.
Fireflies used to be really good about sending me hardware, but I haven’t really heard anything since they started using regulated drivers. I hear they’ve also been having major issues with production so a bunch of their products haven’t been available for a long time.
So there’s no support for those in mainline Anduril. Updating them is going to be a lot more difficult than just downloading a new .hex file.
The code has been refactored quite a bit to allow it to support newer and more complicated lights with more features. Even single channel lights now use the multi-channel API.
This doesn’t just help with lights using multiple different sets of LEDs. It also allows much deeper and more powerful customization for each hardware model. Old code had a single function in FSM which handled all lights, and it had a bunch of #ifdefs to determine which lines to execute… and it was a big mess which was holding back driver circuit development. With the multi-channel API though, each light can define its own hardware-specific functions which do anything it needs. It’s cleaner, easier, and more powerful.
The multi-channel branch also, of course, improves support for multiple channels and channel modes. Navigating through a large set of channel modes is still a bit clunky, but it’s quite a bit better than not having them at all.
Anyway, multi-channel is getting merged into the anduril2 branch very soon, since I finally finished it yesterday.
2 Thanks
I agree that this seems like an overreaction to a pretty minor implementation detail. AVR ISP is pretty good at what it does, and UPDI is even better. They allow flashing firmware quickly and easily using really cheap generic parts, and the most impactful difference between the two is the number of pins. UPDI uses half as many pins so it’s easier to fit onto small circuits.
The rest doesn’t really make a difference in practice. If your hand slips mid-flash, one reports the error a few seconds sooner than the other, but in both cases you just re-position and try again.
1 Thank
Yes, I released new builds for every supported model. I finally finished the multi-channel branch, with every build target converted to the new APIs… so that meant it’s time for a batch of .hex files and now I can merge it into its parent branch.
The next priorities are:
- AVR DD support
- Github
- Major re-org of all the project files
I got an AVR DD dev kit yesterday and hope to get that working pretty soon… which is a prerequisite for the next generation of Anduril lights. It’s the direct successor to attiny1616, with upgrades to almost every MCU feature… and plenty of space for years of development and new features.
Also, the project is long overdue for a move to Github. Bzr and Launchpad have both been neglected for a long time, and Git + Github are much more convenient for almost everyone who wants to contribute. So I expect to move to a new platform ASAP.
As part of the Github move, I also plan to split FSM+Anduril into their own project which is separate from the larger flashlight-firmware repository. It needs a bunch of changes to give it a saner project structure, and to make it compatible with Github-isms… and while I’m doing that, I also plan to totally restructure how the files are organized.
The plan is to model it loosely on how QMK is organized, because QMK is a similar project but much more mature and robust. Anduril supports half a dozen manufacturers and like a hundred different hardware models… while QMK has ~895 manufacturers, ~2422 hardware models, ~7226 keymaps, and a powerful system for user-specific configurations. This type of organization would make it way easier for people to create and maintain their own custom versions, and many of those could ideally also be included in the main repository.
…
And, of course, keep adding support for new lights as they come out. There are a few exciting ones in progress.
9 Thanks
Congratulations and thank you 
Thanks for the big update and all the hex files @ToyKeeper !
The only models that I am missing hex files for are the Wurkkos TS21 (early production runs didn’t have any flashing pads, but later and current ones do) and the FWAA.
The FWAA is of course a bit of a problematic case. Lumintop threw whatever seem to be working at the light, it came with some sort of modified fw3a-219 firmware (it blinks out the product code 0312). Plus there are at least two hardware revisions of the driver, marked “FWAA-M V1.1” and “FWAA-M V2.2” (the later one has 2 resistors less on the battery facing side).
This is all a bit of a mess, so I don’t know if a newer firmware is feasible.
Unfortunately I am having trouble with the fw3x-lume1 build (0314).
The next channel mode for the number blinks doesn’t work (3C during battery check in advanced mode), not sure if this is a bug or if it is disabled intentionally as the lume1 driver could potentially be installed/used without the RGB board (@Light_Veteran has also found this problem).
But more importantly the temperature regulation doesn’t seem to work correctly.
What I did was the following: flash current hex file, factory reset, switch to advanced mode, turn light on (1C), go to turbo (2C). Then I just let it run for a while. The light doesn’t step down (the brightness only drops a little bit due to temperature sag) and gets incredibly hot. When I stopped the test after a few minutes I could barely hold the light and the the temperature check blinked out 69°C.
I also tested the hex file that @dmenezes provided in the other thread with the same result (this time the temperature check blinked 65°C because I didn’t let it run as long).
Am I doing something wrong? or is there a bug in this build?
Might this have something to do with the fuses? Do they need to be set in some specific way? I vaguely remember reading something about fuses, but I am not sure when or where (plus I never had to set any fuses for flashing any other light).
Probably it’s a bug because Aux work in other mode, also I have FW3X and FW3A with Lume1 so they have different aux and both do not work
Temperature is a big argument 
Those have never been officially supported. I think they just use builds from other lights, but I’m not sure about the details. Maybe sc21-pro and fw3a-nofet?
Ah, I’m not really surprised about that one. It’s the last build I updated, specifically because it’s unusual and likely to have issues. I really should have one to use for development and testing, but I don’t. So I’ve had to make the code based on guesses.
Lumintop didn’t accept updates from me for very long after the FW3A was released, and then fell out of contact entirely. They made a ton of hardware variations and downgrades, did unfortunate things with firmware, and produced every FW3A derivative imaginable… while also pretty much ignoring community feedback. So I gave up and walked away. The FWAA and FW3X were both released after that, so I wasn’t really involved. The FW3X was significantly better, created from the designs of LoneOceans, and he sent me the code so I merged the code in … but have never been able to test it or properly maintain it.
The code isn’t complicated, it just got more features over time. But still relatively easy to understand.
2 Thanks
Definitely very unfortunate how Lumintop went their own strange way without community help/interaction.
If there is some way I could help with getting the fw3x-lume1 build to work properly, please let me know.
Do the fuse setting play any role in this? or are they unrelated to the problem?
The TS21 that I have came with sofirn-sp36-t1616 firmware (0614), so I just flashed that and is seems to be working fine (but I will perhaps try out sc21-pro as well).
I will give the fw3a-nofet firmware a try, once I get around to opening up my FWAA lights. Thank you for the tip.
The fuses are probably fine. The issue is the firmware. The circuit is unlike anything else Anduril runs on, and it needs special handling for several things, and that specialized code is in relatively deep parts of FSM. I can’t test it on other hardware because nothing else works that way.
I don’t know what builds they use. I’m just guessing.
the pinout corresponds at least, on the FWAA 1x7135 is on pin 5 and FET on pin 6, in fw3a-nofet PWM1 is pin5 and PWM2 is pin 6 (PWM3 unused).
1 Thank
Edit: I completely missed something in thinking I had the cause of the aux bug, looking into it now 
It looks like the channels are defined (8 options in 9H from on), they just aren’t switching to aux (the main LEDs don’t switch off, but also the aux don’t switch on)
2 Thanks
Thank you for all your hard work!
Fixed the fw3x-lume1 bug.
Need to add to the hwdef:
#define USE_CONFIG_COLORS
#define DEFAULT_BLINK_CHANNEL CM_MAIN
Now onto the bug itself, because I found it interesting:
DEFAULT_BLINK_CHANNEL needs to be defined for 3C in battcheck mode to work. Otherwise, what happens is when in battcheck mode, the 3C handler from channel-modes.c gets called instead (as channel mode state exists under other states) which causes the light to blink to acknowledge it, and move to the ‘next’ channel, except by default only one channel mode is enabled, so it wraps back around to CM_MAIN. Due to this, if you enable an aux channel in the 9H from on menu, then do a 3C in battcheck, it works, but only because it changes the selected channel mode (i.e. for ramp mode, etc).
This is kind of ugly, but also optimal in terms of code size. One alternate fix would be to make the channel_mode_state 3C handler check state and only work when not in battcheck state, so battcheck mode’s 3C handler will be guaranteed to be called or nothing will.
Alternatively, you could just add somewhere (maybe in channel-modes.h?), this:
#if NUM_CHANNEL_MODES > 1 && !defined(DEFAULT_BLINK_CHANNEL)
#define DEFAULT_BLINK_CHANNEL 0
#endif
Which solves the issue by making it impossible to happen, without any extra image size, by always defining a blink channel as 0 (the first channel) if not already set in the cfg.h.
Another fix would be to change the ifdefs in battcheck-mode.c from #ifdef DEFAULT_BLINK_CHANNEL to #if NUM_CHANNEL_MODES > 1 instead.
Here’s a hex for anyone else interested (@Noir): 31.3 KB file on MEGA
2 Thanks
I just cleaned up the thread. That’s probably enough said.
4 Thanks
