Bonjour,
Merci pour tous vos commentaires, cela me donne beaucoup d'éléments pour réfléchir.
Pour info:
- Effectivement j'ai une contrainte mécanique. Il faut que la carte rentre dans un boitier. Je peux éventuellement l'allonger mais il ne peut pas faire plus de 60x60mm de section.
- les 4 ports série, c'est pour
+ Comm avec le module affichage
+ Comm avec le module accéléromètres BNO55. Il a son propre MCU ARM M0. il peut aussi communiquer en I²C et je câblerai aussi ce port pour tester. Cependant, il me semble qu'avoir un port de comm avec un buffer c'est plus pratique. Je m'attends à ce que le le BNO55 m'envoie en continue ses valeurs, pas besoin de réclamer à chaque fois. Il suffit de lire le buffer qui peut être géré avec une interruption (normalement). Je m'attends aussi à ce que la communication soit régulière et que les valeurs soient associées à un temps. Avec l'I²C je suis moins sur de la régularité de la communication puis qu'elle doit être réclamée au niveau soft. je testerai les 2 possibilités.
+ GPS ou FLARM. Le FLARM est un système anti-collision, sur son port série on peut récupérer le signal GPS et la position des autres planeurs qui sont équipés... et ils le sont tous
+ Bluetooth: pour transmettre la variométrie/altimétrie et position des autres planeurs à un système de navigation sur smartphone:
www.xcsoar.org www.lk8000.it (qui est un fork de xcsoar). S'ils utilisent l’altimétrie du GPS le calcul de plané final est peu précis. D'où l'intérêt de transmettre la variométrie/altimétrie pneumatique.
Grace à vous j'y vois un peu plus clair. J'ai plusieurs possibilités:
1) je viens de me rendre compte que l'Arduino Due rentre en largeur. Je peux faire un PCB en mode Shield. Utilisation Arduino IDE + FreeRTOS
2) Je supprime, pour cette version, la partie comm extérieure. J'utilise la Nano dans un premier temps puis une Nucléo STM32F303-K8 que j'ai déjà. Ca me permet de progresser gentillement de Arduino-->Mbed-->Nuttx. il y a un debugger ST Link V2 intégré (aspect non négligeable).
3)le teensy 3.6 à l'air vraiment tentant. Certaines personnes arrivent à le modifier pour le debugger mais ça n'a pas l'air simple.
4)l'ESP32 à l'air vraiment bien. il n'a que 3 ports série mais il a le bluetooth intégré et à l'air d'être débuggable ce qui correspond parfaitement à mes besoins. Par contre l'installation Eclipse + toolchain + système débug à l'air coton! seul l'ESP-WROVER-KIT a le debugger les dimensions n'ont pas l'air de fitter.
je n'envisage pas le PIC32 pour l'instant car j'ai eu un PICKit avec le ICD2 (In-Circuit Debugger), C'était pratique pour débugger mais j'ai bien galérer pour le reste et il y avait très peu d'aide sur le net.
Pour l'instant je penche pour la solution 2) d'autant plus que je viens de voir qu'on peut acheter un debugger externe ST Link V2 pour quand je ferai un PCB avec un plus gros STM32.