Saving a variable into flash.

mjaved47

Is there a way to save an updated sensor reading into the flash?

Rayman

I've posted some code a while ago for using the extra space on the flash as a drive:
https://forums.parallax.com/discussion/171517
It may or may not still work...

But, you don't want to continuously erase a file and write a new file as you'd wear out the flash...

But, appending new data to a file should be OK.

Or, just use the underlying driver to write to the raw flash sectors directly without a file system.

Mickster

Funny that this should come up because I was just reading the FlexBasic docs and there is mention of mount sd and mount sd external.

I have the Rev B. Does this mean that the on board flash already emulates an SD card?

JRoark

I have the Rev B. Does this mean that the on board flash already emulates an SD card?

Nope, but I like the way you think!
There are currently three MOUNTable resources in FlexBASIC:

1). the SD card located on the default pins on the EVAL board,
2). the SD card located at a user-defined location in the pin range of 0-31 or 32-63,
3). the host laptop or dev system that is attached via the USB port (i believe this is the “Plan 9” filesystem).

But Christmas is coming, and you never know what Santa might bring. Lol

ManAtWork

I think, to save a single value to flash a filesystem and SD card is overkill. How often do you need to update the saved value?

I'd do it with single page write commands to the SPI flash. Mark the written pages as used with some flag and for reading search for the latest. On rollover erase the full sector and start over.

mjaved47

@ManAtWork said:
How often do you need to update the saved value?

Once a day maybe.

mjaved47

@Rayman said:
I've posted some code a while ago for using the extra space on the flash as a drive:
https://forums.parallax.com/discussion/171517
It may or may not still work...

But, you don't want to continuously erase a file and write a new file as you'd wear out the flash...

But, appending new data to a file should be OK.

Or, just use the underlying driver to write to the raw flash sectors directly without a file system.

Thanks. I'll try it.

Mickster

@ManAtWork said:
I think, to save a single value to flash a filesystem and SD card is overkill. How often do you need to update the saved value?

I'd do it with single page write commands to the SPI flash. Mark the written pages as used with some flag and for reading search for the latest. On rollover erase the full sector and start over.

Parameter storage, in my case. Not something that would be written very often.
It actually just caught my attention but it's not something that I need right now as I have another solution.

ManAtWork

@mjaved47 said:

@ManAtWork said:
How often do you need to update the saved value?

Once a day maybe.

If it's only once per day or only on user request then you don't have to worry about wear out. I'd suggest simply placing the variables you need to store in a DAT section. When required write the memory range from RAM to flash with the same absolute (hub) address. The next time the propeller boots it automatically initializes the DAT field with the flash memory contents.

At least this method worked for the P1. I don't know if the P2 calculates a checksum for the boot memory. Maybe you need to add a dummy byte to fix the checksum. Also make sure that you always erase and write a full block (at least 4k). You can't write single bytes.

Rayman

I think my FTDI EVE code (Antares) uses the flash code to store resistive touchscreen data in flash as a file.
Could be wrong about that though, been a while since I looked at that...
Meant to do that though...

JonnyMac

@ManAtWork said:

@mjaved47 said:

@ManAtWork said:
How often do you need to update the saved value?

Once a day maybe.

If it's only once per day or only on user request then you don't have to worry about wear out. I'd suggest simply placing the variables you need to store in a DAT section. When required write the memory range from RAM to flash with the same absolute (hub) address. The next time the propeller boots it automatically initializes the DAT field with the flash memory contents.

At least this method worked for the P1. I don't know if the P2 calculates a checksum for the boot memory. Maybe you need to add a dummy byte to fix the checksum. Also make sure that you always erase and write a full block (at least 4k). You can't write single bytes.

I was speaking with Chip about that process the other day. There are a couple of issues: 1) unless the flash page is erased, you can't write single values, so this would complicate the saving new values process, and 2) If DEBUG is used it changes the flash image and addresses would be fouled.

I have a project with very infrequent updates of values that I used to store in the upper 32K of the P1 EEPROM. In the P2, I'm going to use a flash page that is in the second 512K section of the flash. Long term, I'd love a flash file driver that would work with the 1M boundary and higher. I think @"Mike Green" may have written something that will do that -- but I misplaced the code he sent me.

pik33

If the flash is empty, and data is written once a day, then you can

1. clear the flash from 1 MB up (first 1 MB is reserved for a P2 program
2. you have 3840 pages free
3. when you need to write, read the flash and find the first free page
4. write data, add 00 byte to the end of data
5. when you need to read,find the last not empty page, then read data
6. after about 10 years, the flash is full. Backup it, clear again, rewrite the last month or year if needed at the start of the flash (after a P2 program)
7. repeat