Découverte des cartes STM32 pour remplacer les Arduino Nano

[JacquesZ]

L’info vient de tomber sur le forum de Sim Innovation:
La prochaine version d’Air Manager (v3.7, pourtant l’instant en bêta) supportera nativement les cartes ESP32, que je ne connaissais pas.
https://siminnovations.com/forums/viewtopic.php?f=5&t=2145&p=20750#p20750

Voici les caractéristiques de l’ESP32 en termes de puissance et de RAM ça augmente, par contre, 3,3V seulement.

Module ESP32 : ESP-WROOM-32 d’Espressif.
Microprocesseur dual core de 240 MHz pour les Cores ESP32-D0WDQ6 et ESP32-D0WD. 160MHz pour les Cores ESP32-D2WD et ESP32-S0WD
4MB de mémoire flash
Mémoire flash embarquée : 16-Mbit pour le Core ESP32-D2WD
Connectivité
WiFi 802.11 b/g/n conforme à la norme IEEE 802.11 compatible avec les sécurités WFA, WPA/WPA2 et WAPI
Bluetooth 4.0 LE et BR/EDR
32 Entrées/Sorties
26x E/S digitales (3.3V). Toutes les sorties peuvent être PWM
18x entrées analogiques
3x UART
3x SPI
2x I2S
2x DAC
2x I2C
Consommation en mode sommeil (Deep Sleep mode) : 5 μA
Capteurs intégrés
Effet Hall
10x entrées pour interface tactile capacitive
Protection cryptographique : AES, SHA-2, RSA, ECC, random number generator (RNG)

Jacques

[tabar57]

Oui Jacques j'avais lorgné sur cette carte mais je ne vois pas trop ce que je peux faire du wifi et du bluetooth sur mon simu
Merci pour l'info en ce qui concerne AM, j'hésite encore sur la maj, j'ai des jauges qui fonctionnent bien sous 2.1.3 notamment ton EADI et j'ai pas envie de me prendre la tête pour l'instant
Il me manque déjà pas mal de cheveux avec les STM32

Cordialement

[fab]

... termes de puissance et de RAM ça augmente, par contre, 3,3V seulement...

S'il faut y passer au 3.3v, il faut ajouter ceci :



http://www.ti.com/lit/ds/symlink/txs0108e.pdf

[A320 hérétique]

Ca a l'air bien pratique quand les echanges sont bi-directionnels ... merci Fabien.

Michel

[JacquesZ]

Oui Jacques j'avais lorgné sur cette carte mais je ne vois pas trop ce que je peux faire du wifi et du bluetooth sur mon simu

Je pense que le Wifi et Bluetooth sont surtout pour l’IOT, les objets connectés.
Ce qui est intéressant dans notre cas c’est la puissance et la mémoire vive accrue, et la prog via l’IDE Arduino(pas sûr), encore facilitée par AM. Si l’ESP32 est bien compatible Arduino je me demande si les librairies d’interfacage avec nos simus sont utilisables?
A creuser

Pour AM, si les jauges actuelles te vont bien, gardes cette version, car depuis la v3.0 et le passage à OpenGL, le code d’affichage des textes a changé.

Jacques

[revolution07]

suite discutions sur les cartes..

Mon avis qui n'engage que moi, (basic pour certains mais moins pour d'autres, petit tuto comment ca marche)

je pense que l'architecture est importante et doit être découpée très précisément. nous avons des outils d'une puissance énorme, mais malgré tout ce qu'on en fait c'est un véritable gâchis. On est aller sur la lune pour moins que ça,... et maintenant pour faire clignoter une led il faut un micro/ram/.... c'est de pire en pire

le simulateur c'est : des capteurs, des voyants, des afficheurs, boutons, potentiomètres, des servo-moteur... les entrées/sortie (E/S) physique

Pour transformer le physique(signaux électriques) en logique(0/1 ou informatique) il faut l'interfacé les E/S du simu avec par exemple une carte IO CARD, SIOC.. ou encore arduino...
Attention cependant l'arduino peut être intelligent(ou pas!), comparer au io card et sioc qui ne font que de la "traduction" de signaux. Cependant avec une IO CARD il y aura une charge de travail plus importante coté ordinateur, car ce n'est que de la communication et de l'adaptation de signal, or qu'avec un carte arduino par exemple(ou stm32, sp32, ...y'en a des milliers) elle pourra s'occuper de taches de bas niveau et aussi un peu plus évoluer. si on a un équipement lourd à gérer, on pourra se contacter de le mettre sur un autre arduino, l'adapter en fonction de E/S.(nano, uno, mega...) pour lui tout seul (exemple GPS, ILS, COM/NAV/ADF/DME). avec l'USB, on peut connecter 128 périphériques !!! pourquoi s'en priver (rapide et cordons pas cher, nombreux hub disponible)

l'interface sert de communication entre une liaison série haute vitesse( avec arduiono : 250000 bauds /s c'est pas mal), qui doit lire ou écrire des données, et les entées/sorties ou ses données sont adaptées. Cette interface ne doit pas être trop intelligente. elle ne doit jouer que le rôle de pilote/driver. Le programme de cette interface doit tourner en boucle sans interruption.
Si elle est trop intelligente elle va ralentir l’acquisition, l’émission et la transformation des données

architecture générale:
logiciel sim <-> API ou FSPUI <-> programme interface E/S( INT1) <== USB / WIFI / BLEUTHOOTH ==> CARTE (INT2)<==> E/S

qu'est qu'on peut faire avec 250000 bauds/s à 8bits + 1 Start + 1 Stop => 250000 / 10bits = 25000 octets par secondes

pour être fluide on peut se baser comme pour les ecrans, à 24 voir 25 passage par secondes, ca nous fait 1000 octets par passages. donc plus qu'il n'en faut en théorie.

donc comment coder ou conceptualiser par exemple le cas de l'afficheur d'une com/nav (je donne des freq bidon):
ordi ---usb-- arduino

sur INT1 : le programme accède à l'API de FS ou mémoire offset de FSUIPC pour lire les valeurs des com et nav du logiciel de simulation. Un octet(byte pas conformdre avec bit(1/8 d'octet)) va jusqu'à la valeur 255, sans optimiser, on va prendre en com 8.3 pour 123.225kz 1 octet pour 123mhz et un autre 225kz. soit 2 octet(byte) par com/nav, soit 2x2 com +2x2 nav = 16 octet. ca sera le paquet de données dit UTILE(celui qui détient l'information)

INT1 va envoyer un message via l'USB à INT2, dans un langage compréhensible (un dialogue), que l'on appelle protocole
on va creer ce que l'on appelle une trame (une phrase, un ordre, une action) ou il y aura les données dites UTILE et les données de contrôles [CONTROLE| DONNEES]. on peut faire plus complexe, gestion erreur, balisage début et fin.., mais bon la ça suffit c'est de la simu.
on a décidé arbitrairement du mot de contrôle pour contrôler com/nav va etre COM, en 3 octet les lettres C O M, ca peut être aussi un octet mis a 1, ou 55 ... le mot de control permet lors de la lecteur d'aiguiller le message recu. ex : COM pour réception des com, ADF pour adf.... A1 pour un voyant alerte général...on aurait pu mettre a,b,c,d; ou encore 1,2,3,4,5...

notre trame:
[CONTROLE| DONNEES] => [C O M | COM1 | COM2 | NAV1 | NAV2] == 3o + 4 x 2o = 15 octets
donc on va envoyé x/fois par secondes : [C O M | [123] [255] | [123] [255] | [123] [55] | [123] [55] ]

sur INT2 : avec une interface arduino, nous recevrons les données com 123.225 et 123.225 et et nav 123.55 et 123.55 via la laison serie USB, sous forme codée [C O M | [123] [255] | [123] [255] | [123] [55] | [123] [55] ]
On décortique le tout, et on envoi à chaque DIGIT d'afficheur le bon chiffre, le tout en boucle. Car 1 seul est allumé en même temps mais x fois par secondes, c'est comme les écrans, l’œil ne le voit pas.

voila pour le com/nav. admet on que l'on veuille envoyer maintenant la vitesse vers l'instrument Airspeed indicator
on pourrait envoyer [A S I | vitesse]. on met la vitesse sur 2 octet (valeur possible de 0-65535), suivant l'avion 1 octet 0-255 ca suffirait pas

je veux maintenant coder mes afficheurs d'alertes. admet on qu'il y a en 7 sur le zing. comme il doivent être allumés ou éteints, on peut faire du binaire 0/1. soit en méthode bourrin j'utilise 1 octet par alerte, j'aurai 7 octets, soit je code le tout par bit dans un octet ex [0 0 1 1 0 0 1 1 0 1] . chaque position 0/1 correspond à 1 seul alerte. Le poids du message sera d'un seul octet. avantage il est petit et rapide, désavantage il faut décortiqué chaque bit.

ex de code, chercher si la valeur du 6 bits est allumé: (0 0 X 0 0 0 0 0) 0010000 = 20 hexa

Code: Tout sélectionner

if (octetrecu & 0x20)  { alumer_alerte_plus_de_carburant() ;}
if (octetrecu & 0xA0)  { alumer_alerte_generale() ;} 
...

pour les bottons, potentiomètre... c'est pareil mais en sens inverse. de INT2 => INT1

-------------
exemple de ce que peut faire la carte arduino nano qui commandera un VOR mécanique, avec des taches précises
suivant le hardware bien-sur. on admettra que le cadran à degrés(rose des vents) est dirigé par un moteur pas à pas, avec un capteur pour détecter le deg 0. un encodeur rotatif pour sélectionner les deg. une aiguille (servo) pour l'indication gauche ou droite, un flag to/fr/off

mise sous tension
- initialisation du cadran des degrée à 0 deg. sert à caler le cadran car le hardware ne permet pas de savoir à quel degré il se situe
- flag à off
- aiguille au milieu

Boucle:
- acquisition <= data USB ( deg de course, deg aiguille, flag)
- si donnée reçu => mise en mémoire
- traitement et mise a jour des mouvements des moteurs (par tic)
- traitement du flag s'il a changé => actionne le flag FR ou TO ou OFF
- envoi position de l'encodeur=> USB

Par interruption : quand une rotation intervient, l’interruption arrête le traitement du microprocesseur
- test rotation de l'encodeur=> mise en mémoire puis retourne dans la boucle. ici le traitement est très très rapide AQUISITION -> MEMORISATION

Bonne lecture, c'est un peu fouillis.

[tabar57]

Bonjour,

Oui ton cours est parfait sauf que c'est pas tout a fait comme çà que je fonctionne avec les Arduinos, Lua et Sioc.
Le flot des données n'est pas permanent sur l'USB car tout simplement la carte Nano ou STM 32 ( vu son prix ) est dédiée à une fonction, en l'occurrence pour ce qui me préoccupe en ce moment les blocs de comm Collins CTL 22,62 et 92.
Donc les données n'arrivent sur le port USB correspondant que lorsqu'une valeur change, ce changement dans la valeur d'un offset est guetté par le script Lua par un event qui lance le transfert de la valeur de l'offset sur le port com correspondant.
C'est ensuite l'Arduino ou la STM 32 qui se charge de la mise en forme et de l'affichage sur écran Oled.
A priori d'après ce que j'ai pu constater c'est plutôt la lenteur de certaines fonctions d'affichage qui pose un "petit" problème de ralentissement ou la lenteur du bus I2C, je suis en train de creuser tout çà, j'ai même ressorti l'oscillo

Je vous tiendrai bien sûr au courant de mes avancées.

PS : au passage, j'ai réussi à adapter le sketch .ino du sélecteur d'altitude ( qui fonctionne bien sur la Nano ) sur la STM 32 et l'écran SSD1306 128 X 32, çà avance

Cordialement

Bernard

[tabar57]

Bonjour à tous,

Je vous avais promis des nouvelles de mes avancées sur la STM 32 couplée à l'écran Oled SH1106 alors c'est plutôt bon puisque j'ai réussi le portage du programme arduino de l'ADF vers la carte STM 32.
Il me manquait une librairie spécifique à cet écran ( différent du SSD1306 ) et une déclaration différente au niveau du constructeur.
Voilà une photo de cette avancée
https://i57.servimg.com/u/f57/12/13/98/25/adf_st10.jpg

Cordialement

Bernard

[fab]

Mais on ne doutait pas de ta persévérance

Ce sont de véritable puzzle !

[tabar57]

Merci Fab,

Elles sont quand même pas mal ces petites cartes pour quelqu'un qui ne maitrise pas les pics, même si je n'utilise que 5% de leur puissance et puis les petits Oled c'est vraiment super aussi.
Ca ouvre un super champ de découverte mais çà prend beaucoup de temps.
Le prochain challenge pour cet instrument Collins à base de STM32 et SH1106 c'est de modifier la luminosité de l'écran à partir de la cellule photo présente sur le boitier original, je vous avoue avoir déjà commencé mais pour tout vous dire, la bibliothèque d'écran que j'utilise ne le permet pas ( SH1106.h ) , par contre la bibliothèque U8G2.h possède la fonction de modification du contraste et j'ai testé son bon fonctionnement. Mais en contrepartie les fonctions d'affichage sont complètement différentes et il faut que j'opère beaucoup de changements dans l'écriture du programme.
Passionnant tout çà ...

Bernard