Beware of bell/whistle ideas :
By checksum, do you mean something like an md5 that I may in future distribute with the s19 files? or what? The s19 files have checksums, but it's per line. or is that first record an overall one too? I'm not sure.
I'd like to see it have a detection feature where you tell it to figure out what it's talking to and it tells you what it's talking to and what actions you need to take from that state to get loading. I don't need this, but it idiot proofs it a bit which could cut the support load on us.
As per the comment i just put on the mantis :
http://freeems.aaronb.info/tracker/view.php?id=21 I'd like to see it with the ability to just update the settings/code and just update the tables. I know gearhead would really like this and so would I actually. This could be done just with address/page ranges/sets that are supplied by me to you in some config file with the s19. most likely it won't change much/at all for a while so you could hard code the two sets for now data and the rest.
Obviously you want to be able to verify a load, but less obviously it would be nice to verify just the code at a later date.
So, to reiterate those regions :
tables of long term format
settings of dynamic nature
code of dynamic nature
tables you want to update from a stored s19 of your own or some other settings file.
settings you want to get from the firmware you are loading and should be treated with the code... except for verification. Obviously all the settings AND tables can change so ONLY the code should be verified when doing a verify at a later date. When loading a whole file the whole thing should be verified. when loading just the data just the data should be verified.
I'd like to see a transfer rate indicator, maybe two slow/fast or an adjustable averaging slider? :-) I told you bells and whistles ;-) Some sort of real time speed indicator is important though.
When loading with verify you could have a choice of two options :
fail fast
verify last
the latter is good to see what went wrong and where, the former good to not waste time and flash cycles.
speaking of which, there are no time or space constraints, so use an md5 or sha1 hash of each sector in the packet payload (if using the same packet format) then its a 100% guarantee that things are right. You could have multiple modes or combination of modes for returning data to ensure integrity :
return the actual data
return a strong hash
return both? - probably best to always do both.
what about adjustable load speed. You'd need to do a scan of your firmware to know what speed its at before telling it to change speed. If you are having checksum fails on transmission slowing it down could probably help get it burned correctly. I plan to support adjustable speed in the vanilla firmware too.
when loading, what are you thinking? something like :
- extract data from s19 and check each line with its checksum while building an image in memory
- generate a strong hash
- build a packet with a sector, address, page, and hash
- send it
- firmware receives it
- checks the hash against the contents
- burns it down
- checks the contents against the contents
- checks the contents hash against the received hash
- for fast fail, returns data from flash with address, page and hash
- for verify last, returns some small ack only to say next block please
- for verify last, send back all the blocks (keep a record of what you receive) with hashes and address/page sequentially in a row.
Sound good? :-)
Thoughts?
I don't give a toss how it looks, but others might, and good GUI feedback will make the user experience truly golden :-)
Fred.