Non-volatile memory dilemna.....

[JAM2014]

Hi All,

I'm working on a design based on the PIC 16F1459. A new requirement late in the design requires that I store about 50 bytes of configuration data in non-volatile memory space. The 16F1459 does not have EEPROM. It looks like my options are:

1. Add a small serial EEPROM to my design
2. Use the internal flash memory storage on the 16F1459
3. Switch to a different PIC with EEPROM such as the 18F25K50

Any thoughts on what would be the 'best' option? At the moment, I'm at about 50% ROM usage, but I could see that being chewed up quickly if i have to put in a lot of code to implement option #2.

Jack

[PCM programmer]

What features of the 16F1459 are you using ? USB, CWG, UART, etc ?
What package are you using ?

[temtronic]

I'd use a bigger PIC as you _always_ need more stuff, memory, I/O, etc. I see that PIC has USB. is that necessary? If so consider the cost/benefits of using a USB<>TTL module. Yes, cost $2 but frees up a LOT of codespace in the PIC as ALL the 'USB' stuff is in the module. Also module comes with a properly wired connector, couple of LEDS (you can remove to lower power) and, well, the module works. Most don't consider using the modules BUT if you actually price out your R&D time it may be cost effective, especially on small production runs of say 100 to 1000. Most tech don't like being an accountant but you should price out the product which includes R&D time. IE say you've spent 100 hrs getting USB in the PIC to work. That could easily be $5,000 or over 2500 modules and less than 5 hours to have a working product. Just something to consider.
As for choice of PIC, if possible choose one with more features than you need. Yes, a buck or two more BUT allows for FAST upgrades thus reducing R&D costs. Also you build a common core of code, personal libraries that you KNOW work. Jumping from PIC to PIC, especially series, can cost you a LOT of time (and money).
I use 28 and 40 pin PICs where 18 pinners would work BUT it's a lot easier and cheaper to just grab a 'big' PIC, build a 'proof of concept' product in a day or two and make the client happy. When he comes back wanting more, I can add code without needing to upgrade the hardware.

just points to consider.

Jay

[newguy]

Solely speaking to the memory aspect of your question....EEPROM built into a PIC doesn't have a high endurance. "Ordinary" SPI/I2C EEPROM is a better option, particularly if you're not going to be accessing/writing very often. If you will be writing often, then FRAM would be a better option. If you're writing/accessing extremely often, then MRAM is the longest life (most endurance) option.

[JAM2014]

Hi All,

I'm using the USB and UART peripherals, and that's it. Package is a 20 pin SOIC. I'm not worried about endurance of the non-volatile memory, as the configuration I need to store will be done very infrequently.

Jack

[PCM programmer]

Look at the 18F14K50. It has a similar pinout, and it has 256 bytes of
data eeprom.

[Ttelmah]

His existing chip can be used fairly easily, provided he is happy to work with the memory as a block.

The program memory on this chip has pages organised as 32*14bit words.
The chip has high endurance flash at 0x1f80.
A write using write_program_memory to this address, will write 32words, of which the low byte of each is the HEF (32bytes in each page).

If he organises the configuration data to be laid out as 32bytes occupying the low bytes of a 64byte array, he can (at the cost of 32bytes extra RAM), just write the whole lot with a single block write operation. The read can be done the same way.

[JAM2014]

Hi,

Unfortunately, the 18F14K50 would need a crystal as it doesn't support ACT. I have room on my board for a (slightly) larger pin count PIC, but not a crystal.

The data that I need to store will *not* change often, and can be written/read all at one time in a block, so I'll investigate the write_program_memory option!

Thanks,

Jack

[temtronic]

An option, perhaps?

Consider your 'config' data as bits NOT bytes. PICs are efficient in bit manipulation. Perhaps you can then 'pack' your 'config' data to use less memory ?

Might be worth investigating.

My energy management program breaks the day into 15 minute units so 96 bits = a 24 hour period. That's only 7 bits of a byte. Top bit is used for 'status' bit.

Jay

[JAM2014]

Hi,

The 'data' is bytes, not bits, so 'packing' isn't an option!

[Ttelmah]

You need to understand the memory layout of the program memory.

It has pairs of bytes, comprising each word. The word is only 14bits, so in the RAM array, byte 0, has 8 bits usable, then byte 1, only has 6 bits. Then byte 2 has 8 bits and byte 3 has 6 bits again.
When implementing the HEF, Microchip only implemented it on the low byte of each word. So bytes 0, 2, 4, 6 etc..
So the HEF is read/written as the alternate bytes in the RAM array.

Now the flash & HEF, are written in 'pages' of 64 bytes (32 words). The pages only erase when you write to the first byte in a page. There are a total of 128bytes of HEF, occupying the low bytes of the last 128 words of the memory. So four pages at 0x1F80 0x1FA0 0x1FC0 0x1FE0.

You have to write 64 bytes to write each 32 words, which can be used to store 32 bytes in each page. The actual read and write code (provided you just write/read 64 byte blocks, is very small (only about 30 instructions). The hard work is preparing the data array to contain your data in a logical manner.

[JAM2014]

Hi Ttelmah,

I think I 'get' the program memory layout! Here is my array definition:

[Ttelmah]

I don't think it'll like you writing only 63 bytes. The transfers are word wide. Must be an even number of bytes, both for read and write.

[Ttelmah]

If it still doesn't work after switching to 64 bytes, have a look at:

<http://www.ccsinfo.com/forum/viewtopic.php?t=54018&highlight=flash>

I had to re-write the CCS functions a few compiler versions ago, for a similar chip, so they may still have problems for yours.

[JAM2014]

Hi All,

It seems that my problem is due to a silicon errata on this chip related to writing to flash memory when the internal oscillator is greater than 4 Mhz.

http://ww1.microchip.com/downloads/en/DeviceDoc/80000546F.pdf

If I use this clock setting, which I need for USB, it doesn't work: