Cette question demande, entre autres, s'il existe une grande courbe d'apprentissage entre l'utilisation de Python sur un Raspberry Pi pour prototyper un point de terminaison et l'utilisation d'un microcontrôleur.

Il y a clairement une grande amélioration de la consommation d'énergie (au prix d'un débit de processeur réduit), il y a donc de bonnes raisons d'adopter l'approche MCU pour un produit qui doit être alimenté par batterie.

L'une des raisons potentielles de s'en tenir à un ordinateur à carte unique qui exécute Linux est qu'il n'y a pas de nouveau logiciel à apprendre (au-dessus de python ou similaire) en supposant que l'application peut être écrite dans un langage de haut niveau (où il devrait y avoir beaucoup de standard bibliothèques).

Sur une plate-forme de développement intégrée, les choix probables sont C ++ (mbed ou arduino) ou micropython. Mon impression est que celles-ci ne sont pas significativement différentes ou plus complexes que l'écriture de code à exécuter sous Linux - bien que les plates-formes présentent des avantages individuels. Ai-je oublié quelque chose qui concerne un développeur de logiciels?

Plus précisément, je pose des questions sur les points de terminaison IoT - il n'est donc pas essentiel d'avoir toutes les ressources d'un système Linux pour les applications qui m'intéressent ici. Il convient également de souligner que les considérations de puissance et de latence font de l'implémentation du MCU une exigence difficile dans ce type d'application.

Ajout à la réponse complète de George et au point 2) support matériel. Même si le matériel souhaité (par exemple Ethernet, WiFi, carte SD) est ajouté au microcontrôleur / Arduino via des blindages ou des cartes d'extension similaires, les bibliothèques pour les exploiter exercent une pression considérable sur la petite mémoire (par exemple ATMEGA328 (un contrôleur Arduino typique) a 32 Ko de FLASH et 2 Ko de RAM). Surtout lors de la combinaison de plusieurs fonctionnalités (mise en réseau, affichage, carte SD), cela peut être une grave limitation.

Quelques exemples du monde Arduino:

Prise en charge d'une carte SD et d'un système de fichiers simple (FAT):

• Cartes SD (taille de code inconnue mais probablement pas un gros problème si le SPI matériel est utilisé), au moins 512 octets de mémoire RAM
• Petit FAT FS nécessite ~ 2..4 kB FLASH et ~ 44 octets de RAM

Utilisation d'un affichage matriciel:

• Divers affichages typiquement 0,5 .. 3 Ko de RAM

Ethernet avec pile de protocoles TCP / IP:

• uIP : les besoins en RAM dans la plage d'une taille de paquet typique (> 1 ko), cependant, les contrôleurs Ethernet monopuce sont généralement livrés avec un tampon sur puce qui peut contenir quelques trames Ethernet de taille maximale.

  Il est possible d'exécuter l'implémentation uIP avec aussi peu que 200 octets de RAM, mais une telle configuration fournira un débit extrêmement faible et ne permettra qu'un petit nombre de connexions simultanées. ( Source. )

• Pile IP avec protocoles TCP et UDP pour Arduino : minimum de 128 Ko de mémoire externe

• IP sur interface série: SerialIP ~ 9 ko FLASH et "assez" de RAM

Dans l'ensemble, la programmation avec ces limitations nécessite une approche assez différente et nécessite une optimisation en ce qui concerne l'espace du programme et la taille du code (FLASH), les données d'exécution (RAM) et la vitesse d'exécution. Cette réponse l' a bien étoffée.

Comme la question se pose spécifiquement sur la plate-forme mbed, il est bien sûr intéressant de noter qu'elle inclut les fonctionnalités les plus pertinentes pour l'IoT, à savoir la connectivité ainsi que le chiffrement, l'authentification et l'autorisation. Il offre soi-disant une prise en charge matérielle de Bluetooth Low Energy et IPv6 sur un réseau personnel sans fil à faible puissance. Bien que ces fonctionnalités de connectivité ne soient disponibles que sur les cartes de développement répertoriées avec généralement> = 128 kB FLASH et> = 16 kB RAM. Les cartes de développement plus petites, d'autre part, incluent des systèmes avec des microcontrôleurs aussi petits que l'ARM Cortex-M0 + Core avec 16 Ko de mémoire flash, 4 Ko de RAM (c'est-à-dire pas beaucoup plus que des Arduinos de taille moyenne) sans connectivité dédiée.

Cela dépend de ce que vous essayez de faire.

1. La plus grande lacune est qu'un microcontrôleur que vous avez mentionné (comme Arduino) n'exécute pas un système d'exploitation multitâche tel que Linux. Cela signifie que si votre application dépend du multitâche ou du multithreading, cela peut être beaucoup plus difficile, voire impossible, à exécuter sur Arduino.

2. La deuxième lacune est le support matériel. Par exemple, le Raspberry Pi prend en charge les caméras, l'audio USB, l'Ethernet et le WiFi prêts à l'emploi. Rien de tout cela n'est pris en charge directement par Arduino, et bien que vous puissiez utiliser différents boucliers (tels que l'hôte USB, Ethernet ou WiFi), leur utilisation n'est pas aussi simple que l'utilisation de la mise en réseau sur Raspberry Pi.

3. La troisième lacune concerne les ressources disponibles. La plupart des microcontrôleurs ne sont même pas proches des ressources offertes par Raspberry Pi. Par exemple, même le premier Raspberry Pi offrait un processeur fonctionnant à 700 MHz avec 256 Mo de RAM et pouvait être utilisé avec 32 Go de stockage. Un Arduino Uno typique basé sur ATMEGA328 fonctionne à 16 MHz et dispose de 32 Ko de stockage et de 2 Ko de RAM.

L'utilisation de Raspberry Pi est donc beaucoup plus facile pour les développeurs venant de PC. Les principaux avantages de l'utilisation de microcontrôleurs sont:

• les coûts (un clone chinois d'Arduino Nano coûte moins de 2 $ la pièce avec la livraison)
• consommation d'énergie (les microcontrôleurs pourraient être très bien optimisés pour une faible consommation d'énergie - important si vous devez fonctionner sur piles);
• disponibilité en temps réel, c'est-à-dire capacité de réagir en temps réel aux changements de signal;
• taille (Arduino Mini est deux fois plus étroit que Raspberry Pi Zero, et si vous n'avez pas besoin d'autant de broches, la taille ATTINY85 est inférieure à un sou, et cela fonctionne sans cristal).

Si aucun de ces éléments n'est important, l'utilisation de Raspberry Pi est certainement plus logique.

OUI, c'est un grand saut de la programmation en Python à la programmation en utilisant les outils de langage basés sur C typiques sur micro-contrôleur. En fait, dans de nombreux cas, vous devrez peut-être écrire une partie, sinon la totalité, de votre application en langage assembleur.

Comme déjà souligné dans les autres réponses, les microcontrôleurs sont très limités en ressources et vous perdez ainsi toutes les commodités d'un système d'exploitation Linux et tous les outils que vous pouvez exécuter localement. Itérer avec l'IDE Arduino est très lent par rapport à l'exécution de scripts locaux.

Bien que j'ai une grande expérience professionnelle avec les micro-contrôleurs et les microprocesseurs, je préfère exécuter mes projets personnels en utilisant du matériel RPi avec certains Arduinos pour des choses critiques en temps réel. J'ai également essayé le Beagle Bone Black et, à certains égards, c'est plus pratique que d'utiliser un RPi avec un ou plusieurs Arduinos.

Oui, grande différence

La différence est comme le jour et la nuit, tant en ce qui concerne le matériel que les logiciels. Aucune comparaison valable du tout.

Quand utiliser lequel

Utilisez un Arduino, si ...

• Les contraintes d'espace rendent un Pi irréalisable.
• La consommation d'énergie d'un Pi serait trop.
• L'argent est un problème (surtout si vous avez besoin de plusieurs ou plusieurs contrôleurs individuels dans votre projet, chacun exécutant une logique très simple uniquement).
• Vous voulez devenir nerveux et graveleux et travailler à un niveau beaucoup plus bas pour le plaisir ou pour acquérir des connaissances.
• Vous avez besoin d'une extrême simplicité et / ou d'un comportement en temps réel défini à 100% et de zéro chance que quelque chose hors de votre contrôle tue votre programme.
• Vous n'avez pas besoin d'Ethernet, d'une fonctionnalité hôte USB difficile (c'est-à-dire, accéder aux disques durs; l'utiliser du côté client, par exemple en tant que périphérique HID, est OK) et ainsi de suite. La plupart d'entre eux peuvent être installés sur un Arduino (verrry lentement), mais à un coût élevé en termes de RAM / EPROM et également de fonctionnalité. Comme il n'y a pas de multitâche préemptif, le déblocage des tâches devient assez compliqué très rapidement.
• Vous êtes d'accord avec l'IDE de développement Arduino simpliste, ou avec creuser beaucoup plus profondément (c.-à-d., Construire les programmes vous-même), et - si vous n'allez pas pour un périphérique de téléchargement USB comme le Pro Micro - un kit de développement acheté ou fait par vous-même /brûleur.

Dans tous les autres cas, un Pi est beaucoup plus convivial. Le Pi est simplement un autre ordinateur (lent).

Ne vous méprenez pas. Je possède un Pi et l'utilise pour plusieurs services Linux sur mon réseau. Je programme également fréquemment des Arduinos (Pro Micros principalement). Les deux sont excellents, je les aime de la même façon, mais ils ont des scénarios d'utilisation très différents.

Sur votre question de difficulté - elle est relative. La seule fois où l'Arduino est devenu difficile pour moi a été difficile de déboguer les problèmes de synchronisation, surtout s'ils étaient combinés avec une électronique douteuse (c'est-à-dire des interférences EM, des câbles trop longs, etc.). Si vous êtes ferme dans la langue de votre choix (c'est-à-dire, C pour l'IDE Arduino), vous devriez être en mesure de pirater toutes les bibliothèques que vous utilisez. Pourtant, il sera toujours plus complexe qu'un Pi, où vous pouvez par exemple utiliser un langage de script de votre choix pour des choses non temporelles critiques - celles-ci seront toujours plus faciles à développer et à déboguer.

Je pense qu'il y a quelques points qui n'ont pas encore été explicitement spécifiés.

L'environnement de développement est complètement différent. Vous pouvez réellement développer un logiciel Pi sur le Pi - vous pouvez même utiliser une interface graphique si vous le souhaitez. Il existe des outils de débogage avancés intégrés ainsi que - enfin, énormément de ce qui est disponible pour tout système informatique.

Les contrôleurs devront être développés / émulés sur un ordinateur séparé puis envoyés au contrôleur pour les tests finaux.

Le Pi peut exécuter pratiquement n'importe quelle langue avec laquelle vous souhaitez le programmer, les micro-contrôleurs en auront généralement un ou deux.

Le Pi peut exécuter un certain nombre de systèmes d'exploitation (y compris Windows IoT et un tas de systèmes spécialisés), les contrôleurs intégrés ont tendance à ne pas exécuter du tout un "système d'exploitation".

Aussi en ce qui concerne le runtime / OS - le Pi prend quelques secondes pour démarrer - si vous voulez réellement faire quelque chose dans ces premières secondes, le pi ne fonctionnera pas pour vous. De plus, à moins que vous n'ayez pris des mesures extrêmes pour empêcher toute écriture sur le stockage, vous ne devriez vraiment pas simplement couper l'alimentation, vous devez exécuter un "arrêt" et attendre un peu. Cela peut également limiter certaines utilisations.

Un autre point post-déploiement que je n'ai pas vu mentionné. Je ne sais pas comment je serais absolument sûr d'avoir correctement sécurisé un Pi - qu'aucune agence n'a collé un petit morceau de code quelque part qui autorise un accès non autorisé dans certaines circonstances - sans le retirer de tout le réseau et désactiver tous les mécanismes d'accès sans fil . Les micro-contrôleurs sont assez faciles à sécuriser car vous écrivez presque tout le code en cours d'exécution sur la chose.

Bien sûr, vous pouvez toujours développer votre propre image Pi sans véritable OS et prendre en charge la totalité de la carte / CPU, ce qui en ferait à peu près un microcontrôleur hella puissant / cher avec tous les avantages / inconvénients associés. Quelqu'un l'a probablement déjà fait, mais je n'ai pas cherché quelque chose comme ça récemment.

La différence entre le développement d'une application avec un Pi peut être très différente ou quelque peu similaire au développement d'une application avec un microcontrôleur en raison de différences matérielles ainsi que des différences de la chaîne d'outils de développement logiciel.

Il existe une large gamme de microcontrôleurs disponibles allant de processeurs 8 bits à 64 bits et ayant de quelques K de RAM à quelques gigaoctets de RAM. Des microcontrôleurs plus performants offrent une expérience de type Pi. Les microcontrôleurs moins performants ne le font pas.

Et même avec le Pi, il existe de grandes différences entre le développement pour le système d'exploitation Windows 10 IoT et le développement pour Raspian, Mate ou un autre système d'exploitation basé sur Linux. Windows 10 IoT nécessite un PC de développement utilisant une chaîne d'outils Visual Studio avec un débogueur distant ciblant l'environnement Universal Windows Program (UWP). Le développement pour Raspian ou Mate peut en fait se faire sur un Pi avec les outils disponibles sur le Pi.

Le protocole d'application contraint est utilisé pour les petits appareils contraints utilisés avec l'environnement Internet des objets. Pour avoir une idée de la variété du matériel et des logiciels du microcontrôleur, cette page sur la mise en œuvre du protocole CoAP donne une idée de l'environnement qu'elle cible. Il mentionne le système d'exploitation Contiki dont j'ai vaguement entendu parler, ainsi que des systèmes d'exploitation mieux connus tels que iOS, OSX et Android. Les langages de programmation mentionnés sont Java, JavaScript, C, C #, Ruby, Go, Erlang, Rust et Python.

La chaîne d'outils utilisée pour le développement avec microcontrôleur varie selon le fabricant ainsi que les types de ressources disponibles auprès des communautés de développement et des initiatives open source. Dans certains cas, vous obtenez un assembleur croisé, dans d'autres cas, vous obtenez un compilateur C croisé, et dans d'autres cas, vous obtenez une belle chaîne d'outils avec toutes les cloches et les sifflets et les émulateurs et similaire à la chaîne d'outils Visual Studio pour Windows 10 IoT.

L'environnement de développement réel d'un microcontrôleur peut impliquer l'utilisation d'un programmeur EEPROM et des outils logiciels pour créer une nouvelle image et la pousser vers l'appareil ou l'appareil peut avoir la connectivité nécessaire pour permettre le téléchargement d'une nouvelle image via une connexion série ou via une connexion réseau.

Mon impression est que la plupart des microcontrôleurs ont un compilateur croisé C bien que le compilateur ne puisse prendre en charge que des normes plus anciennes telles que K&R ou peut-être C98. Les compilateurs croisés C ont souvent des mots clés non standard pour les fonctionnalités spécifiques au microprocesseur, par exemple les mots clés faret nearpour les pointeurs avec les anciens processeurs 8080 et 8086 avec leur mémoire segmentée.

Il existe également des langages spécialisés qui ciblent les microcontrôleurs tels que le langage de programmation FORTH . Ces langages ont souvent une conception d'exécution qui cible le métal nu afin qu'il n'y ait pas de système d'exploitation autre que l'exécution de la langue.

Le système d'exploitation peut aller de pratiquement inexistant à un système d'exploitation Linux simple jusqu'à un système d'exploitation spécialisé tel que freeRTOS ou Windows Embedded ou un système d'exploitation Linux ou Microsoft Windows complet. Voir ce projet SourceForge MINIBIAN pour Raspberry Pi . Voir également cet eBook, Baking Pi: Développement de systèmes d'exploitation qui décrit le développement d'un OS rudimentaire pour Raspberry Pi en assembleur.

Cet article de Visual Studio Magazine, Programmation de l'Internet des objets avec Visual Studio , fournit une vue d'ensemble des nombreux périphériques disponibles, suivie d'une vue d'ensemble de l'utilisation de Visual Studio IDE pour le développement pour Linux ainsi que Windows.

Il existe un univers énorme et croissant de microcontrôleurs programmables en réseau, disponibles dans le commerce. À un niveau très bas, vous disposez d'une variété de simples appareils 16 et 32 ​​bits d'une variété de fabricants de puces traditionnels comme Texas Instruments. (J'ai joué un peu avec le kit de développement SensorTag et c'est très amusant, ce qui me fait penser que le Watch DevPack pourrait également être un excellent ensemble d'outils d'apprentissage.)

Certains dispositifs de microcontrôleur plus connus incluent Arduino, BeagleBoard et Raspberry Pi. Ces environnements ont tous un support communautaire étendu et sont prêts à être connectés à un grand nombre de capteurs externes, moteurs, servos et tout ce que vous pourriez imaginer. Adafruit, la superstore d'apprentissage de l'électronique fondée par Limor "Ladyada" Fried, fournit toutes sortes de périphériques pour ces cartes, ainsi que sa propre gamme de cartes de développement Feather légères.

...

L'univers d'appareils le plus intéressant pour les développeurs familiarisés avec Microsoft .NET Framework et Visual Studio peut être les environnements compatibles avec Windows 10 IoT Core. Ce sont des appareils x86 et ARM qui prennent en charge les applications de la plateforme Windows universelle (UWP) écrites dans une variété de langues, notamment C #, Visual Basic, Python et Node.js / JavaScript. Le noyau Windows 10 IoT prend en charge des appareils tels que Raspberry Pi, Arrow DragonBoard 410C, Intel Joule et Compute Stick et MinnowBoard. Il existe également des plateformes de produits intéressantes, telles que le portable Askey TurboMate E1.

Un exemple spécifique d'une application de microcontrôleur

Il s'agit d'une image d'une carte microcontrôleur d'une cafetière automatisée. Cela semble être un composant standard pour les cafetières automatiques fabriquées en Chine. Le site Web du fabricant est imprimé sur le PCB.

L'image est composée de deux vues. La vue de gauche est l'arrière de la carte contenant le microcontrôleur et les circuits de support. La vue de droite est l'avant de la carte avec l'écran LCD et un ensemble de boutons qui sont utilisés pour régler l'heure actuelle et pour effectuer des actions telles que la programmation d'une heure de démarrage, etc.

La vue de droite s'insère dans un support qui s'insère ensuite dans une ouverture à l'avant de la cafetière. Les interrupteurs sur le PCB inférieur sont actionnés par des interrupteurs à culbuteur. L'écran LCD, qui semble être un objectif spécial, est utilisé pour afficher l'heure et l'état actuels ainsi que pour afficher l'interface utilisateur lors du changement des paramètres de la cafetière. La LED rouge est utilisée pour indiquer quand la cafetière est en train de faire du café et pour indiquer quand vous avez terminé en éteignant l'éclairage.

Le microcontrôleur est un ELAN Microelectronics Corp EM78P447NAM (fiche technique) qui est un microcontrôleur 8 bits. Certaines des statistiques de base montrent ce qu'est un appareil petit et minimal, mais il fonctionne bien pour son objectif. L'intention est de développer un logiciel qui est ensuite téléchargé dans la ROM à écriture unique dans le cadre de la fabrication.

• Faible consommation d'énergie:

* Less then 2.2 mA at 5V/4MHz

* Typically 35 µA, at 3V/32KHz

* Typically 2 µA, during sleep mode

• ROM 4K × 13 bits sur puce

• Trois bits de protection pour empêcher l'intrusion de codes mémoire OTP

• Un registre de configuration pour répondre aux besoins de l'utilisateur

• 148 × 8 bits sur registres à puce (SRAM, registre à usage général)