Flashlight Firmware Repository

Always do thermal config at full battery.

Yeah, I didn’t think about it until I was already a few minutes in, and the head had only got to “just warm” and now I’m thinking I have to start over. :person_facepalming:

But, I have to make sure my cells are at full power, and do it when I have time to wait around for it to get hot. I didn’t know it would take so long to heat up, but I’m glad it does! Meanwhile, I don’t want to retain this “failed” setting if there’s a way out of it. :wink:

The temp started dropping, so I just shut it off. I’ll try again later. I’d still like to know the answer, if someone will tell me. Is there a way out of thermal config without saving state, if “waiting” needs to be cut short for any reason?

What you just discovered is the reason I like anduril… Just set the thermal limit, at an exact temp, with a series of clicks.

Yeah, I saw discussion about that. It would be nice, but it’s not the way Narsil works, and I don’t have the ability to re-flash the driver. :weary:

I have a general question about the modes in the firmwares.

I’ve read the code of several firmwares in the repository to understand how “multiple-clicks” function works for e-switches.

All of them had the same technique of counting clicks each time the button is not pressed and press-duration > 0.
So for the simplest UI of: 1 click = ON/OFF and 2-fast-clicks = TURBO :
When you double click (and the light is initially ON), first of all - the light turns OFF and then moves into TURBO mode.
Am I right or missing something?

What I don’t get is how do you distinguish a single click from multiple clicks? Because from what I can see, the firmwares in the repo, always run the code for 1-click, and when multiple-clicks detected, it’s code will run in addition to the 1-click code.

Thanks :slight_smile:

FSM solves that issue. Using this UI toolkit, it does not do the 1-click code before the 2-click code or the 3-click code… unless you specifically tell it to.

On some FSM-based interfaces, it intentionally goes to the 1-click level before going to the 2-click level, but it’s not a side effect. It only does that if it’s instructed to do so on purpose. Otherwise it’ll wait until the user is done clicking before it responds. For example, the Baton clone UI demonstrates both methods.

Thanks for the reference :slight_smile:
It’s an interesting implementation, ill test on my diving light soon

TK
I wanted to flash Anduril in my D4 with xpl-hi. But what does the lower muggle ceiling mean? I found it here

That was a one-off special build because someone requested a version with muggle mode limited to ~150 lm.

Thanks for this. This is exactly what I needed after I enabled some additional code in Anduril for dual switch support. I ran out of space and couldn’t make sense of the compile options I was missing in Atmel Studio. Now it compiles without issue!

Texas_Ace, were you ever able to suss out those problems with the GT70 style driver and Anduril? I’ve been researching a lot, and trying to find a way to get Anduril onto my GT70, but am not coming up with much information unfortunately.

Are Anduril inputs and outputs assigned to the same ports as Narsil and bistroHD?
Narsil:

bistroHD:

And Anduril?

Yes

Check the individual hwdef files to see how the pins are mapped for different types of hardware:

https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/fsm/files/head:/ToyKeeper/

/* BLF GT driver layout
* ----
* Reset -|1 8|- VCC (unused)
* eswitch -|2 7|- Voltage divider
* AUX LED -|3 6|- Current control (buck level)
* GND -|4 5|- PWM (buck output on/off)

/* Emisar D4 driver layout
* ----
* Reset -|1 8|- VCC
* eswitch -|2 7|-
* AUX LED -|3 6|- PWM (FET)
* GND -|4 5|- PWM (1x7135)

/* Fireflies ROT66 driver layout
* ----
* Reset -|1 8|- VCC
* eswitch -|2 7|- optic nerve
* FET -|3 6|- 7x7135
* GND -|4 5|- 1x7135

As always very helpful. Thanks a lot!

I actually do have some experience in programming Arduinos but I am quite lost in the repository.
Could somebody point me out which files I would need to compile the code for the FW3A?

Sorry, it’s kinda buried. The top level of the code organization at Launchpad is branches. Normally everything is in the trunk branch, but that’s treated as a place for stable code to land. Development is done elsewhere. In this case, development happens in the fsm branch, and in other branches off of that one. So the fsm branch is a better place to check for the latest updates.

Within a copy of the repository though, the top-level directories are authors, and then the next level is projects. Anduril is part of the FSM project, also known as Spaghetti Monster… so the full path is ToyKeeper/spaghetti-monster/anduril .

It’d be a good idea to branch a local copy of the whole repository, in order to get all the files and preserve the directory structure. It’d also be a good idea to use the included build scripts, like typing “make” in the Anduril directory. Grabbing individual files tends to lead to problems, and building it with other tools works but isn’t really supported.

Sometime soon I really should merge everything back into trunk. It has been a while. I’m just waiting on some projects to finish first, because there are a bunch of changes which haven’t quite landed yet.

Thank You! I got it.
Next step ist to try to compile the code. Should not be to complicated on Linux, I think.