Astrokit est composé d'un système linux temps réel mou embarqué sur une microsd card qui s'enfiche sur une raspi2,
et d'une petite carte électronique reliée à la raspi2 vias les ports gpios.
Après avoir longtemps hésité entre développer sur un micro-contrôleur
ou sur une carte de la nouvelle génération type "nano-ordinateur" comme la raspi,
je décide de lancer mes développements sur cette dernière,
ou sur une carte de la nouvelle génération type "nano-ordinateur" comme la raspi,
je décide de lancer mes développements sur cette dernière,
pour faciliter l'intégration de mes développements en langage C.
Bien qu'ayant une expérience en assembleur et développement sur microcontrôleur,
ce qui me freine sur l'utilisation d'un PIC ou d'un autre microcontrôleur, c'est la gestion de la mémoire et la gestion inévitable des catalogues,
gourmands en flash ram, ainsi que les nombreux calculs en virgule flottante qui doivent rafraîchis régulièrement,
Bien qu'ayant une expérience en assembleur et développement sur microcontrôleur,
ce qui me freine sur l'utilisation d'un PIC ou d'un autre microcontrôleur, c'est la gestion de la mémoire et la gestion inévitable des catalogues,
gourmands en flash ram, ainsi que les nombreux calculs en virgule flottante qui doivent rafraîchis régulièrement,
notamment la modulation Pwm, très gourmande en calculs (on module les deux fréquences de moteurs avec une fréquence Pwm fixe beaucoup plus haute).
Bien qu'un PIC pourrait faire le travail, ajouter une flash et rentrer dans des problématiques électroniques
autour d'un PIC me semble fastidieux, sans compter de devoir éventuellement gérer les aspects réseaux
et les connectivités existantes, ce qui est loin d'être trivial sur un microcontrôleur.
De plus, la tendance "légitime" est aux cartes à base d'architecture RISC, et aux soc à base d'ARM,
Bien qu'un PIC pourrait faire le travail, ajouter une flash et rentrer dans des problématiques électroniques
autour d'un PIC me semble fastidieux, sans compter de devoir éventuellement gérer les aspects réseaux
et les connectivités existantes, ce qui est loin d'être trivial sur un microcontrôleur.
De plus, la tendance "légitime" est aux cartes à base d'architecture RISC, et aux soc à base d'ARM,
en raison de leur implémentation aisée sur une carte dédiée, et des progrès faits en matière d'intégration système.
Je me lance le défi de réussir ce projet sur ce nano-pc, qui ne possède ni RTC, ni TIMER,
sachant que je vais être confronté à une gestion temps réelle des signaux,
sur un système qui n'est pas temps réel.
Mais avec l'avantage de travailler sous Linux autour d'un soc à base d'Arm.
La raspi2 intègre de plus un quatre coeurs > 1Ghz, ce qui est loin d'être négligeable pour l'ensemble des calculs effectués.
Linux n'est pas temps réel : il faudra donc patcher le noyau, minimiser l'utilisation de la CPU,
optimiser les développements dans un optique temps réelle avec gestion des mutex et autres attributs de threads en C.
Linux n'est pas temps réel : il faudra donc patcher le noyau, minimiser l'utilisation de la CPU,
optimiser les développements dans un optique temps réelle avec gestion des mutex et autres attributs de threads en C.
Bien qu'il existe la possibilité d'écrire un module noyau pour la gestion des interruptions,
celles-ci sont de toute façon en concurrence avec les autres interruptions et les appels systèmes du noyau.
Les premiers tests concluants ne m'indiquent pas de persévérer dans l'écriture d'un module noyau.
Concernant la Raspberry Pi, je m'attendais comme pas mal de gens à un "gadget".
Une carte aussi petite, avec si peu d'électronique, et faisant tourner Linux,
ça ne pouvait pas être sérieux et je m'attendais à des bugs,
des interruptions matérielles inopinées, des reboot inexpliqués, des I/O error à répétitions ...
Rien de tout cela.
Au bout de deux ans d'utilisation,
c'est assez incroyable de constater une bonne adéquation entre le Soc Broadcom et l'OS Linux,
idem pour le reste de la carte.
- absence de bugs matériels
- aucune I/O error
- aucun bug au niveau de l'UART, des Gpios, de la sortie Hdmi, de l'audio, ...
des interruptions matérielles inopinées, des reboot inexpliqués, des I/O error à répétitions ...
Rien de tout cela.
Au bout de deux ans d'utilisation,
c'est assez incroyable de constater une bonne adéquation entre le Soc Broadcom et l'OS Linux,
idem pour le reste de la carte.
- absence de bugs matériels
- aucune I/O error
- aucun bug au niveau de l'UART, des Gpios, de la sortie Hdmi, de l'audio, ...
- bonne tenue dans le temps
Bref une fiabilité qui en ferait presque une carte professionnelle.
Bref une fiabilité qui en ferait presque une carte professionnelle.
Pour toutes ces raisons, je décide finalement de travailler sur la Raspberry Pi 2 et non pas sur un micro-contrôleur,
sans exclure de porter le projet sur une autre carte ou bien sur un microcontrôleur.
Elle a aussi l'avantage du prix
..
..
Quand on regarde les possibilités offertes, et surtout de combiner les
avantages des couches de haut niveau avec l'OS Linux,
avantages des couches de haut niveau avec l'OS Linux,
et les couches
basses avec une gestion directe des Gpios, sans compter d'offrir les
services réseaux et la panoplie linuxienne habituelle, modulable à
souhait.
basses avec une gestion directe des Gpios, sans compter d'offrir les
services réseaux et la panoplie linuxienne habituelle, modulable à
souhait.
Cependant, la raspi2 conserve le défaut de n'être pas dédiée à la base à un projet embarqué, qui n'a pas besoin de la plupart des connectivités
Le HDMI, les ports USB ne sont pas vraiment indispensables pour de l'embarqué.
Il aurait été idéal de garder uniquement le SOC Broadcom avec l'ARM 4 coeurs, l'ensemble des GPIOS mais aussi
d'intégrer quelques sorties analogiques qui manquent vraiment sur cette carte, ne possédant pas de CNA.