@RWB, actually it’s more like 820 images! I haven’t looked at the TinyFlash library enough to say whether it can handle a larger flash or not. However, another library could be used instead since SPIFFS uses callback functions for the flash interface.
At present, the demo app compiles to less than 30KB (28524) of code including the SharpMem, HttpClient, TinyFlash and SPIFFS libraries. As you know, most of the RAM used is consumed by the display buffer, which on a 400x240 unit is 12KB of RAM. I’ll print out freeMem in the demo to see what it reports.
@peekay123 Yea 1MB for images should be plenty, but while we are at it, I think it would be beneficial to make it so we can use larger Flash chips for future task if it’s not to much extra work.
If we can then I will just throw in some 16MB or larger chips on the devices I’m building so I have that room in the future if I need or want to use it.
We’re leaving Fonts data as it is stored on the Photon/Electron’s memory correct.
I don’t really like SD cards for some reason but is it just as easy to push this data to an SD card as it is an SPI card or no? I think the SD cards are more power hungry?
Can SPIFFS be used on an SD card?
Just asking, so I have a better understanding of all these options.
It sounds like you have everything basically working with the SPI chip now correct?
Let me know what I owe ya when you’re done. I don’t like to ask anybody for anything without offering something in return
Yes, since I would need to rewrite the Adafruit_mfGFX library (aka lots of work). Font data would need to be stored in the correct format to work. The display of text would be slower.
Data could be stored on an SD card as it is since SPIFFS uses calls similar to the SDFat library. SD cards use more power when active but also had a low power mode they switch to automatically.
SPIFFS is optimized for flash IMO. The SDFat library is optimized for SD cards so will be much faster.
Everything IS working with the SPI Flash chip. Given how often you might download data, I believe the SPIFFS/TinyFlash combo is good. I will be doing some performance measurements tonight. If you want to ship me some 16MB chips (2), I can use the last 2 adapters boards I have and work on adapting the code.
Does this mean that any size SPI Flash chip in the same package would work? I guess I did not buy the Winbond specific flash chip.
I can throw in some larger chips for testing if they are available and you think they will work. Might as well see what works and what doesn’t while we’re at it
@RWB, the larger chips have some fancy features that may be be exploited. However, if you send pairs of each you want to try, along with adapter boards, I’ll give them a shot!
These devices use NOR flash which is different than NAND (I think!) used in the ISSI devices. I can’t vouch for how well they will work with the existing libraries
@peekay123 Mouser has the memory chip your testing now listed under NOR flash. I couldn’t find any reference to NOR or NAND in the datasheet for the chip, so I was not sure.
@RWB, the code I wrote is very specific to the SharpMem monochrome display. However, it would be easy enough to expand the bmp parser/drawer to use 16bit RGB565. By using a librarie’s drawPixel() function, the code can be made generic enough. However, the parsing/drawing portion of the code would need to be unique for each bitmap type since the BMP data describes all that data in its header. What do you have in mind?
Right now our product is using the pixels library so that we can use anti-aliased fonts and compressed bitmaps (at the time all images have to be stored on our P1). To simplify this images would not need to be compressed if they were on a SPI flash. We are using the ILI9341 driver and hardware SPI.
I realized that this Pixels library is not used by many people so support is probably limited. But we found it extremely valuable to utilize the compressed bitmaps and anti-aliased fonts.
This draw functions are below:
Compressed BMP line 751
raw BMP line 673
@peekay123 For now, I only need the SharpMem to work with the SPI flash, but I can see using this extra memory for images to be displayed on the RGB panels.
I can also see this additional memory holding Audio files that can be downloaded and played via some sort of Audio chip.
I can see uploading jpg image files to be used with color LED displays.
With 1 or half a Gig of memory, you could easily upload full video files if you have an LCD Display that can decode video files. I think that would be possible the Photon can download the video file to the SPI flash memory.
I imagine a marketing display using a large LCD screen or RGB panel connected to a Photon where you can track customer interaction live, gather potential customer info like phone numbers or email address, plus have the ability to update the images, or marketing videos at any time. I can see this being used by businesses for more effective marketing.
Being able to easily and remotely update the Photon + up to 1Gig of external flash memory opens up a lot more opportunities than only having the 128K of Photon memory to work with
To sum it up I see the other file formats being added as time goes on as each one is needed or requested by the people who are needing the support for their particular project like what @wesner0019 is asking for right now.
The reason I choose the larger 1Gig memory card is just to prove it can be used and that it works reliably. I will not ever need that much room for the Sharp display, but I know I can use the extra memory for other things as different needs or ideas come up.
@wesner0019 I originally picked the P1 because I also wanted to store data on its extra 1MB of memory but what pissed me off what that you couldn’t update the 1MB of extra flash on the P1 along with the Firmware update
Now we have a way to do that. Plus now you can use the more available Photon instead of the unavailable P1 module and add more SPI flash memory for the extra $2 price difference between the P1 and Photon modules.
I’m very happy we now have a solution to update the external SPI flash at any time. I think it opens up many new opportunities like what your already talking about.
@RWB, having the external storage, whether its a flash chip or a microSD, can be very useful. With device sizes now being so large and so cheap, file compression is no longer critical. Having a file system to manage these files is absolutely a must and both SPIFFS and SDFat do a great job for each storage device. Streaming audio from a file is definitely possible though I can’t speak to streaming video due to the bandwidth requirements.
The SDFat library is time tested and robust. More testing of SPIFFS may be necessary but it seems like an excellent library so far.
@peekay123 I see the SDFat library as a great solution with higher data transfer speeds.
The main revolutionary feature for me is the ability to easily load this external memory by simply providing the web link to the files your wanting to store on the card. Up until now, as far as I know there has been no easy way to go about doing this I remember asking for a way to update the extra 1MB of flash on the P1 and finding no way to do it.
So are the main differences from your point of view on the SPIFFS vs. SDFat libraries?
I like how easy it is to change out SD Cards to increase storage capacity + the ability to load the SD card from a laptop which would be beneficial for Electron users.
It sounds like you can run SPIFFS on the SD card also, so I’m struggling between thinking an SD card is better vs. 1Gig flash chip since the SD Card can just be switched out.
I wonder which solution is more efficient power wise?
