Challenges: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
=Challenges - How to Overcome Hardware and Software Limitations= | =Challenges - How to Overcome Hardware and Software Limitations= | ||
The Arduino hardware is pretty limited - you get | The Arduino hardware is pretty limited - you get | ||
* 32kB of unmodifiable (at run-time) flash memory for the program | |||
* 2kB of volatile SRAM memory for variables, and | |||
* 1kB runtime-programmable, non-volatile EEPROM memory for data | |||
* Updating device configuration (ie, MQTT/ WLAN) - ideas: via SD Card or via writing config data to EEPROM | That's it. Pretty much any icon on your Linux, Apple, or Windows desktop consumes more space. | ||
This is a challenge to your software you already have to address at compile time. It gets potentially worse at run time. Processing network data requires buffers, and buffer sizes may be variable. During operations you may want to change the configuration of the device. If you want do to that without re-programming the chip, you need to use an interface of some kind (wireless, SPI/ I2C, or SD card). | |||
* Updating device configuration (ie, MQTT/ WLAN) - ideas: via SD Card (which is enduser-friendly) or via writing config data to EEPROM | |||
* Updating device code - via ISP, or - ideas - OTA with the Arduino uploading a program to the ESP, followed by the ESP flashing the Arduino | * Updating device code - via ISP, or - ideas - OTA with the Arduino uploading a program to the ESP, followed by the ESP flashing the Arduino | ||
[[IoT with AME|Home]] | [[IoT with AME|Home]] | ||
Revision as of 12:58, 15 June 2018
Challenges - How to Overcome Hardware and Software Limitations
The Arduino hardware is pretty limited - you get
- 32kB of unmodifiable (at run-time) flash memory for the program
- 2kB of volatile SRAM memory for variables, and
- 1kB runtime-programmable, non-volatile EEPROM memory for data
That's it. Pretty much any icon on your Linux, Apple, or Windows desktop consumes more space.
This is a challenge to your software you already have to address at compile time. It gets potentially worse at run time. Processing network data requires buffers, and buffer sizes may be variable. During operations you may want to change the configuration of the device. If you want do to that without re-programming the chip, you need to use an interface of some kind (wireless, SPI/ I2C, or SD card).
- Updating device configuration (ie, MQTT/ WLAN) - ideas: via SD Card (which is enduser-friendly) or via writing config data to EEPROM
- Updating device code - via ISP, or - ideas - OTA with the Arduino uploading a program to the ESP, followed by the ESP flashing the Arduino