E-switch UI Development / FSM

1039 posts / 0 new
Last post
Tom E
Tom E's picture
Offline
Last seen: 2 months 6 days ago
Joined: 08/19/2012 - 08:23
Posts: 15065
Location: LI NY

Ok, you remember my changes better than I do! smile 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/comment/1795408#comment-1795408

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.

Tom E
Tom E's picture
Offline
Last seen: 2 months 6 days ago
Joined: 08/19/2012 - 08:23
Posts: 15065
Location: LI NY

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

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

 

Tom E
Tom E's picture
Offline
Last seen: 2 months 6 days ago
Joined: 08/19/2012 - 08:23
Posts: 15065
Location: LI NY
Scallywag
Scallywag's picture
Offline
Last seen: 6 hours 48 min ago
Joined: 01/11/2018 - 22:23
Posts: 2359
Location: Ohio, United States

Tom E wrote:

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.
d_t_a
Offline
Last seen: 18 hours 4 min ago
Joined: 08/04/2017 - 23:58
Posts: 2706
Location: Manila, Philippines
Tom E wrote:

Attiny85 going EOL:


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


 

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?

SammysHP
SammysHP's picture
Offline
Last seen: 1 hour 22 min ago
Joined: 06/25/2019 - 14:35
Posts: 1428
Location: Germany

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

Tom E
Tom E's picture
Offline
Last seen: 2 months 6 days ago
Joined: 08/19/2012 - 08:23
Posts: 15065
Location: LI NY

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

 

MascaratumB
MascaratumB's picture
Offline
Last seen: 7 hours 55 min ago
Joined: 10/29/2016 - 12:12
Posts: 7218
Location: Portugal

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 Oops
I’ll be looking for the experts replies.

Thanks in advance for reading Thumbs Up

SammysHP
SammysHP's picture
Offline
Last seen: 1 hour 22 min ago
Joined: 06/25/2019 - 14:35
Posts: 1428
Location: Germany

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.

MascaratumB
MascaratumB's picture
Offline
Last seen: 7 hours 55 min ago
Joined: 10/29/2016 - 12:12
Posts: 7218
Location: Portugal

SammysHP wrote:
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?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 month 1 week ago
Joined: 01/12/2013 - 14:40
Posts: 10892
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
MascaratumB wrote:
Would it be possible to … 5C (tactical mode) … 1 H for momentary ON 2 H for momentary Strobe

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.

MascaratumB
MascaratumB's picture
Offline
Last seen: 7 hours 55 min ago
Joined: 10/29/2016 - 12:12
Posts: 7218
Location: Portugal
ToyKeeper wrote:
MascaratumB wrote:
Would it be possible to … 5C (tactical mode) … 1 H for momentary ON 2 H for momentary Strobe

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 Big Smile
Thank you very much for the reply and the explanation ToyKeeper Thumbs Up Thumbs Up Beer

EasyB
Offline
Last seen: 2 months 2 weeks ago
Joined: 03/09/2016 - 15:24
Posts: 2250
Location: Ohio

EasyB wrote:
I’m experimenting with using lower PWM frequency (2kHz) in Anduril and am having a strange problem. I started the discussion in the attiny 25/45/85 development thread

I am using FET+1 drivers used in the V1 D4 and D1S which use attiny85. I want to use the lower PWM frequency because I am using a CN5710 regulator chip which wants the lower frequency, but the same problem happens on a stock unmodded D1S driver.

I added a 8x divider to the timer by changing TCCR0B from 0×01 to 0×02 in the fsm-main file. Upon making this change the ramping and other operation is apparently normal while the light is on, but I’m observing the following problems:

When turning on, the LED blinks at a very low brightness as you press the button then goes to the memorized level when you release the button. Whereas during proper operation the LED stays off until you release the button.

Sometimes when attempting to turn the light off it will instead go to the max 7135 channel level. But some part of the MCU thinks it is in fact off, because the next button click will always go to the previously memorized mode as if it was just turning on. It really does seem random whether the light turns off or goes to the max 7135 channel level. But the probability of it malfunctioning goes up with the PWM duty cycle. If I’m low in the 7135 channel duty cycle it usually turns off as it should, but if I’m high up in the 7135 channel duty cycle it usually malfunctions and goes to 7135 channel max level.

RampingIOS v3 does have the same problem.

RampingIOS v2 (in TomE’s folder) does not have the problem.

Does anyone know what the problem is and can it be fixed?

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

madcrow
Offline
Last seen: 2 months 2 weeks ago
Joined: 09/04/2018 - 16:03
Posts: 80
Location: Hungary

Hi TK,

I noticed the following comment in loop() while doing some tinkering with the Anduril code:

Quote:

// FIXME: can eat the next button press
// (state changes in loop() act weird)
set_state_deferred(off_state, 0);

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 Smile )

Thanks a lot for your advice

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 month 1 week ago
Joined: 01/12/2013 - 14:40
Posts: 10892
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.

EasyB wrote:
I’m experimenting with using lower PWM frequency (2kHz) in Anduril and am having a strange problem. I started the discussion in the attiny 25/45/85 development thread

I am using FET+1 drivers used in the V1 D4 and D1S which use attiny85. I want to use the lower PWM frequency because I am using a CN5710 regulator chip which wants the lower frequency, but the same problem happens on a stock unmodded D1S driver.

I added a 8x divider to the timer by changing TCCR0B from 0×01 to 0×02 in the fsm-main file. Upon making this change the ramping and other operation is apparently normal while the light is on, but I’m observing the following problems:

When turning on, the LED blinks at a very low brightness as you press the button then goes to the memorized level when you release the button. Whereas during proper operation the LED stays off until you release the button.

Sometimes when attempting to turn the light off it will instead go to the max 7135 channel level. But some part of the MCU thinks it is in fact off, because the next button click will always go to the previously memorized mode as if it was just turning on. It really does seem random whether the light turns off or goes to the max 7135 channel level. But the probability of it malfunctioning goes up with the PWM duty cycle. If I’m low in the 7135 channel duty cycle it usually turns off as it should, but if I’m high up in the 7135 channel duty cycle it usually malfunctions and goes to 7135 channel max level.

RampingIOS v3 does have the same problem.

RampingIOS v2 (in TomE’s folder) does not have the problem.

Does anyone know what the problem is and can it be fixed?

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 month 1 week ago
Joined: 01/12/2013 - 14:40
Posts: 10892
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.

madcrow wrote:
I noticed the following comment in loop() while doing some tinkering with the Anduril code:
Quote:

// FIXME: can eat the next button press
// (state changes in loop() act weird)
set_state_deferred(off_state, 0);

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 Smile )

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.

NoneTheWiser
Offline
Last seen: 10 hours 14 min ago
Joined: 01/03/2022 - 09:57
Posts: 14
Location: The high desert

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.

Quadrupel
Quadrupel's picture
Online
Last seen: 11 min 53 sec ago
Joined: 12/03/2017 - 10:40
Posts: 1025
Location: Lithuania

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

Pages