Bmp on P1 external 1Mb flash

Does anyone know if .bmp pictures (to be used for the mfGFX library) can be stored on the 1MB external flash on the P1? If it can can you offer clues on how to do so.

Thanks,

@wesner0019, you can use the amazing flashee-eeprom library to store pictures to the external flash. You would need to write code to read the bitmap from eeprom, parse and convert the image to a format compatible with the display library, possibly store it to a display buffer then show it.

I recommend, however, to do the BMP to raw image data conversion PRIOR to storing it in external flash so it is easier to retrieve and display. :smile:

@peekay123, thanks, Do you know of any tutorials on how to use the flashee library? I looked at it briefly and it looks to be really complete

@wesner0019, not sure about tutorials but there are LOTS of posts in the community that can help you.

@wesner0019 Did you ever get the Bitmap images stored on the P1’s external memory?

@RWB, on the Core it was possible to dump data into its external flash via DFU-util. I’ve pinged the Particle Team to see if the same holds for the Photon.

Read/Write to the external flash on the P1 is working via the interface found in the spi flash library.
However the flash can not be accessed via dfu-util due to some missing parts in the bootloader, and I believe this should be looked into for the next patch.

@jakeypoo, is there an issue for this in the repo? If not, can you please post one.

@peekay123 Thanks for looking into this.

Have you ever tried the spi flash library mentioned by @jakeypoo for accessing the P1’s external memory?

@RWB, the flashee-prom library is available on the IDE I believe. I have not had occasion to try it yet but from the many topics I’ve seen, it works quite well.

The issue exists :sunglasses:

@peekay123 @jakeypoo @ScruffR @bko @Hootie81 @wgbartley

Is the data that is stored on the P1's 1Mb of extra flash erased every time you update the P1 with new code?

Also if we can't easily store data on the P1's extra 1Mb of flash during a OTA update then is there possibly a easier way to send data to the P1 and have that data stored on that 1Mb flash chip?

Like how could we send a Bitmap array to the P1, and then push that data onto the Flash Chip?

Do you think the best way to do this is as recommended in this post by Zachary? This is way beyond my pay grade but I'm dying to be able to remotely update the images for the LCD screen graphics that would ideally be stored on that 1Mb memory chip.

@RWB, step back a bit:

  1. The external flash on the P1 uses SPI and (at this time) cannot be programmed any other way than through an app running on the P1.
  2. Using flashee-prom in the APP is a great way to interface with the external flash
  3. You cannot OTA directly to the external flash
  4. The external flash is much larger than the available user code flash space (1MB vs 128KB). So you can’t flash the entire 1MB in one run. So “chunks” would be required and custom HAL code!
  5. The external flash is not erased or affected by the OTA, only the user app

You could program the external flash by setting up an SPI micro-SD card with the “raw” data to transfer and write an app that reads the data and flashes it over. Or, you could write an app that uses TCP and transfer/flash the data packet by packet. That also means you need an app on you PC to do the transfer.

1 Like

@peekay123 Thanks for the reply and confirmation that the 1Mb of flash is not affected by the OTA. That’s good to know.

So for this challenge the SD Card direct manual update & direct manual PC transfer is not allowed. It has to be a total wireless, hands off update from headquarters.

Based on what I’m learning the only way to accomplish a total wireless write to the P1 is to do the following:

1 - Create a function on the P1 that would start a data transfer that would store the transferred data on the 1Mb of flash memory.

2 - Custom HAL code would need to be written to transfer a array of data in “Chunks”. It looks like the Core used this “Chunk” transfer method already so at least there is something to reference that actually worked.

Now I have zero idea what the Hardware Extraction Layer “HAL” actually is or does but I know its integrated into the back end of the whole Particle platform. I wonder how hard it would be for somebody who understands how all this works to give us a way to remotely write to this flash file?

I mean is this something that’s really hard to do or just something that nobody has had a need to figure out yet?

Would $500-1,000 be enough to pay somebody to figure this out over a weekend or week? Or is this more like a 5-10k type of job that would require somebody really special to get it done?

Just curious. It doesn’t seem like it should be that hard considering were connected the internet and the data transfer rates are crazy quick when your only talking about 1Mb or less.

@RWB, if you don’t need to have COAP on the data transfer you could just use TCP that you enable/disable with a particle.function so no need to modify the Hardware ABSTRACTION Layer :wink:

2 Likes

@peekay123 I don't care how it works as long as it works :smiley:

Do you think you could make this work using a Function that enables/disables TCP?

From what I seeing TCP seems to be a error checked way of transferring data over the internet which should keep us from sending a incomplete data array.

TCP provides reliable, ordered, and error-checked delivery of a stream of octets between applications running on hosts communicating over an IP network. TCP is the protocol that major Internet applications such as the World Wide Web, email, remote administration and file transfer rely on. Applications that do not require reliable data stream service may use the User Datagram Protocol (UDP), which provides a connectionless datagram service that emphasizes reduced latency over reliability.

One a scale of 1 -10 where do you think getting this working via TCP falls?

I think it would be great to be able to have a LED/LCD screen that we can remotely reprogram without any user intervention.

Here is 1 example of a sign with many bitmap image arrays that could benefit from the ability to update over WiFi. I'm more interested in updating the look and feel of the user interface of equipment using Sharp Memory LCD screens which tend to have decent sized image data arrays.

I looked in different area but couldn't find if the Electron will have this extra 1Mb of Flash storage or not. Would this same TCP data transfer feature work with the Electron also if so?