I dont understand how you guys do what you are doing but just wanted to say following with interest. Excellent work. :+1:
I like so I’m suscribed… :+1:
Chips stacking: flux(simple fluid smd flux) all legs and back pin on both(old and new chip), pre tin each of them with favorite tip and gentle touch of good solder(koester stannol or similar) on 350 C, super glue new to old guy(use the best sg you can find), solder back and then solder legs, a bit bending of legs helps and can be done with screwdriver but when good pre tining preparation is done you’ll not need to bend them. Maybe it sounds complicated but it ain’t and that should be 10-15minute work for 4 stacked chips.
I tried paste way but it is messy cause paste when burned leaves some nasty sticky fluid and I am always afraid that it can short something on the driver…
This is always interesting to see(done by Andi in 2011):
So gchart, I think you've got a point there.
So bistro counts in three steps (well not including the last two steps lol)
1) Find the start of group
2) Find the length of gruop
3) copy group
with variable mode lengths each one has a pgmreadbytes command in a loop or two.
With fixed modes 1 was just an assignment and with reverse modes 3 had to be separated from 2 anyway because you must know where the end is before you can reverse the copy. With no reverse or moon I've combined 2 and 3. Technically it may be possible to do that with moon and no reverse but it's probably ugly and a pain at least. I don't know. Working out that index madness in hd's big copy statement was a bit painful.
Ok but I can maybe always combine 1 and 2 and then maybe combine all three then if there's no reverse. Yes, this might save something.
Nice. It worked, with that and a little other squeezing I can get 4 byte redunadncy in biscotti, yay :THUMBS-UP: . I was only trying for 3, or I could use 3 and add another mode group.
Since you mentioned 70% odds of 1's and 30 of 0's.. I worked it out and assuming bytes are independent that gives one in about 2,800 chance of failure at 3 bytes, probably much better than your chance that your SPITFIRE branded light is DOA for some other reason. 4 bytes brings it to about 1 in 69,000, but two bytes is only one out of 78. I'd definitely agree that 3 is pretty good if it's what there's room for and at the end if you've got a few bytes left one more is better.
Nice! :+1:
All these things about exactly how many bytes a certain set of C instructions takes can be really elusive. The same instructions dropped into two different codes won't take the same bytes. It depends on things like how many registers are already in use, and even which ones.
In the posted version of HD I replaced the repeated menu toggles with a loop over an array of toggles. That reduced code size by something like 40 bytes. Ok, now, I just reverted back to the old way, and the code got smaller again! I do try to take a look at the assembly from time to time to get hints about where to save space, but it's hard to do systematically with multiple build configurations. Usually when something like this happens it's april fools and some mistake caused the compiler to optimize away a bunch of (important) code, but that doesn't seem to be the case. My best theory is that tightening up count_modes, an inline function, freed up registers that have now changed the balance of the two toggle methods, that or maybe some combination of other related small tweaks. The other possibility is I'm going crazy and have no idea what I'm doing anymore, but at least it's getting smaller. At this particular moment I'm still a little suspicious. It is getting very close to April 1. I better flash it at test it.
Yeah, if code gets strangely smaller than I expected, I get suspicious pretty quickly.
Turns out I can do reverse modes in one pass too, but requires a little more magic to do it neatly. Actually it's going to end up more tidy not less. Partially though because I figured out preprocessor if's for reverse modes is redundant. Can just preprocessor define the config variable instead and if on that, and let and let the compiler optimize it out.
updated: hmm, well while it is one pass and is tidy, it's looking like might not turn out smaller for other reasons.
I see, this trick required making the beggining address of the array dynamically set with a pointer. Instead of counting where the end is, it has to work backwards and count where the beginning is. I think the global non-constant pointer takes more instructions to access throughout the program than the constant array address required. Have to actually go fetch the pointer value instead of just hard coding in the address, and in many paces.
Bottom line is one pass for reverse modes doesn't seem beneficial, but reducing it to two still helped.
Yeah, it’s amazing sometimes what seems like more compact code doesn’t necessarily compile any smaller.
I’ve been doing a lot of A/B testing of various routines using preprocessor conditions to see what actually compiles better. Sometimes I get what I expect, but I’m also frequently surprised.
My latest HD Makefile spits out the preprocessor output for all build configurations into a separate directory. Definitely helps to cut through the clutter to see those. In this case that alone doesn't really show the issue though. You have to look deeper. Anyway, lots of space saved and lots more functionality will be squeezing in. Still not quite able to get a full BLFA6 down-build, but lots of room for safe presses and more in biscotti. Biscotti was designed down from bistro in the first place though. BLFA6 is related, but is optimized for what it is. I'm still 40 bytes over on it, even without safe_presses, but some of its functionality is available to to the biscotti build now, like turbo timeout, and for those who just really like the way BLFA6 works and want it on an attiny 25 with a little customization, this could be good for that.