Upgrading the toolcahin in studio 5 did nothing (surprised, not a byte different, maybe I didn't change what I thought I changed). Compiling in linux avr-gcc 4.8.3 saved 48 bytes indeed. That's a bit strange. There probably shouldn't be any difference.
yeah, I could not explain it either so I just stuck with Linux rather then try lol.
It is very likely to be compiler version. When I switched from gcc 5.3 to 6.2, my code inflated by 20 bytes on about 1K. So 45 on 2K is not at all impossible.
As far as I could tell from the assembly in my case, some decision taken differently had a cascading effect and resulted in more register spills. As each load or store is 4 bytes, it adds up very quickly. I tried tweaking a bunch of low level gcc flags but could never make the new gcc produce the smaller code.
Yep. I think I didn't upgrade the compiler when I thought I did. I re-upgraded to studio seven (had downgraded from it before) and now linux and windows are usually within a couple of bytes of the same. Which is good, because the debugger/simulator functionality of AVR studio is crucial. I didn't have any trouble with version 7. I think something exists for simulation in linux but I'm not sure how good.
I have a TA flavor bistro version now with Vcc included at 1850 bytes. I'll pass it along one way or another soon, like by cut and paste in PM. It's still got at least fifty fifty odds of not working on the first shot. I did add the Vcc switching functions since I'd written them anyway. They're selected out and replaced with one-time macros, but they don't include a clibration switch and I probably won't finish that up since it looks like it would wipe out all the available memory. Could be something to come back to on a tinny45 driver series.
I'm still have OTSM in the long plan, but this version is essentially complete give or take bugs.
You can upload the C file to a file host, http://www.filedropper.com/ is the first one that came up in google. I don’t really have a go to file host myself since I have my own server.
Dealing with a strange bug at the moment, not clear it's even anything to do with my changes though. The only version working is stock bistro. Could be hardware related though. On hold until I know what I know.
By request. TTF-bistro (TK, TA and FR)
http://www9.zippyshare.com/v/TTSQ1Mcx/file.html
1854 bytes (I think 1850 in linux) including Vcc. I've thrown in an extra blink-out function for debugging (not compiled in). No OTSM in this round, but this sets it up well for that hopefully.
TA I'll let you re-package and post it with more permanence (I even forgot to include your build script). Vcc works fine. LVP and batt check are accurate. Everything else seems ok, but test it out well. Never mind my removed comment about cap thresholds. They're fine, just my eyes not working.
The included calibration is within 0.05V or better on my hardware (same diode as you recommend I think). I'm kind of thinking a simple single number calibration "bias" would be nice to add to the code. Instead of going and measuring new calibration curves you could just tweak the offset up or down a bit and probably get close enough. Come to think of it storing a few configs like that in eeprom could be done by script without recompiling.
Oh maybe I mentioned, it, but you can make longer mode groups now if you want. If you want one for example that's 15 modes, just increase the MAX_MODES config to 16 (including moon) and you're all set. It will only cost the extra bytes you actually use in the individual modes that you expand, and maybe just a few more, but maybe not even. It's not 7*24 though. Untested, but it should work now.
Very strange, that code you have is a very old version. it should have been updated to the latest when I posted that link as I had just re-uploaded it.
Luckily it is mostly just mode and calibration changes. I have since changed the timing calibration drastically. The issue is finding something that works with the cap both hot and cold. I ended up just extending the med click to a very long time so that even when hot both short and med click were possible. It is a bit too long when cold though but the best I could work out with the OTC cap.
I will look at things closer later, I think I still have one TA driver, I will toss it on there and see what it does.
It was my mistake. My eyes weren't working. It's probably defined correctly. It's defined twice but not twice at the same time.
Oh yeah, gocart was going to work on some code to bias the PWM output by voltage to give some “regulation” to the FET modes and allow us to limit current for LED’s like the 219C without giving up performance as the cell drains (it will actually get better funny enough).
You can see where he was asking about it here: Xpg3 2d, vs 219c high cri for triple or quad optic - #43 by Texas_Ace
Obviously it would have to be implemented into this version of the code since the normal version would not have enough space. This will be important for the driver I am prototyping at the moment.
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.