View previous topic :: View next topic |
Author |
Message |
FFT
Joined: 07 Jul 2010 Posts: 92
|
How to store a HEX file in rom space of 18F? |
Posted: Tue Sep 07, 2010 2:32 pm |
|
|
Hi All,
I use PIC18F4520 and I want to store a HEX file in the rom space of the PIC.
PIC's rom has enough free space but I don't know the structure of the rom. If it is like eeprom, I think it is possible to do what I want using write_program_memory command.
Is this possible? Can I write the hex file as below in the rom space and when is needed I should read it to send to another pic?
I want to back-up a .hex file (as txt file) which will be sent thru rs232 and then I want to send it again.
Example hex:
Code: | :04000000B9EF18F04C
:08000800046ED8CF05F0E0CF33
:1000100006F00001E9CF0CF0EACF07F0E1CF08F0DD
:10002000E2CF09F0D9CF0AF0DACF0BF0F3CF12F01C
.
.
:1000F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF10
:04010000FFFFFFFFFF
:10008E00204443456E657267792076332051756141
.
.
:1000EE006F7A7475726B3140676D61696C2E636FD8
:0300FE006D200072
:040000004552410024
:020000040030CA
:0E0000000008160F0005810000800FE00000D0
:00000001FF
;PIC18F4520
;CRC=9F4B CREATED="06-Sptember-10 18:13" |
Thanks in advance for your help.
Best wishes |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Tue Sep 07, 2010 2:49 pm |
|
|
Yes you can.
You would use the command write_program_memory just as you describe.
Make sure to read the device's datasheet for specifics as PIC's have different needs when writing to program FLASH. There's also RULES on writing to FLASH as well as the ENDURANCE (that's a keyword) of each flash cell (bit).
You will probably want to plan for how much space you need.. and remember that you could save the HEX to that space as binary or text. Each char is 1 byte. This will include the non-hexadecimal chars like the ':' and CR/LF's.
Those take up space.. so when you LOOK with your eyes at the file, keep in mind there's at LEAST 2 bytes you aren't seeing.
So with that.
Have fun. :D _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Sep 07, 2010 2:55 pm |
|
|
Even easier, buy a product that does what you want to do. The Microchip PicKit 2 and 3 come with an included software module called Programmer-To-Go that allows you to use the PicKit as a standalone programmer without the use of a PC. The only difference with your solution is that the target is programmed over the ICD connector instead of over RS232. The PicKit 3 is available for US$45.
CCS sells the Load-n-Go handheld programmer for US$199.
Searching the web you can find more products and hobby projects for the same goal. |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Tue Sep 07, 2010 3:03 pm |
|
|
ckielstra wrote: | Even easier, buy a product that does what you want to do. The Microchip PicKit 2 and 3 come with an included software module called Programmer-To-Go that allows you to use the PicKit as a standalone programmer without the use of a PC. The only difference with your solution is that the target is programmed over the ICD connector instead of over RS232. The PicKit 3 is available for US$45.
CCS sells the Load-n-Go handheld programmer for US$199.
Searching the web you can find more products and hobby projects for the same goal. |
If that's what he's doing with it.
:D _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FFT
Joined: 07 Jul 2010 Posts: 92
|
|
Posted: Tue Sep 07, 2010 3:25 pm |
|
|
@bkamen,
I want to save the hex file as a text (ascii) which means a hex number is 2 bytes. I'll send every every row of the hex file to the pic and it'll write the row to the backup space.
For example If I have 50% free space in rom and I send the same hex of the pic via rs232 to backup space I can't store the hex there (in 50% free space), because the hex is in ascii and it is 2 times bigger, right?
How many bytes I can write in a row (address) of the rom space?
@ckielstra, thanks but I don't wanna make a standalone programmer. I have one.
Now I'll download the datasheet and will take a look. |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Tue Sep 07, 2010 4:07 pm |
|
|
FFT wrote: | @bkamen,
I want to save the hex file as a text (ascii) which means a hex number is 2 bytes. I'll send every every row of the hex file to the pic and it'll write the row to the backup space.
|
well, yes and no.
FF can be a single hex byte, correct.
But you are dealing with a TEXT file..
Therefore (1) F is a char (byte) the next F is another char/byte.
If you do a binary save, you will have to convert the HEX file (which is text) to binary.
If you do that, now you have to regenerate the binary back into the HEX text format. Let's say that another way: To go from binary back to HEX file (text) format, you'll have to know where and when to reinsert the colon chars, the string headers followed by the payload and the checksum with the CR/LF chars.
Have you downloaded the Intel HEX File specification yet? You should.
I think you'll find it a more interesting ride than you're making it out to be.
http://en.wikipedia.org/wiki/Intel_HEX
Quote: |
For example If I have 50% free space in rom and I send the same hex of the pic via rs232 to backup space I can't store the hex there (in 50% free space), because the hex is in ascii and it is 2 times bigger, right?
|
It's more than 2x. You really need to read the Intel HEX format. Then some of these questions would already be answered for you.
It would be easiest to keep the file verbatim... just copy that sucker into memory someplace as the text file. Then spew it back out.
Then all the memory placement and payload sizes stay intact with the checksums and memory block allocation.
Quote: |
How many bytes I can write in a row (address) of the rom space?
|
Depends on the PIC. You need to refer to the datasheet.
@ckielstra, thanks but I don't wanna make a standalone programmer. I have one.
Now I'll download the datasheet and will take a look.[/quote]
Fabulous.
Is it the PIC18F4520 you want to use?
Can you afford to add an external Flash/EEPROM? What about figuring the max size then using a bigger PIC (like the 18F4620) to add in "headroom".
Anyway - you'll see what I mean. Read the Intel HEX spec and then stare at your .HEX file a bit until you have your head wrapped in it a little better.
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FFT
Joined: 07 Jul 2010 Posts: 92
|
|
Posted: Tue Sep 07, 2010 5:49 pm |
|
|
Hi,
I can't use another pic and I don't have external memory chip.
In datasheet of 18F4520 is written that at a time can be written 32 bytes and can be erased 64 bytes. But how can I understand how many empty rows (addresses) are there?
Maybe I can receive a row of the hex file and delete ":" and checksum bytes, then convert the asciis in hex
for example this row :
:100130003F0156702B5E712B722B732146013421C7
can be converted to :
100130003F0156702B5E712B722B732146013421
and they will be written as hexadecimal using atoi() function,
they are 20 bytes in the example.
But I don't know will I have enough empty rows?
Actually my question is not changed, it is how to store a hex file in the rom space? Of course it should take minimum space.
Or
I can compress every line (row) in the hex file and write them in rom and then decompress and if it is needed reconstruct the row and send it. But I should have a compressing algorithm...
What you recommend? |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Tue Sep 07, 2010 8:12 pm |
|
|
Think about it this way:
You want to use the PIC18F4520.
It has 32768bytes of program memory.
You say your application takes up 1/2 of that.
That leaves you 16384bytes of space left to hold your program copy.
if you took every byte of *program code* in your hex file and saved it to program memory, it would then take up the other half.
The problem is: the HEX file contains more stuff besides just the program code. There's also the config registers which the 4520 has 11. (with jumps in addressing that need to be identified in the hex file)
So it sounds to me like you need to come up with a compression algorithm to cramp on space to store that .HEX file.
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FFT
Joined: 07 Jul 2010 Posts: 92
|
|
Posted: Wed Sep 08, 2010 1:53 pm |
|
|
Thanks. I know these ideas. I just wanna learn the rom space structure.
if this is the address row and if an address row can contain 64 bytes
Code: |
------------------------------------
0x00xxxx : |_0_|_1_|_2_|_._|_._|_61_|_62_|_63_| |
I have 16384 bytes left, that makes 16384/64 = 256 rows, right?
The all PIC's rom space has 512 address rows and each of them has 64 byte erasable(writable) space, right?
My hex file has 842 lines as text file (shown by notepad++).
This means I have 256 free rows and there is no way to store this file in the rom, right?
Could someone speak me by calculations, please? I don't know what database (array) structure has a PIC's rom space at all.
Maybe I can optimize the code to take 40% of rom space but I can't more than of that.
Best wishes |
|
|
FFT
Joined: 07 Jul 2010 Posts: 92
|
|
Posted: Thu Sep 09, 2010 2:14 pm |
|
|
Any help?
Is that correct my previous post? |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Thu Sep 09, 2010 2:25 pm |
|
|
I think you're doing more math than is needed.
The PIC's memory "pages" are just how it's wired to handle the memory.
You don't have to have a line-by-page mapping.
Just look at the raw numbers.
You have X amount of bytes of flash to save stuff.
You have Y chars of HEX file to save.
If (X < Y) {
Get bigger PIC || Add External memory || Compress the image
} _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FFT
Joined: 07 Jul 2010 Posts: 92
|
|
Posted: Fri Sep 10, 2010 9:30 am |
|
|
Thanks, I understood now.
Actually I'm not talking about the pages. In the intel hex link has shown that every text line in the hex file has an address, byte count, checksum, etc..
I'm talking exactly about the address part of a line.
Ex:
Code: | :10010000214601360121470136007EFE09D2190140 |
Here 0100 is the address which I call it as ROW in my previous posts.
Now everything is clear, every byte has individual address and every line in the hex file has a starting address, the next line has different address which is not one more than the previous address value (not previous address+1).
So, does anyone know a good compressing algorithm? :-) |
|
|
|