Writing logged data from sensor to flash once SRAM is full?

Go To Last Post
38 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

 

This is more of a general memory question. Not sure where to post it.

 

I have an ESP8266 that logs data from a sensor. The sensor outputs a 1 byte number and the ESP8266 writes it to an array. This sensor produces 1 byte every +-1ms so the array gets full really quick. The largest array i can make is 45000 bytes then it starts complaining that instability may occur. 

 

I can log data for approximately 50 seconds before the array becomes full. I need to log data for as long as I can. If I can log data for 3 minutes it would be great.

 

My question:

 

When my array becomes full, can i copy this data to the flash then overwrite the array with new data and so on until i have all the data i need? I understand i can read data from flash but i am not sure if it is possible to write data to flash while the program is running? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

calvingloster wrote:
Not sure where to post it.

As it's an ESP8266 question, an ESP8266 forum would seem the obvious place?

 

https://bbs.espressif.com/

 

https://www.esp8266.com/

 

Wouldn't it make more sense to have something like an SD-Card ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doesn't that module have wifi, why not log data to the cloud, instead of locally?

 

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Doesn't that module have wifi
  Yes it does but the unit gets attached to a vehicle and data can only be retrieved once the vehicle comes back. 

 

awneil wrote:
an ESP8266 forum would seem the obvious place?
Yea my bad, i have not registers to any esp forums. I would like to apply this to an AVR as well for future projects

 

awneil wrote:
Wouldn't it make more sense to have something like an SD-Card ... ?
Space is a major issue 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

calvingloster wrote:
I would like to apply this to an AVR as well for future projects

Apply what, exactly?

 

There's no reason to suppose that the behaviour/capabilities of the ESP flash is in any way related to the AVR's flash ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A couple of points:

 

1) Never allow SRAM to "get filled up"

 

2) Never allow SRAM to "get filled up"

 

3) More of the same

 

Use some sort of external memory. Maybe its serial NV memory. Maybe it SD card. Maybe something else.

 

Then, once you have figured out what you are going to do, write small blocks to it. You have to do it in chunks that will transfer in less than a millisecond if you don't want to disrupt the sampling. OR, write the transfer routine to be tolerant of interrupts.

 

I use a uSD card that can be "written to" about once every 10ms. This is somewhat of an illusion, however, because I use the FatFS library and it accumulates data in a buffer (which I assume is one memory page in size), then transfers that to the card when ever it chooses to.  Fortunately, my sample rate is slow enough that it all works OK.

 

You say that an SD card is not an option. Then, tell me, just where are you going to put all that data? It seems to me that you have an impossible requirement that you have to resolve, somehow.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The esp8266 uses external serial flash. Yes, you can write to it. You need to find out if thrme write speed is faster than the data you sample, otherwise a buffer will eventually fill. A common technique is the ‘ping pong’ where you have two buffers the size of the flash sector (4k methinks) . Whilst one buffer is being written, the other is being filled with data. The buffers are then swapped ie:ping pong.
Another technique is a fifo, maybe a circular buffer.
Note the esp8266 does not execute from flash - the code is loaded from flash into ram and executed. Thus the flash can be written at any time.

Last Edited: Thu. Apr 12, 2018 - 05:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Apply what, exactly?
  Well i thought i could generalize the concept to more than one platform. That is, if you run out of SRAM space to log data for retrieval at a later stage, you can write some of it to the

 

flash

ka7ehk wrote:
2) Never allow SRAM to "get filled up"
 Would it be more wise to fill the SRAM half way then write to the external memory? 

 

ka7ehk wrote:
You have to do it in chunks that will transfer in less than a millisecond if you don't want to disrupt the sampling
It will be ok for the sensor to stop logging every 30 seconds or so for up to 1 to 2 second to offload the SRAM.

 

ka7ehk wrote:
You say that an SD card is not an option.
  Problem with the SD card is i do not have enough space in my enclosure. Once i have logged all my data and the vehicle comes back a switch will be flipped which will activate the ESP wifi and i will connect to it with a laptop or phone where the data will be displayed on a web page in graph format.

 

This might be a stupid question so please forgive me if it is. The ESP8266 has 4096kb of EEPROM that can be written to which is not nearly enough in any case but from googling apparently the ESP8266 does not actually have EEPROM, instead it uses its flash. If this is the case the flash is 1MB which is probably more than enough "EEPROM" than i need? Can i not log the data to this and read it out once i flip the switch after the vehicle has returned? 

Last Edited: Thu. Apr 12, 2018 - 05:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you Kartman. I will do some research on "Writing to and reading from ESP8266 external serial flash"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
4k methinks
  I believe you are correct. May i ask, why is only 4k available if the size of the flash is 1MB. Some modules have up to 4MB. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What kind of data are we talking about, how often is it sampled, why not use the car's wifi to upload to cloud storage, and view real time?

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cars have Wifis? I thought the coathanger antenna was for AM! Mind you, i’m halfway across the pacific and i’ve got wifis.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The flash is composed of a number of sectors of 4k each. You have to write a complete sector - not a byte at a time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are different firmware packages made for the ESP8266.

You can probably write to it as simple blocks, but it is also common to have a built in file handling capability.

This is often used for the "over the air" updates.

 

The common ESP8266 module's also come with different flash sizes.

Usuallly beteween 1MB and 4MB Flash.

I loved the ESP8266 for it's 300+MHz, Multi MB flash, the WiFi was a nice add-on, but I mostly dropped it because of it's lack of documentation and the firmware blobs.

 

Edit (after reading Awneil and his quote of your previous post).

 

4096kB would not be enough, but 1MB is enough ???

How much data do you actually need?

 

"Flash" and "EEprom" is pretty much the same technology. I actually never really understood the differentiation.

The ESP8266 does not have any "Flash" nor "EEprom" on board. Under the tin can there are 2 chips. 1 chip is the ESP, the other is a "dataFLASH" or whatever it is called to store data and the ESP8266's program. That is also the reason there are versions with different sizes of "EEprom" / "Flash" on the market. Search for some pictures of "naked" module's without the tin can on top. This site for example has a lot of pictures of the different module's:

https://www.esp8266.com/wiki/doku.php?id=esp8266-module-family#esp-07

If you use the ESP, you should do some more reading to what is in it. (And go to a better forum for that chip). Maybe this forum:

https://www.esp8266.com/

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Thu. Apr 12, 2018 - 08:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

calvingloster wrote:
Well i thought i could generalize the concept to more than one platform. That is, if you run out of SRAM space to log data for retrieval at a later stage, you can write some of it to the flash

No, you can't - because different chips may have entirely different Flash arrangements

  • Some cannot write their own flash at all
  • Some can write their own flash, but not while running from it
  • As noted, the ESP doesn't run from flash at all - so that issue is irrelevant.

 

 

Problem with the SD card is i do not have enough space in my enclosure.

Really? A micro-SD is pretty tiny.

 

Or you could use eMMC, or dataflash, or similar

 

 

Once i have logged all my data and the vehicle comes back a switch will be flipped which will activate the ESP wifi and i will connect to it with a laptop or phone where the data will be displayed on a web page in graph format.

 

This might be a stupid question so please forgive me if it is. The ESP8266 has 4096kb of EEPROM that can be written to which is not nearly enough in any case but from googling apparently the ESP8266 does not actually have EEPROM, instead it uses its flash. If this is the case the flash is 1MB which is probably more than enough "EEPROM" than i need? Can i not log the data to this and read it out once i flip the switch after the vehicle has returned? 

Again, these are detailed product-specific questions - you need to address them to Espressif support, or an ESP-specific forum.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What about writing into TCP/IP buffer (up to 2.048 bytes) with AT+CIPSEND, AT+CIPSENDEX or AT+CIPSENDBUF commands ...

Last Edited: Sat. Apr 14, 2018 - 11:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That assumes you have something connected via wifi. As well, I think the intention is not to use the AT command firmware.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you really need RAM (I don't think so) , then perhaps a FRAM (I think the biggest in SOIC 8 house is 512 K byte).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
That assumes you have something connected via wifi. As well, I think the intention is not to use the AT command firmware.

 

You can keep it waiting by not writing the last byte (as declared by the <length> parameter), or by being automatically send when logged in upon return.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So where is the data going to be stored? The implication here is the data exceeds the size of ram, thus using a tcp buffer (which exists in ram) will not be sufficient.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indeed.

 

The OP states he already has 45000 bytes in RAM - so a (potential) extra 2K in the TCP buffer isn't really of any significant benefit ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ooops ... that's right indecision

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems you've biffed the design here, and you're lookig for a fix you can implement on your current platform.

 

I would suggest one or some of the following:

1. Reconfiguring the sensor to reduce it's sample rate enough to meet the 3min logging duration requirement.

2. Simply throw away 3 in every 4 samples. That'll get you to 4*50s (3½min).

3. Implement a data compression algorithm.

 

No 3. is by far the most difficult way but potentially the most fun to investigate. BTW: If you go this way; develop the code as a PC program with 3min  blocks of real data with the greatest variation you can achieve.

 

PS As I write this I'm listening to 192 kbit/s 48kHz audio (MPEG2) that originally would have been 1411.2 kbit/s  (2*16*44.1k).

Can I hear that there are missing bits ? Yes!

It it good enough for my purposes? Yes!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:

It seems you've biffed the design here, and you're lookig for a fix you can implement on your current platform.

 

I would suggest one or some of the following:

1. Reconfiguring the sensor to reduce it's sample rate enough to meet the 3min logging duration requirement.

2. Simply throw away 3 in every 4 samples. That'll get you to 4*50s (3½min).

3. Implement a data compression algorithm.

 

No 3. is by far the most difficult way but potentially the most fun to investigate. BTW: If you go this way; develop the code as a PC program with 3min  blocks of real data with the greatest variation you can achieve.

 

PS As I write this I'm listening to 192 kbit/s 48kHz audio (MPEG2) that originally would have been 1411.2 kbit/s  (2*16*44.1k).

Can I hear that there are missing bits ? Yes!

It it good enough for my purposes? Yes!

 

 

Thanks for that I will have a look into the methods you mentioned. I do however need data every millisecond.

Why can I not just write the data to the Flash? It is there, it is available, Im just not sure how to do it. I have asked how on a more platform specific forum. I am just a bit puzzled as to why you say I have biffed the design when you dont know my constraints.

Last Edited: Sun. Apr 15, 2018 - 09:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can write to flash; but to achieve the desired rate you need to know:

 

  1. The page buffer size
  2. How quickly you can fill the buffer
  3. How long a write cycle takes

 

If it were my design I might have included a serial EEPROM (24LC256 perhaps). So answering the above

 

  1. The page buffer size = 32 bytes
  2. How quickly you can fill the buffer = (5+32)*9 / 400kHz = approx. 1ms
  3. How long a write cycle takes. = 5ms

 

Is there enough throughput ? At 6ms per 32 bytes - Yes there is plenty.

 

Edit

We're all inquisitive types here and I meant to ask:

What is the application?

What parameter must be sampled at 1ms intervals?

 

Last Edited: Sun. Apr 15, 2018 - 11:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mr Winterbottom, not sure if you read post #8. I mentioned there that I can wait a few seconds to write to flash. I don't need to write to flash every millisecond. Every 40seconds or so I must write to flash to free up the ram. When I do this I don't mind waiting up to even a few seconds.

I have a linear actuator thats reading the position of a damper. The damper is moving in and out very fast and I need to track its movement to analyse what its doing.

Last Edited: Sun. Apr 15, 2018 - 05:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wouldn't deliberately delay anywhere. If you have identified some part of the system to be bandwidth limiting you need to do whatever is necessary to optimize the bandwidth at that point and delaying won't help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
The flash is composed of a number of sectors of 4k each. You have to write a complete sector - not a byte at a time.

 

How do i do this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely there's a datasheet. In my experience flash can usually be written multiple times in the same page but only, of course, 1 to 0 bit transitions. But if you start by erasing the page (to all 1 bits) and then write sequentially this is not an issue. If, however you need to go back and change anything already written then this may be more of an issue and the moment you get to a 0 to 1 bit transition you have no choice but to read out the entire page contents, erase the page, then write the update. (and it's the erases, that usually involve high voltage, that take a REALLY long time).

Last Edited: Sun. Apr 15, 2018 - 05:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

from the Espressif SDK:

 

spi_flash_erase_sector(uint16 sec)

spi_flash_write(uint32 des_adr, uint32 src_adr, uint32 size)

spi_flash_read( ...

 

found on this (swiss [german]) page: http://benjaminmarty.ch/blog/2016/05/03/esp8266-flash-eeprom/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the linear actuator have a mink glove attached?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I remember an episode of The Big Bang Theory that featured a robot hand that performed a similar task. The OPs actuator moves very fast. He's sampling it's position at 1kHz; lets hope it doesn't approach his Nyquist limit of 500Hz.

 

Actually that's so fast you could almost play tunes on it.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try using F-RAM like this 128K byte IC on eBay:https://www.ebay.com/itm/5PCS-1M...

 

Feel free to post ESP8266 requests.  It is a companion processor to the AVR.  It is cheap and available.  AVR users integrate it into their designs more often than they mix with PICs, which is AVR's new stepsister CPU.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Surely there's a datasheet. 

In this case, possibly not - I have heard that Espressif rely upon "The Community" to do that (unless you're a major customer buying millions of chips) ?

 

Said community is here: https://www.esp8266.com/

 

It would make a lot more sense to have the discussion there - where the experts are, and keeping the information together in one place.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I’d question the use of an expensive fram when there’s a perfectly good 4MB serial flash available. As well, i’d skip the esp8266 and go the esp32- it’s a far superior part.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

especially when that "expensive fram" is only a fraction of the size of the Flash!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bitflipser wrote:

from the Espressif SDK:

 

spi_flash_erase_sector(uint16 sec)

spi_flash_write(uint32 des_adr, uint32 src_adr, uint32 size)

spi_flash_read( ...

 

found on this (swiss [german]) page: http://benjaminmarty.ch/blog/2016/05/03/esp8266-flash-eeprom/

 

Thanks this write-up looks promising. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Since arduino supports esp8266, thrn this might be useful:
https://forum.arduino.cc/index.php?topic=491469.0