George MacCayev wrote: (I reply in bold so it can be detected by eye).
-------------------------------
Michael,

K.> George.....your reply hardly seems as being
K.> written with due respect.
Sorry for that...Should I take off this expression(:-)?

K.> So get off your soap box which does not appear
K.> to be any sort of fabrication at all!!
Seems I treaded on soap-orator's toes(:-).
Thank you, Michael, you are very polite.

Well, to the questions.

1)

K.> So I maintain the text editor idea is
K.> still "workable" but a bad solution.
This is a good decision for you. And it is cheapest one besides. You have to do nothing exept using any text editor. Very nice for joung programmers. the text editor may work for one shot solution but it is not good for repeatitive solution where merging takes place at each build

2)

K.> In my comments regarding FLASH loading I was
K.> talking about the loader mechanism that runs
K.> on the target.
K.> Not the part of a downloader on a PC.
Michael, please say me honestly how will you then merge hex-files in this case and download it to target MC? By Morse code? download to target any way you want. Hex records are commonly used. My comment about the FLASH re-programming loader inside the target is that if the image is merged in binary on PC then converted back to linear increasing address sequence in final hex file image then a target loader can watch for records of data at download time. Each time some new data arrives it can check to see if the destination FLASH area is already erased. If not then the block containing this block can be erased first. The flash block is most likely much larger than the record size of data sent from the host PC. Also the arriving records are convenient if they always start on address boundary of 16 bytes or 32 bytes. If source data comes in order then the flash block erase happens automatically just as the first record in a flash block has been downloaded. Subsequent records (coming in sequence) will nicely fill in the rest of the flash block without further erase! If you do not work in this order then the application loader needs to have a buffer the size of the full flash block that would hold the existing flash block bytes while the areas not specified by the current record are erased and re-written back into the current block (with the new record area skipped on the re-write). Sometimes this buffer would be RAM and other times people try to a reserved block of the flash for this purpose.

K.> 8051's still, in general only have 128 or 256
K.> bytes of RAM. My comment still stands. If you
K.> look closely at my comment I specifically refer
K.> to the " in-target programming algorithm".
Wouldn't you like to put into MC the Red Army song mp3-file as well(:-)? No and also not the mp3 for the Stars and Stripes Forever song either.

3)

K.> The checksum value I am referring to has no
K.> connection to the checksums of HEX records.
Me too! The standard Intel hex file has one byte inverted check sum for each line! But I was talking about small C-program which calculates the CRC-16 for the whole code and puts this two bytes of CRC into the end of the hex-file. In this case, of course, bytes in the hex-file must be in the same order like the program image. fine......but a simple minded code image check code calculator that worked strictly off hex file records of a non-merged file set that was not sequential and may have unspecified holes will not compute the same check code as a target run time calculation that works across the whole code ROM space. Checksum code could survive if records were out of order but a CRC would not as they are byte order specific. This is why, for sake of automation, and covering all bytes in the image it is most reliable to merge the multiple hex source images to binary and then run the check code computation across the binary buffer!!


I realize I have repeated myself over and over here to get my points across. I hope other readers do not get too bored. I have addressed the problems of code image handling and hex image merging time and again over many years and I know my comments from the original post I made are completely valid. My defense of my original ideas comes at your comment that it was just an "academic discussion at the meanest intellengence level". Which of course you can see I completely disagree with.

Michael Karas