Firmware dev

Architecture du firmware MeshCore

Comprendre la structure interne: modules, composants, et abstractions hardware

Comment le firmware est structure

Le firmware MeshCore tourne sur plusieurs plateformes (selon support): ESP32, nRF52, STM32. Il doit gerer radio LoRa, interfaces, stockage, et logique applicative.

Une architecture modulaire facilite la maintenance: separer radio, routage, protocole, et UI/IO.

En France, le reseau est en structuration. Pour les devs, une bonne comprehension du firmware aide a produire des fixes utiles et testables.

Modules coeur

Vue simplifiee en 5 familles:

1. Module radio (driver LoRa)

Controle de la puce LoRa (ex: SX1262/SX127x): TX/RX, freq, power, interruptions.

radio.init(868MHz, preset); radio.send(packet, size); radio.receive(callback);

2. Module routage

Decide quand relayer, comment limiter la propagation, et maintient des infos de voisinage/routes.

routing.handlePacket(packet); routing.addNeighbor(nodeId, rssi, snr); routing.findRoute(destination);

3. Module protocole

Encodage/decodage des paquets, types de messages, et chiffrement (selon modes).

protocol.encodePacket(message, dest); protocol.decodePacket(rawData); protocol.encrypt(payload, key);

4. Application

Logique "user": messages, GPS, telemetrie, node info, etc.

app.sendMessage("Hello", userId); app.updatePosition(lat, lon, alt); app.getTelemetry();

5. Interfaces

I/O: BLE, serial/CLI, ecran, boutons, stockage, etc.

bluetooth.init(); bluetooth.sendToApp(message); screen.display(text);

Architecture systeme

Souvent event-driven:

Event loop

Boucle principale qui traite: radio RX, BLE events, timers, boutons, etc.

Radio en interruptions

La puce LoRa declenche une interruption sur reception. Le firmware met le paquet en queue pour traitement.

Design non-bloquant

Eviter les operations longues bloquantes. Utiliser taches/queues pour rester reactif.

Demarrer MeshCore

HAL (Hardware Abstraction Layer)

Abstraire le hardware permet de supporter plusieurs plateformes:

GPIO abstraction

Boutons, LEDs, pins via une API commune.

hal_gpio_write(LED_PIN, HIGH);

SPI/I2C abstraction

Acces radio (SPI) et peripheriques (I2C/SPI) via fonctions de bas niveau.

hal_spi_transfer(data, size);

Power management

Sleep, clock scaling, power gating selon plateforme.

hal_enter_deep_sleep(seconds);

File system

Stockage config et etat en flash via une API commune.

hal_fs_write("config.json", data);

Benefices de cette approche

🔧

Modularite

Changer un module sans toucher tout le reste (idealement).

📱

Multi-plateformes

Support hardware plus large si HAL est propre.

🔄

Extensible

Plugins/modules additionnels possibles (selon support).

🐛

Testable

Mieux isoler et tester des briques.

⚡

Performance

Event-driven et non-bloquant aident en embarque.

🔓

Open source

On peut auditer, comprendre, et contribuer.

FAQ

Langage du firmware ?

Souvent C/C++ en embarque. Les details dependent du repo et des plateformes supportees.

Memoire utilisee ?

Variable selon plateforme, options, et version. Verifiez les builds officiels si vous ciblez un board precis.

Puis-je ajouter un module ?

Oui si l architecture le permet. Gardez un design simple et testable.

Frequence des updates ?

Variable. Suivez la page GitHub Releases pour les versions stables.

Compatibilite ?

Le protocole vise la compatibilite selon versions, mais les details changent. Testez avec votre noyau local.

Comprendre pour mieux contribuer

Si vous voulez contribuer ou debug, comprendre les modules (radio/routing/protocol) est un bon point de depart.

Voir les appareils Lire plus sur MeshCore