Attiny25/45/85 FW Development Thread

There is a much better reason in my opinion and it's the main tradeoff I've been arguing about which approach to use for targetting these PWM curves. The reason is if all the FET modes have 100% 7135s plus some PWM level on the FET, you are guaranteed that all the FET modes, regardless of low the PWM level is, are higher than the ALL7135 modes. If you didn't do that a mode that started out above all 7135s at full battery would end up below all 7135s with a weaker battery. You'd get mode orders that change with battery level and the number of 7135's you have. However, once you're doing voltage correction, this argument doesn't go away, but it gets better and other arguments favor well, not FET only, but PWMing the 7135s with the FET. There's still pros and cons either way there though.

The FET can handle the current. Although, sure, spreading heat a bit helps too.

I thought a little about testing power off detection times to help optimize them. The thing is you need to measure start time well, which means you need the mcu to shut the power off itself. I was staring at the 7135 pads, it might just be possible to wire one sideways for this purpose. It's a bit of fuss just to get some tests though.

Good to hear you have some bistro based OTSM code coming along!

As far as the regulation goes, I am not understanding what you are saying.

The FET modes will indeed always be higher then the 7135’s, this is how it is designed, how it should be and I don’t see anyway where this will not be the case unless the ramp table is vastly changed around.

You only ever bring the FET online after the 7135’s are at 100%, thus the FET can only add power to the 7135’s not subtract it no matter what the FET PWM is.

Let the 7135’s regulate best they can using hardware and let the software try to improve the FET best we can. We are not going for perfection here, just improvement and trying to not waste all that extra duty cycle on the FET modes.

Mostly I was just pointing out exactly what you just said, that yeah, if done that way, it keeps the modes in order. That's why their doen that way. But things are more complicated with voltage feedback. You say leave the 7135s alone, but you're not leaving them alone. When you change the PWM you're changing the amount of time speant in 100% on AND the amount of time speant instead at 7135 ON level. You're changing both. If you want to think of it like you're just changing the FET duty cycle, ok, but that's not the case, you're changing both duty cycles, and in a way that's more non-linear than changing PWMimg it all together. Anyway, it can work either way. if someone writes up some code that works with multiple levels or just a turbo for low vf leds, and has defines for both adc modes and does it that way, great.

For the otsm the biggest thing is right now I'm just using ram to store the sleep data. That's ok if you wake back up, but if you dont' the ram gets corrupted and might sometimes look like a valid short sleep time by accident. So that gets a proof of concept working but it's not ideal. I either need some ssymbly magic to let me initialize the variable but jump past the initialization on restart, or I'll have to revert to eeprom, but as it's on every click, it needs wear leveling. So a little left to work out to really polish it off.

Thats just it, The 7135’s PWM should not be changed, only the FET (although for the new driver 2 channels will need to be able to do this so it needs to be able to select which channels are effected.)

Why do you think that the FET pwm duty has an effect on the 7135 pwm duty? they are addressed independently in bistro as far as I know and one does not effect the other unless you try to make it that way.

If both duty cycles were being changed then you are correct (although I still don’t think it would be a noticeable difference for any mode where the FET is active). They should not both be changed though, this is key to the software regulation working properly.

TA. Could you remeasure the standby current on one of your drivers running narsiltriple? However, keep measireinf for 10-15seconds and see if the current drops down after a bit.

I’m thinking it will. I totally rearranged, cut up, rewired, and removed all amc7135s from the driver to make it comparable with standard Narsil. It works but I measured the current draw and it was 4.6ma :person_facepalming: I then remeasured and watched it for a while and it dropped all the way down to .04ma. So I may have reacted too soon and done all that for nothing. :person_facepalming: :person_facepalming: :person_facepalming:

I would like to know for sure though. So if you could measure that when you have time that would be appreciated. Well, I do have an indicator led now.

Yep, you are correct, it dropped down to 16ua after about 10 seconds.

Well it made me be creative atleast. Geesh

That does make me feel better about Narsil triple though. I thought I was going to be lost for my next few eswitch builds

lol, glad you kept at it, I was worried all my last narsil builds were in vein lol.

I do know the feeling though, I went to the trouble to add a voltage divider to some 15mm drivers only to break the drivers when trying to press-fit them to the pills. :confounded:

[/quote]
Why do you think that the FET pwm duty has an effect on the 7135 pwm duty?
[/quote]

Because it abosultely does. You're thinking about it from a pin output persepcetive, not a perspective of what the currents through the FET and 7135 are actually doing. It's a parallel source, but not a separate load

The PWM is a series of up and down pulses of course. There's an on duty cycle D and an off duty cycle 1-D. RIght, you're only applying that to the FET but what actually happens is this. During on time, both the FET and 7135's are "on" right? But what does that mean? You get Fet light plus 7135 light? No. It means you get 100%. It means the led sees 4.2 V. It's almost exactly the same as if the FET was on and the 7135s were off. They don't add.

Now what happens during offtime? You get 7135 power. during offtime of course. The amount of time you have a full fet power level is D and the amount of time you have 7135 power level is 1-D. That's still the expression for PWM, but the opposite PWM.

The total power is calculated by PFET*D +P7*(1-D). P7 mean s7135 power.

You can write that in another way more like you're thinking because if we replace power with voltage it rearranges to D(V-V7) +V7. So you can call the first part FET power, but the point still is FET power interpretted that way isn't just proportional to V anymore. You have to correct it for all7135 contribution.

In the end though, yes, if you increase PWM as battery voltage goes down, sure, you'll be going the right way (if you don't do it much of course).

Anyway, I'm really not that worried about that, was just trying to point out several nuiances that matter but the two adc setups is a bigger one to watch out for.

What I care more right now, is does anyone know what happens to the RAM on these things when they're unpowered? Does it decay to all zeros? To all ones? Or to something random? If it's either of the first two, I can take advatage of it. If it's the last, I probably better switch to eeprom. Mostly I don't actually need memory rentention during power off. I just need retention when restarting the program using a variable that won't get reinitialized. But I have no way to tell the difference between a restart and a cold start other than this variable, and in the cold start the uninitialized variable would be corrupt. I'll probably just switch to eeprom. I'm not sure this wear levelling is really needed anyway. Is anyone planning to change modes on their light 100,000 times? I might be able to find a way to squeeze it into the mode save wear levelling as the second byte in the train. It needs a few bytes of code though and, well, I have a few left.

hmm.. another way to do this is to turn main into a subroutine fake_main, and have real main just call it. The global variable are initialized in main, but I jump to fake_main to bypass initialization. I'd have to figure out how to reliable get the jump address for fake_main. It shouldn't be a function call because I'm inside an interrupt (or two) and want to clear the stack. Hmm maybe I could just clear the stack at the start of fake main. Very hackish, but it's all a bit hackish.

My friend, you are arguing in a circle. The different channels share the load however all 7135s + %1 of the fet is still brighter(unmeasurable but…) than all 7135s on there own. Whatever percent load you add from the fet will cause some voltage sag, but the 7135s don’t care, they dump off extra voltage anyway. Less voltage to dump off even makes them more effitient. Correct? I should keep quiet cause you are much smarter than I. So just take my comments as trying to help.

It doesn't matter because in the end you're going to adjust the correction factor from experience. There are just things easier about doing it one way, and other things a little easier about the other. As far as the 1% difference in having both channels, both ways reach that at 100%.

This is all right. A line is a line is a line. ONe just has to figure out how to do it in the fewest bytes, make it most comfortable for mode definitions, and avoid things like overflow errors. Starting from the bottom (which is also what I did) has a physical significance because the bottom battery voltage is the real equivilent vf you're targetting. Starting from the bottom does make overflow a little easier too. If your slopes are right nothing should ever PWM to zero (because that's just the all7135 mode and you should have just been using that anyway then). However starting from the top the math will try to produce more than 100% at some point as your voltage drops too low and you'll have to catch the overflow in the calculation, or just know where the bottom is and put a conditional to catch it. But once you know where to put that, you've already found the bottom anyway. No matter what, you need to know where the bottom is. And might as well approach it with that idea so you can just get to it and figure out if your battery even has enough juice to hit the mode.

That's why I just went ahead and defined modes by bottom voltage. You can still use a ramp table like we have. You'll just have to calculate the bottom voltage from there.

While you are correct in your technical thinking, I am a much more practical guy. If all the 7135’s are on, the total current through the light with any PWM to the FET will be higher then the combined 7135’s. Will the efficiency be effected some? Sure but it will still have more current and be brighter with any added FET PWM on top of the 7135’s.

The tiny amount of technical variance that you are describing will not even remotely be noticeable to the human eye, as such I am not worried about it.

This setup will not be anything close to perfect anyways, the idea is to simply improve things better then they are now and see how it plays out. What we learn from this can be applied to a future tiny85 version of the firmware where it can be expanded to take into account the tiny things you are mentioning bringing up.

At least that is how I see it.

Wow, what I'm finding is this ram lasts an enormously long time with 10uF cap in place. So far it's remembered for about 3 or for minutes. Haven't tested longer. Anyone interested in a memory mode that remembers for say half an hour but eventually resets to default? That would actually fit my usages. Would have to tackle this eventual corruption issue though. Maybe set four or 5 bytes to 170 (10101010) and check all 5 to verify non corrupt state. It's an idea for my restart problem too though.

I'm not worried about any tiny technical variance. It will quite drastically impact the correct slope to use. But anyway, the slope will get set by testing. The difference in those slopes affects how easily you cna define regulation modes for all levels vs just the top ones. And more importantly to you, it means that determination depends on how many 7135s you have. That's all. The variation from whatever wrongly shaped line we use probably isn't a big deal since it will be wrongly shaped regardless.

Bottom line, you're going to need different calibration constants for different numbers of 7135s, especially switching between tripple's and FET+1's. That's a huge effect, not tiny. If you PWM it all together there's less impact from that and you'll get regulated modes that work pretty well on all drivers. The flip side though is your mode orders might get out of whack when switching drivers. So either way, you need some setting changes. Just different ways to skin the cat.

Yeah, I just got 20 minutes of RAM memory. Of course in reality there will be 40uF not 10 but the power will get run down to 1.8V or so by OTSM. so who knows how long it will last if at all. It has to just accidentally work out to 20 to 60 minutes probably to be useful. For temporary memory less or more isn't useful. It's like OTC all over again, on longer scales. Will depend on every resistor in the driver. Too much nuisance.

Of course I'm being abusive with this program restart. Nobody encourages programming this way. The kosher way to do things is to set flags and unroll out of the (nested) interrupts back into the main program. Then I'd need to add checks to short circuit the delay functions to bypass all the strobbing and menus and whatever going on, and then break out of the loop at the end and restart initialization from there, keeping the variables I want. It's still a possibility but I don't like it. There are many places where variables between user click and true restart will get messed with where they just weren't designed to be messed with because a full reset was anticipated. It requires really rethinking the whole program, so I continue with the hacks.

RAM corruption test.

So I got my answer on this particular byte of ram in this chip. If loaded with 10101010 it always corrupts to 00011001 or 25 after shorting the caps (no, not 255). Slightly surprising that it's stable, but still mostly useless. I don't like betting that the byte I care about isn't the first one to get a bad bit either, so checking other bytes for corruption probably isn't a solution. It will have to be one of the other three solutions to carry data back to the start (post init jump, eeprom, or interrupt unrolling).