Attiny25/45/85 FW Development Thread

Now that I'm staring at assymbly more anyway, I'm a bit less ethusiastic. Below is a do-nothing interrupt handler (intentionally does nothing), in C it was empty:

ISR(WDT_vect){
00000197 PUSH R1 Push register on stack
00000198 PUSH R0 Push register on stack
00000199 IN R0,0x3F In from I/O location
0000019A PUSH R0 Push register on stack
0000019B CLR R1 Clear Register
0000019C POP R0 Pop register from stack
0000019D OUT 0x3F,R0 Out to I/O location
0000019E POP R0 Pop register from stack
0000019F POP R1 Pop register from stack
000001A0 RETI Interrupt return

Well, yes, that does absolutely nothing, except move some bytes there and here, and back there again. It seems like probably standard ISR setup to save things (working registers and status register) to stack and clear register (R1 anyway) so you can do something, and then pull the stuff back off the stack again at the end to put it back as it was. But I'd kind of think since nothing is being done, it should be kind of smart enough to actually do nothing. It sure seems to me like the only instruction needed here is "RETI". Looks to me like a bit of inline assymbly could save some more bytes. I wasn't really looking for this. Just ran into it trying to understand something.

Ahh, more details here:

http://www.avrfreaks.net/forum/why-code-empty-interrupt-routine

The first answer isn't helpful at all but it gets better.

I am looking at things from the big picture, what you actually see with your eyes point of view.

From this point of view it is a tiny effect that will be all but unnoticeable to the human eye. In fact I would venture to say it would be totally unnoticeable as any mode that would use software regulation would be after the 7135’s are already on and at that point the human eye just can’t make out rather large differences in output.

When the difference from the 7135’s to turbo is ~800 lumens to ~1100 lumens and you have to got back and forth a few times to make sure turbo was actually working, I am simply not worried about something that would make a fraction of that amount of difference in output.

As far as needing septate calibrations for different numbers of 7135’s, I actually kind of doubt this will be the case, I don’t change the firmware at all for the different 7135’s levels I use right now. at least not for a change of 1-2 7135’s. The 22mm drivers have 9 of them and the 17mm have 7. Both work perfectly fine with the default firmware needing no changes. The LED used plays the much larger role from my experience.

Now triples might need a different table but even this I think will work fine with the same basic slope, sure it will not work the same but once you get into triple lumen levels even larger differences in output are unnoticeable to the human eye. 3000 vs 3800 lumens in a triple is hardly noticeable if the beam profile is the same.

Yeah, 7 vs 9 won't be a big deal. 4 vs 9 though, yeah, maybe. 1 vs 9 certainly. Anyway, perception and usefulness are not the same thing. More light is more useful, especially in traffic.

Anyway. Restart works. I can distinguish restarts from cold starts now without corruption concers, without rewriting the whole program or using eeprom, just some stack hacking. I also realized I was being silly about detecting memmory decay. It's not like checksums or redundancy are a new concept. Just write a byte 4 times and make sure they're all the same. That's not what I did here though in the end, but it could be done to make the existing OTC-less fastpresses work better or to have mid-term memory/timing over periods of say of an hour, which actually looks possible.

You make a habit of blinding drivers in traffic?

I think you're looking for the other light forum. Man, you can get banned there for even discussing any kind of non-DOT approved illumination.

At some point I started getting wakes from real non-simulate restarts. Just 128+ ms. It doesn't sound like much but basically I think initial sleep detection and shutdown eats through a ten'er. Every 10uF from there should add about 1.5s. I'm at 4.2V but I'm also at 2.7V cuttoff, so not so different from 3V and 1.8V cuttoff. I'll see how many caps I can balance on top of each other.

LOL, well I referring to your earlier post:

I can’t come up with a situation where more lumens in traffic is a concern? I tend to try to stay out of the street, particularly at night. But thats just me. :stuck_out_tongue:

On a bicycle at high speed, you need much more "microsopic" vision of the road surface than you do in a car. Ruts will kill you. Not everything has to point up. But other lights around (from traffic etc) do reduce your contrast. It's not perceived brightness that matters. It's actual brightness that determines how far down the road you can see well. I don't think I was the only one saying this in the modes group discussion. Anyway, my single 18650 lights, don't put out 3800 lumens.

What you want on a bike light is to be able to set it to a fixed brightness, have it stay there, and select the appropriate such brightness based on the runtime you need to get.

oh, and that power off wasn't quite real.. I shorted c1. I mean that does shut power off, but it shuts it of FAST. So it's still kind of cheating.

So 4 s 2s (didn't reset the counter, oops) with another 20uF added , my prediction wasn't that far off. But actually that was with 1.8V cuttoff (always was)..1.25s 0.75 at 3.1V on this chip though. Many more ifs, ands, and buts compared to a final light still some good, some bad. One of the big ifs is that the ADC wasn't on during power off detection and power off is clearly about 10uF worth of the drain. All this matches up reasonably well (still true after correction, was a bit high, is now a bit low) with the current measurements I made before. I still think this is probably the cause of Mike C's observations about the ADC being so important.

I set the main loop to only turn on the adc before taking readings, added idle sleep to the delay function, sped up the ADC, and added a 16ms delay (sleep) in the main loop. This should keep power-off detection drain under control hopefully.

Oopsie, sorry guys for not keeping up with this thread. I just don't have the time I used to. Work has gotten a bit crazy, and still some doc/med issues. Wayyy behind on pm's as well.

Think you guys figured out the parasitic drain in Narsil - it's got a 10 sec delay before shutting off, unless LVP is in effect. If so, it actually stays up for 6 minutes so periodic LVP blinks can be done for a while.

Sorry, got some loose ends in Narsil 1.3, just haven't gotten to finishing the mods.

No problem, totally understand! I have much the same going on in my life (about about to get way crazier!).

Thanks Tom. Ya, figured it out the long way:) I did some more learning atleast. I have a number of drivers built and waiting for the updated Narsiltriple. I didn’t realize you were so busy. There’s no pressure here! Your free services to blf are invaluable to the rest of us. Whatever and whenever you contribute it is greatly appreciated!!!

K, I'm gonna make it a priority to clean up the latest Narsil soon, because I need to update my Manker U11, and really want to get a Lumintop SD26 modded with a TA triple as well. The U11 came out just plain awesome - it's a GREAT host, no matter what you think of Manker. Mine has a XPL2 V5 4000K LED that can do 2,000 lumens.

The U11 was a challenge to customize with a OSHPark driver, to say the least, but it came out really, really nice. I trimmed the TA driver to fit, then epoxied on the vertical switch mount board, and with the switch LED support, ramping, triple channels, in a great pocket size 18650 light that can throw some.

Getting Narsil in a OTR M3 was tricky, and came out great, but I think the U11 might be the best light I've done w/Narsil. I got a 2nd U11 but would like to do a triple in it - need to work it out with a spacer though.

I’m about to finish a build that uses a charging circuit along with a TA driver running Narsil. You can read about it here. It would be awesome to get the u11 running with Narsil and with charging. It would be pretty tight in there though!

It may be possible if I can get an integrated driver/charger board designed successfully. I am on a mission to get charging onto our blf drivers. Of course I’m way under qualified but…

Getting better and better. I forgot that I have a trim pot in my drawer so I can mock up a bleeder. Those power saving tricks I mentioned above seem to have worked unless I just confused myself with the low readings earlier. Anyway, I'm getting 1.5s now at 3.1V with a real power shutoff (disconnecting the wires to the supply) with a 1.2Kohm bleeder. I'd expect that to go at minimum 2.25s, maybe more at 47uF. We can still play with lower C1 and lower bleeder resistance, but I think this is basically licked. Of course quality caps will keep that from dropping too badly when hot but it will drop. There's only so hot you can get at 3.1V though, and you get more time at higher volts anyway.

I'm still tweaking the code a bit to try to get the size a touch lower. Changing the wake counter to register saved 30 bytes or so, but is for some reason (probably optimizations) unstable. Changing a couple of other things to register already saved 50 to maybe 75 bytes though, by reducing i/o instructions.

Basically I'm calling this mission accomplished. Just decoration now. For any catching up, the mission was watchdog based off-timing working in bistro fitting into a 47uF cap and an attiny 25 using BODS, long sleeps with dual wake interrupts, and more, to reduce power drain,

Oh and I'd say adding the pin change final wake noticably improved the feel of the reponsiveness even at 128ms sleeps but as it's sort of built in to this method I didn't really pay attention to directly compare. It obviously helps at 250ms sleep and that saves power if we find quarter second timing resolution to be good enough. I think it is.

Accepting to just put voltage readout on Vcc sure helped to move this along. Multi-S lights will be another issue and in this technique will require using the LDO as a reference voltage, and well selected R2 and R1, but there's a working place to start from to get there now instead of trying to solve everything at once. The software change for that is simple, just need to us the READ_VOLTAGE_DIVIDER define and redefine the voltage reference somewhere else. Will just have to layout a new calibration and or rules for resistor values.

I can let someone else work all that out but I'm reading full input voltage on pin 7 now, so 4.2V max, and I'd say you'd want to keep it about like that, or close. Votltage reading can reference off a 5.0V LDO anyway, so it's fine. So for a two s light I would just use equal R1 and R2, and either go big, and use a separate bleeder to control power down speed or set the total resistance in R1 and R2 to what's needed for that (maybe 1K) and leave off the bleeder. Either way. Tail-caps light will probably modify the math. For a 3S light, obviously R1 should be twice R2 etc. One calibration should work for all of it, but probably not the same one that's in there now.

It sounds very promising. So the OTSM is working, now the only real issue left to figure out is how to allow it to work with multi-cell lights with few/no changes?

For reference I will be moving away from the zeners and to LDO’s almost exclusively. In fact the new driver design has a 3.3V LDO built into the design for all drivers. I also recently added an LDO version of the TA 17mm as well.

So with an LDO being used for multi-cell lights would allowing it to work with any voltage input be that hard to work out? I assume a change in the voltage divider but that is a pretty simple thing to change for most people compared to a firmware change.

Actually I keep lousing the measurements when in a hurry. It seemed like those were fast seconds, but I made up for it by going to 500ohms. 1.25S at 3.1 V, I think that will still work out, but I was looking at 47uF caps in more detail and man, those DC voltage vs capacitance curves for 10V and 6.3V caps (only ones available in 0805) are nasty, so it will need testing with a real CAP (but a v-chip can still help too). Also I wonder what our rules are. TA you're the driver arranger. What are you interested in trying here. I'm betting that adding capacitance to the traditional OTC slot helps almost every bit as much as adding it to the C2, but I'm not sure. Possibly matters how pin states are set (something I haven't understood or played with enough). It depends if we're thinking new boards or just keeping the ones you have. If keeping them, might as well use the spot. Then you can get 100uF anyway.

I think 5.0V LDO is a much better choice. 5.0V gives you much more off-time power. PLENTY in fact, but 3.3 is down on the low end. Of course we want it to work at 3.3 anyway, but's no need to cause issues for people with multi-cell lights and lousy caps. More importanly I'd like to keep the resistor divider simple, so two equal resistors for 2S, no divider for 1S, two to one for 3S etc. If you have a 3.3V ldo, you can't put 4.2V on the sense pin, it's way past spec. You can only go to Vcc +0.5 V. So that makes resistors more complicated and at the same time reduces the margin for error in them before hitting the cuttoff voltage. There's enough margin, but then you really have to get it all right. With 5.0, 2-S, just use any two equal resistors and you're set. 5.0 would also allow auto detect but that's not going to happen in a 2048 byte bistro anyway.

Otherwise, setting this up for multi S won't be a big deal. Forget tailcap lights for right now, I'm too lazy at the moment to think about them, but without that and with a 5.0V LDO, you just need to divide the voltage by two for two cells. If you want to skip a bleeder then you'll want the total R1+R2 to be low and within some window, but there's still a ton of flexibility there. No more of this 19.1 vs 20 vs 22 nonsense. That won't matter, so long as they're both the same and both in the right ballpark (I'd say two 250 ohms each is looking pretty good). You could instead have them higher(but still equal) and use a 500 ohm bleeder, but it's probably completely unnecessary.

As for the software, it's just one config option and getting the right calibration table in place, which will depend on the LDO voltage so best to choose one and stick with it.

At the moment I'm using no R2 resistor for 1S. That's probably fine and even R1 could be shorted, but to bring the voltage down slightly farther into spec a 10x R2/R1 would be ok too (so backwards from the past). It probably really doesn't matter though.