 |
 |
| View previous topic :: View next topic |
| Author |
Message |
qve
Guest
|
| PCM flash write 16f883 |
 Posted: Sat Jan 30, 2010 12:58 pm |
 |
|
I would appreciate suggestions on how to read/write critical parameters that are programed as literals or maybe constants in flash programatically. They are usually of data type int16 or int32.
Is to possible for compiler to keep track of literals for replacement in code with a flash write function? Ex. #define testparam 0xaabb
or possibly use a constant table and replace table data? Ex. const long testparam = 0xaabb; or const long testparam[2] = { 0xaabb, 0xaabb };
How would I pass the location to the write function and would I need to worry about the opcodes as well as the data values or can the compiler take car of this thru some special magic?
All input is appreciated. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Jan 31, 2010 12:24 am |
|
|
If you're changing some stored parameters, normally this would be done
in data eeprom, not in flash. Is it essential that this be done in flash ? |
|
|
qve
Joined: 30 Jan 2010
Posts: 5
|
|
| Posted: Sun Jan 31, 2010 11:48 am |
|
|
The reason I was thinking flash is so conditional statements would execute literally instead of reading an EE value into ram for comparison which has the potential to corrupted by program bugs, brown out, etc. I could to read the EE each man loop and refresh the ram location but this seems like unnecessary overhead if flash solution could be implemented.
I should mention that these parameters may only be changed once or twice during the service life of the product via internal web server. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Jan 31, 2010 12:41 pm |
|
|
Here's an example of how to find the address of the data in a const array.
I have used an #org statement, just so we know where the array will
be placed, ahead of time. The const array has a few bytes of "access"
code placed in front of the actual data. The access code starts at the
#org address of 0x100. If you run this program, it displays 104 (hex).
If you go into MPLAB, into the View Program Memory menu, you will
see the data is in the form of several RETLW statements.
| Code: |
addr opcode Assembly
100 140A BSF PCLATH, 0
101 108A BCF PCLATH, 0x1
102 110A BCF PCLATH, 0x2
103 0782 ADDWF PCL, F
104 3434 RETLW 0x34
105 3412 RETLW 0x12
106 3478 RETLW 0x78
107 3456 RETLW 0x56
|
To change these values, you would have to keep the same "RETLW xx"
format.
I would not do this myself. I would consider it too messy, too
unorthodox. I try to keep everything simple and clean.
Here's the test program:
| Code: |
#include <16F883.H>
#fuses XT, NOWDT, BROWNOUT, PUT, NOLVP
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
#org 0x100, 0x110
int16 const test[2] = {0x1234, 0x5678};
//======================================
void main()
{
int16 addr;
int8 i;
int16 value;
value = test[i];
addr = label_address(test);
printf("addr = %lx \r", addr);
while(1);
}
|
Perhaps there is another way. CCS has a special feature called
"addressmod" which would allow you to make an array from data eeprom
memory. The manual has some examples on how to use addressmod.
However, you would have to carefully test this and prove that it works
before using it in a program. Also, whether it works or not will be highly
dependent upon your compiler version. In earlier versions, I think it
may be buggy. |
|
|
qve
Joined: 30 Jan 2010
Posts: 5
|
|
| Posted: Mon Feb 01, 2010 9:46 am |
|
|
Thanks for the tip on the label_address function and the sample code as well. You are correct that it is a bit unorthodox but sometimes it's necessary.
It's amazing how one can spend time browsing thru all the functions, etc. in the help system then routinely use the same few over and over. |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Fri Feb 05, 2010 8:43 pm |
|
|
PCM programmer wrote
| Code: | #include <16F883.H>
#fuses XT, NOWDT, BROWNOUT, PUT, NOLVP
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
#org 0x100, 0x110
int16 const test[2] = {0x1234, 0x5678};
//======================================
void main()
{
int16 addr;
int8 i;
int16 value;
value = test[i];
addr = label_address(test);
printf("addr = %lx \r", addr);
while(1);
} |
Now I am intrigued
1) Except for proving the address is correct is the #org necessary since label_address(test) gets the address?
2) Has anyone been able to get #org to work with a struct ?
label_address works just fine with a struct
Here is the concept
A device is programmed with say a struct of parameters that is const. Upon power up an identical struct only this time in RAM is populated with a read_program_memory using label_address to get the rom address of the struct and read it into the identical ram structure. Next via rs232 an update of the parameters is sent and a write_program_memory updates the struct of parameters in rom.
Now upon power failure restart the rom struct in flash is read via
read_program_memory and moved to the ram copy only this time its with the updated parameters.
The updates are very rare and the PIC lacks eeprom.
Any advice etc? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Feb 05, 2010 9:34 pm |
|
|
| Quote: |
1) Except for proving the address is correct is the #org necessary since
label_address(test) gets the address?
|
The reason for the #org is to I can easily go look for the code in
the Program Memory window in MPLAB. I know where to expect
it to be, and I can verify that the address is correct. Other than
that, the #org is not necessary. |
|
|
|
|
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
