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.
Just to make sure, what is the link for the most recent working version?
I’d prefer to add that one instead of an earlier one which didn’t work. 
Perhaps this should be added too?
I just did a quick check, and I don’t think anything in the repository matches all of the following:
I see everything except tiny13 in one of Tom E’s projects, and everything except dual PWM in one of my projects, and everything except single-click off in JonnyC’s code… but nothing with all of them in one place. Unless I missed something.
That sounds like it’s definitely a hardware difference. You can measure some hardware traits using the files under ToyKeeper/battcheck/* , but that’s just one option.
One possibility is that maybe the fast_presses variable on that exact MCU happens to decay to a useless value. This would be rare, but is possible. You could try changing around the order of variable definitions to maybe align that with a different part of RAM… or try dumping out its value on boot in order to check if it’s even relevant.
Anyway, it’s hard to say for sure what the issue is.
The one in the post is the most recent version, I have it installed in the S8 in my sig line. I was going to ask though, can one of you wizards take a look at the LVP code? I’ve experienced some strange behavior that I haven’t totally found a pattern for. It’s almost like mode cycling stops working when LVP is kicking in. Like you’ll be in turbo/fet mode, lvp will step down to medium, then you can jump back up to turbo, but you can’t cycle past turbo to low. No matter how many “short presses” you do it stays in turbo until lvp starts to step it down again.
Yes, I couldn’t find a matching FW too, that’s why I was asking.
But after the changes I’m satisfied with it so far. The next time the light is opened I’m going to set the long press to about .3s as well. And delete the first mode which is off. I think pd’s solution should be the best. BTW then it is exactly the same UI that Nitecore is using e.g. in their HC30.
The only thing I’m not happy so far is that the turbo stepdown is happening in PWM-channel 1 only (where are my AMCs) and not in PWM-channel 2 (where is the FET). This has to be changed but I want to find out myself first. If I can’t do it I will ask again.
sub