I think I have everything working now. I haven’t actually tested LVP yet, but I don’t know why it wouldn’t work as the mode order is now back to “normal”.
Would one of you mind looking over it to make sure there isn’t some hidden screw-up that will cause me grief later? thanks
once again, mine is on the right, stock STAR is the left. Diff check
edit: JK, now I’m back to having the problem that when power is cycled when in mode “0” it doesn’t come on in mode “3”. plot twist: So if I hold the button for 2.5 seconds it enters mode “0” (off). If I then remove power for <5 seconds, when power is reapplied it is still in mode “0” (no bueno). However, if I remove the power for >5 seconds before reapplying, it comes on in mode “3” as it should. Any ideas here?
That issue was on my “power supply.” I decided it wasn’t a big deal, so I installed it in the light anyways. Miracle of miracles, once in the light that weird behavior went away.
FWIW, I did some tests a while ago for the mem-decay method of detecting short presses. If I drain the OTC, it seems to take about 0.5s for the memory to decay. If I leave the OTC fully charged, it seems to take about 4s for memory to decay.
Just a thought. I don’t even know if you’re using that method.
I’ve had other issues with it before, especially with turbo timers. Idk if it’s ripple or what.
For instance on this driver, I have the timer set to 2 minutes. Its 6*7135 (2.3amps). If I have my buck converter limited to a lower output, like 1.5amps, the turbo timer steps down wayyyy early, like 1 minute instead of 2. But if I don’t limit output on the “power supply”, the timer works just fine.
I don’t understand it, but I’m slowly learning that if something isn’t acting the way the firmware says it should, try it on a battery before freaking out.
I do my initial tests on a batt 90% of the time - an old TrustFire in a holder w/red&black wires ended with alligator clips. Sometimes if it's more risky, I'll go slowly up with the bench PS. I'm usually carefully continuity testing everything out first, so not much risk applying power.
Oh, on a variable current / voltage power supply, with current limited, the voltage can do some weird things. You can only limit one or the other, basically, and the other will adjust itself accordingly.
I’ve been finding that even voltage calibration seems to work better with a battery than with a power supply (and a DMM to confirm voltage in real time).
I do. On the 25/45/85 thread, have a dnld link but it requires a 45 or 85. Blew past 2KB code, so the 25 won't cut it. It's also fully programmable (64 possible mode combos) and I posted an instruction manual (2 pages) on it's operation. Didn't upgrade a Y3 yet, but I'll have to do 4 of them shortly. Have the dual switch (e-switch/power) version dnld'ed in a X6R and works well so far.
Great, but can it be applied on wight`s A17dd ver 0.44 and tinny13? The last Y3 i modded was with that driver, el and tail switch and TK Ramping UI table firmware, V6 1D dedomed and 210k cds, came out exellent but now i need the firmware i mentioned
No tiny13 support, only a 45 or 85 on a FET+1 driver. I've only used the FET+1 wight drivers, like the BLF A6 driver, in 17 and 22 mm sizes. All my e-switch build/mods are or will be 85 based. It can be changed to work with a conventional FET or 7135 (only) driver but I don't see it worth the effort for now. There are some newer OSHPark boards available now for the larger footprint of the 45/85, but mostly I'm doing the "bent in pin" technique to retrofit.
I’m thinking about giving bistro a try. I have components for wight’s 17mm FET+7135 and I recently ordered an Attiny 25. Unfortunately I got the normal 25, not 25V. Would I have to make some important changes to the code for the use of the “standard” 25?
Nope, no changes. In fact Richard at MtnE sells the 25, not the 25V. Only difference is low operating voltage, but the LVP kciks in before you should get that low anyway.
Thanks Tom and TK. I will give it a try. I succeeded in flashing all different kinds of firmware from TK’s repository, but now I’ll have to find out how to work with these new *.h files. Will do some research now. If I think that’s over my head, I could just use the bistro.hex file, right?
edit: ok, I think I found out how to deal with these header files.
The headers are something I’m still deciding how best to set up.
Originally, I told the code to include “…/foo.h” so it would automatically look in the right place. But that makes it not work when all the sources are copied to a single directory, or when a project is one layer deeper. To fix that, I can include “foo.h” without the … for parent directory, but the build options will then need a “-I…” to add the parent to the default include path. Maybe a “-I…/…” too. Simple fix on a command line, but it means one more step when using AVRstudio.
It’s weird trying to support foreign build systems. Normal software doesn’t have these issues. Normally you’d ship a Makefile and force everyone to build in the same way, but AVRstudio doesn’t like that approach. As builds get more complex though, it gets harder to build with different tools. So I’ve tried to keep it pretty simple, but duplicating code all the time feels like scratching a chalk board.
