There are a few considerations that must be understood when developing with IoT. This page doesn't aim to be an "end-all" list of those considerations, but hopefully it will assist us in building more robust and secure systems.
We recommend following C++ best practices by default, and using Arduino's style guides where relevant. In most cases C++ guidelines will do just fine; however, there will be times when you will need to follow Arduino conventions.
Available memory is potentially one of the biggest concerns when developing for IoT.
|Board||Available Flash Memory|
|Adafruit 8266 Feather||4MiB (1MiB ~= 1.05MB)|
|Adafruit ESP32 Feather||4MiB (4MiB ~= 4.2MB)|
|Arduino Uno||32 KB of which 0.5 KB used by bootloader|
|Raspberry Pi Zero W||512MB RAM|
|Raspberry Pi 3 Model B+||1GB LPDDR2 SDRAM|
A desktop/server environment can generally handle large objects and operations fairly well.
In microprocessor environments, a 50K string, or making lots of copy/new/malloc calls can and will cause a crash. This is due to something known as Heap Fragmentation.
Dos and Don'ts
Stringtypes when possible. It's not that strings are bad, but they come with overhead. Consider what the goal is when deciding between the two. if you're passing bodies of readable/searchable text, consider using a
string; If you don't need the memory management or need to search for substrings, consider using
charas it can be faster and more secure when used correctly.
DON'T carelessly pass raw pointers. i.e. "Dangling Pointers"
DO know your platform! Not every platform supports the same methods and libraries. Desktop/Server environments should have no problem making full use of the Cpp STL; however, only some Arduino boards offer support for the Cpp STL by default, where many might not support it at all.
DON'T use assertions. Failed assertions will exit disgracefully. Prefer patterns that handle errors gracefully, such as returning 'bool' or passing destination buffers.
DO be particularly mindful with memory handling. Microcontrollers inherently have very limited memory capacity, this can lead to fragmentation if we're not cautious.
DON'T be reckless with sensitive information. Using a test passphrase or wallet for trying out a sketch or example is fine. Leaving hard-coded private information in something you plan to share or release is a terrible idea. Consider what the problem you're trying solve actually is and what alternative solutions may exist.
DO prefer use of RTC (real-time clock) modules. Particularly when dealing with signing and network operations.
← IoT Home