E-switch UI Development / FSM

I finally got around to giving the new thermal regulation a try. Here is the result:




I’d say it’s a major step forward, but it still overshoots the temperature target too much for my taste. The overshooting seems to become worse with higher temperature targets.

I have not had the time to try it out on my other D4(S)V2 lights yet. But for comparison, here is a graph of what the thermal regulation of the code in my merge request looked like:

Another test with the new thermal regulation:


Bonus test:

Thanks! This is incredibly helpful. I haven’t been able to run any thermal tests lately, and it’s really useful to see the results compared to the best known version.

It could definitely still use some improvement, but it looks like it’s a significant improvement from before. :slight_smile:

Lately I’ve been focusing mostly on getting Anduril 2 ready. It’s basically done; I just keep procrastinating about finishing the diagrams and tutorial.

That’s right, and the more I use it, the more I like it.

Hi,
Will baton firmware work on a BLF A6 driver (17DD+1)?

No, the BLF-A6 driver uses an attiny13 chip, which does not have enough ROM to fit the Baton firmware. It also is not designed for use in e-switch hosts.

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 0x01 to 0x02 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?

I’ve been fiddling with the Anduril 2 code for a while now and I just don’t quite understand the eeprom management. If there is a way to set a hybrid memory step and a timer I would appreciate some guidance when someone has time.

I still don’t know what you mean. There are already various timers and memory slots. Can you explain a bit more what you want to do?

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.

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.

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

It is used in ramp-mode.h

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>

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

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?