MCLoader & XPort

[Jumper]

I downloaded VB 2005 Express and it is way better than any other VB i have used. Support for COM port is back again and it is really easy to read HEX files either into byte arrays or to read the lines into a string array.

ReadAllText and ReadAllLines are really usefull functions

Since each line after the colon has the number of data bytes we can easily get the data bytes from the string. Just remember that they are stored LB, HB in the HEXFILE. Rearrange that part and send them out as a string to the comport.

In the pic collect them with HSERIN [HEX4 x] and they are ready to be written to the FLASH.

Do this for all lines until the next line in the HEX file has an address that is different from 16+last line's address, then we know we have gotten all data.

It can be done in any VB but in 6.0 and 2005 there is a comport object, 2003 does not have that.

and it is free

/me

[Joe Rocci]

Jumper,

Thanks for the insights.

I'm a VB6 sorta guy and I have the complete MS Visual Studio, so that's what I'll do the application in.

My previous comments about parsing the .hex file lines and padding the short ones might have been premature. I was thinking about how you'd implement this if the PIC was coded in assembler, in which case I believe you generally write 64 byte blocks. In that case, the file lines would have to be read, buffered, parsed, and disassembled & reassembled into the 64 byte chunks the PIC likes to work with before transmitting to the PIC. I still haven't figured out all the limitations of WRITECODE, but it seems to me that, assuming the intended write block has been ERASECODE'd, you can write one byte at a time? In this case, it's quite simple as you said, and data can be fed to the loader in chunks as small or big as it can buffer in RAM. Do you agree??

Joe

[Jumper]

Now here is where the 128 (in the beginning of the thread came in)

I get a string from the PC, erase the blocks and write the data. When this is ok I send a command to the PC to show we are ready for the next data chunk.

Then we can fiddle around in the PIC without missing any data.

So I just gathered the start address for the HEX file (in our case allways 0040) and the collected the data from the hex file and arranged it so it will fit the HSERIN HEX4. Then I feed out the characters from the string in as big pieces I want to have.

At the same time you can calculate a checksum for each chunk that the PIC will report back before sending next data. It is also possible to encode the string so only your loader will understand the data. With the code protection turned on the application software can not be copied (unless they break the code of your encrypted file, just pick any algorithm from the internet and it would't be easy to do)

Or invent you own "super safe" algorithm as the DVD people did :-) (not that good idea)

But at least we have solved the basics of how to trick PBP into making some kind of loader. Too bad we had to hijack the old define but, with our new loader who needs that define anyway. Then we can hope the really clever people in this forum might figure out a way to include our own defines.


/me

[Joe Rocci]

I got a little time today to work on the coding for the PIC end of this loader system. Programing entirely in PBP (with the exception of one line of assembler for the final 'GOTO" that starts the downloaded application), it looks like this loader will fit into about 600 bytes of PIC18 memory space - not as bad as I expected.

The down-side is that there are other loaders, coded in assembler, that are as small as 100 bytes. The up side is that this one's written entirely in PBP, is supportable by virtually anyone, and is therefore infinitely scalable for any desired level of functionality by anyone in this community.

In the coming days, I'll try to find time to write the VB6 host application that drives the loader. Once something that functions is available, I'll try to find a way to post the sources so that this can become an open-source, community supported tool.

Joe

[Jumper]

If you got all of the loader including library to fit inside 600 bytes I am impressed. I had expected much more.


/me