 |
 |
| View previous topic :: View next topic |
| Author |
Message |
starfire151
Joined: 01 Apr 2007
Posts: 195
|
| Store / recall some runtime values in 16F1574? |
 Posted: Sat Feb 20, 2021 3:14 pm |
 |
|
Is there a way to store a few bytes of runtime values in the PIC16(L)F1574 chip and restore them on the next power-up?
In looking at the datasheet for the 16F1574, it says it has "128 bytes if nonvolatile data storage" (not "of", "if"... it's probably a type-o but it's written the same way on the datasheet for the PIC12(L)F1572 chip, also  ).
Trying the write_eeprom() and read_eeprom() didn't work. Apparently this does not access like EEPROM. I looked a bit at the write_bank() and read_bank() commands but I'm not quite sure this would be appropriate or would work.
Does anyone have any ideas how I could save a few bytes (less than a dozen) in a non-volatile way using this chip?
Thanks. |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9224
Location: Greensville,Ontario
|
|
| Posted: Sat Feb 20, 2021 3:29 pm |
|
|
Curious, so I downloaded the datasheet...
Chapter 10 of the datasheet tells how, shows using ASM...
Someone may have done it in 'C' though.... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Sun Feb 21, 2021 4:16 am |
|
|
This is the high endurance flash.
It is read/written using the program memory instructions, not the EEPROM
instructions. It doesn't behave like EEPROM at all, requiring a whole 'page'
to be erased, rather than a single byte. The page is 32 instructions long.
Remember that each 'word' of this can just store 14bits of data.
So it is nastily complex to use. The high endurance ability only applies to
the low byte in each word. You have to format your data to fit into
these reduced size words, and write the whole entity as a block.
| Code: |
#define HEF_LOCATION 0xF80 //change to suit chip
//Now start by 'preloading' the HEF, with the bytes you want. Bytes
//remember.
#ROM HEF_LOCATION = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,
18,19,20,21,22,23,24,25,26,27,28,19,30,31,32}
//Because we do this, the compiler won't put other values here, so
//we must fill with 32 values, from each of which a byte is actually
//used. Change the low bytes to be what you actually 'want' stored
//here when the chip is first programmed.
void read_data_HEF(char * data, int size)
{
//read a block from the HEF, and transfer alternate bytes
//to a block in RAM
char buffer[64]; //block size of HEF
read_program_memory(HEF_LOCATION, buffer, 64);
//Now move alternate bytes into RAM
for (ctr=0;ctr<size;ctr++)
*(data+ctr)=*(buffer+(ctr*2));
}
void write_data_HEF(char * data, int size)
{
int ctr;
//now write a block to the HEF
char buffer[64]; //block size
//Now copy the bytes required into this
for (ctr=0;ctr<size;ctr++)
*(buffer+(ctr*2))=*(data+ctr);
//Now write this. Remember processor will stop during this write.
write_program_memory(HEF_LOCATION, buffer, 64);
}
//So in your main, if you have your data to save stored as a structure
void main(void)
{
struct {
int16 something;
int32 something_else;
char some_text[8];
} data_to_save;
read_data_HEF(&data_to_save, sizeof(data_to_save));
//loads the data - first time the pre-saved values.
//then when you want to write the structure:
write_data_HEF(&data_to_save, sizeof(data_to_save));
}
|
|
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9224
Location: Greensville,Ontario
|
|
| Posted: Sun Feb 21, 2021 5:36 am |
|
|
As Mr. T. pointed out HEF is, well, 'interesting' ! Almost looks like someone created it by accident in the lab and someone else said 'better use it, it cost us a million bucks '...similar to 'sticky note glue'.
There's probably a 1009 PICs with similar features to the 1574, a few will have EEP for 'default' or 'runtime' values. Perhaps choose one of them ?
Since I always seem to need a RTC, I use a module that has a DS3231 AND a small EEP(4kb).Only cost $2 and save a lot of time....no pun intended. You can even use the SRAM in a DS1307 as it's battery backed !
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Sun Feb 21, 2021 7:29 am |
|
|
The thing that really 'annoys' about the HEF, is it tends to be supplied on
chips that often don't have a lot of spare RAM, and having to setup a whole
page of memory as a buffer to talk to this is very irritating.  |
|
|
starfire151
Joined: 01 Apr 2007
Posts: 195
|
|
| Posted: Sun Feb 21, 2021 9:59 am |
|
|
Thanks, very much, for the replies.
I did some more digging and found an app note written by Microchip on how to access the High-Endurance Flash (AN1673, "Using the PIC16F1XXX High-Endurance Flash (HEF) Block"). It's dated 2014 but does directly relate to how to read and write from HEF. It even includes some C routines.
The note mentions the HEF as a cheaper alternative to EEPROM with the same retention features (100K E/W cycles) as opposed to Program Flash access, which is slated as 10K E/R cycles.
It's interesting to note that the read accesses can happen with no appreciable effect on the processor, the write cycles cause the processor to "stall", which includes responses to interrupts. It appears the stall period is around 2ms (from the code example) so it may not have that big an impact but still needs to be accounted for.
Mr. T, your example seems to be much more straight forward. In my specific case, I don't have that many values to save (3 16-bit values and 3 8-bit values) so this looks like a viable approach. I will try it out this morning.
I'm really trying to keep the footprint to a minimum for my application and the pins are all pretty well allocated. Ordinarily I'd just use a small 24LC16 I2C EEPROM but I don't have two pins for I2C.
This should be a good test case for the HEF anyway...
Thanks, again, for all your help. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9224
Location: Greensville,Ontario
|
|
| Posted: Sun Feb 21, 2021 10:14 am |
|
|
re: | Quote: | | trying to keep the footprint to a minimum |
That can come at a HUGE cost in required R&D time and money in getting 'something' (HEF in this case ) to work very reliably.
As the saying 'penny wise, pound foolish' goes, I've found using a 'big,expensive' PIC can save a lot of time, hence money.
You've probably spent at least 10 hrs reseaching this, still will need another 10 to get 'something' to work, another 10 to be sure it works.... that's 30hrs x $50/hr = $1500. THAT buys a lot of 'bigger-better' PICs.!!
I'm amazed very few factor in R&D as an actuual cost...
Just food for thought...
Jay |
|
|
starfire151
Joined: 01 Apr 2007
Posts: 195
|
|
| Posted: Sun Feb 21, 2021 11:32 am |
|
|
Your point is well taken but isn't it also important to know how to work with the available features (as odd as they sometime are).
I'm not putting this project together to make thousands of end devices. I don't consider it "foolish" to delve into the odd features of a part. Since I'm retired now, my time is "infinitely" more valuable than $50/hour (which I was making substantially more than before I did retire ). I just want to know how to make it tick...
I agree with your statement for those in a working, production atmosphere but if we don't spend a little time on R&D, we may as well resign ourselves to the fact that pretty soon all the datasheets will be in a foreign language... 
Thanks, again, for the help. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Sun Feb 21, 2021 11:58 am |
|
|
Key is, that I'm 'taking advantage' of the supplied CCS function, that
automatically erases a page provided you start on a page boundary
(which the HEF does). Hopefully I got the code right (these were
written 'as I typed', so could easily have faults (though reading again,
they still look right).  |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9224
Location: Greensville,Ontario
|
|
| Posted: Sun Feb 21, 2021 12:03 pm |
|
|
Seeing how you have lots of 'free' time, if you want to have a lot of 'fun'..figure out HOW to detect and correct for a broken wire in a system using Dallas Semi 'one-wire' temperature sensors !
It's my current 'brain teaser' while waiting for Spring to arrive
Sad thing is I can currently 'detect and correct' a system using 15 miles of copper wire, so you'd think a mere 100' would be easy.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Mon Feb 22, 2021 4:36 am |
|
|
I'd suggest probably reading the device ID. If I remember correctly the
last byte is a family number that is the same for all the devices. So if this
doesn't retrieve correctly, you are not talking to the device properly,
and know there is a problem. |
|
|
|
|
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
