@RWB, I’ll be testing some Particle.function() code to command the photon to fetch a specified file into flash. Other commands could be used for display sequences, listing files, etc. I’m just bantering ideas about.
The main difference between the SDFat and SPIFFS is that SDFat is optimized for SD and has been around a long time. The author has also created a version for Particle which uses SPI DMA for maximized speed. I don’t know enough about SPIFFS but it seems to depend on the user to optimize operation via callback functions. The biggest difference with an SD card is the mechanical aspect as it is designed to be removable whereas chip flash is not. The environmental conditions (shock, dust, heat, accessibility,etc.) should dictate which is best for the application. As for power, both provide low power operation though again, the application will dictate the best solution. There is no “one shoe fits all” solution here.
@peekay123 Yes was thinking about the SD card + vibration / shock and how that could cause possible issues instantly or over time with contact loss potentially just like we have heard happen with the Electron SIM cards.
For the product I’m building Heat can get high so if that is not good for SD cards, then the chip solution is better.
I guess the best way to do it for my Electron-based solutions would be to just add a Photon to the mix also and update the Flash Chip over Wifi Only when we’re talking about downloading MB’s of data.
@RWB, adding a Photon to an Electron seems odd. Why use an Electron if you have WiFi in the first place!! You could, instead, update the files on the flash using a (read-only) microSD for fast transfer, which would only be used for transfer and removed for normal operation. If you recall, another member had developed a way to upgrade firmware using an SD so you could exploit that as well.
Poor scalability. Spiffs is intended for small memory devices - the normal sizes for SPI flashes. Going beyond ~128Mbyte is probably a bad idea. This is a side effect of the design goal to use as little ram as possible.
So it seems the 1Gbit flash you picked is the max that he recommends. Phew!!
@peekay123 I was just thinking of just using the Wifi as a way to update the firmware & SPI flash knowing it would have to be moved to a location where there was WiFi or a Wifi Hotspot (Like a cellphone with Hotspot) would need to be brought close to the device before updating the firmware & flash memory.
But yes you are right about using the SD card slot for firmware & flash memory updates only. I like that idea a lot actually for Electron situations.
This has me leaning back towards just using the SD card again
Also this whole time I though the 1Gbit flash memory was actually 1 Gigabyte of memory Now I see it’s only 128MB of storage
Considering all the work you have done already getting the Sharp Memory Display working with the SPIFFS file format how much of that time would have been wasted if we just decide to do the same thing but with the SD card using the SDFat library?
It’s looking like the largest flash chips I can find that are under $10 are 128MB. For that price, the SD card solution starts to become cheaper and more flexible when it comes to offline firmware & Flash storage updates.
The only reason we’re using SPIFFS is because the HTTP file download program that @Suprazz provided us was dependent on the SPIFFS library he was using. If I knew that the SD card could also be used, I would have given more thought to which I thought was better.
Now that I know were limited to 128Mb for Flash Chips vs. GigaBytes of memory for SD cards I’m back leaning towards wanting to use SD cards
So how much trouble is it to display Bitmap images stored on an SD card on the Sharp Mem display?
How hard to push the downloaded files from the HTTP links to the SD card instead of the Flash chip?
It looks like you already have the RGB Matrix panels working with images stored on the SD card.
Regardless I’ll cover you for the time you have invested.
Let me know what you think. Hope you don’t think I’m crazy
The SD Card provides the most flexibility plus it’s already well supported as you have already mentioned.
I’m assuming that maybe the draw function may be a little bit quicker if the data from the SD card transfers quicker, maybe not though if it’s based on Photon’s processing speed.
I just ordered up 2 SD card breakout boards for testing. I have plenty of 16 Gig micro SD cards laying around the house, so that’s a big plus!
I did learn a few things about SPI Flash along with the different NOR and NAND Flash technologies, and power consumption levels between the different sized chips. So that was not time wasted for me either.
@wesner0019, the guy to talk to about flashee eeprom library is @mdma. However, as you know, the SPIFFS library works very well with low cost external flash.
Ok thanks I’ll ping him. The reason I’m looking at this is because we’ve already developed firmware for the P1 but we are developing the same product with the electron and need external flash with the electron. I was looking at maintain the firmware as much as possible between the two. As we are at 128K program limit.
@RWB, I got the SDFat version of the code to work. It was easy to switch between SPIFFS and SDFat but when it came to drawing pixels to the display, nothing worked. It turns out that every SDFat SPI operation resets the SPI clock, making it too fast for the SharpMem display. Resetting the SPI clock before drawing a bmp row of pixels fixed the problem. With SDFat, the display time for a full screen is 158ms. Another thing I noticed is that compiled code is smaller by about 7KB with SDFat vs SPIFFS.
I also received your care package. Do you still want me to look at using these larger flash chips with SPIFFS?
I was thinking the SDfat would hog more memory than Spiffs but it’s really nice it’s the other way around.
The SD card solution should serve all my needs now and into the future so I have no need for the SPI flash chips or Spiffs library.
The SD card breakout arrived but I am out of town for a few days so can’t text anything till I’m back.
If I want to also use the lower resolution 4 inch sharp mem display does the buffer need any modifications?
You also have the http downloading to SD card working? How does it handle a download error or WiFi loss during download? Will it show an error or retry automatically if the data transfer does not complete? I’ve never used it before.
The quicker write to screen times are great. What do you use to calculate these times?
@RWB, the lower res display will work fine with the BMP draw code and SharpMem. There is no fancy timeout, wifi loss or other detection/recovery in the http code right now. I would need to spend more time to do add robustness to the code.
If you build any boards, you should consider a “captive” SD socket instead of a push-in/push-out type. The timing is measured from the start to end of the bmpDraw() function using a millis() counter. I will be doing sub-timing to see where the time is being spent though I have a pretty good idea already.
@peekay123 No worries about the Http timeout or incomplete data transfer warnings, I was just curious and have no idea if something like that was standard or not.
I guess I could code something that would verify the file size after download and then trigger the download again if it’s not correct.
I will look into Capacitive SD sockets for sure. I’m sure make military grade or robust versions for rugged use scenarios.
I thought you may be using a scope to read the time between the start and end of the write to LCD. Using the milli timer makes more sense.
Now I see it’s only 128MB of storage 
