Flashlight Firmware Repository

Hmm, great minds think alike. This is what I’m running on my Dawn: GitHub - treellama/crescendo-ta: Crescendo firmware for Texas Avenger "TA" flashlight driver

I just got a Gemini, which has the same too-slow-OTC TA driver, so I guess I’ll find out how well Crescendo works with a forward-clicky.

I will probably patch out the memorize-ramp (and maybe memorize-battery-check) for my own lights. But I wanted to check if it was intentional before submitting a pull request. Let me know if I can help with Crescendo otherwise, whether it’s contributing patches or just testing your redone version. And thanks for creating it in the first place :slight_smile:

lol, ditto. I never actually knew what the final light was setup with until mine showed up a month or 2 ago.

So I’ve been using Ubuntu (kubuntu actually) for some time now and I’m trying to get my system set up to edit and flash. I’ve installed the avr environment and avrdude successfully and also I believe I have access to ToyKeeper’s repository through terminal now by installing the Bazaar/Launchpad thing, I forget what it is called but I think it worked. I’m just not sure how to bridge the two together and get the files from the repo to flash to the Attiny. I’m sure it’s simple, but I haven’t found the answer by searching; I guess it’s one of those things that Linux users are just supposed to “know”. :slight_smile:

Also, how do I take a C source code file, edit it, and flash it if I pull it off the repo, and where does avrdude find it’s files to flash? Thanks.

The short version is:

% bzr branch lp:flashlight-firmware
% cd flashlight-firmware

Then edit whatever, using your editor of choice. The build scripts are mostly in the bin/ directory, or for Anduril you should be able to go into the anduril/ directory and run make . This produces .hex files, which are what avrdude uses. The flashing scripts are in the bin/ directory too.

Got it! I think I’ll get it figured out. It seems avrdude just grabs the hex files from the home directory so even if I edit and compile C source code I could place it back into the home directory manually and flash from there.

I would like to use your .sh scripts sometime though, have to figure out how to do that!

Tried flashing Anduril on my D4S now it does n’t turn on…
Reflashed and no problem the second time!

Ran this command in a Linux terminal:
sudo avrdude -p attiny85 -c usbasp -Uflash:w:anduril.2019-08-05.emisar-d4s.hex

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e930b (probably t85)
avrdude: NOTE: “flash” memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file “anduril.2019-08-05.emisar-d4s.hex”
avrdude: input file anduril.2019-08-05.emisar-d4s.hex auto detected as Intel Hex
avrdude: writing flash (7926 bytes):

Writing | ################################################## | 100% 8.62s

avrdude: 7926 bytes of flash written
avrdude: verifying flash memory against anduril.2019-08-05.emisar-d4s.hex:
avrdude: load data flash data from input file anduril.2019-08-05.emisar-d4s.hex:
avrdude: input file anduril.2019-08-05.emisar-d4s.hex auto detected as Intel Hex
avrdude: input file anduril.2019-08-05.emisar-d4s.hex contains 7926 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 4.63s

avrdude: verifying …
avrdude: verification error, first mismatch at byte 0x0000
0x00 != 0xa4
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was e2, and is now fe
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: hfuse changed! Was de, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: efuse changed! Was ff, and is now fe
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK (E:FF, H:DE, L:E2)

avrdude done. Thank you.

Just use 3.3 V, works much more stable than 5 V. The USBasp has three pins with a jumper. Just move it to the other (3.3 V) side.

I ran into this same problem too! And then stumbled into the solution after some frustration. Why is this a thing? Why is 3.3v more stable than 5v?

Can someone tell me where to get the most current code to compile myself? I always pulled code from launchpad but after loading some stock lights with precompiled Hex files from Index of /torches/fsm I see now that the .c file I’ve been building off of is NOT the most current. I’d like to base my custom builds on the most UTD code (with things like 2-stage lockout and manual memory) but the most current .c file I see is from May and missing those things!

You need to get the fsm branch. Second one down in the list.

Because of the limited amount of pins on the ATtiny one of the ISP pins was used for the output that controls the main LEDs. So every time that pin is used for programming, the main LEDs turn on as well (that’s why you see the LEDs flicker). With 5 V the LEDs use a lot of current, so much that the USB controller resets the port or the voltage is just pulled down to less than 4,7 V (which also causes a reset most probably). When using 3.3 V the LEDs are turned on as well, but pass less current, thus the USB controller will not be reset and the flashing is successful.

What list? This is where I’ve always pulled code from but I just tried a fresh pull then built and flashed a driver I’m working on and it’s not got any of the new features…

Direct link me please.

Click on the second one (/fsm) in the list HERE
in /fsm if you click on Browse the code you will go HERE
Then click >> ToyKeeper >> spaghetti-monster >> anduril (revision 438)

Don’t know if it is exactly what you are looking for.

That seems to be it. Thank you!
I really don’t understand this whole source control thing. Why is the link I used (which is from TK’s signature) so outdated?

The reason is because of how things are organized. It’s somewhat complex.

The firmware repository is a place to collect all flashlight firmware, not just mine. My stuff is all crammed into one subdirectory, while other authors have their own directories. The organization isn’t just a matter of the folder structure though, but also a matter of how the revisions themselves are organized.

There’s a pattern or a “best practice” in revision control systems called feature branching. The basic idea is that there should be one “mainline” path through history which only has “cooked” revisions. These are revisions which have been tested pretty thoroughly and are considered safe or stable… as opposed to “raw” revisions which are unproven and likely to have problems.

Meanwhile, development is done in “feature branches”. These have all the raw revisions. The usual pattern is to make a branch, develop a new feature, test it, develop some more, test it, submit it for review, fix the issues noted in review, test it more, and then when it’s finally ready, it can be merged back into the mainline. All the clutter and missteps of development are kept out of the way, so people following the mainline don’t have to care about it.

The link in my signature goes to the stable mainline branch, called trunk. It’s usually a bit behind in terms of features, but also considered generally safe.

So that’s the general development cycle.

For Anduril and other FSM-based interfaces, things get a little bit more complicated. FSM is a sizable project, so it has its own cooked-vs-raw branch thing going on. The cooked branch is called fsm, and I make a variety of raw development branches based on it when I add new things.

… And then I also periodically merge fsm back into trunk. It’s probably overdue for that to happen again, since the two have diverged so much since the last merge.

I could also probably add a link in my signature for FSM, since it has become such a big project… or perhaps shorten the link which goes to launchpad so it’d go to the main repository page instead of trunk. This might make it easier to find the other branches. Will probably do that second one, since it keeps the focus more on everyone’s projects instead of just mine.


Edit: Merged fsm into trunk and published the changes, so both should be up to date now.

THANK YOU!!

Also thanks for the lesson in source control systems, I now understand the idea. I’m FAR from understanding and being able to use it but atleast now I know where to look for the most UTD version to use as a starting point for my [relitivley basic] code mods and why it works how it does.
So if I come up with something cool I make my own launchpad, upload my version and you see that and (after lots of testing) merge it into the real thing?

Or just send a patch or modified source files or something. I don’t really expect people to learn a software management system just to send a few changes.

A suggestion for Anduril: auto lock. If enabled, the flashlight will automatically go into lockout after some time (e.g. 15 minutes) without user interaction in the off state. This will reduce the possibility of accidents when the user forgot to put the light into lockout mode. The enable/disable setting could be n clicks in lockout mode.

Does anyone have a FireFlies E07 hwdef and cfg file?

@ToyKeeper

Anduril new feature request:

Add a way for Anduril to blink out the version number or date of the installed firmware version, e.g. when clicking 15x from off.

Reason: Muggle-Gate ;-) and possible future releases with bugs or major changes.

There should be a way for the user to determine the exact firmware version that is running on the flashlight.