Nice, I think the first post I ever made here was about exactly that concept. I like it. I was thinking about it again recently. The tough part (other than finding room for any more code) is getting attiny to do some light weight math, but this is mostly probably about being clever with the calculations, so puting some thought into it. Nice that someone is.
I will try to merge the latest changes I made to the code into your compacted version and re-upload for you to work with going forward.
If this works, then we just need to get the OTSM working and add a PWM “regulation” is all I can think of to polish off bistro functionality.
After that if there is space getting a working rampng mode would be epic but not sure if there will be space for it.
I'm not sure we can fit both without taking out a couple of strobes but we'll see. I feel there's probably a few bytes somewhere to spare still but that could become an illness. Actually I'm very impressed with these optimizing compilers. You think you see some code that does three ifs and a while when it could be done with one do-while and two less variables.. and basically the optimizer has already outsmarted you. I mean sometimes you can save a little, but it's amazingly smart. Other times though.. it doesn't seem clever about figuring out when to inline. I figured you could put inline on everything and it should ignore it if best for -Os, but sometimes yes sometimes no. Maybe smarter compiler options help. On the whole though, looking at the assymbly that comes out of the thing is impressive. If we're not careful the compilers will decide the whole endeavor is a waste of bits and optimize it all away as useless instructions.
If/when the compilers are that smart, the fix is simple: just install a compiler onto the ATtiny and let it take care of all the modes on the fly! :partying_face:
Worst case if overrun’s the tiny25 and we have to move to tiny85’s with bent pins. Just harder, more bulky and less clearance on already cramped boards and slightly risky.
Oh, I almost forgot. I added a proper turbo to turbo T2T check. It actually just checks that the first "solid" and last "hidden" mode aren't identical. It doesn't check the first hidden, that could also be an issue when backing up, but it's not normal to have an issue there, and it's harder to fix. I think the old hack just assumed the first solid mode was turbo if reverse was enabled, but that wasn't always true, and now it doesn't need to be true either. The check cost about an extra 20 bytes though, lol.
very nice!
Apparently some people in security and such already get irritated because they try to overwrite some password in memory and the compiler decides that's a pointless thing to do. So what of the rest of it? Blinking out a bunch junk on screens for some humans who will still die anyway? Just don't type -O9. It could be dangerous. The machines might take over.
It probably does not take that much to be close enough. Although it doesn’t do PWM, I have similar “software” regulation in my firmware which requires only division by Vcc. The function is nearly 50 bytes but that’s in part because it works with a 16-bit value.
I think this would work with PWM as well since the Vf/current curve is a fairly straight line over most of the range (for the 219C anyway). I will try to come up with some code later.
If the code was general enough it could take a couple of paramters and produce different curves. Then the same 50 bytes can maybe reused for voltage calibration curves too, saving a little back. Anyway, it sounds like gocart is on it, so maybe see what he comes up with.
I am going to quote what I posted in that other thread for those here. Not sure on how to actually make this work but this was the general outline I was working with:
I would prefer more options to sparing the 25 myself. If the limit is reached now, it will only be a matter of time anyway as options that we cannot even think of now will be desired tomorrow. Ya know?
oh TA you were talking about syntax..
mode_cnt-=1&!(modes[0]^modes[mode_cnt-1]);
That's the T2T check. I wrote that and I honestly can't remember how it works (What the F&^!(?). That's some horrible programming there, but it saved 2 bytes as I recall. :)
Is this already in the code or does it need to be implemented?
It's in there.
I agree on one hand. The issue is we all like 17mm drivers and fitting a tiny85 pad on a 17mm driver takes up half the board space.
If we bend the pins it is ok but the issue is that sooner or later we will want to use these designs in a group buy light and/or have the drivers made by a machine and they can not bend pins in those cases. So keeping the tiny25 as long as possible goes a long way to those ends.
Although it is possible that I can fit a tiny85 on the board I am working on now if I drop the other components down to 0402 or 0201 but then it would have to be machine made really.
Ya. Understood.
I actually think with VccLVP and OTSM you can probably remove enough stuff to fit an 85 (I'd say 45 since they seem far more likely to be easily available with BODS which should help keep the cap size down, but the fit is the same other than that).
Just saw your quote TA. Seems we had the same thought on combining the calibrations.
Actually I was already playing with this with this version.. but with inverted reads the voltage calibration actually gets pretty non-linear. For PWM regulation that's ok, but you want accurate voltage. Even a quadratic correction isn't as good as I hoped, and I figured for now without combining things it wouldn't have saved space anyway.
What voltage calibration is that? I think I missed something somewhere as I’m not aware of any curve besides the one needed to “regulate” FET output.
Edit: I take it from your later post that you meant the code needed to handle the “read 1.1V with Vcc ref” mode. Makes sense as both need a division.