E-switch UI Development / FSM

BLF Special Edition Products
1016

I want to have a factory default setting embedded in my firmware that when a factory reset is performed it will set the Anduril 2 hybrid memory to step 3 with a 10 minute timer.

I’m assuming this is possible as a eeprom value is set for the AUX light defaults, I just don’t know the syntax otherwise or where to place it.

1017

Add this to your config:

#define DEFAULT_MANUAL_MEMORY 50
#define DEFAULT_MANUAL_MEMORY_TIMER 10

This sets it to level 50/150 and 10 minutes timeout.

1018

Oh wow, I’m not sure why I was overcomplicating it so much. I thought the value was something I had to embed in the eeprom.

I’ll give this a shot, thank you!

Edit: do you remember where the defines are that pull this into FSM code?
Edit2: found it in ramp-mode.h lines 150-157

1019

It is used in ramp-mode.h

1020

ToyKeeper (or maybe gchart or someone with repository access/knowledge):

I would like to get a change into FSM/Anduril 2 repository base line, file: fsm-main.c

The change:

  • for the ATtiny25/45/85, any of the up to 3 supported channels can be mapped to pin #3, not just the third channel

I needed this for a couple specific drivers, can't recall which ones, but maybe from OSHPark or a manufacturer design, not sure.

You can see below that only the 3rd channel has the special support for PB4 (pin #3). The "new code" supports PB4 for any of the 3 channels. Maybe the same thing could be done to support pin #7 as a output channel - that would be nice as well. There's maybe a better way of doing this, cleaner, more elegant - my code is more brute force. let me know if this sounds ok, and do-able. I've been using it locally for quite a while.

Current code:

#if (ATTINY == 25) || (ATTINY == 45) || (ATTINY == 85)
static inline void hw_setup() {
    // configure PWM channels
    #if PWM_CHANNELS >= 1
    DDRB |= (1 << PWM1_PIN);
    TCCR0B = 0x01; // pre-scaler for timer (1 => 1, 2 => 8, 3 => 64...)
    TCCR0A = PHASE;
    #endif
    #if PWM_CHANNELS >= 2
    DDRB |= (1 << PWM2_PIN);
    #endif
    #if PWM_CHANNELS >= 3
    // Second PWM counter is ... weird
    DDRB |= (1 << PWM3_PIN);
    TCCR1 = _BV (CS10);
    GTCCR = _BV (COM1B1) | _BV (PWM1B);
    OCR1C = 255;  // Set ceiling value to maximum
    #endif

New code:

#if (ATTINY == 25) || (ATTINY == 45) || (ATTINY == 85)
static inline void hw_setup() {
    // configure PWM channels
    #if PWM_CHANNELS >= 1
    DDRB |= (1 << PWM1_PIN);
    TCCR0B = 0x01; // pre-scaler for timer (1 => 1, 2 => 8, 3 => 64...)
    TCCR0A = PHASE;
    #if (PWM1_PIN == PB4)
     TCCR1 = _BV (CS10);
     GTCCR = _BV (COM1B1) | _BV (PWM1B);
     OCR1C = 255;  // Set ceiling value to maximum
    #endif
    #endif

#if PWM_CHANNELS &gt;= 2
DDRB |= (1 &lt;&lt; PWM2_PIN);
#if (PWM2_PIN == PB4)
 TCCR1 = _BV (CS10);
 GTCCR = _BV (COM1B1) | _BV (PWM1B);
 OCR1C = 255;  // Set ceiling value to maximum
#endif
#endif

#if PWM_CHANNELS &gt;= 3
// Second PWM counter is ... weird
DDRB |= (1 &lt;&lt; PWM3_PIN);
#if (PWM3_PIN == PB4)
 TCCR1 = _BV (CS10);
 GTCCR = _BV (COM1B1) | _BV (PWM1B);
 OCR1C = 255;  // Set ceiling value to maximum
#endif
#endif</code></pre>
1021

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.

1022

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.

1023

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

1024

Attiny85 going EOL:

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

1025

I have 56 now it will last me a bit. But now I’ve got to actually get myself some pogo-flashers.

1026

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?

1027

So they just discontinue the plated version? Then there’s no change for us.

1028

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

1029

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:

1030

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.

1031

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?

1032

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.

1033

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:

1034

Toykeeper, do you have any idea what could cause the above behavior?

1035

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