Method to save variables in flash

[Moto Geek]

I know this is a long shot, or maybe not... If I collect data by reading the value of an 8 bit input port, lets say every 5 seconds, I then assign that byte to a variable in an array, first reading = invar(1), second reading = invar(2), etc... 600th reading = invar(600). From what I understand, GCB can have up to 10000 elements in an array. Is there any way to take advantage of the larger flash available in the newer chips, ie 16f18326 to somehow store these variables so they remain after power down? The eeprom is not big enough for storing 600 variables. Is there some way to set asside a certain amount of flash to "store" data for future use?

If not, that would be a great function, if it is actually doable... Thanks for any info!

[Anobium]

Yes, look at the Memory devices in the Help. Whilst you could use PROGMEM why not keep things simple and use a 47xxxx device.

[stan cartwright]

I searched and got-
This is the Memory section of the Help file. Please refer the sub-sections for details using the contents/folder view
Where is contents/folder view option?

[stan cartwright]

Is this down to knowing program memory start/end and pokeing the values to store in 6000 bytes from end and that will be the same on re power?
If using uno/nano or any boot loader then need to know where that's stored I suppose. That's a point! What is it on uno/nano 328p? never thought about that untill now.

[Chris Roper]

Is this down to knowing program memory start/end and pokeing the values to
store in 6000 bytes from end and that will be the same on re power?

No.

It would require allocating a block of Flash to emulate an EEPROM.
Flash can only be written to in blocks and the target block must be erased
before it is written to, not just the first time but every time.
Also remember that although FLash can be rewritten it cannot be accessed
like RAM, so you would not be able to treat FLASH as variables.
You may, however, be able to use it to backup your variables prior to power
down.
Not all devices would support it but but the newer ones should.
Allocating a block to use would, in theory, require changes to the Linker
Script used at compile time, but GCBASIC may already have provisions for
that.

[stan cartwright]

Thought it sounded too easy Chris Roper. It's flashed ram not ram,more like the program is in rom?
Is there any use/need for peek/poke in gcb?

[Moto Geek]

I took a look at the manual, but not too much there as far as usage (example). The commands are
ProgramErase
ProgramRead
ProgramWrite

On ProgramErase, it says...

Note that it erases memory in 32-byte blocks.

Not sure exactly where to start, or if this is worth it or not. Just thinking it would be cool to use some of that monster flash available for storing variables that could later be called back into ram and used in the program. I will check the demos folder to see if there is any info there that shows an example.

[Peter]

I did something along those lines on a recent project, I will dig out the code when I get back.
I wrote the the non-volatile memory manually using a PICKit3, read the data into my program then wrote a value back to tthe non-volatile memory so I could test whether it had been read.
The purpose of this was to set the clock of an MCP7940N on power up, but not on subsequent reboots/power events.

• If you are using the built in memory of the chip, you need to know whether your chip has EEPROM or HEF (use EPRead/Write or HEFRead/Write).
  http://gcbasic.sourceforge.net/help/_hefm_overview.html
  http://gcbasic.sourceforge.net/help/_eeprom.html
• HEF is pinched from the top end of the flash program memory area (the addresses overlap), EEPROM is a seperate memory space
• EPWrite lets you write a single address, I think HEFWrite emulates this by reading the block, changing it, erasing the block then writing the whole block back to memory.
• I think EEPROM stores a word at each location, but HEF only stores a byte.
• I had trouble figuring out how the location related to addresses on the PICKit3, but I'm sure someone else can figure it out, and if it's only your program that does the reads/writes it doesn't matter.
• Setting up PICKit3 to not overwrite HEF when reprogramming was a PITA. I recall it was simpler with EEPROM.

I think ProgramRead/Write/Erase accesses the whole flash program memory area so you could use these to access HEF. It would be easier to use the HEFWrite or EPWrite commands if you can and if the HEF (or EEPROM) is big enough for what you need.

Another consideration is that the main flash program memory area may be normal flash memory with a reduced lifespan compared to the HEF area. There is some info in this application note http://ww1.microchip.com/downloads/en/AppNotes/00001673A.pdf
In reality, Microchip may have found it's just as cheap to make the whole lot HEF rather than use two different types of flash on a die so you may be OK using the lower part of the program flash area.

[Peter]

Sorry I just saw in your original post that you have 600 variables. HEF seems to be limited to 128 bytes (or 128 words of EEPROM) so this won't be enough and you would need to use the lower part of the flash program memory area using EPRead/EPWrite which I am sure is possible but you would need to be careful that you don't overwrite any program code (i.e. stick them at the top end of the memory).

You will need to protect these addresses when reprogramming the chip so they don't get erased/overwritten.

[David Stephenson]

Here's a routine I use for datalogging on a 16f18326. It only writes, but as the flash memory should be set all on (3F) when programmed the flash is effectively erased. It can read back later using a programmer. Just make sure that the staring address is above the program code or you will get some interesting glitches. Note: despite what the datasheet says the memory can be written to one address at a time (14-bits).

sub flashdata1
    'adr1 = address xx8 = data
    nvmadrl = adr1
    nvmadrh = adr1_h
    set nvmCON1.NVMREGS off  
    set NVMCON1.wren    on  ' Enable writes
    set NVMCON1.lwlo    on  ' Write Latches
    NVMdatl = xx8
    NVMdath = xx8_h
    set NVMcon1.lwlo    off 'write
    SET INTCON.GIE      OFF
    NVMcon2 = 0x55
    NVMcon2 = 0xAA
    set NVMcon1.wr      on
    set PMcon1.wren     off
end sub

[Moto Geek]

This is interesting, will have to give it a whirl... Thanks for the info, same chip too, bonus!