So, my current thermostat project is running out of flash space as I add fancier control algorithms. Even though I’ve already stripped out everything I don’t need, including the Serial and UsartSerial, TcpServer and client, USB connection stuff, Tone, I2C, SPI ,Servo, and the EEPROM libraries… I’m hoping that the Photon will solve this problem in the future. So, any updates on how much of the Photon’s 1MB will be available for user code? Thanks!! Looking forward to trying it out…
It’s still early days, but we hope to offer close to 128k for user code. That size allows room for the system code (512k) plus factory default and OTA backup.
In cases where developing locally and don’t require OTA update or factory reset, it may be possible to offer more.
1 Like
Hello, 128k is not much more than a current 108k on core, and it’s really NOT MUCH !!!
Could you please dedicate as much space as possible for the user code ?
Is there any external flash in the Photon ? In Zach’s announcement there is info about external flash in P1,
how about Photon ? Core is using external flash for default, backup and OTA, I was hoping it’s the same in Photon/P1, and most of the 1MB internal flash would be for user code ! Could you clarify this ?
@kefir135 The current core only has ~20K for user code. The current hardware has 128K flash, of that flash after the bootloader and firmware you only have about ~20K. So as @mdma states we will be moving from ~20K to 128K of user code space.
Now - I still wish there was more, especially if we have an LCD display with graphics. We will want more to store our graphics in flash and they can get big 
May be an option to attach external flash and put the OTA firmware, factory default firmware and the WiFi blob in there?
@mtnscott, good point. If the real user size is 128K then it is a huge step up given that FreeRTOS is in there along with wifi/cloud management. Mind you, more is always better 
@mdma, is @mtnscott right about the sizes? Is the 128K the space after the base core code (which is like ~32K with an empty sketch right now)? Or is that the total maximum program size (which is 108K)? I realize that it may be too early for these questions, but I’m just curious. Thanks for all everyone there does!!
@mumblepins If you compile an empty sketch the flash used for the firmware + empty sketch = ~75K That leaves you with approximately ~35K for user program.
I did some work previously about what’s available -
2 Likes
Yep that’s correct, 128K is the space for just your app, not the system code. The system code is 512k, so it’s kept separate to avoid needing to store multiple copies of that redundantly.
We’re looking at about 3-4x the space for user code on the photon compared to what is available on the core. I’d love to offer 256k but there are lots of technical hurdles here to overcome!
It’s still early days, and things may change, but let me assure you we will be doing as much as we can to give as much memory as possible to the user!
4 Likes
@mdma Currently when we compile on the Core any library function that is already referenced in the firmware is available for the user code at no additional flash cost. Will that also be true for the Photon with it’s 512M of firmware space or will we be including the library functions with our user code? - meaning that our user code size could grow dramatically with the Photon vs the current core.
@mtnscott, when the compiler links the final Core code, only the functions used will be included. So if you never use Serial2 or sprintf for example, that code will not be linked in. The user app is not the only code using libraries since the firmware “main()” is also used. This is why the minimum code size is always 74KB or so.
In the Photon, FreeRTOS will be used, requiring a certain minimum resources (flash and RAM) to operate. On top of that will be the minimum firmware requirements to support wifi and cloud operations. Finally, the user APP will be added for the final compile. So the 512KB referred to by @mdma is the space used by the “kernel”, separate from the user APP and possibly being flashed separately (and only when it changes).
Based on everything I have seen so far, I would not be surprised if the Spark Team creates some compile flags that allow a user to omit cloud connectivity entirely while leaving “raw” wifi operation since so many members have opted to go that way. EARLY DAYS!!! 
Yes, today the final core code includes the firmware.
which is implied by your first statement.
This is probably what I wanted to know... If in fact the user code and firmware are compiled & linked at the same time any library function used by the firmware will not need to be included again for the user code. For example - lets say that the function atoi takes 256 bytes of flash. If atoi is called by the firmware that 256 bytes are allocated from the firmware space (currently 74KB) so the user app can call atoi and no additional flash is needed [TODAY]. But if the Photon implementation requires the firmware to be compiled, linked, and flashed separately from the user app then that same 256 bytes will be allocated in the Firmware AND in the user app.
In a nut shell - if my app today takes 8K of flash (calculating based on the firmware being 74K and total size of elf file being 82K) With the photon it could be either 8K or 8K + library functions.
It would be interesting to know is how much of the 74K of firmware is system libraries.
I was just seeking clarification on this.
@mtnscott, I believe the goal would be to have a single instance of any library. If the “firmware space” is separated from the “user space” then the compiler will need to keep an object link pointer file so that when the user app is compiled, the correct pointers can be used for the firmware-based code. This suggests to me that:
- The firmware is flashed along with the user app to ensure firmware library reference “correctness”
- Or, like the Core, the firmware and user App are compiled together and flashed as a whole,
- Or, via some script, the compiler identifies the firmware version and links the correct version-specific files
- Or, I don’t know what the hell l’m talking about and all this is hot air out of my butt
1 Like
YES YES YES YES!!! Too bad I can only hit like once!
Buzzing conversation! I like that. If I may clarify a few points:
- the system firmware and user firmware will be separate. When you call system functions, there will be no extra cost, since these are already present in the system firmware.
- When flashing the user firmware, the system firmware may also be updated if it is not at a minimum version required.
- libraries, e.g. neopixel, webserver, flashee, are part of user firmware. They don’t take up so much space compared to the system firmware, so 128k of user firmware space is still a lot! And we hope to open up 256k or even more for user firmware in some situations.
- the photon will be awesome!
@mtnscott, on your query regarding the 74KB allocation, I would say it is ALL system libraries except for the code in main.c. That is because the (current) compiler configuration assumes wifi and cloud connectivity so all functions required by that are linked in. There is currently a (experimental) branch of the master repo (feature/hal-no-cloud) that will compile without cloud connectivity, reducing the code in size somewhat. The question is how much do you remove before it just becomes a dumb processor like an arduino?
With FreeRTOS, it will be interesting to see if wifi and cloud connectivity are implemented as “threads” or “processes” and if the user can create their own threads instead of just setup() and loop(). If designed correctly, the entire set of cloud objects and threads could be “disabled” and if desired, not compiled in. An RTOS opens up some interesting possibilities (and challenges) 
@mdma, the question @mtnscott had was if, for example, the SQRT function is called in the firmware (pulling in the code from the math library) AND the user app also calls the SQRT function, then when the user app is linked, will it reference the firmware SQRT function or will it link in a new copy?
1 Like
Dude, that goes without saying! And with guys like you, BDub and the rest of the Spark Team, like, no kidding!!! 
1 Like
I guess I am specifically interested in C and C++ system libraries. Currently with building firmware + user code any C/C++ system library function that is used by the firmware is effectively 'free' for the user application.
I would like to know if that will be true for the Photon, will there be something like a linker map that goes with the firmware that allows the linker to resolve any system calls that are already linked and present in the firmware such that the linker will not include it again separately in the user application.
@mtnscott, I believe @mdma has given use the answer here:
- the system firmware and user firmware will be separate. When you call system functions, there will be no extra cost, since these are already present in the system firmware.
- When flashing the user firmware, the system firmware may also be updated if it is not at a minimum version required.
So, YES the user code will reference firmware code without duplicating it. If the user code references firmware "features" that are newer, the firmware in the Photon will be updated along with the user code. 