CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Speeding up write_program_memory()

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Bill24



Joined: 30 Jun 2012
Posts: 45

View user's profile Send private message

Speeding up write_program_memory()
PostPosted: Tue Jul 17, 2012 1:07 pm     Reply with quote

Using write_program_memory() on a PIC24 with a clock speed of 20mhz to write decoded lines from a hex file appears very slow. E.G a 32K file downloaded via USB takes several minutes.

Is this a feature of the way write_program_memory() works or is it that PIC24 flash writes are very slow ?

I would like to achieve download speed similar to a USB memory stick. Does anyone know if this is possible ?

TIA

Bill24
temtronic



Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Jul 17, 2012 1:20 pm     Reply with quote

You'ld have to consult the datasheet to see if there's a 'block' write mode..IE writing say 512 bytes (a 'block') at one time. I don't use the device so I don't know, but if available it'll definitely speed up things.
I use USB flashdrives through 'Vinculum' modules at 115K200 but can go as high as 3Mbytes if needed.
hth
jay
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Tue Jul 17, 2012 3:14 pm     Reply with quote

Just curious, when you say "32K" is that 32K lines or 32K in terms of raw bytes for the file?


When I do RS232 bootloading on a PIC18, a 36KB file (it's like 820+ lines), it takes about 10seconds. (at 57,600b/s)

Something's up with the bootloader I would think.

Which bootloader are you using?

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
Ttelmah



Joined: 11 Mar 2010
Posts: 19499

View user's profile Send private message

PostPosted: Wed Jul 18, 2012 2:11 am     Reply with quote

Key is what size of block you are writing.
The built in define 'FLASH_WRITE_SIZE', tells you the block size of the chip. You _must_ write to the memory, in multiples of this size, and also starting from addresses that are multiples of this, if you want speed.
If you do, the compiler will automatically use block writes, and it takes basically the same time to write a whole block, as a single byte....

The data sheet does tell you this (indirectly...), with:
"This function is most effective when count is a multiple of FLASH_WRITE_SIZE,".

Best Wishes
jeremiah



Joined: 20 Jul 2010
Posts: 1345

View user's profile Send private message

PostPosted: Wed Jul 18, 2012 6:02 am     Reply with quote

One caveat to that:
You can use write_program_memory() to write less than FLASH_WRITE_SIZE, however, the write_program_memory() will fill the unused spaces with 0xFF, and go through the process of writing those 0xFF to the flash write buffer.

So, even if you tell the write_program_memory(), to write 4 bytes, it will still internally write 256 bytes. In order to speed the process of writing program memory up, it is in your best interest to write as many bytes as you can in one go, so you don't waste time writing 0xFF's in the spaces you later put data in.

The only requirement for write_program_memory() is that the data is in multiples of 4bytes and that you issue the erase_program_memory() for a block once if you aren't writing to the start of the current block.
Bill24



Joined: 30 Jun 2012
Posts: 45

View user's profile Send private message

PostPosted: Wed Jul 18, 2012 9:53 am     Reply with quote

The program downloaded is around 32K bytes. I am basing the code on the CCS example. I think I am going wrong as I am writing 32 bytes at a time. I.E one line of a HEX file, Not one block which on the PIC24 I am using 0x400 words.


Thanks for your suggestion. I have not tried it yet but I believe it will solve the problem.
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Wed Jul 18, 2012 10:53 am     Reply with quote

Bill24 wrote:
The program downloaded is around 32K bytes. I am basing the code on the CCS example. I think I am going wrong as I am writing 32 bytes at a time. I.E one line of a HEX file, Not one block which on the PIC24 I am using 0x400 words.

Thanks for your suggestion. I have not tried it yet but I believe it will solve the problem.



Yeees... Writing one word at a time is always slower than a line (up to the write buffer size of the PIC - not necessarily the HEX line size which as you know is smaller) at a time.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Wed Jul 18, 2012 12:06 pm     Reply with quote

I've implemented a PIC24 bootloader in 2008, starting with PCD V4.078. At this time, several bugs have been involved with the pcd_loader.c code and the built-in flash write functions didn't work as apparently assumed in the code.

I rewrote the code, besides other details I implemented a page buffer. Unfortunately I can't tell which of the changes has been obviated by later PCD and example code versions, but I assume, that a page buffer is still essential.

The bootloader is sufficient fast, I didn't see a reason to edit the basic operation.
jeremiah



Joined: 20 Jul 2010
Posts: 1345

View user's profile Send private message

PostPosted: Wed Jul 18, 2012 12:34 pm     Reply with quote

FvM wrote:
but I assume, that a page buffer is still essential.


You don't need a page buffer. Just a row buffer. The PIC 24 writes a row a time (64 instuctions = 128 words = 256 bytes). You still have to erase a page at a time though.
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Thu Jul 19, 2012 12:47 am     Reply with quote

Quote:
You don't need a page buffer.

I basically agree. If I remember right, I implemented the page buffer to support non-continuous hex files that "jump" between pages.
Ttelmah



Joined: 11 Mar 2010
Posts: 19499

View user's profile Send private message

PostPosted: Thu Jul 19, 2012 1:04 am     Reply with quote

Yes. You need a page buffer if you are going to allow partial writes of pages, since you then have to store the whole page before the erase, and just change the parts you need before writing back.

Best Wishes
jeremiah



Joined: 20 Jul 2010
Posts: 1345

View user's profile Send private message

PostPosted: Thu Jul 19, 2012 6:00 pm     Reply with quote

FvM wrote:
I basically agree. If I remember right, I implemented the page buffer to support non-continuous hex files that "jump" between pages.


That's definitely a good reason. CCS can generate non-continuous hex files, so I definitely have worried about that too. I've tried a couple different routes of my own with good success:

1. Write my own write_program_memory() that doesn't do the erase, then call erase_program_memory() for each page in the user section of flash memory at the beginning of the whole process once. I can then write data to my hearts content. It's a little wasteful on the write cycles if you aren't using most of the user space, but part of me likes how all the user pages have close to the same usage.

2. Write my own write_program_memory() that doesn't do the erase, then keep a list of flags for each page initialized to zero (a bit array works for this). Each time I get a start address I calculate the page it is in, see if the flag is set, and, if not, call erase_program_memory() for that page and set the flag for it so I don't erase it again.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group