Yes, I think so. I wanted the blinky modes to actually turn off between blinks, so I made it use phase-correct PWM by default (and only use fast PWM for the always-on modes).
BTW, I tried the idea of changing the ceiling value according to voltage. I had to rearrange a bunch of other code to make room, but I think it’ll work… ish. I’ve only tried a very coarse correction table so far, and due to the variability in voltage measurements, it tends to make moon mode blink brighter or dimmer every few seconds.
This could be fixed by using a bigger table and/or taking an average of several voltage readings, but those both take more space. I’ll probably at least try a slightly bigger table though.
The problem right now is that I’m too sleepy for any complicated math. I’ve got a non-linear curve with an unknown equation (the power to the emitter rising during each pulse) which changes shape according to another non-linear curve (voltage drop), and the only way I can correct it involves another non-linear curve (PFM response curve, roughly 1/x shape). Given these three, I’m trying to make a fourth curve which takes the first three as input and returns a result which is as close to flat as possible. And then quantize that fourth curve into a relatively small table.
That’s too much math for me to do this morning.
I would really love it if this driver had a single 7135 chip available for handling moon mode. (like RMM’s moonlight special, only on a FET driver)
Edit: So, I tried a simpler approach… added a lowpass filter instead. It seems to work pretty well. The PFM level will simply ramp up/down by 1 any time the voltage reading says it’s not right. That means the flicker is very small, and when it does change it’s pretty smooth. If the voltage flips rapidly above and below a threshold, the PFM level will just hang out somewhere in the middle. Plus, it looks cool smoothly ramping up on boot.
OTOH, I’m seriously scraping the bottom of the barrel now for spare bytes. It’s at exactly 1024 and I don’t see anything else I can reduce in size without dropping features.
Oh, yes, probably. But I didn’t know that was a usable symbol in avr-gcc so I used the hex value instead. I think it’s probably fine either way as long as it’s documented / commented.