E-switch UI Development / FSM

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...

Attiny85 going EOL:

https://www.microchip.com/product-change-notifications/#/16686/GBNG-14CATI014

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 :+1:

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 :smiley:
Thank you very much for the reply and the explanation ToyKeeper :+1: :+1: :beer:

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:

  • Do you think pop_state() actions are also affected? Should they be deferred as well when invoked by loop() ?
  • Have you ever investigated the actual root cause? (Probably some kind of race condition. Algorithms do not just “act weird” for no reason :slight_smile: )

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 :smiley: . 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 … :beer:

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.

Changing, compiling, flashing soft to hardware, testing. Repeating until desired result. It took for me few years only. Here is latest result

How to change/add /remove levels/steps in “Baton” code easy way aka how to use “level_calc.py” for mortals?
P.S. I didn’t find out how to and rewritten code in different way etc:

if (actual_level == 2) { set_level(3);}
else if (actual_level == 3) { set_level(15);}
else if (actual_level == 15) {set_level(29);}
…and so on.