I have been digging into the process by which you load apps from the SD card to launch. Is my understanding correct that you are, in the most basic of terms, performing the following steps:
- Flashing app.bin to EEPROM in some upper program area separate from the main firmware/loader
- Setting a “pointer” to specify to start execution there (still unsure about this part)
- Rebooting so the app loads up
- Then, when we want to return to the Loader, we are just removing a pointer but not deleting the app from EEPROM? The reboot and return into Loader happens very fast, so we couldn’t be writing/overwriting/deleting much to return to the Loader
***4A. If I reboot without initiating a proper return to the Loader [mp.loader()], it reboots back into the app we loaded in #1. You must call to mp.loader() to remove this pointer and return to Loader (what exactly is happening here?)
I’m sure I’m missing a bunch of details in there, but if #4 is right, in that we are leaving the app in EEPROM after return to the Loader and only logically saying we don’t want to boot to that app anymore, I have a suggestion to improve loading times when launching back into an app that was most recently launched:
- The app developer supplies an .md5 file with their .bin. We include this md5 sum when we write it to EEPROM for future reference
- The next time you launch an app, loader compares the md5 we wrote to the EEPROM with the .md5 supplied with the app you are trying to launch. If they are a match, we know we don’t have to write it to EEPROM again because it is already there
- If an app has been updated since last run or you load a different app, the .md5 won’t match what is currently in EEPROM and we write it fresh
- If an app does NOT have an .md5 supplied, we proceed to write to EEPROM fresh each time it’s launched just like we do now…allowing for backwards compatibility with apps that don’t include the .md5
- By storing the md5 sum for the EEPROM copy of the app, we don’t have to waste time calculating the md5 on the Ringo EVER, no matter how large the app/game is…“EEPROM_stored_sum”=" .md5_stored_sum" or we write it fresh, no harm done
If all this makes sense and does work the way I’m thinking, this would reduce load times when simply returning to the app you were previously using down to the same as the return to Loader. Think of it this way…you are playing a game. A text comes in. You can see the notification via homePopup(), but you can’t reply there. So, you leave the game at the next save point, quickly return to Loader, and reply to your text. Now you have to wait for the much longer write process just to get back into the game you were just playing.
Of course, this also reduces the wear on EEPROM. Sure, it’s good for 100,000 writes, but if you are in and out of the same app all the time all day (your favorite game), you are drastically increasing write cycles needlessly if the game is already sitting there in EEPROM, ready to run and the Loader just isn’t “aware” of this fact.
Does that make any sense, @robertCM @albertgajsak?
Note: I did find this thread for MAKERbuino, but I wasn’t sure how much of this same methodology you were using on Ringo and/or how it could be varied/would be applied in the scenario I’m speaking of. Bootloader, loading from SD etc..? [SOLVED]
)…cuz sometimes you just gotta have a one-on-one with the CPU/MPU directly. 
