What is the ram size of Photon for user part firmware is available?


#1

I use an array size is 31200 bytes as an video buffer.After that I was touch by many wired issue.
1.soft ap api stop work,but if I remove one function from setup() it will work,even the function body it is empty soft api not work
2.wired red blink,I do read through the user firmware code and can not find out why
After reduce the array size to 6240,it works.


#2

Hi Ming!
Have you read the datasheet for the Photon?
https://docs.particle.io/datasheets/photon-(wifi)/photon-datasheet/

“STM32F205RGY6 Flash Layout Overview
Bootloader (16 KB)
DCT1 (16 KB), stores Wi-Fi credentials, keys, mfg info, system flags, etc…
DCT2 (16 KB), swap area for DCT1
EEPROM emulation bank 1 (16 KB)
EEPROM emulation bank 2 (64 KB)
Device OS (512 KB) [256 KB Wi-Fi/comms + 256 KB hal/platform/services]
Factory backup, OTA backup and user application (384 KB) [3 x 128 KB]”


#3

It is about flash.


#4

Have you tried the forum search?


Did you try System.freeMemory()?

15KB in itself should not be a problem, but how much RAM is the rest of your code using?
Can you transfer some immutable data into flash?


(Update: After your edit the numbers have changed from 15650/15610 to 31200/6240 which is a massive change and makes me think where did the original figures come from :wink: )


#5

Yes I have seen this also. With some of the recent releases the amount of free memory has been reduced, so if you allocate sizeable blocks of memory (I was allocating about 18k), the amount of free memory obviously also goes down. The upshot of all of this is that if you start Soft AP (which uses a LOT) of memory your device will run out of memory and fault. I reworked my code to drop my 18k buffer to a 5k buffer and was able to run soft AP with no problems.


#6

Sorry,I made a mistake.
When use 31200 bytes It is not work,reduce to 6240 bytes It works


#7

How much RAM we should keep for heap and stack?


#8

I am using latest system firmware too,I need a large array for a color screen.


#9

IIRC the stack is set to 6KB but if you are using SW timers the timer thread needs another KB and when using the Application Watchdog that also needs some stack space for itself and the required heap space is hard to estimate as the demand is highly dependent on your actual code.

But tuning your program to the very limit is hardly a good idea as future system updates may nibble away some of the available RAM forcing you to stick with an older (potentially buggier) system.

BTW, what kind of color screen do you intend to drive and do you actually need a pixel buffer for it?


#10

The color screen blink when I refresh it,I have to translate 9bit each time so I have to use I/O not SPI to send data to screen,I am trying to use a buffer to fix blink issue.

Is there a way to keep blink red when an hard fault triggered?I have to do other work and can not keep an eye on led for a long time


#11

You can’t keep the device in panic mode, but you can check the reset reason when the device comes back from a crash.

I don’t know where your blink issue exactly comes from, but there often are ways to avoid that effect by re-thinking/rearrange the actual screen updating.
Blinking often comes from clearing and redrawing areas which don’t want to be redrawn but rather overwritten. For example, if you have “mutating” text, you could clear the background and then draw the text ontop of the cleared area - which would lead to flickering - or you better just select the correct backcolour for the text and just overwrite the previous text without clearing it at all - this won’t flicker.


#12

Hi ScruffR, can I just clarify something you said.

if you are using SW timers the timer thread needs another KB

Is that if you are using SW timers that each timer thread needs another 1 KB?


#13

Yes, but there only is one timer thread for all timers to share.


#14

Understood. Thanks for the clarification!