Choix d'un microcontroleur / carte à microcontroleur

[bisou10]

Salut,

Aujourd'hui j'ai des contraintes bien spécifiques: je dois exécuter,entre autre, une boucle à 50us. Petite (un calcul simple et en fonction la commande de quelques bits), mais périodique dans un certain mode, beaucoup moins dans un autre. Cependant, je suis obligé de me tenir aux 50us quand je suis dans ce mode, qui peut durer.

Comme je suis un vieux renard, je voudrais bien une carte type Raspberry PI. Uniquement pour y mettre un noyau linux, manière d'avoir un peu de flexibilité. Et pour être déterministe, tournant sous Xenomai. Ben oui !

Par contre 50us... c'est rapide. J'ai peur que l'overhead système joue "un peu". Les couches du noyau, toussa.

Le souci, maintenant, c'est que je voudrais justifier que je tiendrais 50us. Et là, je sèche un peu. J'ai du mal à faire la relation entre les MIPS, la fréquence du CPU, et ce que me prendra l'ordonnanceur Xenomai.

Je pense aussi à faire travailler le GPU pour cette boucle, mais pareil, comment justifier que je rentre dans ces 50us ? Ca fait 20kHz pour une boucle soft.... hmmm.

De manière générale, comment vous garantiriez 20kHz ? Avec Linux?
Sans Linux, j'ai le même souci, cependant, bien que je me sente directement plus à l'aise pour avoir le contrôle des timings sur une IT timer overflow.

Je sens qu'a part le maquetter...
-----

[mayonaise]

C'est quoi ton calcul, une addition ou une diagonalisation de matrice 987654321 x 987654321 à arguments complexes ?

[bisou10]

La vérification de 3 ou 4 IOs numériques, 2 tests de comparaisons et la mise a jour de quelques variables de statuts. Le traitement sera rapide (j'ai bien conscience qu'il ne faudra pas trainer de toutes façons). Au pire je m'arrangerais pour avoir un calcul simpliste pour pouvoir tenir les perfs.

[Aurélien]

Bah prends plutot un arduino...

[A voir en vidéo sur Futura]

[bisou10]

Merci Aurélien, mais si tu lis le post initial, mon problème c'est de savoir le justifier...

[Aurélien]

Ben alors faut pas dire dans ton sujet "choix d'un microcontroleur" ...
J'ai cru comprendre que tu pensais prendre un raspberry. Je trouve que c'est démesuré et risqué pour le niveau de précision que tu veux, donc je te conseille un arduino. Je ne suis pas compétent pour aider sur raspberry

[mayonaise]

Si tu cherche à connaitre les temps d'execution d'un programme avec un OS temps réel, tu devrais essayer de collecter des infos sur les forums dédiés à ces logiciels, je ne sais pas comment connaitre le temps par boucle sur un arduino, il faut voir le code assembleur généré, mais je ne connais pas finement non plus le fonctionnement du bootloader. A froid comme ça, je dirais qu'au vu de tes objectifs, un PIC programmé en assembleur (trolling interdit, je ne connais que ces µC, raison de la proposition) te donnera satisfaction pour moins de 2€, ça compte comme argument face au raspberry pi ? L'assembleur est à ma connaissance le seul moyen de connaitre les temps d'execution exacts et tu peux toujours associer un watchdog serré qui viendra rectifier le tir en cas de plantage.

[Ridezebigone]

Bonjour,

un OS temps réel et du C écrit avec des connaissances de temps réels permettent de connaitre précisément le temps pris par chaque fonction. Mais bon, ce n'est plus vraiment à la portée d'un bricoleur...

sinon, je suis assez d'accord avec les remarques précédentes, un rpi + linux pour traiter qqles I/O et faire un calcul, autant prendre un PC qui tourne au GHz, tu pourras coder avec tes pieds et tu auras de la marge pour assurer tes 50us de latence.
Sinon avec un microcontroleur bien choisi (arduino, pic et autre) et un peu de rigueur ça doit le faire.

pour info, avec un ARM9 qui tourne à 400Mhz et un linux (distri faite 'maison'), il est difficile de tenir des timings inférieurs à 50ms. Avec un Rpi 'standard', tu ne feras pas beaucoup mieux. il te faudra utiliser un os temps réel, il y a des sites qui peuvent t'aider à installer un RTOS sur un Rpi, mais encore faut il savoir comment bien coder l'application ensuite.

A+

[grosmatou75001]

Si tu cherche à connaitre les temps d'execution d'un programme avec un OS temps réel, tu devrais essayer de collecter des infos sur les forums dédiés à ces logiciels,

+1 Il y a des gens bien compétents sur fs mais sur ce genre de trucs très spécifiques tu risque de ne pas avoir de chance...

un PIC programmé en assembleur

Moi je ne connais que les AVR. Les meilleurs tournent à 20MHz, ça fait 1000 coups d'horloge par cycle (donc tout les 50µs) pour faire le calcul sachant que les instructions prennent entre 1 et disons 4 coups par instruction. Au pire on prends de l'assembleur et le problème me semble tout à fait réglable. Si on doit interfacer le truc on peut toujours rajouter une liaison série / I2C / SPI avec un RaPI ou autre chose.

L'assembleur est à ma connaissance le seul moyen de connaitre les temps d'execution exacts

Oui, mais le code assembleur peut très bien être du C digéré par un compilateur. Le résultat est souvent difficile à comprendre mais pour connaître le temps d'exécution il suffit de mettre un breakpoint au bon endroit et de lancer le simulateur...

[Aurélien]

L'assembleur est à ma connaissance le seul moyen de connaitre les temps d'execution exacts et tu peux toujours associer un watchdog serré qui viendra rectifier le tir en cas de plantage.

Non, pour faire une tempo, on peut aussi (et encore heureux !) utiliser les modules timers présent dans tout microcontroleur. Ca décharge le programme du décompte et lui permet de faire autre chose en attendant.

[grosmatou75001]

Oui bien sûr, pour une action qui doit être répétée tout les x µs on utilise un timer! Ma remarque concernant l'assembleur se rapporte au cas où on veut savoir si le code qu'on a écrit (en ASM ou en C ou en n'importe quoi finalement) prend trop de temps ou pas.

[bisou10]

Alors, merci de vos retours.

Je programme souvent des PICs. Oui, une IT sur timer overflow me garantira 50us.

Je programme aussi des ARMs sous Xenomai (extensions RT du kernel Linux, utilisable en userspace). Je sais bien entendu maitriser le temps d'une tâche, mais pas dans ces proportions (ca commence à drifter à partir de 1ms sur les boards que je teste).
L'avantage de la RPi, c'est que je continue à faire tourner Linux, et donc j'ai plein d'outils, je peux gérer une stack ip en natif, les accès aux bus SPI/I2C, les librairies de gestion de LCDs, etc...

Mais 50us, c'est chaud chaud cacao même pour Xenomai. Mes maquettages rapides sont que, sur un RPi, je suis en timeout avant de rentrer dans ma fonction de test. Je suis en train de maquetter sur un 18F en ce moment, à 8 MIPS, on verra ce que ca donne.

La solution vers laquelle je me dirige c'est moitié-moitié. Ma fonction rapide sera sur un PIC, le reste sur la RPi, parce que je sais que je vais avoir de l'i2c à 400kHz et du spi sur ce projet. Et là, j'apprécie mon bon vieux Linux, parce que je gagne un temps fou.

Sinon, je code en C, et j'ai trés trés rarement eu à regarder l'assembleur généré. En fait le compilateur est assez performant pour m'éviter cette phase

Thx guys !

[terriblement]

salut,

j'ai eu à gérer une transmission de donnée "pas orthodoxe", avec une péridoe de 16µs, avec mon PIC ca a très bien marché.

Donc je plussoie, un pti micro pour faire les choses rapides, qui communiquera ses résultats au PC d'une quelconque manière.

[bisou10]

Tu peux me dire quel est le modèle de ton pic ?

[Aurélien]

Tu peux me dire quel est le modèle de ton pic ?

Ca n'apportera rien à la discussion, tout PIC ou autre micro bas niveau est capable de faire ce que tu veux.

[bisou10]

Aurélien, c'est à moi d'en décider... Merci de ne pas présumer ce qui m'intéresse ou pas.

Une référence ca me parle. Un commentaire disant que "oui ca marche", beaucoup moins.

[Aurélien]

Aurélien, c'est à moi d'en décider... Merci de ne pas présumer ce qui m'intéresse ou pas.

Tu es sur un forum, tu décides de poser ta question. Je suis sur un forum, je décide d'y répondre. Tant pis si ça froisse ton égo, mais ta question est inutile.

Une référence ca me parle. Un commentaire disant que "oui ca marche", beaucoup moins.

Dans un post tu dis que tu sais programmer les PIC, que tu les connais. Donc tu as déjà travaillé avec des PICs. Et comme je te dit que ce que tu veux faire est faisable sur N'IMPORTE QUEL PIC dans quelque langage que ce soit, je te redis : la question de savoir quel autre PIC a utilisé quelqu'un d'autre n'a aucun sens. Ou alors c'est que tu ne sais pas du tout de quoi tu parles.

Aurélien

[terriblement]

Pour info :
18F46K22

Il y a des versions avec largement moins de PIN si tu n'en as pas l'utilité

[bisou10]

Nous y voila.

Tu es sur un forum, tu décides de poser ta question. Je suis sur un forum, je décide d'y répondre. Tant pis si ça froisse ton égo, mais ta question est inutile.

Merci tu as tout dit. Tu fais des réponses qui n'en sont pas, "Utilise un Arduino", "Ca ne t'apportera rien". Bizarrement, moi je vois ça à l'envers: tant pis si ca froisse ton égo, mais tu n'es pas obligé de répondre. Tu peux m'expliquer pourquoi ma question te parait inutile, mais après les réponses laconiques... Bof bof.

Dans un post tu dis que tu sais programmer les PIC, que tu les connais. Donc tu as déjà travaillé avec des PICs.

Belle généralisation. Contrairement à toi sans doute, je ne prétends pas maitriser tous les aspects. Je n'ai jamais eu un tel timing à tenir, et que je m'inquiete légitimement d'y parvenir. Demander une référence est une bonne base. Si tu n'en es pas persuadé, moi je le suis, et ça me rend service. Tu peux argumenter en m'expliquant qu'un 12C est capable de le faire, et tu seras bienvenue. Mais là....

Ok, on s'est expliqué, fin de la parenthèse.

@terriblement: merci.

[terriblement]

comme le souligne Aurelien, tu peux prendre N'IMPORTE quel PIC, il sera capable d'effectuer un interrupt toutes les 50µs.

Tu peux cliquer sur n'importe quelle case et en prendre un au hasard, ça marchera:
http://www.microchip.com/pagehandler...crocontrollers

[mayonaise]

Juste histoire de troller hein, si je prend un 10F200 à 4Mhz max, il les fait commpent les lectures de valeurs analogiques en 50µs ?

Sinon, dans ton cas, la seule contrainte que je vois à ton choix de microcontrôlleur c'est :

• Quelle familles sais-je programmer ?
• De combien d'entrées sorties TOR j'ai besoin ?
• De combien d'entrées sorties ana j'ai besoin ?
• De combien de ports de communication j'ai besoin ?
• Et puisque je connais ma famille que je sais programmer, combien d'instruction de combien de cycles seront nécessaires à la réalisation de mon programme (ce qui me donnera la vitesse minimale de fonctionnement de mon µc et la taille de mémoire programme nécessaire) ?

On réunit les critères et on prend le moins cher.

Après, histoire de continuer le trolling, ceux qui aiment les trucs performants savent coder des µcontrôlleurs qui font toutes leurs instructions en 1 cycle ... Comme les PIC qui sont bien sûr la seule solution valable à n'importe quel problème

[bokan]

Peut être que je dis une grosse bêtise, mais je me lance quand même.

Que dirait-tu d'utiliser un FPGA ? Y'en a des simples et pas cher. Et là si ton code est réalisable, il me semble qu'il n'y aura plus de problèmes pour justifier les performances.

J'étais tombé sur ce projet sur Kickstarter il y a quelques temps :
http://www.kickstarter.com/projects/...d-freesoc-mini
http://moeller.io/

[mayonaise]

Les FPGA, je connais pas, mais j'ai vu des astuces pour en récupérer des moins chers que ceux que tu propose sur ce post : http://www.taylorkillian.com/2013/04...or-color3.html le mec utilise des accessoires qui améliorent les couleurs sur un signal hdmi et qui sont basés sur les FGPA. Ca vaut 10$ et mériterai d'y passer du temps. En tous cas, l'idée de faire ça avec un FGPA est très maline si on sait s'en servir

[terriblement]

Je ne connaissais pas l'existence des PIC10, autant pour nous

[mayonaise]

autant pour nous

Au temps pour vous lien expliquant cette particularité de langage

[Gérard]

Au temps pour vous lien expliquant cette particularité de langage

"Temps ou tant", peu importe, il reconnait ne pas avoir connu les 10F. Ce n'est pas grave en soi, tout le monde s'en remettra.

[mayonaise]

Ma dernière remarque n'était bien sûr destinée qu'à être interprétée à la manière d'une anecdote, j'ai fait l'erreur bien plus souvent qu'à mon tour à ce sujet avant de découvrir cette particularité qui mérite d'être partagée. J'espère que terriblement ne sera pas autant piqué au vif que tu ne semble le craindre et si c'est le cas, je le prie de bien vouloir accepter mes plus humbles excuses...

[Aurélien]

Bah, vu que les académiciens ne sont même pas tous d'accord, je suis pas sur que ce forum soit approprié à ce genre de débat..

[terriblement]

Je connais l'origine de cette expression, les deux orthographes sont valables, enfin, tout dépends de l'académicien avec lequel on cause.

[bisou10]

je vais recentrer dans le sujet. Au temps pour moi (oups!) ) , le FPGA est un solution qui a été éliminée d'entrée (de mon côté je ne connais pas le VHDL donc je ne savais pas évaluer cet aspect, mais je n'ai pas eu à me poser la question).

Je suis définitivement parti sur une acquisition via un PIC, et une carte maitre pouvant utiliser SPI et I2C, sous Linux, avec éventuellement Xenomai (ce dernier point est encore à débattre, Xeno utilise un modèle de drivers spécifiques qu'il faut porter s'ils n'existent pas pour bénéficier d'un environnement déterministe complet).

Le PIC choisit va dépendre de mes calculs sur les temps d'acquisitions AN, et de la façon dont ca respecte (ou pas) mes timings.

Merci !