Choix d'un micro-contrôleur

[invite428fabda]

Bonjour à tous !


D'abord, je vous explique mon cas.
En fait, j'ai fait un circuit électronique où tout fonctionne avec du tout ou rien. J'ai besoin de contrôler ce circuit à partir de l'ordinateur.
Seulement voilà, j'ai testé plusieurs moyens comme l'Arduino. Ce dernier n'a pas une communication assez rapide avec l'ordinateur et pour le reste va au-delà de mes besoins : ce que je veux, c'est activer mes portes et mes démultiplexeurs depuis mon ordinateur à partir d'un programme que j'ai codé sur celui-ci, je n'ai pas besoin que le micro-contrôleur soit autonome ou soit programmable. En fait, mon circuit n'est vraiment rien d'autre qu'un bête périphérique, l'intelligence se trouve dans le programme sur l'ordinateur.
Concernant la vitesse de communication, j'ai besoin d'ouvrir et fermer les portes et les démultiplexeurs de mon circuit plusieurs dizaines de milliers de fois par seconde. Au total, en comptant les portes et les pins d'entrée des démultiplexeurs, cela fait 24 éléments.

J'ai testé d'autre choses que l'Arduino comme le pic18f4550 que je n'ai pas réussi à maîtriser ou encore le Duinomite basic qui s'avère trop lent.

Par conséquent, ma question est : que me conseillerez-vous comme micro-contrôleur pour répondre à mes besoins, pas plus, pas moins ?

Pour vous faciliter la réponse à cette question, je me dois de vous informer sur mon niveau. J'ai un excellent niveau en programmation, cela fait des années que je programme en C et surtout C++ qui sont mes langages favoris mais je débute en électronique (preuve en est par ailleurs de la difficulté que je vous décris précédemment).


Merci d'avance à tous pour vos réponses !

PS : je vous remercierai d'avance de ne pas me poser des questions sur mon circuit autre que celles concernant la communication avec l'ordinateur, le reste étant hors-sujet. L'information que ce qui est à contrôler sont des portes et démultiplexeurs en tout ou rien me semble suffisante.
-----

[alainav1]

bonjour,
cela me semble difficile de communiquer "plusieurs dizaines de milliers de fois par seconde " du pc vers l'exterieur ?
ceci dit je ne suis pas un grand specialiste de ce type de communication .
quand au µP un pic avec un quartz de 20MHz degenere une horloge interne de 4MHZ ensuite la programmation en assembleur doit permettrer de communiquer a la vitesse souhaiter .
n'en sachant pas plus voila ce que j'en pense ,pour etre rapide: programmation d'un pic par exemple en assembleur . une impulsion du pc commande le pic de realiser la sequence par exemple .
cordialement
Alain

[jiherve]

Bonjour,
un adaptateur USB <=> Parallèle, on devrait pouvoir émuler un port centronics.
JR

[alainav1]

bonjour,
a ma connaissance le convertisseur usb parallele est mono directionnel et utilisable seulement pour une imprimante
cordialement
Alain

[A voir en vidéo sur Futura]

[Forhorse]

la fonction recherchée ne me semble pas réaliste.
il y a un bug dans le cahier des charges. Pour des taches rapides c'est quand même mieux d'avoir algorithme principal qui tourne dans un microcontrôleur/processeur/DSP dédié (en fonction du besoin en type/puissance de calcul) et de n'avoir que sur le PC l'interface de commande si nécessaire.
Enfin moi je dis ça, je dis rien...

[ftorama]

L'USB2 a un temps de latence de 1ms donc quelque-soit le micro choisi, il ne conviendra pas.

Il faudrait alors se diriger vers d'autres modes de communication, peut-être le PCI-express mais il faudra de toutes façons intervenir en profondeur dans l'OS pour obtenir de telles performances.

Je rejoins donc Forhorse sur l'impossibilité de faire ça via un PC. Un SoC type ARM pêchu ou un FPGA conviendraient bien mieux.

L'erreur des informaticiens, c'est de croire que tout est faisable via un PC, tu ne trompes pas l'adage

[invite428fabda]

Merci pour vos réponses !

Je trouve l'idée de l'adaptateur USB => parallèle excellente. Je n'ai pas besoin de communication bidirectionnelle, je ne fais qu'envoyer des informations au circuit.
Quant à la présence d'un algorithme principal sur le micro-contrôleur, je n'en vois par l'intérêt car cela ne change pas la quantité d'informations à envoyer, celles-ci étant lues à partir d'un fichier sur le PC, seul le lieu de traitement change.

Je vais donc faire quelques recherches du coté du convertisseur USB => parallèle.

[Forhorse]

Parce que tu crois que dans un convertisseur USB-parallèle il y a un super processeur de la mort qui tue plus rapide que les µC que tu as déjà essayé ? cette bonne blague !
Je reste sur ma première position...

[jiherve]

Bonsoir,
l'avantage de l'USB c'est justement qu'il n'y a pas de processeur, c'est de la RS232 améliorée, cela existe en bidir (indispensable pour contrôler une imprimante s'il faut un chouilla de protocole). Quant à la latence cela peut ne pas être un problème surtout en unidirectionel.
De toutes façons avec un µC externe la communication se fera le plus souvent en USB, vu qu'il n'y a plus rien d'autre, le PCIe ,Ethernet,ou le SATA sont bien trop lourds pour la plupart des applications, cela explique la multitude de périphériques utilisant ce protocole (remember : Universal Serial Bus)
JR

[azad]

Hé bien, ne posons pas de questions indiscrètes. Cependant de deux choses, l'une.
1- "Ton circuit" est vraiment le tien. Tu l'as donc pensé, schématisé et réalisé. Actuellement tu souhaites avoir un diagramme de fonctionnement où apparaitraient les états de la vingtaine d'entrées-sorties de ton circuit. Ce qui laisse à penser, qu'il ne fonctionne pas tout à fait selon tes désirs, et qu'il "t'échappe", donc qu'il n'est plus tout à fait "ton" enfant. Dans ce cas, il faut revoir ta copie : tu t'es planté quelque part.
2- Tu souhaites connaître le sus dit diagramme mais cette fois il s'agit de percer le fonctionnement d'une carte dont tu n'es pas l'auteur. Désir qu'intellectuellement (ne mêlons pas la soif de savoir avec la morale) on peut trouver tout à fait légitime et que je comprends très bien. Ce cas est le plus intéressant. Il faudrait savoir, parmi les vingt-quatre pins de la carte, combien sont des entrées et combien des sorties.
Comme tout semble fonctionner à des vitesses proches de 100nS, et que tu ne dis rien sur la longueur d'un cycle complet, il est clair, qu'il faut un bon débit pour enregistrer un fichier d'état….. Si les contrôleurs actuels te semblent trop lents, et si le traitement du flux issu d'une USB l'est aussi, il reste la solution de mettre les mains dans le cambouis et de te concevoir une carte électronique qui actionnerait l'engin à cracker.(Ne nous voilons pas la face) Pour cela je verrais bien l'usage de PALs ou autres GALs autrement dit, je rejoins Forhorse qui a évoqué les DSP.
Et pour conclure, dis-toi que si l'auteur de la carte est un tant soit peu futé, il a pu, lui aussi utiliser des circuits genre Pal/Gal…. auquel cas ton projet est voué à l'échec - sauf à utiliser de très gros moyens.

[ftorama]

Bonsoir,
l'avantage de l'USB c'est justement qu'il n'y a pas de processeur, c'est de la RS232 améliorée, cela existe en bidir (indispensable pour contrôler une imprimante s'il faut un chouilla de protocole). Quant à la latence cela peut ne pas être un problème surtout en unidirectionel.

J'ai pas l'impression que tu saches ce qu'est de l'USB. L'initialisation d'un périphérique implique toute une partie d'échanges "intelligents" avec l'hôte, énumération, ré-énumération éventuelle, négociations sur le courant utilisable par le périphérique, etc.

De toutes façons avec un µC externe la communication se fera le plus souvent en USB, vu qu'il n'y a plus rien d'autre, le PCIe ,Ethernet,ou le SATA sont bien trop lourds pour la plupart des applications, cela explique la multitude de périphériques utilisant ce protocole (remember : Universal Serial Bus)

On parle quand même de piloter des signaux à 10kHz avec, d'après ce que j'ai compris, des calculs entre chaque salve. L'USB est très efficace pour envoyer des salves de données mais pour faire du traitement à la volée, je reste totalement sceptique.

La question à se poser, mais la réponse est secret-défense, est de savoir quels calculs sont si énormes pour qu'un micro ne puisse pas les faire. Vu les Quad-Core Cortex-A5 qu'on trouve aujourd'hui ou les Dual-Core hétérogènes (le gros coeur fait les calculs, le petit fait la synchro), je ne vois vraiment pas l'intérêt de passer par un PC. Ne parlons même pas des micros à logique programmable tels que les pSoc de Cypress ou les XMOS.....

Bref, le cahier des charges est bancal à la base, et on a pas le droit d'en savoir plus pour pouvoir corriger la trajectoire. Perso je laisse tomber. C'est du ressort d'un designer ou d'un FAE

[invite428fabda]

Merci pour vos réponses.

@Azad : je n'ai pas tout compris mais sache que je suis bien le concepteur du circuit et qu'il n'y a que des portes et démultiplexeurs à activer, rien n'est envoyé au micro-contrôleur ou à l'ordinateur, c'est unidirectionnel. Le circuit fonctionne parfaitement puisque je l'ai déjà testé avec Arduino mais la vitesse de communication de ce dernier avec l'ordinateur est trop lente pour aller jusqu'au bout.

@ftorama : Non, pas de calcul complexe à faire, mais je n'ai pas envie de perdre mon temps avec quelque chose comme le 18F4550, je cherche quelque chose de simple à utiliser.
Ça demande pas de gros calculs mais de la vitesse de communication avec l'ordinateur qui contient les fichiers contenant les valeurs à envoyer.
Maintenant, ce que je cherche à faire, c'est activer/désactiver des portes en tout ou rien, il y a-t-il vraiment besoin de quelque de puissant pour ce faire ?
Comme je l'ai dit dans mon premier message, je ne l'ai pas précisé pour rien, mon niveau n'est pas très élevé en électronique. Je n'ai pas d'a priori particulier, je cherche juste quelque chose qui répond à mes besoins tout en étant le plus simple possible.

J'ai regardé les convertisseurs USB => Parallèle de FTDI et ils semblent répondre à mes besoins.

[ftorama]

Merci pour vos réponses.

@Azad : je n'ai pas tout compris mais sache que je suis bien le concepteur du circuit et qu'il n'y a que des portes et démultiplexeurs à activer, rien n'est envoyé au micro-contrôleur ou à l'ordinateur, c'est unidirectionnel. Le circuit fonctionne parfaitement puisque je l'ai déjà testé avec Arduino mais la vitesse de communication de ce dernier avec l'ordinateur est trop lente pour aller jusqu'au bout.

@ftorama : Non, pas de calcul complexe à faire, mais je n'ai pas envie de perdre mon temps avec quelque chose comme le 18F4550, je cherche quelque chose de simple à utiliser.
Ça demande pas de gros calculs mais de la vitesse de communication avec l'ordinateur qui contient les fichiers contenant les valeurs à envoyer.
Maintenant, ce que je cherche à faire, c'est activer/désactiver des portes en tout ou rien, il y a-t-il vraiment besoin de quelque de puissant pour ce faire ?
Comme je l'ai dit dans mon premier message, je ne l'ai pas précisé pour rien, mon niveau n'est pas très élevé en électronique. Je n'ai pas d'a priori particulier, je cherche juste quelque chose qui répond à mes besoins tout en étant le plus simple possible.

J'ai regardé les convertisseurs USB => Parallèle de FTDI et ils semblent répondre à mes besoins.

Tu as quel volume de données à envoyer?

Même avec l'Arduino, tu peux gagner du temps en bufferisant les données, c'est à dire en les envoyant par salves plutôt qu'un à un. Ensuite le micro se charge du cadencement. D'ailleurs, l'USB est plus efficace avec des blocs de données. Maintenant, le port série par défaut de l'Arduino ne suffit peut-être pas et il faudrait peut-être passer par un autre protocole.

Quoiqu'il en soit, avec des ports qui ont des temps de latence et des OS non temps-réel, il est totalement farfelu de vouloir sortir des séquences précises directement du PC

[azad]

Désolé, je ne comprend plus….
Tu as conçu le circuit toi-même et il fonctionne correctement. Alors, tout est bel et bon !
Tu sais ce qui est entrée, n'ignore rien de ce qui est sortie… alors tu peux établir une table de vérité. Où donc est le problème ?
Si c'est pour une simple question d'école, par exemple pour servir de sujet d'étude, alors tu n' as qu'à diminuer la vitesse de fonctionnement, placer quelques indicateurs sur ta carte et son fonctionnement sera clair. Exactement comme on le fait souvent quand on écrit un programme un peu volumineux : on crée une fenêtre de débogage et on y affiche les états des variables, ou n'importe quoi d'autre. Et du coup, l'acheminement via des ports USB ne posera plus de problèmes.
J'ai écris plus haut qu'il te fallait revoir ta copie. En l'occurrence il apparaît maintenant que tu cherches à activer ou désactiver quelques-unes des portes qui composent ton montage. Hé bien prends des portes en tri-state et rajoute une ligne d'entrée qui va directement commander ces portes. Ou des latch, ou des switch digitaux, rien qu'en CMOS ou TTL, la panoplie est vaste.

[jiherve]

Bonsoir,

J'ai pas l'impression que tu saches ce qu'est de l'USB. L'initialisation d'un périphérique implique toute une partie d'échanges "intelligents" avec l'hôte, énumération, ré-énumération éventuelle, négociations sur le courant utilisable par le périphérique, etc.

Ftorama, la c'est un presque pastiche de l'arroseur arrosé car tout ce que tu mentionnes, et que je connais aussi (une petite recherche sur ce forum pourra te rassurer à ce sujet), est prit en charge par l'adaptateur qui est je le rappelle est USB <=> parallèle.
il y a aussi USB <=> I²C avec (si si cela existe aussi).
5S de gogol avec adaptateur USB parallèle ou autre éclairera ta lanterne.
Et le monsieur qui demande il dit et répète que les calculs sont faits sur son PC, c'est tout de même facile de lire et de comprendre!
JR

[Forhorse]

Et moi je vois pas en quoi un convertisseur USB - parallèle sera plus rapide que ce qui à déjà été essayé. C'est quoi le débit max de ce genre d'appareil ?
Et puis il faut 24 sorties à ce que j'ai compris, alors on fait comment ? on en met 3 ?

[jiherve]

Re
Le besoin semble être de l'ordre de la dizaine de KHz donc avec un port tenant au moins 30K il suffira de transmettre trois octets, et un peu d’électronique en plus, rien n'est jamais gratuit.
JR

[Forhorse]

sponsorisé par GDF-suez

[MiGaNuTs]

Un raspbery pi plutot qu'un PC ce me semble pas mal pour lire tres vite des fichiers puis "ecrire" des trucs directement sur des sorties.

Si je me rappelle bien il y'a 40 GPIO dessus.
Lire des fichiers ca ne lui pose pas trop de soucis je pense.
Se programmer en C ou en C++ ca tombe assez bien vu pour lui aussi.
Code::Blocks, GCC et roule.

[bobflux]

Je réponds à l'OP.

Il faut savoir si le machin nécessite du temps réel dur, ce qui implique une vitesse de réaction maîtrisée, ou pas.

J'ai l'impression que tu veux juste envoyer des données, et qu'elles sortent d'un port quelconque à un débit assez lent (qq dizaines de kHz), sans que le PC ait à réagir, mais tout de même avec un timing assez précis.

Dans ce cas, il faut évaluer le débit de données : nombre de bits * fréquence d'actualisation, et une connection USB sera probablement adaptée.

[ftorama]

Un raspbery pi plutot qu'un PC ce me semble pas mal pour lire tres vite des fichiers puis "ecrire" des trucs directement sur des sorties.

Si je me rappelle bien il y'a 40 GPIO dessus.
Lire des fichiers ca ne lui pose pas trop de soucis je pense.
Se programmer en C ou en C++ ca tombe assez bien vu pour lui aussi.
Code::Blocks, GCC et roule.

Un Cortex-M0 ou un M3-M4 devraient largement suffire pour extraire les séquences d'une carte SD, les bufferiser et les rebalancer sur les ports de sortie. A mon avis, avec le Raspberry (et encore plus avec un PC), on prend un marteau pour écraser une mouche. Et là aussi, ça se programmera en C/C++ avec une relative simplicitépour un développeur avec les librairies CMSIS.

[gienas]

Bonjour à tous

Merci de ne pas polluer les discussions en cours.

La charte "prévoit" un sujet par discussion.

Si d'autres questions se posent, il convient d'ouvrir une nouvelle discussion, avec un titre adéquat.