I knew that sounded familiar: Anduril ... 2? - #699 by Tom_E
Your code looks pretty good, Tom. I just threw it into my Anduril2 branch with very minor tweaks. Hopefully TK will merge my branch into hers again sometime. I also made sure my branch was completely up-to-date with TK’s (thru her rev 613). If you would please, pull down the code, compile it, and throw it onto a light (perhaps your Mateminco MT01 mentioned in the post above?) and make sure everything’s good to go.
Ok, you remember my changes better than I do! 
:FACEPALM:
Oh crap! I pulled earlier this morn, been sync'ing my local up and came across this FSM thing I keep forgetting about... :FACEPALM: again.
Will pull again. Actually sounds like TK has more in the works based on feedback she's been getting here: https://budgetlightforum.com/t/-/67518/33
Actually the only local changes I have to worry about was that FSM one and cfg and hwdef files. I got a lot of custom defs, then a couple settings I always use, etc. Between her and you, all my local mods starting with Anduril V1 are in the new Anduril 2 baseline.
Right now I got one set of Anduril 2 sources all in the same folder, and 2 solution/projects: for the 85 and 1634. My 1616 build is separate, so I need to bring it in to the common Anduril 2 folder, then I can build anything right in Microchip Studio for Win all from one common source code base! With (Microchip Studio (MS), only way I could set up different MCU's successfully was to create the project from scratch. It's really not that bad though, goes quick, specially since all the source code is in one folder. You do, however, have to mark all the .c files that are include'd with a "Build Acttion" of "None" so it doesn't try compiling them. It's a little pain but I understand why TK did it.
The way it's done (TK and you) with switches to support 3 different sub-families of AVR's is pretty cool.
Ok, finished the updates and now have it setup, building, for 3 projects for the 85, 1634 and 1616 all from one source code set. Easy now...
I did a 1634 build using:
#undef USE_THERMAL_REGULATION
It built ok, and with a smaller size of about 900 bytes, so I think this will kill thermal reg effectively. Will try it, hopefully with nothing burning...
I have 56 now it will last me a bit. But now I’ve got to actually get myself some pogo-flashers.
Following your link leads to a PDF with suggested replacement parts.
Any idea what are the implications of the “suggested replacement”? Would they also be flash-able with previous existing flashing adapter and SOIC8 clip?
So they just discontinue the plated version? Then there’s no change for us.
Yea, you guys are right! Ooops! I only read this:
EOL Description:
The selected Atmel ATtiny13A, ATtiny25, ATtiny45 and ATtiny85 device families available in 8L SOIJ NiPdAu LF package will be moving to End of Life (EOL) status effective today. These products will no longer be offered after July 31, 2022. Please review the attached parts affected list for details about replacement parts if applicable.
But it says "8L SOIJ NiPdAu LF package", so very limited EOL and not the variants we use anyway.
I shouldn't have panicked so quickly... 
I am not sure if this is a good thread to place this question, but here it goes.
Would it be possible to have Anduril lights have both momentary ON (1 defined level) + momentary Strobe (ex: tactical strobe) when configuring the flashlight in the 5C (tactical mode) option ?
Like:
1 H for momentary ON
2 H for momentary Strobe
I’ve thought about this today as I normally carry the Olight Warrior Mini that allows both momentary Turbo & momentary Strobe through the tail switch. Other flashlights, like some Wuben lights with dual switches, allow momentary turbo and strobe, but the feedback takes longer, it is not immediate and therefore is not good for a prement situation.
When I go out at night for a walk I always take the OWM with me because with both modes I can signal my place on the road if needed, instantly.
I would prefer to take a smaller light like the FWAA but I can only use or momentary ON or momentary Strobe at a time.
Having that option (1H & 2H) in this or other Anduril lights would be quite nice, if possible. But I am not sure if it is :zipper_mouth_face:
I’ll be looking for the experts replies.
Thanks in advance for reading 
The whole reason for the tactical mode is to have just a single action for the switch so that you can use it for signaling, Morse code etc.
Hum, I get that, and I understand the reason why it is configured that way. Although I believe the common user probably doesn’t know Morse code (except for SOS, eventually).
However, my question is more on the: is it possible - in terms of programming - to have both momentary modes as I explained above?
Yeah, it would just require modifying the code for momentary mode.
It currently doesn’t care how many times the button is pressed, but you could change it to do different things on EV_click1_press and EV_click2_press. Or, inside the part which handles presses, make it check whether the counter portion of the event is odd or even, and do different things for each.
Even if I don’t know how to “program” I hope I can do this resorting to the pins and some learning on how to perform those changes!
If/When I get to do that, I will probably need some help, but that will take a while 
Thank you very much for the reply and the explanation ToyKeeper :+1: :+1: 
Toykeeper, do you have any idea what could cause the above behavior?
Hi TK,
I noticed the following comment in loop() while doing some tinkering with the Anduril code:
I also saw that the current workaround for this anomaly is performing the state-change in a deferred fashion in main().
What I am wondering about is:
)Thanks a lot for your advice
The initial low brightness could be just the Anduril 1 style of activating moon immediately on button press. There’s a compile option to select button press, release, or timeout while turning on, and the “press” style works that way.
The +1 channel getting stuck while turning off, however, sounds like the MCU is going to standby before the PWM cycle has a chance to complete and turn the power off. That would leave the power on sometimes, at random, with the probability determined by the duty cycle. It may be helpful to insert a small delay after setting all channels to zero, before actually going to standby mode.
Yes, any state change in loop() should probably be deferred until the main function has a chance to handle it. The issue I encountered was: In version check mode (and simple UI’s battcheck), it turns itself off after blinking out a pattern, but the readout could be interrupted by pressing the button… and then the next button press would be ignored.
It should say “fixed” instead of “fixme”, but I guess I forgot to update the comment. These two state changes were the only place the issue happened, and it was fixed in 2020 in anduril2 r573.
MascaratumB,
So, do you have a flashlight you want to update the firmware on? Do you have a programming cable?
I’m working on understanding how to mod the Anduril firmware, and made the mods you spoke about. I have it working on a DT8. It adds about 18 bytes to the DT8 program size. If you can tell me what light you have, I can try building the firmware for it.
At last! I’m so exited! Today, after ages of learning , I mastered Flying Spaghetti Monster code and created “perfect” UI for E-switch in my way . No useless “smooth” ramping, only pure perfectly spaced stepped modes in carousel with reverse. Separated Moon and Turbo, auto and manual start level, Aux, momentary lockout, battery voltage blink, some strobes, emergency momentary turbo mode with disabled LVP, smooth ATR and so on …
How did you go about this? Is there some sort of idiots guide to compiling with FSM? Do you have to flash the firmware to test it, or is there a way to test it on the computer? I’m sure I could fuss around w the code and set something up I like, but I have no idea how I would compile it or troubleshoot.