Flashlight Firmware Repository

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.

Breezy is a modern fork/replacement of bazaar and works fine with the latest version of Python 3.

You can try my own Docker image for building the firmware. It should include everything to build all versions of Anduril.

1 Thank

The T1616 DFP error message should point to a readme in /bin IIRC, where there are instructions for installing it (downloading and pointing to its path in build.sh or something).

I use FreeBSD for development and I downloaded the firmware repository:

1. anduril2 : Code : Flashlight Firmware Repository

bzr which I used on FreeBSD 13.0 to download an older snapshot is longer supported on FreeBSD 13.1. brz is available as a port/pkg but I didn’t need it after all as despite the comment above of the download on launchpad not working, I just tried it and it did work:

2. click “Browse the code”, then “view revision”, then “download tarball”.

Then install software:

3 pkg install avr-gcc

4 pkg install avr-libc
This uses avr-libc 2.0.0 so I later modified the port to compile 2.1.0

5 for linuxisms (bash): ln -s /usr/local/bin/bash /bin/bash

6. The README in the zip says to download an Atmel pack for newer attiny1 series (needed as I wanted to change the firmware in the latest version of the SC31pro).

http://packs.download.atmel.com/

and use the environment variable as stated in the README

7. Compiling.
I had already tried to compile for example ‘crescendo’ before downloading the Atmel pack and before updating avr-libc and that worked fine.

===
The 2 pocket lamps I want to reprogram are, with version/type identifier if I counted correctly:

- SC31pro, version check says: 2022 02 08 (then not a zero but a long pause, I guess this is a change in later anduril versions to not give leading zeroes but a long pause) 614 [ From the table of models/firmwares: 614 = sofirn-sp36-t1616 attiny1616, is that correct? ]

- D4V2 219b sw45k + boost driver: 2021 11 12 0273 [ 0273 = noctigon-dm11-12v attiny1634, is that correct? ]

===
I tried hello_world and which gave errors, the inline functions are not recognized or not treated correctly by the compiler it seems:

JonnyC/STAR/STAR:
avr-gcc -Wall -g -Os -mmcu=attiny13 -o STAR STAR.c

/usr/local/lib/gcc/avr/11.2.0/…/…/…/…/avr/bin/ld: /tmp//ccOwF4CX.o: in function `main’:
anduril2-r653/JonnyC/STAR/STAR/STAR.c:(.text.startup+0x8): undefined reference to `ADC_on’
/usr/local/lib/gcc/avr/11.2.0/…/…/…/…/avr/bin/ld: /tmp//ccOwF4CX.o: in function `__vector_8’:

etc.
Same happens in hello_world.
Removing the ‘inline’ keyword makes them compile. Weird, what could be the issue?

Then in ToyKeeper/spaghetti-monster/anduril/

‘make’ gives:
= 40 builds succeeded, 22 failed =

Some give too much code such as:

= emisar-d4s-219c =
/usr/local/lib/gcc/avr/11.2.0/…/…/…/…/avr/bin/ld: anduril.elf section `.data’ will not fit in region `text’
/usr/local/lib/gcc/avr/11.2.0/…/…/…/…/avr/bin/ld: region `text’ overflowed by 10 bytes
collect2: error: ld returned 1 exit status

then the attiny1 series give other issues:
= sofirn-sp36-t1616 =
In file included from …/fsm-standby.c:24,
from …/spaghetti-monster.h:74,
from anduril.c:92:
…/fsm-standby.c: In function ‘sleep_until_eswitch_pressed’:
…/fsm-standby.c:59:9: error: ‘MCUCR’ undeclared (first use in this function)
59 | set_sleep_mode(SLEEP_MODE_PWR_DOWN);
| ^~
MCUCR looks to be defined in many header files in the Atmel pack but not for the attiny1616, unless it uses another include too which for some reason doesn’t get included.

The avr-gcc compiler version number (avr-gcc -v) is 11.2.0

Any ideas on what to do to fix this?

Have you tried this? It shows Python 3.7 to 3.9: FreshPorts -- devel/brz: Distributed version control system based on bzr

Then use Docker with my image to compile. Or use the latest development version of avr-libc and version 11 of avr-gcc without DFP.

There shouldn’t be a pause but a very short blink. But the version and model sounds right.

If it’s what version check says… Emisar/Noctigon got very confusing with their driver and host combinations.

That example is not maintained anymore. Only Anduril/FSM is maintained.

avr-gcc 11 will create larger files than version 10 and it won’t fit.

That is an incompatibility between avr-libc and the DFP. Just use the latest development build of avr-libc without DFP (or my docker image).