Dear Jef Mangelschots,
In message AANLkTinLu+nJp-s1BwJ+ZOcASdptWfEQr020jW2wT=b=@mail.gmail.com you wrote:
It is not exactly _parsing_ the record, but storing the decoded data to it's final destination, which usually includes flash programming cycles.
Whenever some code takes a ASCII string (in my case an S-record), extracts fields from it, converts these to numeric values, then I call that parsing.
Me too, but that's not what is taking the time. It is the flash programming cycles.
Kermit protocol works great for us for transferring binary files (using both Teraterm and Hyperterminal). It is my understanding that we cannot use Kermit PROTOCOL to transfer S-record files with loads command. I though you indicated that in your previous email and it simply doesn't work when I try.
Sorry if I was not clear enough. I always meant to refer to using kermit binary protocol in combinationwith the loadb command.
I am aware that you have suggested in many places AGAINST the use of S-record, but there is a genuine use for it. When using U-boot in a non-Linux bareboard embedded system, you need a way to give your users the capability to upload now software. An embedded software image is not a 'file' like in Linux but a memory image where data needs to reside at fixed addresses. In an multi-megabyte address space, the 'executable image' can consist of chunks of data spread over a wide range. 2 options here: (1) create a binary image of the entire Flash area, (2) a file that specifies which byte go in which address, i.e. an S-record file. Option (1) results in a big file with very little. Unless you break it up in smaller pieces and ask your user to burn image 1 at offset x and image 2 at offset y, ...
You could probably wrap the parts in a FIT image, transfer it in binary mode, and use a script to extract the parts and move them into place.
Best regards,
Wolfgang Denk