Flashlight Firmware Repository

I know jon_slider was trying to download the tarball of a branch and has been getting HTTP 500 errors. I’m seeing the same thing.

it hasn’t worked for a very long time, on Windows you can use bazaar explorer : Bazaar

edit : Ah Android, you mean from a browser ?
edit : nope, doesn’t work either, some certificate error…

No my phone i have the Z flasher app it works really well its mostly the KR4 tintramp thats not working

I just found this post by TK
https://www.reddit.com/r/flashlight/comments/u16k31/sp10_pro_bug_when_turning_the_light_off_from/i4dn3t9/?context=3

it gives a link to her latest Hex

From what I’ve heard, Lumintop downgraded the driver and then used mismatched firmware. :person_facepalming:

I haven’t been in contact directly since 2019 though, so… I don’t know what they’re doing.

Canonical got rid of most of the Launchpad developers, so the site has been under-maintained for years. One of the consequences of this is, when the tarball function broke, nobody fixed it.

The recommended way to get the code is with bzr/brz (bazaar or breezy):

$ apt install brz
$ brz branch lp:flashlight-firmware
$ cd flashlight-firmware

The bazaar-vs-breezy thing is also a consequence of Canonical firing developers. They got rid of the Bazaar developers, but kept the name and the project ownership… so the developers forked it to a new name and kept working on it. The new one eventually replaced the old one, so now it’s Breezy (brz) instead of Bazaar (bzr).

After the code is branched locally, updates can be applied periodically with “brz pull”.

  • pull: apply upstream changes exactly, so the local branch will be an exact copy of the remote branch (may fail if local copy was changed)

If you made your own changes though, it’ll be necessary to use a more complex process: “brz commit ; brz merge ; brz commit”. This saves your local changes, merges in diffs from upstream, and then finalizes the merge. It’s generally a good idea to make sure the local and upstream changes don’t have any conflicts though, before doing the final commit. Breezy tells the user when it detects an obvious conflict, like when both branches changed the same file in different ways… but it can’t detect everything automatically. So, at minimum, it’s a good idea to do a sanity check by running the build script to make sure the code still compiles.

  • merge: apply upstream changes, but also preserve local changes
  • commit: check in local changes

To make things a little easier, I use a shell alias:

alias b=brz
alias g=git

Then I can use “b” or “g” to run these tools, like “b st” to see a list of changed files, or “b diff” to see exactly what was changed, or “b branch lp:~toykeeper/flashlight-firmware/anduril2” to download a local copy of the latest Anduril2 code.

@Nanuek Thanks for this. I have never used Docker but figured it out today and this worked for everything but downloading the source. Couldn’t download the tarball either so I grabbed it from somebody’s GitHub though it’s slightly out of date.
Anyways Anduril2 compiled for all but the 5 lights using the 1 series ATtiny boards on the first try. :slight_smile:

Is it possible to somehow enable a soft start in Biscotti? When I just uncomment it, I get errors like this:

Hi, is there already a PDF version of the Anduril 2 manual somewhere? I’m aware of Ivan’s HTML version which is great in the browser but AFAICS not when printing to PDF.

If not I’d be happy to make one… The current anduril-manual.txt is close to Markdown, and I guess Ivan has a Markdown version (to generate his website) which raises the next question:

ToyKeeper would you consider merging a branch that converts anduril-manual.txt to Markdown? (Any reason it hasn’t been done already with Ivan’s version?)

If it’s just a matter of someone needing to do some more work I would be happy to contribute.

Also curious if Ivan’s (or someone else’s) Markdown version is publicly available somewhere…

Are you on Linux or do you use Microchip studio on Windows ? I never managed to build Anduril with Microchip studio, with similar errors (”first use in this function”). I gave up and installed an Ubuntu VM, a few commands and done .

Edit : the message I replied to was deleted.

Sorry, I thought I’d move it to the Anduril 2 thread, and deleted the message, but here it is again.

Learning to make my own version of Anduril 2, and tried to build the downloaded Toykeeper branch before touching it, but the build fails with these errors.
Anyone want to help me out?

I’m building on linux.

Strange; my Linux Mint box must have some issues. Got it working on an Ubuntu VM.

Why dont just share working Anduril 2 project for Armel studio?

I guess the question to be answered is who would support the atmel studio project…

I’m trying to find a firmware to use for a twisty flashlight. I’ve never really played with twisties but I can only imagine trying to use something with a complex ui like Anduril would be a nightmare. Has anyone even done a firmware geared toward this? I couldn’t find anything in Toykeeper’s repository, anyway.

I got an ITP A2 Eos (the last remaining cr2 light afaict) and it has room for a 15mm driver, so I’ll probably use one of the mtn-15dd ones. The stock driver is a crappy boost converter made for disposables. I just want something basic like L-M-H i guess.

Any simple clicky UI can work for a twisty. The “standard” firmware option from MTN should work fine. I believe it is best to use a special fuse setting in order to prevent mode skipping: -Ulfuse:w:0x79:m This adds a 64ms startup delay for the MCU. You could ask mtn to flash it with this fuse setting.

Ok cool - if the startup delay helps, that should be good enough. I can flash it myself, I’m building from source because i want to customize the levels anyway and not use the FET, to avoid melting the thing. I just didn’t want to deal with trying to imitate 50mS button “clicks” by twisting the head really fast. Thanks.

For twisty use it is probably best to avoid clicky firmwares with fancy timing based mode controls like Bistro. Stick to Starry-offtime, Star_noinit, etc.

Ok so this worked out really well, I hacked up an old biscotti firmware, so no long-press reverse cycle etc, and cut down the mode list a bit, and made it work on a mtn-15dd driver board. Voltage and temp cutoff work, no problems so far.

strobe mode next to a FW3A for size.

Nice job!

That is for linux I guess.

For me on FreeBSD bzr is no longer an option unless I install python 2.7 myself (no pkg, no port, as it has been deprecated and brz needs 2.7)

I tried compiling the anduril code (on FreeBSD) and other firmwares and some compile, others not and similarly I get error messages compling firmware for the at1616 series. Not sure what the problem is exactly, it looks like missing definitions in the atmel pack but perhaps the source of the errors lies elsewhere. More on this in the next message.