Selectarea microcontrolerului potrivit

Familii populare

STM32 (STMicroelectronics)

• ARM Cortex-M0 până la M7
• Ecosistem vast (HAL, CubeMX)
• Preț: €1-15 per chip
• Utilizare: Industrial, medical, consumer

ESP32 (Espressif)

• Dual-core, WiFi + Bluetooth integrat
• FreeRTOS inclus
• Preț: €2-5
• Utilizare: IoT, connected devices

nRF52 (Nordic Semiconductor)

• BLE optimizat, ultra-low power
• SDK matur pentru wireless
• Preț: €3-8
• Utilizare: Wearables, beacons, sensors

PIC/AVR (Microchip)

• Simple, 8-bit, entry-level
• Toolchain gratuit
• Preț: €0.50-3
• Utilizare: Aplicații simple, hobby

Criterii de selecție

1. Periferice necesare - ADC, DAC, timere, comunicații
2. Consum energie - Battery life requirements
3. Memorie - Flash și RAM suficient pentru aplicație
4. Ecosistem - Documentație, exemple, comunitate
5. Disponibilitate - Supply chain stabil

Setup dezvoltare profesional

Compilator și toolchain

ARM GCC (gratuit)

• arm-none-eabi-gcc
• Calitate producție
• Folosit în industrie

IAR Embedded Workbench (comercial)

• Optimizări superioare
• Support tehnic
• Necesar pentru unele certificări

Keil MDK (comercial)

• Popular pentru ARM
• Debugger integrat excellent

IDE-uri

VS Code + Extensions

• PlatformIO: Multi-platform, gestiune librării
• Cortex-Debug: GDB frontend
• C/C++ IntelliSense

STM32CubeIDE

• Gratuit pentru STM32
• Configurator grafic periferice
• Debugger integrat

Eclipse-based

• MCUXpresso (NXP)
• Simplicity Studio (Silicon Labs)

Debugging hardware

ST-Link V2/V3

• Pentru STM32
• Preț: €5-25

J-Link (Segger)

• Universal ARM
• Performanță excelentă
• Preț: €50-500

Logic analyzer

• Saleae Logic pentru protocol debug
• Esențial pentru SPI, I2C, UART issues

Structura codului firmware

Bare-metal vs RTOS

Bare-metal (super-loop)

int main(void) {
    init_hardware();
    while(1) {
        task1();
        task2();
        task3();
    }
}

• Pro: Simplu, overhead minim, deterministic
• Contra: Greu de scalat, timing manual
• Utilizare: Aplicații simple, resurse minime

RTOS (FreeRTOS, Zephyr, etc.)

void task1(void *params) {
    while(1) {
        // Do work
        vTaskDelay(100);
    }
}

• Pro: Multitasking real, abstractizare timing
• Contra: Overhead memorie, complexitate
• Utilizare: Aplicații complexe, multiple features

Layered architecture

┌─────────────────────────┐
│     Application         │
├─────────────────────────┤
│     Middleware          │  (Protocols, File systems)
├─────────────────────────┤
│     RTOS / Scheduler    │
├─────────────────────────┤
│     HAL / Drivers       │  (Hardware Abstraction)
├─────────────────────────┤
│     Hardware            │  (MCU, Peripherals)
└─────────────────────────┘

Drivere și comunicații

GPIO (General Purpose I/O)

Configurare tipică:

• Direcție: Input / Output
• Mode: Push-pull / Open-drain
• Pull: Up / Down / None
• Speed: Low / Medium / High

Best practices:

• Definește pins în header dedicat
• Funcții wrapper pentru claritate
• Debouncing pentru butoane (software sau hardware)

Comunicații seriale

UART

• Simplu, punct-la-punct
• Baudrate tipic: 9600 - 115200
• Utilizare: Debug console, modemuri

SPI (Serial Peripheral Interface)

• Full duplex, master-slave
• Viteze: MHz
• Utilizare: Display, flash, senzori rapizi

I2C (Inter-Integrated Circuit)

• Multi-master, multi-slave
• Adresare pe bus
• Utilizare: Senzori, EEPROM, RTC

Întreruperi

Reguli de aur:

• ISR cât mai scurt posibil
• Nu bloca în ISR (no printf, no malloc)
• Flag + procesare în main loop
• Prioritizare corectă (NVIC pentru ARM)

Optimizare consum energie

Moduri low-power

Sleep modes (ARM Cortex-M)

• Sleep: CPU oprit, periferice active
• Stop: Clock oprit, RAM păstrat
• Standby: Aproape totul oprit, wake din RTC/extern

Exemplu consum:

• Active: 10-50mA
• Sleep: 1-5mA
• Stop: 10-100µA
• Standby: 1-5µA

Tehnici de optimizare

Clock gating

• Dezactivează clock pentru periferice nefolosite
• Reducere semnificativă consum

Voltage scaling

• Rulare la tensiune redusă când nu e nevoie de viteză
• Trade-off viteză vs consum

Duty cycling

• Wake up periodic, procesare, sleep
• Exemplu: Senzor care citește la fiecare 10 secunde

Calcul autonomie baterie

Capacitate baterie (mAh) / Consum mediu (mA) = Ore autonomie

Exemplu:
2000mAh / 0.5mA average = 4000 ore = 166 zile

Considerații:

• Self-discharge baterie
• Variație cu temperatura
• Aging baterie

Validarea firmware-ului

Tehnici de debugging

Printf debugging

• Simplu și eficient pentru quick checks
• Overhead: Poate afecta timing
• Utilizare: UART sau ITM (ARM)

Breakpoints și watch

• Stop la linie de cod
• Inspectare variabile
• Step through execution

Live watch

• Vizualizare variabile în timp real
• Fără oprire execuție
• Overhead minim

Logic analyzer

• Capturare semnale digitale
• Decodare protocoale
• Esențial pentru timing issues

Unit testing embedded

Frameworks:

• Unity: Lightweight, popular
• CppUTest: C/C++, mocking support
• Google Test: Pentru componente non-HW

Ce testăm:

• Funcții pure (algoritmi, parsere)
• State machines
• Protocol handlers

Ce nu testăm (unit):

• HAL direct (integrare)
• Timing dependent (system tests)

Hardware-in-the-loop (HIL)

• Testare automată pe hardware real
• Stimulare intrări, verificare ieșiri
• CI/CD pentru firmware

Actualizări firmware remote

De ce OTA?

• Fix bugs post-deployment
• Adăugare features noi
• Security patches
• Evitare recall fizic (costisitor)

Arhitectură bootloader

Dual-bank (A/B):

┌────────────────┐
│  Bootloader    │ (Protected, rarely updated)
├────────────────┤
│  App Slot A    │ (Active)
├────────────────┤
│  App Slot B    │ (Update target)
└────────────────┘

Avantaje:

• Rollback instant dacă update eșuează
• Update în background
• Zero downtime

Securitate OTA

Obligatoriu:

• Semnătură digitală firmware (ECDSA)
• Criptare transport (TLS)
• Verificare integritate (SHA256)
• Anti-rollback (version counter)

Opțional:

• Criptare firmware la rest
• Secure boot chain
• Hardware security module (HSM)

Implementare practică

Soluții populare:

• ESP-IDF OTA (pentru ESP32)
• MCUBoot (Zephyr, universal)
• AWS IoT OTA
• Azure IoT Device Update

Standarde pentru firmware

Safety standards

IEC 61508 (General safety)

• SIL levels (Safety Integrity Level)
• Cerințe pentru software în sisteme safety-critical

ISO 26262 (Automotive)

• ASIL levels (Automotive Safety Integrity Level)
• De la ASIL A la ASIL D (cel mai strict)

IEC 62304 (Medical devices)

• Class A, B, C
• Lifecycle complet documentat

Cerințe comune

Traceability

• Requirements → Design → Code → Test
• Fiecare feature trasabil la cerință

Code coverage

• Statement coverage: minim 80%
• Branch coverage: minim 70%
• MC/DC pentru safety-critical: 100%

Static analysis

• MISRA C: Reguli pentru C safe
• PC-lint, Polyspace: Tool-uri
• Zero warnings policy

Documentation

• Software Requirements Specification
• Software Design Description
• Test Reports
• Change History

Firmware de calitate cu Torcip

Dezvoltarea firmware-ului profesional necesită experiență, procese și tooling adecvat. Calitatea firmware-ului determină succesul produsului.

Best practices recapitulate

• Arhitectură modulară și scalabilă
• RTOS pentru aplicații complexe
• Power management din start
• Testare automată unde posibil
• OTA pentru lifecycle management
• Documentație completă

Servicii Torcip Firmware

Dezvoltare completă:

• Arhitectură și design
• Implementare și testare
• Documentație și transfer

Platforme suportate:

• STM32 (toate familiile)
• ESP32/ESP8266
• nRF52/nRF91
• Custom silicon

Specialități:

• BLE și protocoale wireless
• Motor control
• Senzori și acquisition
• IoT connectivity
• Low-power optimization

Proces:

1. Specificații și arhitectură
2. Sprint-uri de dezvoltare
3. Code review și testare
4. Integrare și validare
5. Transfer și suport

Contactează-ne pentru o discuție despre proiectul tău de firmware și primește o evaluare tehnică gratuită.