Yeah, it kinda is. "NON_WDT" is "Non-WatchDog Timer". Essentially, instead of using the native AVR functions for keeping track of timers ("watchdog timers"), blf-a6 firmware is just counting "ticks" (execution cycles). It's relatively easy to code & understand, plus I imagine there are some code efficiency (space savings) benefits.
When you comment out that #define, disables this entire chuck of code. At compile time, it only gets included if that NON_WDT_TURBO is defined.
#ifdef NON_WDT_TURBO
// Do some magic here to handle turbo step-down
//if (ticks < 255) ticks++; // don't roll over
ticks ++; // actually, we don't care about roll-over prevention
if ((ticks > TURBO_TIMEOUT)
&& (output == TURBO)) {
mode_idx = solid_modes - 2; // step down to second-highest mode
set_mode(mode_idx);
save_state();
}
#endif
New Nanjg 105D.
After erasing and writing the new firmware - always got in group selection mode (instant / fleshstrob, two instant / fleshstrob) and only then entered into 1st mode
2. After erasing and writing the new firmware to the NEW ( not Nanjg 105D, driver in Convoy S2+ (from GB) like red driver in the C8 from Simon) Moonlight is available in all modes (most likely). When there is a strobe (mode battery check) - LED goes out not completely.
There is clearly some sort of mistake.
On the third issue, when, after entering the group selection mode is only Moonlight I did not come across. Yet?
I don’t know if I understand completely correct what you describe, but it sounds like you are experiencing issues that would’ve been reported by many others if they’d occur. Please forgive me for asking again, but are you really sure you got the right fuses? IIRC BOD has to be enabled with Biscotti, so high fuse should not be 0xff, even if it’s written so in the the biscotti.c file. Please, someone correct me if I’m wrong here. I never tried biscotti, but if I were to flash it I’d go with the following line:
I’m use AVR Dude & this *.cmd file
avrdude -c usbasp -p t13 -u -Uflash:w:biscotti.hex -Ulfuse:w:0x75:m -Uhfuse:w:0xFD:m -B 57600
I fussed all morning with one driver. I compile new firmware, downloaded from ToyKeeper hex file. Nothing worked (the first case).
After lunch, I got bored. I took another driver flashed it with the same parameters. And everything was normal once.
Oh, that’s strange. Thanks for the links. First time I read about that. I have some 105D laying around, maybe I’ll check biscotti out today… If so, I’ll report back, if it’s working as it should.
Of course, TK would be the person to most likely understand what’s happening there.
I’m really no expert, I just thought you maybe had the fuses wrong, because it sounded like a misbehaviour that could’ve been introduced by not having BOD enabled. I don’t even know what you’re doing with that “-B 57600” in that line, but it seems like you know what you’re doing.
I use TK's recommended fuse settings (0x75, 0xFF), disabling brownout detection, and it's been working fine for me in several lights/driver running Biscotti.
Where did the FD value for brown out enabling to 1.8V come from? Why are you guys using it?
I thought TK uses the SRAM decay (noinit) trick from alexvh to detect short versus long presses. I thought BOD has to be enabled for that, but you seem to prove that wrong?!
I've been using the same trick for quite a while with brownout disabled in other firmware versions. The 10 uF cap is a big part of that. In fact on the ThorFire BD04 (same as Convoy BD04), I pulled the C1 cap and it tested at ~1.2 uF, so Biscotti worked awful on it. I swapped the cap to a proper 10 uF one, and wholla! Worked great! With the lower cap, you had to be super quick on clicks, and with the normal cap, the timing was much easier, pretty normal.
I got some of the Simon "bad" Biscotti drivers on the way to test/trouble-shoot for Simon, that JDub-74 arranged. Think first thing I'll test is the cap -- pull it and test it's value, it's pretty easy to do. But still don't think that's the main or only problem. Problem is you can't read the fuses (don't think so) or read the programmed firmware.
Hhmm, possible the original Nanjg's weren't 10 uF, but it's been our standard since basically day one with OSHPark drivers, and thought we duped the parts. I'm not sure back then if we knew how to measure caps though. Can't recall... The 13A can take a lot more noisy signals than the 25/45/85's can, so probably could have gotten away with it. The basic Nanjg design is kind of a mess, but they get away with it, counting on out of spec tolerances, etc., and keeping the parts count down.
ComfyChair was the originator of a lot this stuff, including the first custom FET drivers where we hacked in a FET on a Nanjg.
Yea, I was aware the commands exist to read it all back but I understood they didn't work. Now could be because the factory programming locks it to not allow reading, or the USBAVR dongles we use can't do it, not sure...
Worth trying though on the 105D's from Simon - I'll give that a shot. Should have them early this week based on tracking.
I am looking at Toykeepers Firmware for Ferrero Rocher driver. Is there some way a junior woodchuck like myself could edit this firmware so that I can start on high? off, high, med low, off?
Ohhh - this works btw!! I think it did not work with original Nangj's to read the factory firmware, but it works fine on Simon's new Biscotti 105D drivers - I can confirm the fuse values, the code of course is a little harder to reverse engineer (), but it actually looks good. They appeared to use the wrong fuse value in the lower byte: 0x78 instead of 0x75. But... If you use 0x75, the Off value of 0 for PWM lights the LED at a level lower than moon mode. Think this might explain it:
/* This is no longer needed since we always use PHASE mode.
// Need PHASE to properly turn off the light
if ((pwm1==0) && (pwm2==0)) {
TCCR0A = PHASE;
}
*/
It's commented out when it probably should be left in. Because PWM is still in FAST mode, the value of 0 seems to leave the LED ON.
Ahhh, I've modded the FR firmware before, but think simple stuff - mode levels maybe. Not understand what you are saying there.
You want a click to Hi, then next click is OFF, then next click is med low, then next click is OFF? If so, you got a couple changes there....
reverse direction
go OFF after each mode change
The 1st part looks easy. Looks like a compile switch called LOW_TO_HIGH will reverse it, just comment it out. But of course long holds will do the same thing.
The 2nd part to this is completely breaking how modes transition by adding the OFF state between modes. Dunno how that would look like. Do-able but I think code space is tight in the FR driver. Could add some sort of toggle state of OFF and ON, keeping the mode table the same. Again, not sure how much memory is left though...
That is what I need I think. I don’t want off between the modes just at the beginning and end of the cycle. I will give this a shot and see what I get.
), but it actually looks good. They appeared to use the wrong fuse value in the lower byte: 0x78 instead of 0x75. But... If you use 0x75, the Off value of 0 for PWM lights the LED at a level lower than moon mode. Think this might explain it: