E-switch UI Development / FSM

Hi TK, can I have Andúril .hex file? I got tons of error when trying to build with Atmel Studio.
Thanks…

Most of the errors are probably due to missing header files.

The complier is looking for a several .c and .h files. You need to download these from TK’s repository.

Some are located here.

Some are located here.

You need to put these files in your project’s folder.

When you create a new Amtel Studio project, it creates a directory structure based on the name of your project. Right click the tab at the top left of Amtel Studio and click “Open Containing Folder.” Drop the .c and .h files into here and run the compiler again.

Another error you are probably encountering is, “Hey, you need to specify ATTINY” in the tk-attiny.h file. Double click the error, then scroll up a few lines and remove the // from one of the lines reading “#define ATTINY” and change the number to the proper ATtiny model number (13, 25, 85 etc.).

Hope this helps!

I’ve got Andúril running on a Q8, D1, and D4 now. I love having several lights with the same awesome UI!

I have an EagleEye X6R with a TA driver running Narsil that I’d like to reflash, too. It has a forward-clicky tailswitch and an e-switch on the head.

I’d like it to light up at the memorized level when powered up, so I can use the tailswitch as momentary.

I found this piece of code but I’m unsure what changes to make:

void setup() {
// blink at power-on to let user know power is connected
set_level(RAMP_SIZE/8);
delay_4ms(3);
set_level(0);
load_config();
push_state(off_state, 0);
}

Am I on the right track?

Also, how can I format code to read properly when posting here? It becomes a mess if I insert spaces at the start of a line.

For that, it will need to save the memorized level to eeprom so it can remember after power loss. And given how often that level changes, it should probably be wear-levelled. This means bringing in the EEPROM_WL code, which isn’t otherwise used in Anduril, and making changes in a few places. It’ll cost more than a few bytes.

Yes, that’s one of the places which will need changes. It’ll need “push_state(steady_state, value_from_eeprom)” instead of going to the “off” state. And, um, get rid of the initial startup blink. :slight_smile:

The other changes are larger though… I should probably add another compile-time option for it, because this is a request which will probably come up frequently.

As for posting code, BLF isn’t very good at that. It can be done, by using a <pre> in the fancy post editor, but usually I don’t bother.

Thanks, TK! I’ll wait for a possible compile-time option for ‘power on at memory.’

In the meantime, would a ‘power up on turbo’ option be less complicated? Possibly something I could add/modify myself? Lexel enabled that in the previous install of Narsil when I ordered the TA driver.

I pushed an update with dual-switch support. It costs 172 bytes, if enabled at compile time, mostly due to bringing in wear-levelling functions.

The current method goes to the memorized level at boot, unless the e-switch is held. Then it goes to moon instead. (er, the bottom of the current ramp, whatever level that is, so it varies per-ramp)

Personally, I like having memory after lockout. If anything, I’d prefer to make it time-related, not lockout-related.

As for time-related forgetting, I’d probably want to set the time to something pretty long, like a few hours. I haven’t tried the half-sleep mode yet to find out how much power it uses, but hopefully it’s not much.

I get the impression that perhaps the desired solution would be no memory at all, so it always turns on at a specific level. This might be do-able, and I’ve been trying to leave room for a memory option, but I haven’t thought of a way to fit it into the UI yet… at least, not a way that I’m happy with.

Wow, you work quickly! You’re spoiling me. :partying_face:

Very nice! I’m gonna update my dual-switch light right now.

Are you familiar with how the wizard character class works in D&D?

Every morning, they prepare their spells. Specifically, they take a guess at what spells they’ll need that day, and then they prepare each one. They cast 99% of each spell, leaving off only the last word or two, so that later in the day they can speak a few syllables and cause something big to happen.

FSM is the first 99% of a bunch of spells, leaving only the last little bit to be completed.

Personally, I desire memory for very short periods, like a minute or two.
I stop by the trail, turn off the light, empty my bladder, turn the light on.
Other than this…I’m yet to find use for it.
I did some searching on how others use it….I’m surprised I can’t find anything useful really. There are many comments where people just state that they like mode memory or not. Some say that they use it to make sure the light starts on low. The only other that I found was:

But this is a workaround for not having a configurable default mode and mode memory is ill-suited for the task.

I forget; do you have firmware flashing tools? If not, it might be a good idea to get some. I think you would probably enjoy being able to tweak behavior exactly how you like it. At minimum, it would give you access to change compile-time options, but you could probably make deeper changes too.

It’s not something I recommend for everyone, but I think you’re probably serious enough about lights to get some benefit from it.

They are on the way.

:smiley:

I went for a two hour hike last night with a friend and five flashlights running Andúril. Two Q8s, Emisar D1, Emisar D4, and EagleEye X6R.

My friend was very impressed with the Q8 and got the hang of ramping very quickly. It was fun to keep handing him lights to try without needing to explain a different UI with each one.

I set the ramp ceilings to turbo-1 for all but the D4, which I set to turbo-55. He ramped the D4 to the ceiling and said, “Wow!” I told him to double-click and he about fell over. :laughing:

Is there a way to set Andúril’s ramp ceiling to turbo, or is turbo-1 the max value? Would this be a compile-only option? What if the ramp value was set to ‘turbo-(N-1)’ instead of ‘turbo-N’ when using ramp config? Must ramp ceiling and turbo remain non-equal?

BTW, dual-switch support seems to work great. I really like the ‘hold e-switch and click tailswitch’ to override memory.

I find this Andúril more and more interesting. I need to build a triple or quad X6R and try it in that. Or in my Q8 if it ever reach me from china. Ordered it in the first 100 and I’m just waiting and waiting patient.

It already does “turbo - (N-1)”… or, more specifically, “151 - N”. I should probably update the UI diagram to make that more clear.

To check whether the ceiling is set to turbo or if it’s lower, double-click from off, then double-click again. If it goes up, they weren’t equal. :slight_smile:

Got it! I was worried about missing out on that one last ramp level. :smiley:

BTW, your UI diagrams are works of art in their own right.

I need to stop adding things… I have no idea how to fit them into the diagram! :slight_smile:

Specifically, muggle mode. It’ll probably need a whole new section, but there’s no space left on the page.

I’m thinking 6 clicks from off to enter muggle mode, or 6 clicks from ramp to enter muggle config mode. Settings include floor and ceiling levels only. Will probably default to floor=15/150 (~7 lm) and ceiling=100/150 (25% power). Ish. Not sure if I’ll try to fit a 4-bar battcheck mode into it or if it’ll be limited to just ramping.

This sounds great! No turbo for muggles, right?

I vote to omit battery check, or make it a compile-time option. I can already hear my button-mashing friends… “WHY’S IT BLINKING?!” :person_facepalming:

Speaking of muggles, it seems the first thing they do when I hand them a new light is unscrew the tailcap to look at the battery. I’ll have to let them get that over with before I enable muggle mode. :smiley:

I know this, I have the same problem with Tom and the NarsilM cheat sheet. :slight_smile:

TK, I’d like to shorten (nearly eliminate) the delay before ramping when holding the switch from off. I want ramping to start almost immediately.

I poked around in several of the .c and .h files but couldn’t determine where I should make changes.

Could you point me to the code I would need to modify to accomplish this? Thanks!