Flashlight Firmware Repository

1488 posts / 0 new
Last post

Pages

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 22 min 7 sec ago
Joined: 01/12/2013 - 14:40
Posts: 6499
Location: (469219) 2016 HO3
Flashlight Firmware Repository

I’ve been collecting flashlight firmwares into one place and I hope it can become a central place for everyone to keep their code.

The repository is linked in my signature, or you can click here:

Anyone can create an account, branch the code, upload modified versions, file or fix bugs, submit merge proposals, and so on.

A quickstart is in the README, including links about how to flash drivers. To get an idea what is included in the repository, or to find a project relevant to your needs, look through the auto-generated INDEX file for projects matching your criteria.

If you have created any firmwares you don’t mind sharing, please create a new branch and merge proposal with your code, or send me the files and I’ll add them.

I’m using bzr and Launchpad to track and host the code, but if there is sufficient interest I am open to the idea of moving to git and a git-based project platform.

This thread is intended to provide a central place to discuss firmware in general, announce updates, and to avoid cluttering other project-specific threads with off-topic chatter.

Edited by: sb56637 on 09/28/2015 - 18:11
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 22 min 7 sec ago
Joined: 01/12/2013 - 14:40
Posts: 6499
Location: (469219) 2016 HO3

Okay, I’m terrible at keeping up with my todo list. I’m putting it out in public in hopes that more of it will get done, faster. Help is welcome but not expected; I’m putting it here more for my own accoutability. Smile

I’m not sure if this is a good place for it or if perhaps I should track each of these as bugs on Launchpad. The bug tracker there is very nice, and works well as a task list.

  • Figure out an easy way for people to build these projects in Windows. Template WinAVR project or something, I don’t know. Help would be very appreciated.
  • Make periodic full-repository .zip releases, maybe, to make things easier for people who don’t have bzr?
  • Pull in pd68’s tripledown code.
  • Test LVP in tripledown.
  • Pull in mk2’s code.
  • Pull in guardior’s sharkdrv and possibly other code.
  • Update alexvh’s code.
  • Finish merging some of Tom E’s code (PM thread), which I started but never finished.
  • Pull in chouster’s code.
  • Pull in 3-channel version of blf-a6, and investigate pd68’s other two requests at the same link.
  • Pull in CK’s code?
  • Document Mike C’s awesome trick for putting multiple functions on a single pin.
  • Check the license in each project and tag it in the project’s “meta” file.
  • Test LVP in each project and tag working ones with “LVP” in the project’s “meta” file.
  • Describe each project in more detail in the “meta” files, and copy the summaries into a project list in this thread.
  • Add homepage / URL info to each project’s “meta” file.
  • Investigate, measure, and document ultra-low-power sleep modes. (Crux’s posts here and here, ideas here and here and here)
  • Investigate brownout detection behavior in more detail to determine its actual effects.
  • Test how long the MCU can run after power is disconnected, in its absolute lowest-power mode.
  • Document how to make firmwares work on zener-modded drivers.
  • Document the exact components used on popular drivers.
  • Check if _delay_5ms() is worth using.
  • On super-fast strobes, try using digital pin state instead of PWM, for more fine-grained timing control. (60Hz strobe looks erratic)
  • Check if TheStar has any updates.
  • Make BLF-A6 (and tk-otc.c) easier to convert to single-channel.
  • Make Bistro easier to convert to single-channel.
  • Attempt to write a more robust code base for e-switch (and maybe dual-switch) drivers, using a state change table to define the interface.
  • X6R-compatible firmware.
  • Test the fancy lighted tailcap code and merge it into trunk after it’s verified.
  • Make blf-a6 and bistro and related tools more zener-friendly. For example, voltage_blinks[] uses a 3.5-bit voltage value but needs to be 4.4 to allow voltages higher than 7.9V.
  • Pull in Tom E’s latest Narsil code. (done 2016-03-22)

Looking at this list, I’m thinking it might be best to actually track each as a separate bug on Launchpad. It’s a mess in the form of a simple list.

odd
Offline
Last seen: 1 month 2 weeks ago
Joined: 02/12/2012 - 16:17
Posts: 29

Thank you very much ToyKeeper!

Your repository helped me alot in creating my favorite UI.
So much work already done and easily available Smile

Especially the new wear leveling write and the read code part was just what i was looking for.

I modified Dr Jones´ luxdrv for multiple groups (no wear leveling so far) and offtime-memory
using the NOINIT-section.

Lothar
Offline
Last seen: 2 months 1 day ago
Joined: 10/26/2011 - 11:22
Posts: 389
Location: Stellenbosch, South Africa

Awesome, thank you ToyKeeper!

Now we just need some ATtiny25 sample code Smile

pyro1son
pyro1son's picture
Offline
Last seen: 1 month 3 weeks ago
Joined: 03/21/2013 - 08:18
Posts: 432
Location: UK

I’ve been using you repo for a while. But now I will be able to find it much easier Smile

Pastebin                                      &nbs

Chazzy
Chazzy's picture
Offline
Last seen: 7 months 2 days ago
Joined: 06/23/2013 - 13:24
Posts: 292
Location: California

Great work with all the firmware!

I’ve been loving your brass-edc but it looks like I might be switching over to your A6 firmware. Does your A6-biking have additional blinkers?

"Whoa that's a bright light!" ... Yea I guess.

Mods: [HD2010] http://www.reddit.com/r/flashlight/comments/2tw09v/w

zeremefico
zeremefico's picture
Offline
Last seen: 9 hours 12 min ago
Joined: 03/27/2012 - 02:44
Posts: 1264
Location: Greece

thank you ToyKeeper!

₪₪₪₪ ΟΥΔΕΝ ΚΡΥΠΤΟΝ ΥΠΟ ΤΟΝ ΗΛΙΟ ₪₪₪₪

My YouTube channel

Flashlights & edc gear

K40M F16

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 22 min 7 sec ago
Joined: 01/12/2013 - 14:40
Posts: 6499
Location: (469219) 2016 HO3

odd wrote:
I modified Dr Jones´ luxdrv for multiple groups (no wear leveling so far) and offtime-memory
using the NOINIT-section.

Sounds pretty cool; I’d love to include it if possible. DrJones hasn’t given luxdrv an open license though, so we might need to get his permission to publish derivatives.
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 22 min 7 sec ago
Joined: 01/12/2013 - 14:40
Posts: 6499
Location: (469219) 2016 HO3

Lothar wrote:

Now we just need some ATtiny25 sample code Smile


How about attiny85? I hear Mike C has some code working on that, and I’m hoping he’ll decide to share it. Smile

Or, if I ever end up with an attiny25-based driver, I’d be happy to port something to it. I don’t really have the ability to build the driver myself though.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 22 min 7 sec ago
Joined: 01/12/2013 - 14:40
Posts: 6499
Location: (469219) 2016 HO3

Chazzy wrote:
I’ve been loving your brass-edc but it looks like I might be switching over to your A6 firmware. Does your A6-biking have additional blinkers?

No, the BLF A6 firmware only has one strobe (or biking flasher) and a beacon/battcheck mode. Also, it requires an offtime capacitor and it’s designed for dual PWM, so it might not work on the same drivers as brass-edc.c.

However, I made a stripped-down version which removes the runtime config options in favor of making room for other features… so it’d be relatively easy to add other blinky modes. It’s ToyKeeper/blf-a6/tk-otc.c in my repo, and the entire purpose of it is to make it easier for people to build derivatives. I’m assuming that, if someone is modding code, they can configure it at compile time instead of runtime.

Tom E
Tom E's picture
Offline
Last seen: 12 hours 14 min ago
Joined: 08/19/2012 - 08:23
Posts: 10850
Location: LI NY

Ahh, thanks! Didn't know I could update it directly. I'll try to create an acct and directly update then...

I'm all ears on Mike's ATtiny85 version - very, very interested. Can't stand this 13A code limit.

Gotta take a look at your tk-otc version - sounds like what I  need. I'd want a STAROffTime or your noinit with a strobe option. Adding strobe would be much better with  a "short cycle" mode method, but looks like your A6 two method of clicks (quick and hold) would be as good or better. Right now I don't see an easy way to integrate a strobe into STAROffTime

Mike C
Mike C's picture
Offline
Last seen: 1 hour 44 min ago
Joined: 01/22/2014 - 08:03
Posts: 1719
Location: Sweden

ToyKeeper wrote:
Lothar wrote:

Now we just need some ATtiny25 sample code Smile


How about attiny85? I hear Mike C has some code working on that, and I’m hoping he’ll decide to share it. Smile

I’ll be sharing it. It wouldn’t exist if 13A code wasn’t so freely shared by others here.

I have voltage monitoring working, and have coded a user interface so the user can re-program the amount of modes and levels. I’ll make it 105C compatible with defines, so it can be used for 105Cs out of the box. Working on another light right now, but will get back to the 85 shortly. Next on the agenda is getting to know how the temperature sensor works, but it look s fairly simple as it’s the same routine as checking voltage levels with the ADC. It’s the calibration routine that could be the hardest part.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 22 min 7 sec ago
Joined: 01/12/2013 - 14:40
Posts: 6499
Location: (469219) 2016 HO3

BTW, if you use bzr at a command line instead of using a GUI front end, the commands to clone the repo, modify it, and publish a new version are: (’%’ represents a command prompt, the lines you would type in)

% bzr branch lp:flashlight-firmware
% cd flashlight-firmware
(hack, hack, hack, maybe 'bzr add' new files)
% bzr ci
% bzr push lp:~myusername/flashlight-firmware/my-branch-name

Then either submit a merge proposal or simply let me know the branch exists, and I can merge it into trunk.

I generally prefer to keep a local copy of trunk along with a “feature branch” for each set of changes I make, to help keep things clean. This approach is pretty standard, and is discussed in more detail here, along with how the usage compares with git. But if you don’t know how to do that, I can easily accept patches or branches or merge proposals or whatever.

There are a few cross-platform GUIs available for those who want one — Bazaar Explorer, QBzr, and TortoiseBzr.

LED Boatguy
Offline
Last seen: 10 months 2 weeks ago
Joined: 02/10/2015 - 17:28
Posts: 73
Location: Kollyforneah

Since there are so many flashers here :bigsmile: , I thought I’d ask a question about multiple flash/test sessions. Is it OK to leave the SOIC clip attached when doing a short test of a revised firmware? In trying to learn this language (which started out as Martian, but is now more like Swahili) I’m going to be revising this or that in the code, flashing a driver on the test bench to see if it works, then repeat. It would be nice if I didn’t have to reconnect the clip for every iteration, as I have a feeling the clip’s lifespan is related to the number of connection cycles.

I can see a couple problems:
1. Backfeeding voltage into the USBasp.
2. PWMing a 20cm piece of straight wire, and that could cause EMI gremlins to appear and possibly affect the outcome of the test. I’m not even sure if the PWM pin(s) are connected to the clip.

Opinions?

Thanks.

LED Boatguy
Offline
Last seen: 10 months 2 weeks ago
Joined: 02/10/2015 - 17:28
Posts: 73
Location: Kollyforneah

Thanks for your input.

I emailed the question to the USBasp’s developer. Maybe he’ll respond.

18sixfifty
18sixfifty's picture
Offline
Last seen: 54 min 58 sec ago
Joined: 12/25/2012 - 20:19
Posts: 4124

Thanks Toy Keeper and everyone else for all the hard work. I wish I had something to contribute but I’m only just starting with the flashing but this helps for sure.

I was going through this last night and found a couple that were nice.

For us complete laymen a section with just hex files along with a brief description would really be great, but Beggars can’t be choosers right!!

I’m a junky, I mod lights so I can sell lights so I can buy more light to mod so I can sell lights to buy more lights to mod.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 22 min 7 sec ago
Joined: 01/12/2013 - 14:40
Posts: 6499
Location: (469219) 2016 HO3

LED Boatguy wrote:
Is it OK to leave the SOIC clip attached when doing a short test of a revised firmware?

I tried this a while back… and again just now. It didn’t damage anything, but it didn’t work very well either. There were two issues:
  • The clip can short some pins, resulting in strange behavior which differs from how the light behaves without the clip attached.
  • The clip doesn’t stay on very well on its own, so it’s difficult to test the light without the clip coming off.

So, it’s generally a not good idea to leave the clip on during testing. It’s possible that the clip could cause damage, and it changes the driver behavior (which kind of invalidates the test results).

Tom E
Tom E's picture
Offline
Last seen: 12 hours 14 min ago
Joined: 08/19/2012 - 08:23
Posts: 10850
Location: LI NY

TK - I pm'ed you the link to my versions (google_drive_tome_drivers).

Not sure if this is the right thread for this, but here it goes... Your blf-a6 and tk-otc drivers have a couple of features I haven't seen before:

  • The "OWN_DELAY" option to use our own timer delay rather than the delay supplied with the compiler/tool. Interesting because I just noticed on recent Nanjg 101-AK-A1 builds with STARNoInit, the two minutes for a turbo timeout is really 2 mins 20 secs - off by quite a bit
  • you are mixing FET output and the single 7135 output in some modes but not full turbo. This is interesting, and I assume you did test out these combos to find a nice spread of output levels. I notice you didn't publish what the approximate percentage of outputs are in either the source code or blf-a6.txt. Do you have that info now?
  • I assume you set the turbo mode to phase-correct PWM and not fast PWM because it doesn't really matter (PWM's are not used on max setting of 255)

I'm going to try your blf-a6 version on a A17DD-SO8 board. I'm thinking I could just zero set the mode values for the "small circuit" (MODES1x1 and MODES1x2) and set the big circuit PWM mode values to what I normally use for the A17DD-S08. Do you think this would work ok? Is this the easiest approach?

For the future, I plan on dropping the A17DD-S08 driver in favor of wight's FET+1 driver but I still have stock of drivers (most assembled) to use up.

BTW, This BLF-A6 driver is the most advanced for a clicky power switch light I'm aware of in source code. You did a great job on this!! Thanx!!!

Edit: I found one issue in using blf-a6 on a FET only board - the blink'ing is set for the 2nd PWM output port (the 7135), so I simply changed it to the primary PWM port, using a value of 5, and works like a charm now. I added a compile switch for that. From my bench test, it all looked good. Stupid me though -- put it in a Convoy C8 (old style) and it grounded a LED wire lead to the reflector after I tightened the bezel -- fried both the driver and LED Frown. It looked like there was plenty of clearance, but I guess tightening down the bezel really pushed down on the reflector, causing the short...

odd
Offline
Last seen: 1 month 2 weeks ago
Joined: 02/12/2012 - 16:17
Posts: 29
Tom E wrote:
  • I assume you set the turbo mode to phase-correct PWM and not fast PWM because it doesn’t really matter (PWM’s are not used on max setting of 255)
  • If i remember correctly, on fast PWM, PWM IS used on maximum setting ( ON for 255/256).
    Can´t find the thread at the moment, but it was Dr Jones who discovered that in a commercial firmware.

    bugsy36
    bugsy36's picture
    Offline
    Last seen: 1 month 3 weeks ago
    Joined: 07/11/2014 - 18:15
    Posts: 2475
    Location: Florida USA

    Very nice work! Hat's off to all of you!

    It's the simple things that we take for granted that cost us the most

    Ευκαιρία λέει πιάσε με από το μέτωπο γιατί μόλις έχω περάσει δεν θα με πιάσειs

    ToyKeeper
    ToyKeeper's picture
    Offline
    Last seen: 22 min 7 sec ago
    Joined: 01/12/2013 - 14:40
    Posts: 6499
    Location: (469219) 2016 HO3

    Tom E wrote:

    TK – I pm’ed you the link to my versions …


    Thanks! I’ve been out on sort of a personal holiday (went out and played with the butterflies), but I should be able to add it soon.
    Tom E wrote:
    The “OWN_DELAY” option to use our own timer delay rather than the delay supplied with the compiler/tool. Interesting because I just noticed on recent Nanjg 101-AK-A1 builds with STARNoInit, the two minutes for a turbo timeout is really 2 mins 20 secs – off by quite a bit

    Use DELAY_TWEAK to adjust the speed. The MCU clock speed is only spec’d to be accurate within about 5%, and I’ve found it’s often even worse than that. One MCU will do 70 seconds per minute while another does only 55 with the same code. So, you might need to adjust that value to get the timings right. I tried to give it a rough average as default, but I’ve seen anywhere from 850 to 1050 cycles per ms.

    Tom E wrote:

    • you are mixing FET output and the single 7135 output in some modes but not full turbo. This is interesting, and I assume you did test out these combos to find a nice spread of output levels. I notice you didn’t publish what the approximate percentage of outputs are in either the source code or blf-a6.txt. Do you have that info now?

    • I assume you set the turbo mode to phase-correct PWM and not fast PWM because it doesn’t really matter (PWM’s are not used on max setting of 255)


    The output percents change based on the maximum power level — it will be different on a single XP-E2 versus XP-L versus a triple. This is because the 7135 chip runs at a fixed power level but the FET does not, so their relative contribution to the total changes with different emitters.

    Because of this, the levels need to be re-calculated (and the source recompiled) for each class of light it’s used in, and a percent value would only apply to a specific combination of hardware. I calibrated the default to be visually linear (cube root model) on the BLF A6, with up to 140 lm on the 7135 and up to 1400lm on the FET. I estimated the initial values then tweaked it until my light box showed the desired results.

    As for PWM on turbo, I picked those settings because they measured the highest in my light box. Specifically, FET plus 7135 together produced less light than the FET alone. And I vaguely recall someone (comfychair?) measuring max output curves on fast vs phase mode with a high-speed scope, deciding that phase was slightly better.

    Tom E wrote:

    I’m going to try your blf-a6 version on a A17DD-SO8 board. I’m thinking I could just zero set the mode values for the “small circuit” (MODES1×1 and MODES1×2) and set the big circuit PWM mode values to what I normally use for the A17DD-S08. Do you think this would work ok? Is this the easiest approach?


    Edit: I found one issue in using blf-a6 on a FET only board – the blink’ing is set for the 2nd PWM output port (the 7135), so I simply changed it to the primary PWM port, using a value of 5, and works like a charm now. I added a compile switch for that.


    Yes, it should work… aside from that issue you found. Smile

    Thanks for reminding me about that. I should probably release an update with a compile switch for it like what you made.

    Tom E wrote:

    It looked like there was plenty of clearance, but I guess tightening down the bezel really pushed down on the reflector, causing the short…


    Youch, that sucks! I’ve reflector-shorted things enough times that now I always cover the bottom of the reflector with kapton tape. Then again, I also usually test out a build on a bench power supply at low amperage before I try it with a real battery.
    djozz
    djozz's picture
    Offline
    Last seen: 7 hours 16 min ago
    Joined: 09/07/2012 - 17:04
    Posts: 11201
    Location: Amsterdam

    The upcoming BLF-A6 must have the best tweaked brightness levels in the flashlight universe SmileSmile

    Mike C
    Mike C's picture
    Offline
    Last seen: 1 hour 44 min ago
    Joined: 01/22/2014 - 08:03
    Posts: 1719
    Location: Sweden

    LED Boatguy wrote:
    Is it OK to leave the SOIC clip attached when doing a short test of a revised firmware?

    This really depends on what you are doing. The power from the ISP is enough to power the MCU, so if you’re testing start up routines like off time cap testing and brown out detection you should unclip it.

    It’s a pain in the *** to unlcip ‘em all the time. That’s why I built this setup with relays that vex_zg donated after showing me his solution. Now I just press a button to unclip:

    ToyKeeper
    ToyKeeper's picture
    Offline
    Last seen: 22 min 7 sec ago
    Joined: 01/12/2013 - 14:40
    Posts: 6499
    Location: (469219) 2016 HO3

    Mike C wrote:
    Now I just press a button to unclip:

    Nice! That certainly beats my cheap setup… I just have a few different drivers attached via long wires to decapitated hosts, with extra wires soldered on to connect a battery by hand. I have to clip the clip each time, and frequently hold it in place during flashing because it won’t stay on its own.

    So, what I have is cheap, compact, and only took a few minutes to make… but it’s also inconvenient. I hope you don’t mind if I drool a little over your dev setup.

    ToyKeeper
    ToyKeeper's picture
    Offline
    Last seen: 22 min 7 sec ago
    Joined: 01/12/2013 - 14:40
    Posts: 6499
    Location: (469219) 2016 HO3

    djozz wrote:

    The upcoming BLF-A6 must have the best tweaked brightness levels in the flashlight universe SmileSmile


    Hah, we’ll see. I have to recalibrate everything when the production sample shows up.
    Joat
    Offline
    Last seen: 1 week 3 days ago
    Joined: 06/13/2013 - 23:43
    Posts: 519
    Location: Minnesota

    Small through hole mount 2 pole relays are about $1 each from digikey. Anyone want to design a board with two connectors a switch and some relays?

    alexvh
    Offline
    Last seen: 11 months 1 day ago
    Joined: 05/28/2013 - 23:40
    Posts: 29
    Location: Canada

    I’ve posted this in another thread, but it’s relevant here. This is what I use to test features and develop firmware. It can be powered from a battery or from the programmer. The 7135’s on the nanjg aren’t connected to anything. The only problem with it was that I had to unplug and replug the usb cable to reset the programmer sometimes before I could flash the attiny. I think maybe the pwm creates too much noise for the programmer or it tries to read it as a signal and gets confused. I’ve added a reset button to the programmer so I can just reset it instead of unplugging it. The microswitch disconnects ground/negative so pressing it acts like a half-press on a flashlight. I made it after getting frustrated with disassembling my edc light and using a makeshift clip to program it every time I wanted to test something.

    I have to reset the programmer occasionally, but it works fairly well and allows me to test features a lot more quickly.



    My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

    Discussion: http://budgetlightforum.com/node/36932

    Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

    LED Boatguy
    Offline
    Last seen: 10 months 2 weeks ago
    Joined: 02/10/2015 - 17:28
    Posts: 73
    Location: Kollyforneah
    ardvaark wrote:
    Gorgeous setup! Love the relays, great idea.

    Nice!

    I was just thinking about a DIP switch. It would be easy to make a board.

    Mike C
    Mike C's picture
    Offline
    Last seen: 1 hour 44 min ago
    Joined: 01/22/2014 - 08:03
    Posts: 1719
    Location: Sweden

    ardvaark wrote:
    Gorgeous setup! Love the relays, great idea.

    Yep. Gotta thank vex_zg for it. He showed me his setup and had relays to spare. It saves a lot of time.

    ToyKeeper wrote:
    Mike C wrote:
    Now I just press a button to unclip:

    Nice! That certainly beats my cheap setup… I just have a few different drivers attached via long wires to decapitated hosts, with extra wires soldered on to connect a battery by hand. I have to clip the clip each time, and frequently hold it in place during flashing because it won’t stay on its own.

    So, what I have is cheap, compact, and only took a few minutes to make… but it’s also inconvenient. I hope you don’t mind if I drool a little over your dev setup.


    I was starting to get aching hands after all unclipping… well, almost.
    The photo is slightly old, I’ve added a little to the setup. I’ve attached a SIOC14 clip to the remaining pins the relays so I can just as easily program the ATtiny24/44/84. Button pushed is the SIOC8 clip, button released is the SIOC14 clip. The other button is just a convenient power button not attached to the relays.
    LED Boatguy
    Offline
    Last seen: 10 months 2 weeks ago
    Joined: 02/10/2015 - 17:28
    Posts: 73
    Location: Kollyforneah

    Something like this board (ordered).

    With this switch.

    One thing nice about connecting the programmer with that color, 40-wire ribbon is that you have lots of extra wire to fool around with stuff like this.

    ToyKeeper
    ToyKeeper's picture
    Offline
    Last seen: 22 min 7 sec ago
    Joined: 01/12/2013 - 14:40
    Posts: 6499
    Location: (469219) 2016 HO3

    18sixfifty wrote:
    For us complete laymen a section with just hex files along with a brief description would really be great, but Beggars can’t be choosers right!!

    For now, I added something like that to the INDEX file. It lists each project with a one-line description, pulled from the ‘meta’ files in each project directory. The meta files aren’t all complete though, or reviewed by the owners of the projects they describe.

    http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/he...

    Pages