I am using a linux box to build the firmware for the photon board but the 128K size of flash is very limited. On the paper it is a great product but without more space it is impossible to make a powerful application. As soon you put in some libraries the code will easly take all the free space.
For other similar platform with cortex M3 processor I successfully ported ( and runned ) very heavy libraries such as sqlite, u8glib and json parsers, but
Is there a way to increase the flash size? the P1 has 1MB of external flash, could that space be used for the user firmware? Is there a way to extend the flash of the photon with microsd?
Sometimes you just have to pick the appropriate platform for your design. You are not.
The Photon is a micro-controller, not a full computer. Eventually it will be insufficient for the task, and the next step as a Maker needs to be taken, such as using a Raspberry Pi as the main processor, with a Arduino or Particle device as a 'Co-processor".
If it won’t fit in the 128K available, either your code needs work or you are choosing the wrong device for the task.
@CAS, though the Due has “half” the flash, it is not running a FreeRTOS environment and managing both wifi and cloud connectivity. To do this, the Photon partitions the STM32F205 1MB of flash to create separate system and user firmare sections. There is no question that having lot of flash would be great but your application may not be suitable for the Particle platform. The whole idea of IoT is to move the heavy stuff to the cloud.
After the succesfull test on the arduino due I though that the photon should be even better with a whopping 1MB of internal storage. They share the technology ( cortex M3 ) and similar specs, so why not. I am just asking why the resident firmware takes quite the 90% of the space ( 896/1024*100 = 87.5) leaving the user only 128kb. It is really a shame. FYI my code for the Arduino Due takes 350KB with FREERTOS8.1, tcp/ip stack, sqlite3, u8glib and tinyAES, but I don't have FOTA.
The whole idea of IoT is to move the heavy stuff to the cloud.
Yes, I agree but the cloud takes energy and time ( I mean radio and network latency ) where a battery operated device does not have.
BTW, I would like to suggest this tool that I will try to add to the makefile:
Maybe could be added to the web ide to give feedback to the where to optimize.
@CAS, The flash is allocated to create a dynamically linked environment which separates the hardware and software layers through a Hardware Abstraction Layer (HAL), thus creating a portability between Particle platforms, something you don’t have to consider on the Due. The primary benefit is that doing an OTA with user code is much faster. I love my Due but I am not seeing it embedded in any products like the Particle devices are designed to be. If you don’t mind the lack of wifi and cloud connectivity (without extra stuff), then I recommend the amazing Teensy platform.
So you are asking to run SQLite on a micro-controller?
That is what we have platform like the Intel Newton, the Beaglebone and many other devices intended to support complex demands.
I am not asking how, I already did it on a similar micro. I am asking why there are just 128KB for the user and If there is a way to overcome to this problem, maybe using external storage on spi or microsd.
In a nutshell, if you never plan to update your product over the air and are prepared to always update your application and system firmware via USB, then you can build an application that is 384K in size. Note that this isn’t a supported configuration out of the box, you would need to take several steps to enable this. but it’s technically possible.
With that said, have you tried to compile these libraries? I’d also suggest that there are other platforms more suited to running heavier applications, such as the Raspberry Pi which would give you much more administrative control.
@CAS, at this time there is no way to overcome this “problem”. The Photon firmware architecture creates this limit. There may be a way to get an extra 128KB of flash by retasking another part of the flash but only @mdma could say for sure.
Good question! I believe this is a side effect of a few things, the flash page allocation on the micro itself, and the size requirements for things like the wifi radio driver / soft-ap and other features. If memory serves me the page sizes on the device are 128k, and can’t be erased in smaller increments. Like Mat mentioned, we also set aside space to receive OTA updates, store some configuration data, and hold a factory reset image.
I like the idea of freeing up more space! I think the cloud code isn’t the big offender here, pieces like Soft-AP take up a ton of space (hosting dhcp and web servers, etc), or disabling the OTA backup region, etc.
Personally I’m going to keep lobbying us internally to make a “big-photon” with a ton of extra flash space and ram.
In my application the SoftAP will be never used, and probably i am not the only one. It would be great that it could be possible to sacrifice some functionalities in order to get more space, maybe with a modular build. Keep in mind that you are targetting your product to skilled engineers that they have no difficulties to connect an usb cable to the board and reprogram it to a factory state. You can also release a native application to do so.
I hope that in the Electron where the softap is not needed there will be more space.
What are the downsides of having more flash on the Photon? As someone that isnt a engineer besides a slight cost increase what are the downsides?
It would be interesting to see the local Particle Dev application support out of the box local building of the platform, with features to flash the entire Photon with a modular design (eg. dropping the SoftAP)
I can imagine due to the architecture it would be hard to change the web build environment for such scenarios, as I believe the architecture only sends the user code which would make changing the core code impossible?
The assumptions above about SoftAP taking space isn’t correct. The largest part of the stack is the WiFi firmware for the 43362 chip, which takes ca. 240 kBytes of flash. This, combined with a flash page size of 128k makes moving things around very tricky.
For more flash storage, there are these options:
use a P1, which features 1MB of external flash. This can be used for storing data, but not executable code.
Expand the application flash region to 384K and forgo OTA updates (updates applied via USB only.)
Go bare metal and fully reprogram the device. Here you get the full 1MB of flash.
