but it actually does save a few bytes over using globals. It kind of just went from one to two, and then someone hacked a third on, and now it's kind of silly.
And by the way, things are bit broken now. I said I implemented it, but I've done a bunch of "clean" up and reorganizing and who knows how long it will take me to recover from that. I haven't even tried to run it yet. I already know of one thing I broke (a feature that I added though), but I'm not going backwards. I'll twiddle at getting it all in shape as I get time.
:FACEPALM: It ended up being just a dumb mistake. After all that I deleted it. I just didn't have optimization on at the time, doh.
Some days are like that programming. You know like when waste a bunch of time just to figure out the program you're running is in a different directory than the one you're compiling, which explains why the last 10 ways you tried to fix it didn't work. I'm pretty sure anyone who's programmed much has done that one before... or maybe it's just me.
I can vouch for that, for sure.... Was gonna ask bout the S optimize setting, but thought that was little insulting . Anything one could get wrong, I've done, I'm sure. All a matter of how fast you can figure it out. Many times I come in the next morning and it's obvious, staring me in the face.
So here's a new one. Vcc ADC reading seems to mess with the light a bit.
I did of bunch of recent changes without testing, just getting the code organized, surprised things mostly work still, but they seem to. Except the light had a pule, a heartbeat. After burning through another 20 flashes on this poor attiny's life it boiled down to the adc being on and set to the Vcc reference, and having changed the timing of things I noticed now when not before. In fact I intentionally was cycling the ADC on longer between voltage and thermal mode to stabilize readings, but that's the heartbeat. Of course ADC_on was the last thing I suspected. It seems that an adc reference on the Vcc pin is disturbing the electronics and dims (we don't want dim) the light a little.
It's a full single 7135 mode, no PWM. Being a regulator I'd hope it wouldn't be too sensitive to a little voltage fluctuation. I have found these things are pretty finicky,very easy to break entirely. Maybe I should replace the 7135 and see what happens.
I hope that I’am in the right thread. Does anybody get the lvp working for 6V configuration with 36k/4,7k Resistors? For example with blf-a6 firmware. I would be glad to see the code. Thank you guys!
So the fun part with 4 channels was it wouldn't go full off. Actually there's a note about that problem already for the 3rd channel (runs off the same PWM clock), but I didn't understand it until now. Ok, so only phase mode goes full off and timer 1 doesn't do phase mode. The 3rd channel historically drives the FET though and isn't used for moonlight on tripples, so probably just never noticed. Also it's likely significantly worse using interrupts to bit bang the pin. The simulator shows about a 6 pwm-tick delay between the two interrupts handlers running, which could just be from the interrupt handling itself. The first interrupt already starts 3 ticks after the match, so maybe that adds up. I doubt the wave form generator is that bad. I think it's supposed to be a 1 tick spike. Anyway, I'm using the interrupts for my idle sleep clock but I sent a control bit to the on intterrupt to just shut it off on level zero and it behaves. Whoo. I haven't done the same for channel 3, but probably should for potential RGB use.
TK had a note awhile back about not knowing how to slow down timer1 (the channel3/4 timer) below 31 khz. In principle that helps some with this issue and generally with low modes. I'm not sure why she said that though. Actually before I read that, I thought I'd slowed mine down by half. It has a prescaler (TCCR1 CSx), which I thought I adjusted, but now I'm wondering if it doesn't work, or if I was confused. All my blink timings are based on that clock when the 4th channel is engaged so I'll just play with it and see how the blinks go and find out.
E-switch works, but there are many configuration possibilities with slightly different code paths, and the one I tested is maybe not even very normal (ok, tested that one too, it works!), so a little more to test still. Well, there probably is more testing to do, but I'll probably go and and put it out in the next day or so anyway.
Hi, I have a help/knowledge request. I want to alter Toykeeper’s ramping_table_UI FW to work with FET+1, in order to get a lower moonlight mode.
My hope is that this won’t be too difficult to do. A new mode list will have to be made, but the attiny13a should still be capable of running it.
Before I go fiddling around trying to do this I thought I would see if there was some concise wisdom someone could give me regarding this. For example, I see in FET+1 FW codes where the pwm levels are defined for each channel for each mode, but I can’t find where these channels are assigned to the specific pins of the chip.
If I succeed I would like to share the code if that is appropriate. I really like this UI, and I think it would be perfect for me if it had that moonlight capability.
. Anything one could get wrong, I've done, I'm sure. All a matter of how fast you can figure it out. Many times I come in the next morning and it's obvious, staring me in the face.