Bonjour,
 
Je souhaite réaliser un objet connecté à très faible consommation (moins de 40mA) permettant de communiquer avec un serveur via le réseau GSM ou 3G (pas de Wifi à proximité).
 
Je suis donc parti pour utiliser un simple microcontrôleur type PIC et non une arduino/raspberry ou autre.
Le microcontrôleur aura une sortie UART que je souhaite connecter avec celle du module GSM/3G pour la communication serveur.
 
Est-ce possible avec ce hardware d'utiliser une messagerie en XMPP codée en C directement sur le microcontrôleur (sans linux)  pour communiquer avec le serveur ? Quelqu'un m'a en effet dit que seul un environnement linux pouvait gérer ce genre de chose, confirmation ?
 
Spécification de la liaison objet/serveur :
 
Le serveur doit pouvoir réveiller la carte à tout moment
Débit de donnée par connexion : quelques kilo-octets montants et descendants (retours historique capteur en montant, commande utilisateur en descendant)
Possibilité de faire une upgrade du firmware (50-100ko) à distance du microcontrôleur via ce serveur
 
Je suis preneur de toute idées, interrogations, remise en cause etc.
 
Merci d'avance et bonne journée !

Bonjour,
 
Question intéressante! Je me permets de donner un avis complètement subjectif:
 
"Quelqu'un m'a en effet dit que seul un environnement Linux pouvait gérer ce genre de chose, confirmation ?" : vrai et faux (oui je suis d'origine normande ;-)  
Vrai, parce que c'est effectivement la façon la plus rapide en terme d'effort logiciel. Il y a plusieurs frameworks XMPP open source qui sont adaptés aux OS "lourds" Linux, Windows, Mac OS, ... simplement parce que ces librairies reposent sur d'autres standards, principalement les sockets (de Berkeley), openSSL pour le chiffrement et une libraire XMPP.
Faux par ce qu'il est évidemment possible de faire la même chose en "vrai" embarqué, cela demande toutefois beaucoup plus d'effort en terme de développement:
Etant donné les contraintes, choisir un MCU adéquate: PIC ok mais aller au moins vers un PIC32, un 8 bits me parait un peu anachronique.. Personnellement j'aurais une préférence pour un MCU avec coeur ARM M0(+), M3 ou M4(f)...
Pour la partie logiciel:
  - il faudrait utiliser une librairie type lwIp pour le stack IP, plusieurs librairies sont disponibles pour ajouter le chiffrement (SSL/TLS) au dessus de lwIp...
  - Mettre un petit OS temps réel comme FreeRTOS: Ce n'est pas obligatoire mais ça peut faciliter les choses lorsque l'on a une complexité logiciel de ce type.
  - recréer un framework XMPP, basé ou non sur des frameworks existants (il faut considérer les licences des différents implémentations)
une fois ces trois "gros" modules en place, le développement de l'application en elle même sera d"une difficulté équivalente à une implémentation Linux
 
Concernant le modem, attention qu'en UART, la bande passante c'est pas terrible (transfert Asynchrone)! Avec des MCUs modernes il est toutefois possible d'avoir des transferts jusqu'au moins 20MHz (je l'ai personnellement déjà testé sur certain MCUs), mais la vitesse plus traditionnelle reste le 115200 Hz(ou bps/bauds). A cette vitesse même avec un driver impeccable (DMA, ...) il n'est pas possible d'aller plus vite que 11.25 kB/s en 8-1-N-1 (8 bits de data, 1 start bit et 1 stop bit)
 
En considérant les contraintes (principalement les 40mA) il semble évidant qu'une solution Linux (avec un ARM9, Cortex Ax, ...) semble difficile à mettre en oeuvre, ne reste donc qu'une solution vraiment "embarqué' avec un MCU basse consommation, et beaucoup de code à écrire: un beau projet ;-)
 
Reste éventuellement des processeurs hybrides comme les Freescale/NXP iMx6/7 (il y en a sûrement d'autres chez Ti ou concurants): ces processeurs intègrent un ou plusieurs coeurs ARM Cortex A(7/9/...) capable de faire tourner un OS de type Linux (le code/BSP est fourni) et possèdent également un coeur auxiliaire de type M4(f) pour les besoins temps réel. ce coeur "temps réel" est bien évidemment capable de communiquer avec une application tournant dans l’environnement Linux. Je n'ai pas les chiffres de consommation en tête, mais je pensais tout particulièrement au iMx7ULP qui est une variante "Ultra Low Power" de cette gamme définitivement orientée vers l'IOT.
 
J'espère que ces explications aideront, et bonne continuation sur le projet

Bonjour,  
 
Merci beaucoup pour votre réponse ! Je ne l'espérais plus ! Comme vous l'avez dis, la réalisation de montage demande un développement de code assez poussé et nous avons décidé de revoir notre cahier des charges afin de le rendre plus facilement accessible. Nous avons ainsi décidé de déporter la partie gourmande en énergie (MQTT) sur une autre carte qui peut-être alimentée sur secteur (Raspberry) et communiquons avec cette carte par le biais d'un module bluetooth LE piloté par le microcontrôleur. Les attendus en terme de connectivité et de consommation sont donc remplis ! Dans un deuxième temps nous reviendrons peut-être sur ce point et tenterons avec les ressources nécessaires de tout intégrer sur la même carte.
 
Bonne journée !