PIC storing and changing data

peter_morley

Joined Mar 12, 2011
179
I have a PIC 16F684 and im trying to create a stack of data that can be accessed and manipulated. I was thinking about putting these files in the data register bank which starts at 0x020 and ends at about 0x070 or something and I realized this wasn't enough space. Now I am thinking of putting these files at the end of my program. So the number stored at the line in my code should be found at the address it is placed in. I was thinking of doing code like this...
EQU 0x025
EQU 0x038

and this would continue for a couple hundred locations so I don't know if this is right but basically I need a lot of bytes in a stack and I need to be able to access them using FSR and INDF. Any ideas?

Markd77

Joined Sep 7, 2009
2,806
You have 256 bytes of EEPROM, it's fairly fast to read, but quite slow to write, and you can only write it a million times before it stops working.
It's not quite as easy as using FSR and INDF but not too bad. There are examples in the datasheet.

peter_morley

Joined Mar 12, 2011
179
Well it is possible that I would need to write it more than million times. I also would need more than 256 bytes. Would I be able to just store a byte within my code at that PC counter spot?

ErnieM

Joined Apr 24, 2011
8,042
Are you married to that device yet? If you choose one with a SSP module you get a choice of wither SPI or I2C, then you could stick an external SRAM chip out there and get 8Kbytes for about 50 cents.

You can do it without the module by bit banging the pins, but not as fast.

t06afre

Joined May 11, 2009
5,934
If you need more RAM perhaps the 18F series is the best for you

peter_morley

Joined Mar 12, 2011
179
Are you married to that device yet?
Haha well I was married to the 12F675 or whatever until the ic pins just snapped off from wear and tear of trial and error. But now I'm using the PIC 16F684 which is pretty similar. My intentions initially were just to display simple color now im setting up an 18 x 14 pixel configuration. I am using 18x14 which equals 252 because EEPROM has only 256 bytes. The screen ratio is 1280x1024 so I used 18x14 which is close to the ratio of 1280x1024.

peter_morley

Joined Mar 12, 2011
179
You have 256 bytes of EEPROM, it's fairly fast to read, but quite slow to write, and you can only write it a million times before it stops working.
It's not quite as easy as using FSR and INDF but not too bad. There are examples in the datasheet.
I have written this code and I'm pretty sure it says to write to the EEADR and EEDAT register first then enable the write. Here is the code I have and I am not seeing the number 9 in location 0 in EEPROM section. I use the debugger software in MPLAB.

Rich (BB code):
Bank1
movlw	0x000
movlw	0x009
movwf	EEDAT

BSF     EECON1,WREN         ;Enable write
BCF     INTCON,GIE            ;Disable INTs

MOVLW 	55h                    ;Unlock write
MOVWF 	EECON2
MOVLW 	0AAh
MOVWF 	EECON2
BSF    	EECON1,WR           ;Start the write

Markd77

Joined Sep 7, 2009
2,806
After you start the write you need to step through the code a bit because it takes a while to write. It should appear when the WR bit clears itself.

peter_morley

Joined Mar 12, 2011
179
I got past 120 instruction cycles and still the EEPROM would not change so then I gave up pretty much. Only until I pressed play and it went through thousands of cycles did it change. What is the point of having memory spaces that take so long to change? And should it be taking atleast 120 cycles to finish?

Markd77

Joined Sep 7, 2009
2,806
In section 15.5 it says 5-6 ms to write so 5000-6000 instructions with a 4MHz clock.
It's very useful for saving things that need to survive with power removed, you can write it when you program the chip and reading is pretty fast.

Potato Pudding

Joined Jun 11, 2010
688
Hmmm, I was tempted to find my collection of info on connecting PICs to memory cards.

Overkill for this use, and it requires the 4 wire SPI protocol which I don't think your PIC has.

Being able to store/retrieve 2Gb or more in a microSD card that you can buy for about $5 last time I checked is a big step towards being able to do whatever you want to do with a PIC. I remember when PC's had 20Mb Hard Drives so 100 times more than DOS box computers had seems like it should be so much storage. Or buy several microSD and swap them in and out of a socket on the board, then use them to move data to and from a PC. For smaller and cheaper - use something like an I2C connect to a RAM or Eprom added to the circuit board to add several times as much storage as you will normally need. If you need 512bytes and you range across a 2k chip then you are good for about 4x as many Writes, use a 16k and you are good for 32x the writes. That is probably just something to do for practice in your case - mostly useful if you wanted multiple processors to share that memory. Like others have said, and I have to agree, you want a PIC with more flash memory. Last edited: Thread Starter peter_morley Joined Mar 12, 2011 179 Like others have said, and I have to agree, you want a PIC with more flash memory. People have suggested adding external flash memory. My primary concern is how would I go about extracting the bytes of data from the external source. Would it involve me setting a bit in the RAM which would then indicate to the RAM device to send one byte of information to the PIC. Also would I need 8 bits to send one byte? If so that would be hard to implement because I have 6 bits for PORTC. Is this how it would be done though? Potato Pudding Joined Jun 11, 2010 688 My impression of the problem you have is that 128 bytes of SRAM is not enough. I just want that clarified as describing your problem. I don't think you want an external memory chip to go with the 16F684. The easiest external memory chips use a 2 wire or I2C serial communication so you only need two pins. You might be able to code one up in theory but I would rather use a chip that has I2C, SPI, or whatever serial I need built in. Setting it up yourself seems like you are either showing off or making more work than it can possibly worth. Again I repeat that the external memory is only better than a controller that has the needed memory internal when you want the memory to be a shared resource for several controllers. It seems like it is time for you to try something like a PIC16F1825. Costs less than 2 dollars, has 14 pins and 4 PWM channels like the PIC16F684 but it also has 14Kb flash program memory and 1Kb of Ram in chip. Not EEPROM (it has 256 bytes of that if needed) - but it also has 8x the Ram working memory of the 16F684. http://ww1.microchip.com/downloads/en/DeviceDoc/41440B.pdf Potato Pudding Joined Jun 11, 2010 688 If you really wanted to use the 16F684 it might be possible... depending on what you are doing. You might want to use filtering and pattern matching to create a compression strategy. That would let you use about 16 to 48 bytes SRAM for raw data for finding moving averages and slopes. About 1k program flash (EEPROM could be used for template data) for look up tables to use for compression decompression. Depending on how degraded and lossy you allow your compression to be - you could use the other 70 to 100 bytes SRAM to hold an approximation of about 210bytes to 1kb of raw data. (You will need about 10 bytes variable space that I have accounted for.) 3 to 1 to 10 to 1 compression ratios are reasonable depending on the patterning or blank spacing of your data. I still recommend a device with more memory - but everyone has their own geekiness to fun return on investment calculations to make - so I will mention the option. Disclaimer!! This a theory so there is no warranty and you need to do your own research. Don't ask for much more help if you think you want to try this - because I would not try it when another device that should work much easier is available. I would recommend going to 64 to 100 pins and raising the budget by$10 to get 64Kb or more on chip ram with a higher end chip before I would suggest trying to get what you want by coding compression with a 16F684.

I bet it can be done but I would ask why before making it into a plan.

The overhead to return is too severe.

In a PIC32 with 128k it makes more sense because you can afford that overhead, so that you can compress a Mb of data and squeeze it in - a worthwhile trick.

peter_morley

Joined Mar 12, 2011
179
Thanks Potato Pudding for the detailed response. I'm thinking of getting the PIC16F1825 because it has 1024 bytes of ram and can go up to oscillation speeds of 32MHZ without the use of external clock sources. The only thing that bothers me is the organization of the ram. I would always have to be switching banks to access and change the data stored in ram. I am kind of confused as to why there are so many memory banks. I know there are so many to add ram but why so many additional registers? It looks overwhelming.

Markd77

Joined Sep 7, 2009
2,806
They have made it much easier on this PIC than the older midrange PICs. Have a look at section 3.5.2 of the datasheet.

Potato Pudding

Joined Jun 11, 2010
688
I am kind of confused as to why there are so many memory banks. I know there are so many to add ram but why so many additional registers? It looks overwhelming.
8 bit chips only have a natural address range of 256 and you need to bank them to get more address space.

Look at the Bank designation bits as the the upper bits or pages of a 16 bit address. That allows you to have the 14k Flash program memory for example with the PIC16F1825.

And the extra registers are to give you more options. Look at them as hard coded variables for hard coded routines.