 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Mrinmoy
Joined: 20 Dec 2023
Posts: 15
|
| PIC24F series program memory use case as storing some data |
 Posted: Wed Aug 21, 2024 12:45 pm |
 |
|
Hello everyone,
I am using PIC24FJ512GL406 in one of my project and my ccs version is V-5.101. I want to store some configuration data(max 1kB) of my application in the program memory as there is no built-in eeprom available in these series microcontroller. Please guide me in this process. I can't find any way how to choose memory location to store data and how to seperate this memory to save program as well store data because handling program memory is very crucial for such use as of my knowledge.
Any kind of help is highly appreciated. Thanks in advance  |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Thu Aug 22, 2024 12:57 am |
|
|
It is unfortunately slightly complex on the PIC24's.
Unlike the PIC18, they have their memory organised as 32bit words, with
only 24bits of each word available. So you have to do a translation, counting
forwards 4 bytes for every 3 bytes to store, and only accessing three bytes
out of every four. Also the memory has very large erase pages
Now the simplest way to avoid the problems this introduces, is to let CCS
handle it for you. Use their virtual_eeprom driver. Here you use a minimum
of two programming 'pages' of the program memory, and the data is stored
as a 'record' containing the byte to store, and it's address. A record with
an erased address is seen as blank. When you add a byte it searches to
see if a byte with the same address already exists, and if so, sets the flag
to say this has been erased, and looks for the next blank record and
stores the address and value here. This way it only has to erase the page,
when it runs out of empty records.
Soi for you:
| Code: |
//Your processor setup etc..
#define VIRTUAL_EEPROM_START_ADDR 0xxxx //This will need to be at
//least three pages below the top of memory, and on a page boundary.
//You do not reed to set this unless you must fix the EEPROM at a
//location you desire.
#define VIRTUAL_EEPROM_16BIT_ADDR //since you want more than
//256 entries.
#include "virtual_eeprom.c" //Load the driver
//Then in your main()
init_virtual_eeprom(); //must be called before any operation using this
//The virtual EEPROM can then be read and written just like normal EEPROM
//You just read a byte with:
bytevalue=read_virtual_eeprom(16bitaddress);
//or write a value with
write_virtual_eeprom(16bitaddress, bytevalue);
|
Now the driver will use two pages of the program memory. By default these
will be the second and third page down from the top of the program
memory.
This is because the very top page has the config bytes at the top. Hence
cannot be erased. The driver needs two pages minimum, so it can copy
stuff from one page to another when the page gets full, before erasing.
You can tell the driver to double the space used, by setting:
#define VIRTUAL_EEPROM_DOUBLE_SPACE
before loading the driver. Be aware, your amount of data is very large. It'll
only just fit in a page, so changing a single byte will result in needing to
do a full page copy. Using the double_space option will avoid this but
mean you lose 4K instructions of memory (16KB).
Now the driver automatically reserves the space (it does a #ORG to say
this is being used). |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9232
Location: Greensville,Ontario
|
|
| Posted: Thu Aug 22, 2024 10:36 am |
|
|
possible option... ???
IF your project needs a battery backed external RTC module, get one with EEProm. Really not that expensive, uses I2C, data is in individual bytes. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Thu Aug 22, 2024 1:02 pm |
|
|
| Few offer 1KB though..... |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9232
Location: Greensville,Ontario
|
|
| Posted: Sat Aug 24, 2024 5:56 am |
|
|
true, but 1/2 way there !
Maybe he can reduce the size by rethinking what 'configuration data' has to be?
In my energy control systems, I used ONE byte to store the 'opening ' time. Not needing 'to the minute', I allowed 8:00,8:15,8:30, etc as 'times' (15 minute intervals. Only needed 7 bits to 'encode' the time. The free extra bit was a 'control' bit,if set heat was turned on, 0 heat turned off.
I know ,today nobody TRIES to reduce memory needs but....as a 'dinosaur', I didn't have megabytes to play with......
just thinking of options... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Sat Aug 24, 2024 12:12 pm |
|
|
That is very true. Also worth explaining to us how this configuration needs
to change.
If this is fixed, or only has to change as a complete entity, then a single
page of the ROM could be used. I have a standard routine that handles
the 3 out of 4 translation for this. Then a complete block write can be
done as a single operation.
If he can reduce it to 256 bytes or less, then the 8bit indexing can be used
instead of 16bit, and just two pages would work OK.
The big advantage of the virtual driver, is it only has to pause for an
flash erase, when the data has to move from one page to another. A single
write can be done without an erase,
Lots of fine details that affect this.... |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
