Je ne sais pas si c'est moi ou mon précédent post a disparu ?
je n'ai pas eu de notification.
Je suis débutant dans toute la partie commuinication entre 2 MCU et je ne sais pas quel est le moyen le plus simple et le plus adapté pour mon projet
D'un coté je vais avoi un STM32F4 qui va s'occuper d'un codeur incrémental et eventuellement des calculs et de l'autre un arduino Due qui va s'occuper d'un ecran TFT 5 pouces et eventuellement d'un clavier 5x5
Les données n'ont pas besoin de transiter très rapidement et la quantité n'est pas importante non plus. Je veux juste que ce soit facile et fiable.
A prmière vue, le serial serait le plus aisé ? ou le SPI ?
Qu'en pensez-vous ?
J'aimerais aussi m'assurer que le TFT n'utilise pas les ports nécessaires pour la communication avec le STM32. Comment je peux m'en assurer?
Distance: quelques centimetres
Mais je ne peux pas tout faire en un seul:
Tout sur le Due: pas assez rapide par rapport à mon codeur
Tout sur le STM32: je n'ai pas les connaissances pour gérer un TFT de cette taille, je me suis arreté au LCD20x4
Je trouve un peu dommage d'introduire de la complexité pour si peu.
Je trouve étonnant qu'une DUE à 84 MHz ne soit pas assez rapide pour lire les impulsions d'un codeur incrémental, surtout qu'on peut le faire par interruptions.
STM32F4 ne veut pas dire grand chose. Lequel ?
Quel codeur ? quelle est la fréquence des impulsions ?
Quel écran ? SPI ? parallèle ?
Sur la ligne de communication, Y a-t'il un seul maître, c'est à dire un seul des deux vis à vis qui donne les ordres ou pose les questions ?
je n'a ipas encore le chip definitif mais le codeur est un 2500ppr, decodage en quadrature
Moteur 3000 Rpm
et pour mon second projet: regle avec des resolution très faibles de l'ordre de 1 ou 0.1 micron, ca monte aussi vite quand on a des déplacements rapides
On arrive vite a des frequences importantes
Un STM32F446RE ou quelquechose de la sorte et ensuite j'adapterai le reste mais clairement je veux être au dessus de 100Mhz et ils ont pas mal de chip a 180Mhz, c'est deja pas mal. et le prix n'est pas enorme
Pour l'ecran je pensais a celui-ci:
Justement c'est sur le slave/master que je me tate un peu.
Soit j'utilise le stm32 comme pur slave
Soit je mets les deux à égalité (ce que je prefererais pour les evolutions futures...) mais qui rends les choses plus complexes.
Idéalement j'aimerais que le due servent d'interface utilisateur avec le clavier et l'ecran, et le STM serve de lecture de regle, calcul et pilotage moteur (step/dir)
Je maitrise toute la partie pilotage, calcul et lecture sur le STM32, il me manque que la partie communication.
Sur le due, je ne maitrise rien pour le moment meme si j'ai déjà utilisé des claviers dans le passé
Le SPI est maître / esclave uniquement. Il n'y en a qu'un qui tire la corde à linge.
Je veux bien qu'une RS232 soit bidirectionnelle, sans maître ça devient vite le bordel et les collisions doivent être gérées.
Ce n'est pas une mince affaire.
Souvent un host (maître) relié à un esclave RS232 passe par du polling pour envoyer les requêtes et recevoir les réponses.
Un polling à 100ms ou 200ms peut faire l'affaire pour un clavier.
Les requêtes dans ton cas seraient des ordres d'affichage et des demandes de lecture du clavier ou des boutons tactiles.
J'ai déjà développé une solution qui consiste à ajouter un fil supplémentaire utilisé par l'esclave pour dire au host "j'ai qq chose à t'envoyer".
Le host pose ensuite la question "qu'as tu à me dire ?" et l'esclave répond.
Jamais l'esclave ne prend l'initiative de la communication.
Pour le le STM32, pense à FreeRTOS, cela peut aider.
OK je vois.
Donc tu partirais quand meme sur du SPI plutot que du serial.
Je peux aussi voir les choses dans l'autre sens et passer le clavier sur le STM32
Ainsi le STM32 serait le maitre et enverrai uniquement l'affichage au slave. Ca me parait plus logique en fait.
J'ai appris a utiliser le STM32 en suivant des tutos etc avec HAL, j'entends parfois parler de freertos mais je n'ai pas envie d'intégrer une surcouche supplémentaire alors que dans mes utilisations limitées, je n'en aurais pas un gain substenciel.
Pour la petite histoire, j'étais parti sur un module STM32 de lecture uniquement car pas mal de hobbyistes dans l'usinage bricolent sur arduino (il y en a sur des ST mais ce n'est clairement pas la majorité). L'idée était de fournir un petit module de lecture qui sera beaucoup moins limité qu'un arduino uno. Généralement le traitement des données (affichage, calcul etc), le uno suffit bien, c'est uniquement pour la lecture que cela pose problème.
Ainsi on pouvait se servir de ca (idéalement en I2C comme ca on le couple facilement à d'autres capteurs) dans d'autres projets.
Je n'ai pas regardé mais j'imagine bien que ce genre de module existe déjà ... !
Donc tu partirais quand meme sur du SPI plutot que du serial.
Je n'ai jamais essayé le SPI slave sur ARDUINO.
Mais on devrait obtenir de bons résultats en série aussi, peut être 460800 baud ?
Pourquoi pas avec un petit protocole simple STX + données + ETX + éventuellement CRC.
Je peux aussi voir les choses dans l'autre sens et passer le clavier sur le STM32
Aussi, mais il faudra surveiller l'encodeur et le clavier à tour de rôle.
Pourquoi pas sur interruptions ?
HAL
Librairie Stm32CUBE de ST MicroElectronics ?
Il y aussi MBED, mieux foutu, en tous cas de plus haut niveau.
Oui je travailles en interruption pour les deux de memoire. Enfin je n'ai plus le terme exact mais en gros j'ai un compteur qui se remet à 0 automatiquement au bout de X pulses et genere une interruption.
Et je ne me souviens plus pour le clavier mais de memoire j'avais fait en sorte que les deux ne posent pas de probleme. Dans tous les cas on ne se sert pas du clavier pendant un mouvement donc ca réduit le risque.
Oui ce sont les librairies de CubeMX
Comme freeRTOS, j'ai entendu parler de MBED mais je n'ai pas voulu m'ajouter une complexity en plus, tout comme chibiOS par exemple.
OK je vais voir ce qui est le plus simple à mettre en place avec l'arduino comme slave dans un premier temps
Et pourquoi ne pas utiliser un seul ESP32 ? Il se programme comme un Arduino, ou bien il peut utiliser FreeRTOS. Il tourne à 240 MHz, il a 2 cœurs, le SPI tourne à 80 mais peut être utilisé en mode QIO et communiquer 4 données en une fois, donc potentiellement 320 MHz.
Et il existe de très bonnes bibliothèques pour gérer les écrans TFT en SPI.
Ce qui est affirmé sans preuves peut-être niées sans preuves.
As tu fait des calculs pour confirmé cela ?
Oui dans mon message #4 j'ai mentionné un ordre de grandeur
J'utilise un codeur de 2500ppr avec un décodage en quadrature donc 10000ppr.
à 3000Rpm, je suis a 500Khz, donc 250Khz a 1500rpm (ce sont les vitesses assez standard de moteurs asynchrone).
Je ne vais jamais arriver à ce niveau là mais j'en suis bien loin avec un Due
Je ne connais pas les ESP32, auriez vous une board "courante" ?
Ce qui me freine ce n'est pas trop la vitesse de communication mais surtout la vitesse de lecture du codeur.
je peux être plus haut que 80K en lecture?
Je ne crois pas qu'un codeur en quadrature utilise l'ADC, il s'agit juste de lire l'état de 2 pins et de comparer par rapport à l'état précédent. ENcore une fois je ne suis pas un expert, c'est ce que j'ai compris
vibram:
J'utilise un codeur de 2500ppr avec un décodage en quadrature donc 10000ppr.
à 3000Rpm, je suis a 500Khz, donc 250Khz a 1500rpm (ce sont les vitesses assez standard de moteurs asynchrone).
Bonjour,
Heu... 10000pts par tour sur un moteur qui tourne a 1500 ou 3000 tr/mn ça semble un peu excessif.
Tu es sur que tu as besoin de cette résolution? C'est pour quelle application?
En revanche, j'avais lu au sujet du STM32 que quand on l'utilisait avec l'IDE arduino on bridait pas mal ses possibilités notamment en terme de performance. Encore une fois, c'est ce que j'avais lu quelque part, ce n'est peut etre pas le cas en vrai?
je veux juste m'assurer que ce ne soit pas le cas avec un ESP non plus
Concernant la résolution, normalement non je n'en aurais pas besoin mais c'est dans certains cas extreme pour eviter de perdre mon repere car je n'utilise pas de limit switch ou codeur absolu
J'ai peu d'expérience avec l'ESP32, je la construis au fur et à mesure. Pour donner un exemple, j'ai écrit un petit programme avec l'IDE Arduino pour émettre un flux de bits sur une sortie digitale : j'ai obtenu un débit proche de 10 Mbit/s. Sans forcer.
quand on l'utilisait avec l'IDE arduino on bridait pas mal ses possibilités notamment en terme de performance
Je ne pense pas. L'IDE ARDUINO utilise le compilateur GCC xtensa-esp32.
A moins que les options de compilation soient vraiment mal choisies dans l'IDE ARDUINO, il y a peu de chance que cela donne un résultat différent.
Ensuite il y a les librairies ARDUINO. Sont-elles moins performantes ?
J'ai jeté un œil à celles qui gèrent les GPIOs et le SPI. Cela ne me semble pas mal construit.
Et on peut même faire du multithreading.
Bon j'ai craqué et commandé un esp32, affaire à suivre.
Je pense dans un premier temps me servir de la lib arduino, je verrai ensuite. c'est peut etre l'occasion de se mettre à freeRTOS qui semble aussi utilisé sur les STM32. Ca fait une surcouche en plus mais si cela permet d'avoir une base commune pour différents MCU 'cest pas mal pour un débutant
meme si j'ai déjà utilisé des claviers dans le passé