E-switch UI Development / FSM

I had recently requests for my drivers for GT Anduril, is it possible to get the whole Atmel Studio 7 files for GT Anduril?

Lexel, here’s what I do to build an Andúril .hex file in Atmel Studio.

You’ll need to download files from three folders on TK’s flashlight firmware depository.

Download the Anduril.c file from this folder.

Download 21 .c and .h files from this folder.

Download 5 .h files from this folder.

You should now be able to paste the code from Anduril.c into a new Atmel Studio Project. Place the other 26 .c and .h files in the project’s folder.

Set the driver type by removing the “//” from the “//#define FSM_BLF_GT_DRIVER” line. Add “//” to the other driver type lines.

Add a line “#define ATTINY 85” to specify the MCU model.

Make any other changes to the user-configurable options, such as blinks at the boundaries and ramp floor and ceiling.

Build and flash the .hex file.

I took some time today to add the “votive candle” mode (candle mode timer). It’s off by default, meaning candle mode will go until it’s manually shut off or LVP activates… but the user can click 3 times to turn on the timer and add ~30 minutes. Click 3 times again to add another 30 minutes, and so on. The maximum time it can handle is about 4.5 hours.

For most of that time, it’ll run normally. However, for the final minute or so, it’ll gradually dim, sputter, and then shut off.

The UI diagram has been updated too.

If anyone wants to test the candle timer but doesn’t want to wait 30 minutes each time, the part to tweak is the value of MINUTES_PER_CANDLE_HALFHOUR. Set that to like… 2. And then each test should take less than 3 minutes. :slight_smile:

The timing is a bit wonky because I used a power of two as the base unit of time, which didn’t line up evenly with human-friendly minutes. This helps reduce code size and improve consistency when the clock tick counter rolls over, but it also makes “30 minutes, exactly” unattainable. I think the current behavior takes about 31 minutes per triple-click “bump”.

I reflashed a Q8 to try votive candle mode, and it works great! It burned for about 29 minutes.

I was excited to reflash several other lights, but managed to launch my flashing rig off the desk and break a few of the soldered connections to the SOIC clip. I’ll fix it tomorrow. :smiley:

I’ll be using timed candle mode on the nightstand and hanging near my hammock during camping trips.

Thanks for the continued improvement, TK! You really do spoil us. :+1:

TK can you make turbo level setting like ramp max implemented? I have a Skilhunt DS10 but for that size of flashlight and for 2A protertion tripping 16340 battery I want to set turbo under 2A curent a bit and ramp max to 0,6A as that is he stock max current for that light. It will be useful for low forward voltage leds or smaller hosts not to heat up real quick in turbo.

Zozz, you can achieve that effect by changing the values in the ramp table. Basically, cut the FET values in half or something. Maybe even calculate a new ramp with level_calc.py if the shape doesn’t look right. Or use a driver with only 7135 chips and no FET.

It can’t reliably control current on a FET though, so it’ll take trial and error to get things working at the desired level.

I don’t really can do things ike this. I tried some times but I only has windows and run in errors every time. I only flashed hex files. I thought it will be the same as ramp ceiling setting and it can be another line in ramp cfg. but it sets the turbo level. then with a power supply I can test what turbo setting giving the desired current for me.
But if it is not possibble I will ask somebody to make a hex for me as you described.
Thanks!

How hard would it be to change it so in a FET+1 the two channels ramp one after other? Say ‘1’ ramps till it hits max (or some value below max) then engages FET channel and ‘1’ channel shuts off.

staticx57, that should be pretty easy. Just set the first ramp to all zeroes after the point where the second ramp starts. However, this is not recommended because it will reduce efficiency, make the PWM more visible, and make the power-related tint shift pretty obvious.

Thank you! Not so easy when I really don’t know much about programming. I want the 7135 channel to control some Yuji LEDs then switch to the FET channel to power some normal emitters, cut trace of course. On that last thought, any advice on what to change to limit the 7135 channel in all other modes besides ramp? Ideally I am going to base this on your excellent Anduril.

Changing Anduril to support two independent LEDs may be a little tricky. It’s just not designed for that. It can be done, of course, but without knowing much about programming I’m not sure the changes will be very do-able. I’d suggest making it run as a single-channel ramp, then adding a second single-channel ramp, and explicitly using one or the other in the mode logic.

The only UI I’ve made which does multiple independent emitters is for a RGBA setup. It’s not released yet though, and doesn’t have any traditional modes for flashlight use. Instead, it runs on my lightsaber. The modes consist entirely of colorful patterns configured by the user, and most of the interface mappings are for configuring those.

BTW, there’s a bit of an undocumented feature in the candle mode now. During the final minute when it’s dimming before it shuts itself off, the user can “stoke” the fire to keep it burning a little longer. Simply touch the button while it’s dimming and it’ll perk up again. The usual button mappings still apply though, so I’d suggest giving it a button sequence which isn’t mapped to anything. Like click, click, hold. Or 4+ clicks.

It’s a bit like putting an extra coin into a game or a parking meter to keep it going a little longer.

On something with a lighted button, you should be able to tell if candle mode is still active based on whether the button has lit itself up yet. That happens when the timer has expired completely and the UI goes back to the “off” state. As long as the button hasn’t lit up yet, the fire can still be “stoked”, even if it appears to be otherwise off. And during that period, it may flicker briefly back to life on its own, too.

I’ve been running the latest version of Andúril with muggle mode and timed candle mode on nine of my lights for almost two weeks.

Last night I got to share some of them with several young muggles on a rainy walk. An Emisar D4, BLF Q8, and modded EagleEye X6R were used with muggle mode enabled.

The five year-old was excited to show me that power on the X6R could be toggled by twisting the head. Good thing TK chose to keep muggle mode enabled through power cuts! :+1:

I’ve been using a Q8 in timed candle mode every evening on the coffee table. I use a warm-colored diffuser and place the light just inside my peripheral vision while reading or watching TV.

Very neat. I wondered about the short delay between the candle burning out and the Q8’s switch relighting.

I ordered the needed components and excited to get my D4 reflashed. What is the programming language used to create this firmware? Is it same as programming Arduino?

It uses AVR compatible programmer and program

Is there any development regarding dual input voltages with proper LVP for Boost drivers and Narsil based firmwares?

NarsilM has a GT mode with LVP. Voltage is measured via a divider on pin 7, and getting it to work mostly just involves getting the right calibration values.

FSM has a pin7 mode too, with similar requirements.

Nothing yet appears to do multiple voltage ranges on a single firmware.

I just discovered that I was incorrect about my EagleEye X6R’s behavior in muggle mode. It’s running a TA driver and the latest version of Andúril.

With START_AT_MEMORIZED_LEVEL enabled, this dual switch light exits muggle mode during a power cut.

Is this fixable?

Oh, that makes sense. I didn’t even attempt to support muggle plus dual-switch. It would need an extra clause in setup() to pass in the memorized level as a starting point, and some extra code in muggle_state() to use the extra data instead of ignoring it.

It’s a fairly small change, probably under 10 lines, but it’ll take some testing to make sure I didn’t forget anything.

I’ve created a good morning / alarm mode in Anduril as a proof of concept. I put it after the goodnight mode, along with the other blinkies. That means to access it, you do 3 clicks, 2 clicks, 2 clicks. Once activated, it uses the standard config behaviour to ask you for a number of hours and a number of 10x minutes. Eg enter 7 then three for 7 hours 30 minutes. After the delay it will ramp up 1 level per second (too fast?) up to the ramp ceiling.

Current issues:

  • Timer accuracy could be better. I haven’t measured it properly yet.
  • Program size is 8164 bytes (99.7% Full), so there’s not much breathing room for other features. There’s a few bits in Anduril that I might try refactoring to cut this down but most of the time I’m just guessing.
  • Doesn’t do anything sensible to reduce power.

This definitely needs more testing but feel free to have a play. Be warned that this is the first time I’ve written C in about 10 years.

I haven’t got round to setting up a Launchpad account and learning bzr, so here’s the diff on Pastebin for the moment: dave1010-anduril.diff - Pastebin.com

Feedback welcome.

Edit: I may have messed up the timing. More testing needed.