-
- In 35 years, processing power has been multiplied by 70 while cost has been divided by 38000. It's difficult to imagine what we will get over the next ten years
-
Memory, processing power and application
- In 1969, the mission to the Moon succeeded thanks to a computer with 72 KB of ROM and 4 KB of RAM
- It's possible to make a lot with only few resources
- Nowadays, a microcontroller costing less than 2โฌ is more powerful than the Apollo computer
-
- Computer vs microcontroller
- Computer architecture: CPU, memory, interfaces with peripherals (an important one: disk drive), buses
- In a computer, at boot time, a bootstrap program loads the OS into memory. Then the OS loads the applications
- Thanks to the virtual memory mechanism provided by a computer OS, processes are isolated
- A microcontroller: a whole computer on a chip
- Memory
- Evolution of ROM, which now can be erased and written
- Memory map of a microcontroller
- Many microcontroller provides a bootloader
- Architecture
- Overall architecture of a connected device
- Important characteristics
- Depend on the application
- Some characteristics specific to the IoT
- Hardware tools
- Software tools
- Support
- Common microcontroller families for connected devices
- Arm: a company that provides IP blocks, not microcontroller chips - The most widely used architecture
- Many microcontroller manufacturers rely on Arm IP: Microchip, Nordic, NXP, STMicroelectronics, Texas Instruments, etc.
- STMicroelectronics STM32 family
- Cypress PSoc family. Microcontrollers with analog blocks
- Espressif ESP family. Wi-Fi (+ Bluetooth) microcontrollers
- MangOH boards: an open source design based on a Sierra Wireless cellular communication module running Linux
- Microcontrollers for a few US dollars, demonstration/development boards for a few tens of US dollars
- Computer vs microcontroller
-
- Cross development
- The application is developped for a target machine (microcontroller board) different from the development machine (desktop computer)
- On the development machine: edit, compile, link and possibly emulate
- With the development machine and the target board: flash, run, debug
- Debugging may require some specific hardware tool
- Execution environments
- OS - mostly Linux based
- Facilities similar to a desktop Linux, including package manager, GUI, etc.
- Usual memory requirements: 512 MB to 1 GB of RAM, 1 GB to 8 GB of Flash (SD card <=> disk drive)
- An MMU (Memory Management Unit) is required. Supports virtual memory and so process isolation
- Linux can be built for no MMU
- Many different distributions, often generated by Yocto
- RTOS (Real Time OS)
- Deterministic response time
- Monolithic: RTOS + application can't be dissociated
- A task may crash another task, or the whole application + RTOS
- Usual memory requirements: a few KB of RAM, a few KB of Flash
- Many different RTOSes
- Bare metal
- No OS, no RTOS, directly on the microcontroller
- Abstraction layer may be provided (CMSIS, etc.)
- OS - mostly Linux based
- Interruptions and background task
- An interruption makes the microcontroller stop the current execution, save the context, run some dedicated short code, restore the context, resume the execution
- Interrupt handler, Interrupt Service Routine (ISR)
- Events that can generate interruptions: input signal change for a GPIO, timer events, UART events, A/D conversion events, etc. + some software events
- Interrupt during an ISR execution: priorities
- Usual architecture of a bare metal application
- Saving energy: sleep modes
- Code example: UART RX
- Useful design patterns
- Finite State Automaton (FSA) or Finite State Machine (FSM)
- Ring buffer or circular buffer
- Cross development
-
Bare metal software development for STM32 microcontroller
- The target board
- The target microcontroller
- Harwdware and software documentation
- STM32CubeIDE
- Build, run, debug
- SWV
-
Application startup, stack, vector table, startup file, etc.
-
serial
sample application: background task + ISR + atomicity for shared data structures -
- message or stream?
- UDP and many others are messages, TCP is stream
- message format: the problems of transparency, endianness, and serialization (includes endianness)
- ASN.1, Protocol Buffers, CBOR, other
- message exchange: MQTT, CoAP, other
-
Session 4 exercise: UDP over Wi-Fi
- This repository demonstrates step-by-step how to exchange messages between an ESP-IDF application and a PC application using UDP datagrams, through five successive steps
- Go through the first three steps at least
- No specific question. In the exercise report, provide a feedback about what you understood
- Debriefing about espidf-udp
- Introduction to RTOS
- Session 5 exercise: using espidf-udp as a code base,
- Develop a python server which accepts at least one TCP connection request, and which creates a socket to receive data
- Define a message format. Explain every decision you take
- Add code to the python server to decode and display messages complying with the format you defined, received on the TCP socket
- Develop an ESP32 application which connects to the server using a TCP socket, and which sends messages to the server over the socket, on a periodic basis