So I have tried to browse the code and I think I missed it, but is there an adaption of the BLF A6 firmware for single PWM driver, like the BLF17DD/A17DD-SO8 etc?
Apologies If I missed it, I know much of the code works with those driver, but I really like the A6 software and would love to use it on my other lights.
OK, back at the computer and reworked the code a little.
You can try this:
I moved the ON+OFF control for the FET pin to the set_output function in line 377.
This is a little cleaner than patching it into the main.
It compiles (does not fit on a Tiny13 with my compiler), but I do not have a convenient way to test it. Just let me know if it is not exactly what you need.
It should work as is, just adapt the levels for the 1st PWM output to what you need.
By default they are 0 for the lower levels.
Look for these defines around lines 119 and 129 respectively:
First one contains the levels for the 7-mode group, the other for the 4-mode group. Change the zeroes to useful levels.
As far as I can tell at this point, everything is working perfectly. Iāll of course report if I notice anything weird with more use. For me it compiled at 93% of capacity for the 13a. Thanks so much! My S8 can finally get a new heart 
TK: I feel this would be a good one to add to the repository. It is so far the only one that works with my TripleDown driver boards.
Ahhhh I see how youāve done it. Very clever.
HELP!!!
Iām having issues flashing. Over christmas I upgraded my PC to Win10 and since can no longer flash firmware. I have tried different USBasp driver but Iām getting this message:
avrdude: verifying ā¦
avrdude: 250 bytes of flash verified
avrdude: reading input file ā0ā¬75ā
avrdude: invalid byte value (0ā¬75) specified for immediate mode
avrdude: read from file ā0ā¬75ā failed
Can anybody help?
Run it from a virtual machine
Tried flashing with AVRDudess (GUI for AVRDude) and Iāve not got the error message. Will find out how well this has worked on thursday
I have a problem with one of the eight fet + 1 drivers that i built. All of them are running the blf a6 firmware but one driver i canāt get to the soft config mode (blink where i have to select the 2nd group and memory mode). It just continuously goes to the next mode after 15 or more taps. I donāt know if itās a bug in the firmwware but all of my drivers are using the same firmware and this is the only one that is having that problem so maybe not firmware. May itās the mcu? or the otc?
IĀ“m searching for a FW similar to TKs STAR_momentary (which I use atm), but with the possibility to switch off faster. I believe I will like dth_Momentary_v1_1 but I need also dual PWM output.
Any ideas?
BTW IĀ“m not familiar in programming, just able to change mode values and flashing to driver.
Thanks for your help!
And yes, I didnĀ“t read the whole threadā¦
Itās not difficult to change STAR (not TKās btw) so that a long(er/ish) press goes to off instead of going backwards. Thatās what I use. Short press always goes forward, long press from off goes to turbo, long press from on turns off.
My mistake, sorry JonnyCā¦
Yes, the way you describe would fit my needs. But itās not easy for me to change it, probably impossible.
May I see your changes or get the source code?
I can upload the code I used when I get home tonight, but someone else might be able to do it sooner. It really is a simple change, just part of one line if I remember correctly.
Thanks pd, that would be great.
I know I have to learn a lot about the codes work but it takes timeā¦ even to see which change will lead to an effect is one step forward
If youāre in a hurry, you could probably find the answer in the STAR thread a few pages back. I had to ask for help doing it about a year ago(?).
IĀ“m not in a hurry but in the meawhile I found it, changed it and it works 
Now it fits my needs and I have one more nice light with a great UI. Thank you!!!
Cool. Thatās what I use in all of my e-switch lights (so far). I also shorten up the long press so that itās only about 0.3 seconds.
Itās just a small step toward giving it a more normal code layout. Putting everything in one file is pretty unusual, and frowned on in most software development. Instead of using a single code file to represent the state of a project (like saving the build for a specific light), snapshots are more often taken in the form of a code branch or repository tag or a tarball or some other complete snapshot of the entire project.
Soā¦ Common functions, things which donāt usually change from project to project, were moved into shared headers. When one project gets an improvement to these bits, all the others benefit too. The individual projects have less boilerplate code and focus more on the parts which make them unique. And if thereās a common component you like to do differently (such as hardware calibration), you can swap out one file and itāll apply to every project automatically.
I limited this to only my directory though, since other people manage their code in different ways. And I added ātk-ā to the beginning of each file to avoid name collisions. C doesnāt have real namespaces, so I basically kludged one together in flat space instead.
Iāve still tried to avoid a lot of typical C idioms though, like depending on a specific build system or external libraries or anything else which makes it significantly harder to use in WinAVR or OSX. These projects are still simple enough to be manageable without a massive complex internal structure.
Oh, right. I tried a whole lot of different code while making the soft start ramp-up/down code, and it looks like I missed a few things when cleaning it up afterward. You could also make the ramp slower by increasing the number of steps instead of the delay between steps. This way itād be smoother.
On some later firmware, the same code should be able to provide smooth transitions between levels on an e-switch lightā¦ but that ability isnāt really used much in bistro.