I am using the STM32G0B0CET6 MCU and my hardware is already designed with interfacing the MC60 for radio communication. Now I want to port the AWS freeRTOS with including all libraries but am confused about memory. The current MCU is available with the 512KB flash and 144 RAM and its security product. Is it possible to successfully port AWS RTOS on STM32G0B0CET6 without facing a memory issue or without using the networking processor?
My question is suppose my application is using the 60KB RAM so it is sufficient to run AWS RTOS on the current MCU?
The FreeRTOS Kernal itself has a minimal memory requirement, and since FreeRTOS is actually part of the application that is using it, if you have measured the memory requirements of that application, you have included the requirements for FreeRTOS in that.
Remember, programs don’t run within FreeRTOS, but FreeRTOS runs inside your programs and controls the tasks within that. It isn’t an “Operating System” in the manner of Windows or Linux which are outside the programs that run under them, but a “threading” library to allow a given program to become multi-threaded
There is an FAQ on the kernel’s memory requirements, and documentation pages for individual libraries provide nominal code size measurements (eg see the code size table for coreMQTT on this page).
RAM memory requirements are more variable that code memory requirements as RAM usage depends on your configuration. For example, up to a point, TCP/IP throughput will increase as you increase the RAM it is able to use for buffers and the TCP window.
For an IoT application, TLS dominates both code and RAM size requirements - so start by looking at your chosen TLS stack. We have integrations with mbedTLS and WolfSSL. You can also look at a featured reference integration as a reference point - although these are not necessarily optimized for RAM usage and may have more functionality than you require.
If your device will use a radio, and memory footprint is of concern, then consider using one of the available AWS IoT ExpressLink modules. Those offload connectivity, secure storage and OTA to the radio chip, enabling secure IoT connectivity even from tiny 8-bit devices with just a UART required.
Also note FreeRTOS provided heap memory allocators use a statically allocated array as the heap, which by default ends up in the .bss section, which can give the impression the code consumes more RAM than it actually does.
I don’t want to off-load anything in the networking processor. I am planning to run AWS FreeRTOS + libraries (TCP/Ip + corePKCS11 + mbedTLS + Cellular library) i.e complete AWS freertos stack in STM32G0B0CET6 .
I am aware of the code size but I need to get a rough estimation of the RAM uses of these libraries.
I was not able to get them anywhere in AWS freertos Hardware requirement doc.
I have been through the [FAQs] link as well.
My hardware specs, Flash size - 512KB (this is ok! ) SRAM Size - 144 KB (Need help for calculation)
It really depends on the project. I have built FreeRTOS projects and put them in processors with only 8k RAM and 32k Flash, so you CAN build small systems. It really depends on the project requirements.
If the processor is too small to hold FreeRTOS, then the base bare-metal project you could put in it is small enough that the benefits of FreeRTOS probably don’t really help.
I agree with @richard-damon here. It depends on how you configure your project.
As @rtel pointed out - if you want high performance from the TCP/IP stack, you must throw some RAM at it (up to a certain point after which there will be diminishing returns).
If you want to use mbedTLS, then it will also take some amount of RAM (I think it is around 32-35kB with default configuration). If you change the configuration, the RAM footprint also changes.
Apologies if I could not give you a straight answer. But I don’t think there is one - since it all depends on what you want to do with your application and what configuration must you use.
I’m not sure if the qgsm port of the Cellular Library has been tested with your particular modem. Please let us know if you are successful with it or submit any necessary patches on GitHub to get it working.
I would suggest dropping corePKCS11 from your plans due it’s ram/flash requirements (it is meant primarily for mock/testing purposes anyway). You’ll need to determine how to handle private key provisioning and storage in a way that meets your application’s security model.
In general, disabling RSA operations should save you a fair amount of ram
and flash regardless of the stack used. You might also consider an alternative TLS stack since mbedtls is not very well optimized for platforms with extremely limited SRAM. BearSSL is one such option and is used by the espressif ESP8266 sdk.