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.
The project used bzr and Launchpad initially, but Launchpad has been slowly dying, so about a decade later I moved it to git and GitHub.
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.
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.
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?
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.
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.
How about attiny85? I hear Mike C has some code working on that, and I’m hoping he’ll decide to share it.
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.
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.
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
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.
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.
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:
Backfeeding voltage into the USBasp.
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.
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 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).
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 . It looked like there was plenty of clearance, but I guess tightening down the bezel really pushed down on the reflector, causing the short...
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.
. It looked like there was plenty of clearance, but I guess tightening down the bezel really pushed down on the reflector, causing the short...