Reduce ram usage

[rhgndf]

This could save a bit more ram when uploaded into a UNO. I'm using an arduino mega, so just looking at whether global variables use exceeds 2048. With this PR it is at 1551 bytes.

There seems to be a switch table generated by getDuration which is placed in ram and unfortunately, there is no way to put it in PROGMEM: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857 Replacing it with a PROGMEM array instead.

Putting PROGMEM on galinfo does not work out of the box.

Check whether line[32] is enough.

[ole00]

Thanks for the ideas. Interesting is the last commit (switch replacement) that saved 14 bytes. Although it is not much it might be handy at some point. The top 2 ones are also good, but not practical right now, because the 'line[]' array is used for the input buffer while the jedec file is uploaded by the PC app. Currently the whole line (as is in the .jed file) is uploaded to Arduino, and then the line is processed (fuse bits are stored). So unless the uploading/processing is also optimised the smaller 'line' array would cause upload issues. At the moment afterburner has 365 bytes free. With you last commit it can have 379 bytes free. I think that should be enough for the stack to operate without issues. I'll merge your commit 'e9b6eae' and see how it goes. If there will be a memory issue I'll have to redesign jedec line uploading and use your top commits.

[rhgndf]

The line array isn't removed, just shrunk to 32 bytes. The longest line could be uploading of PES which is 23 bytes and a bit more. Uploading JEDEC is fine since it uploads 8 bytes of hex at once. I haven't fully checked all of the commands, but you could definitely increase it back to 64 to be safe.

I think it's possible to get galinfo to be PROGMEM, so you might want to merge this PR after it gets PROGMEM or we find out it's not possible. Might be useful for adding ATF750 support with 14k fuses: https://github.com/nospam2000/afterburner/tree/atf750c

[ole00]

Line: you are right (just checked the PC source code and enabled DEBUG_UPLOAD preprocessor) - I completely forgot how I implemented the fuse upload :) I'll merge the rest of you commits as well. Thanks for that.

Galinfo in PROGMEM: I thought about that as well. Since only one gal item from the array is needed it should be possible to have only one such structure allocated in memory. Then when the gal type is selected that memory structure would be filled-in from flash. That should save ~200bytes.

@nospam2000 branch: nice! I did not know about that fork and the addition of ATF750C IC. It looks like the dev put a lot of effort implementing that. I think - if the support for ATF750C is complete and working - it would be good to have a support for it on UNO. Possibly employ some simple run length compression on fuse row. Or - if the compression would be unfeasible, make ATF750C optional (behind preprocessor), so that it can be used on UNO r4 or Mega.

[nospam2000]

@ole00 : I have done the ATF750C support 3 years ago and I don't remember all the details. It is working on the UNO by splitting the whole fusemap into smaller chunks.

The obfuscuation of the finalization algorithm is pretty good and the timing is very time critical. I never used that in production so there is probably some work left.

[ole00]

@nospam2000 Thanks for the info. Hopefully it should be possible to merge your work to the latest Afterburner - if you don't mind. BTW if it is not secret, how did you figure out which fuses and which addresses to use to program ATF750? Is there a public source code (apart from yours) that programs AFT750 ICs?

[nospam2000]

@ole00 : I would be happy if you would merge it. Shall I create a merge request?

The structure I was partly able to read from the official docs (e.g. the rows/columns and the pin mapping). Most of the data locations in the file I figured out by creating test files and checking where the data changes in the output files (I created about 40 test files). I found no other public documentation.

[ole00]

@nospam2000 well done figuring out the fuse map! Just to clarify - is the programming pinout for ATF750 same as ATF22V10C ? The data-sheet suggests ATF50 is superset of ATF22V10C, but I just wanted to be sure the pins designated for programming are the same as well. Merge request: think I'll need to merge your changes into a different branch before I merge it to master. The reason is that master diverged quite a lot since your changes were published. Currently it seems that the UNO does not have enough memory to fit ATF750 fuses in (I might be wrong as you mentioned it is possible), so this will need to be resolved as well. Also, @rhgnds makes some changes to the code these days (plus there is another unmerged merge request from him which I plan to merge soon), so your merge request merged directly to master would most likely break things and would make it more complicated to merge thgndf's changes. So my plan is to verify and merge rhgndf's changes first and then figure out how to support/merge your code. If you'd like to help, perhaps you could try to rebase your repo to the latest afterburner master. BTW. did you use Arduino UNO, or did you use other board (I'm just curious how you solved the fusemap RAM issue)?

[ole00]

FYI - I've added a discussion about ATF750C support here: #46