More user application memory needed


#21

For non-executable data like fonts/bitmaps etc…I recommend you store these outside your application, in a different memory region. Here are some options:

  • use a P1, which has 1MByte of external flash

  • add your own external flash to the photon

  • store the data in the memory normally used for EEPROM emulation on the photon. This gives a total of 80Kb. The start address is at 0x800C000 (see the memory map.)

  • there are other regions you can write to, such as the OTA region, although beware that the system will overwrite any data stored here next time an over the air update is performed.


#22

Can executable data be placed in the 80Kb EEPROM Emulation area if that area is not needed by the project?


#23

In principle yes. I have not tried it to be sure, but I would hope that if your project doesn’t reference EEPROM then the data is left alone.

You could put executable content there, but you’d have to do the linking yourself. That’s why I suggest using it for non executable content, since that tends to be simpler.


#24

I know I’m late but 80k for the eeprom emulation? THe eeprom is just 2048 bytes so why a such big difference?


#25

The EEPROM emulation uses two flash memory sectors. One is 16K and the other is 64K. The flash memory is erased to 0xff bytes, and you can only write 0 bits to individual bits. You can’t set a bit back to 1 without erasing the whole sector. In order to do the EEPROM emulation, two sectors are used, and when a sector runs out of free space, all of the data is copied to the other page, then the original page is erased. It just happens that the sectors are different sizes because that’s what was left over after allocating everything else. Even 16K is much bigger than the 2K EEPROM emulation because of overhead and you want to go as long as possible between sector erases to reduce wear on the flash and also processor time, as it’s a lengthy operation that runs with interrupts disabled.


#26

good to know! thanks for the details


#27

When you recommend HMI systems such as 4D Systems or Nextion, how do you handle OTA updates? Do you just always assume that the firmware on the HMI system is static but you can always update the Photon? Or do you try and use the Photon to load updates onto the HMI display?


#28

@incorvia, I don’t believe the Nextion can be reprogrammed via its serial port though I can’t vouch for the newer versions. @RWB indicated that in discussions with 4D Systems, it may be possible to remotely flash new code to the display though this has not been tested.

The biggest challenge with updating HMI displays is the size of data that needs to be transferred to update them, limiting these to WiFi or other data-limited protocols. The cost of hundreds of megabytes over cellular may be prohibitive.


#29

@Peekay123 The 4D systems displays can be updated via just the data on the SD card but that leaves you needing to figure out a way to get that possibly large amount of data onto the SD card that the Photon and 4DSystems display would share.

I tested the FTP code over the weekend for downloading and it was not up to the task of downloading files over 100MB reliably or consistently so the code I was trying can’t be relied upon for getting data from the web onto the SD card.

The max download speed was approx 140-150kB a second, so that’s 10 mins per 100MB of data. Doable but not ideal, but updates would be rare.

@rickkas7 Has some code one here for downloading to an SD card also so I need to try that next. My goal is to be able to update the 4D Systems display over the web if possible.


#30

@RWB, I was not aware a 4D display and a Photon could “share” an SD card. Do you have set of instructions from 4D you can share? The FTP code you tried may not have enough exception handling to properly maintain a long connection or the FTP server is part of the problem. A direct TCP stream would certainly be better.


#31

@peekay123 There are no instructions from 4D systems other than how to get the firmware to load from the SD card.

I assume we can connect the Photon & 4D systems SD card to the same SD card pins and get it to work correctly? I figured I could get them to work together one way or another if I could get the Photon to reliably download data from FTP.

And I think your right about the FTP code not having enough exception handling to maintain a long connection. It would stop prematurely even on smaller sized files so it was all over the place on when it would download 100mb and when it would stop at 4 MB before it was done using the local server setup.

Are there any ready to work libraries for the TCP stream downloading you are referring to?

Also, can this code be used on a Photon or Electron only for FTP downloads?


#32

I believe you may have misinterpreted the comments from 4D. The ONLY connection to the SD card is onboard. You want to run the display via VisiGenie which creates all assets on an uSD card which you manually insert into the 4D display to update it. 4D support would say that is possible but not directly transferring new firmware to the display’s uSD. I haven’t been able to find any Appnote to say this is possible. The closest thing I found is having the display in serialcommand mode where a host (aka Photon) could do file operations on the uSD via the host Serial connection. I’m not sure this works with VisieGenie configurations.


#33

Your right but I am planning on using a custom one of these to extend the SD card pins to a custom PCB with a uSD card socket where the 4D display and Photon can share the uSD card.

The Photon would only access the uSD card when I need to run the Update command. I figured I could cut the 4D system display off while updating data to the uSD card via the Photon if needed.

Here is the forum post where others are talking about doing this:

By putting the new files directly on the uSD card we can skip the serial UART data transfer from the microcontroller to the 4D display which would take way to long anyway.

Make sense?


#34

@RWB. interesting. I’ll have a closer look at the forum post. :wink: