Choix d'un microcontroleur

[invitee2f07892]

Bonjour,

Dans le cadre d'un projet, il me faut réaliser un système permettant la mesure d'une vitesse d'un objet pouvant aller à 50 m/s . Je souhaiterai utiliser des capteurs lasers espacés d'une distance d=5cm (espace restreint), reliés à un microcontroleur tout simple et qui permettrait d'afficher la vitesse sur un petit écran.
Malheureusement, je n'y connais pas grand chose la dedans, et je me sens un peu perdu... Je ne sais pas quel micro pourrait convenir, tout en étant le moins cher possible.

Merci d'avance


-----

[BastienBastien]

Bonjour,

http://forums.futura-sciences.com/sh...ighlight=choix

Bonne lecture.

[mat64]

Dans tout problème de mesure, se poser la question de la précision, répétabilité, etc. Tu accepte quelle erreur ? 10 % ? 1 % 0.0001 % ? ça change tout...

Au fait, c'est pour faire quoi ? (je sais, je suis curieux...)

[invitee2f07892]

Merci, j'ai de la lecture en effet

Ce système doit me permettre de mesure la vitesse résiduelle d'un échantillon après s'être reçu un projectile (30 g.) à 350 m/s. Ceci afin de tester différents matériaux.
Concernant la précision, je pense qu'à 0,1 % près serait suffisant.

Niveau répétabilité, ce n'est pas énorme, 2/3 tests par jour je pense car il y a tout un système autour long à lancer...

[A voir en vidéo sur Futura]

[mat64]

Ce système doit me permettre de mesure la vitesse résiduelle d'un échantillon après s'être reçu un projectile (30 g.) à 350 m/s.

ah ah, ça accélère... hier on était à 50 m/s

...Ceci afin de tester différents matériaux...

tu fabriques des gilets pare-balles ?

Concernant la précision, je pense qu'à 0,1 % près serait suffisant.

tu dois donc mesurer des temps de l'ordre de 150 us. Pour 0,1% de précision, tu dois pouvoir cadencer le timer à 10 MHz en gros. En effet, ça doit pouvoir se faire avec un micro "simple et pas cher". Par exemple un PIC16F87, avec le timer 1 configuré en mode compteur.

Niveau répétabilité, ce n'est pas énorme, 2/3 tests par jour je pense car il y a tout un système autour long à lancer...

euh... pour moi répétabilité c'est surtout "entre 2 mesures, est-ce que j'ai deux fois la même erreur". Cette erreur étant donnée par la précision.

[invitee2f07892]

Bonjour,

En fait, la vitesse reste toujours la même, l'échantillon est monté sur un chariot et a donc une vitesse max de 50 m/s (ça sera plus vers les 30 m/s maintenant, vu que l'on a changé le chariot par un plus lourd)

Non, ce n'est pas pour des gilets pare balles . Les applications, on ne les connait pas exactement (contrat un tantinet secret apparemment)...Je trouve ça énorme de concevoir un produit sans réellement savoir à quoi il va servir.... Enfin...

Le PIC16/87 à 16 pattes, on m'avait dit qu'un 8 pattes (plus simples donc, non?) pouvait convenir. Qu'en penses-tu?

Comment savoir si un microcontroleur peut convenir ou non? Au niveau prog. il n'y en aura pas beaucoup, mais il doit quand même pouvoir gérer deux phototransistor et un petit écran.
On nous a appris à progammer (vite fait tout de même) les micro, mais pas à les choisir...

[BastienBastien]

Hello,

http://forums.futura-sciences.com/sh...ighlight=choix

Ca pourrait peut être t'aider un peu.

[RISC]

Ceavin,

Si tu as besoin de très peu de broches d'E/S (cela dépend de ton système de mesure), tu peux effectivement utiliser un beaucoup plus petit boitier.
Je pense en fait que ton choix doit être guidé par le périphérique le plus adapté à ton besoin, soit l'unité de timer en mode comptage d'impulsions, soit l'unité CCP en mode comptage de durée d'impulsion.

Tout va donc dépendre de la façon dont tu veux connecter tes capteurs au micro. Je ne suis pas sur que tu aies besoin de mettre un capteur tous les 5 cm (sauf si je n'ai pas bien compris la différence entre vitesse et vitesse résiduelle).

Dans le mode temps entre les 2 capteurs, tu aurais besoin seulement de 2 capteurs situés à une distance minimale toujours parcourue.

Peux-t-on dire dans ton cas que la distance de ton chariot est "fixe" ou qu'elle varie ? (j'imagine que dans tous les cas ton chariot parcourt une distance minimale)

Je te recommande d'utiliser le mode "capture" te permettrait par exemple de mesurer un temps entre 2 évènement (passage devant un 1er capteur, puis devant un second). La vitesse de ton projectile est donc le nombre d'impulsions internes écoulées entre ces 2 capteurs divisée par la distance (fixe et connue dans ton cas).

Pour pouvoir t'aider à choisir le PIC adéquat, je te recommande d'utiliser le programme de choix paramétrique MAPS que tu peux télécharger et installer sur ton PC (www.microchip.com/MAPS). Tu pourras saisir les paramètres que tu désires (nombre d'E/S, timers, type de boitier,...).

Je pense qu'un PIC comme le PIC12F615 pourrait convenir à ton application (il est capable de fonctionner dans les 2 modes utiles (comptage d'impulsions avec le TIMER1 ou mesure de temps avec l'unité ECCP couplée au timer1).

Pour mieux comprendre comment fonctionne ces périphériques, je te recommende le cours en français sur les PIC de Bigonoff (www.bigonoff.org) et aussi ce site : http://www.aix-mrs.iufm.fr/formation...indexPIC_C.htm

a+

[invite03481543]

Salut,

en utilisant 2 entrées "capture" tu as juste à compter le temps qui sépare 2 détections d'évènements avec une horloge comme base de temps.

Edit: oups, RISC à été plus rapide en mode capture.

[invite2562e666]

Bonjour

Les conseils donnés plus haut par le représentant microchip sont très mauvais:
- Tu devras afficher la vitesse, et donc commander un LCD, il te faut pour cela un minimum de 6 pattes et 0,5 ko de programmes
- il faudra encore 2 à 4 pins supplémentaires, pour les photo transistors, un bouton de remise à 0, l'entrée "signal" de départ, une led, ...
- Tu devra calculer une vitesse, et donc utiliser des flottants; ce qui nécessite quelques Ko de programme flash et un micro (et un compilateur) qui sache "gérer" cela.

Tout ceci est parfaitement impossible avec le pic (12f et 16f) que l'on t'a conseillé plus haut.
Je te conseille aussi très vivement d'éviter l'assembleur (à moins que tu aies quelques semaines à perdre) et de programmer tout cela en C, il y a moyen d'apprendre les bases en très peu de temps.

Au risque de me répéter encore, il existe dans d'autres marques que microchip des microcontrôleurs nettement plus simples, plus performants et plus faciles et moins couteux que les pics (AVR ATmega, Freescale MC9S08).

Pour ta réalisation, tu pourrais t'inspirer par exemple de mon capacimètre (qui utilise extensivement les flottants) donné ici (à base de Freescale MC9S08QG8): http://www.68hc08.net/modules/smarts...php?itemid=121
Le code source est donné (y compris la gestion LCD), il utilise les timer et une modification simple pourrait l'adapter à ton application.

thierry

[invite03481543]

Non thierry, un PIC16F est largement suffisant pour ce genre de chose.
Même si cela peut être fait sur un autre µC.

[mat64]

Quelques remarques à l'attention du représentant motorola

- Tu devra calculer une vitesse, et donc utiliser des flottants;

je vois pas bien ce qui justifie le "donc". ça dépends de la précision voulue, du temps dispo pour le traitement... Bien sur, c'est plus confortable en virgule flottante, mais c'est tout à fait possible de diviser en virgule fixe.

Tout ceci est parfaitement impossible avec le pic (12f et 16f) que l'on t'a conseillé plus haut.

rigoureusement faux

Je te conseille aussi très vivement d'éviter l'assembleur (à moins que tu aies quelques semaines à perdre) et de programmer tout cela en C, il y a moyen d'apprendre les bases en très peu de temps.

mouais... pour un programme simple comme celui la, c'est discutable. Il faut bien voir que le gros du temps qu'il va passer sur ce programme, c'est comprendre le fonctionnement du micro et de ses périphériques, et la, C ou asm, c'est kif-kif...

Ceci dit, je trouve très bien de rappeler qu'il existe autre chose que les PIC (bon, faudrait voir à être un peu moins catégorique quand même sur certaines affirmations...). D'ailleurs, quelle sont les raison qui font que le PIC revient sur le tapis de manière incessante (alors que les autres micros sont "nettement plus simples, plus performants et plus faciles et moins couteux" ) ?

edit: grillé par HULK

[BastienBastien]

Bonjour,

Je ne me risquerai pas (!!!) à prendre position en faveur de l'un ou l'autre fondeur, car je ne connais que les PICs (pour le moment), mais ce qui est sûr, c'est que ce ne sont pas toujours les produits les plus connus les meilleurs.

Par exemple, tout le monde sait que "Windows, c'est mieux, car tout le monde utilise ça", ou "Le lait n'est pas mauvais pour la santé, car tout le monde en consomme depuis toujours".

Non et non, je ne veux pas lancer de troll. C'était juste pour dire que le fait qu'un produit soit connu n'est absolument pas un argument valable. Les campagnes de pubs peuvent influencer durablement nos choix et l'on doit être très objectif, scientifique, "indépendant", pour faire les bons choix. Et puis, les habitudes nous enferment dans l'utilisation d'un produit qui peut être moins bien, mais que l'on connaît et maîtrise bien.

[invite03481543]

Je répondrai simplement que c'est comme pour les voitures, il y a des inconditionnels de tel ou tel marque, mais ce qui est certain c'est que toute les marques roulent et se vendent donc inutile de chercher plus loin une raison, chaque solution à son lot d'avantages et d'inconvénients.
Le tout est de savoir s'adapter aux inconvénients et de profiter des avantages.

[invite03481543]

Moi ce qui me surprend c'est qu'on entend jamais parler des STx, des Toshiba, Beck, Philips,....

[invite2562e666]

Bonjour, Hulk et Mat

J'ai effectivement été peut être un peu rapide en disant que un pic16F ne convenait pas (je maintiens pour le pic12, et j'ai encore oublié 2 pattes pour un quartz pour avoir la précision requise).
Cependant, il n'y a pas (à ma connaissance) de compilateur C pic16 de plus de 2ko gratuit, ce qui interdit l'emploi des flottants. Pour le pic 18, je doute qu'une version "student" gratuite soit (légalement) utilisable dans le cadre d'un contrat commercial. Encore faut il aussi que le pic16 ait une mémoire programme décente.
Quant au C, il me semble évident que c'est nettement plus facile d'écrire
vitesse=espace/temps; plutôt que de se taper un assemblage incertain de routines assembleur, après s'être "tapé" 100 pages pour comprendre comment marchaient les "banks" et les "pages".

Pour mat64 : il n'est absolument pas nécessaire de connaitre les détails de l'architecture pour mettre en œuvre des compilateurs, pas plus que l'asm n'est indispensable pour mettre en œuvre des périphériques (et dans le cadre de ce projet, il n'y a qu'un périphérique à mettre en oeuvre : un timer).

Pour répondre à mat qui se demande pourquoi le pic revient de manière incessante sur le tapis, je répondrais que :
- beaucoup de lycéens l'utilisent pour leurs cours, TIPE,...et il y a le cours de bigonof qui les cible parfaitement.
- Les 16F84 ont effectivement eu leur heure de gloire, étant les premiers à êtres abordables avec des outils de développement gratuits. Mais bon, c'était il y a 15 ans
- Si tu vas voir sur des forums allemands, ce sont des inconditionnels AVR, et les anglos-saxons sont aussi nettement moins branchés pic.

Pour terminer, Hulk, si tu ne l'as pas encore fait, vas voir mon post dans la section "projets", j'explique comment aborder à (très) peu de frais les ARM (Phillips, ATmel, ST, ....). donc je ne suis pas "unimarque".

thierry

PS: sur le site www.freertos.org, il est mis en évidence dans la section "microcontroller performance comparison" qu'un pic18 est 2x plus lent qu'un ATmega (et 10x plus lent qu'un ARM7 de même prix)

[DavidDB]

J'ai effectivement été peut être un peu rapide en disant que un pic16F ne convenait pas (je maintiens pour le pic12, et j'ai encore oublié 2 pattes pour un quartz pour avoir la précision requise).

Oui, c'est vrai que sans la moindre imagination un simple µC avec 6 I/O est effectivement incapable de faire le travail vu le nombre restreint de broches.

Mais en réfléchissant dix secondes on en arrive à pouvoir utiliser un µC avec 6 I/O...

1 broche pour l'horloge externe à quartz afin d'avoir une précision respectant le cahier des charges.
3 broches pour le LCD (Un registre à décalage, ça existe toujours)
2 broches pour les capteurs.

Sinon, pour le reste des propos de thm dans ces posts #10 et #16, je ne me fatigue plus à lui répondre...

P.S. : Dans mon post, je ne mentionne pas de marque, et donc c'est valable peu importe la marque du µC à partir du moment où la vitesse de traitement est suffisante.

David.

[invite2562e666]

C'est vrai que l'on pourrait également tout faire en logique classique, avec un pic pour lui faire jouer le rôle d'interrupteur, cela sera aussi un compteur de vitesse "à pic".

th

[mat64]

...il n'y a pas (à ma connaissance) de compilateur C pic16 de plus de 2ko gratuit, ce qui interdit l'emploi des flottants.

si, SDCC. gratuit et libre en plus.
De surcroit, on peut très bien faire des opérations sur des flottants en assembleur. Je me suis même laissé dire que certains fabricants (que je ne citerais pas pour ne pas froisser les susceptibilités) vont jusqu'a fournir les routines dans leurs notes d'appli.

Pour mat64 : il n'est absolument pas nécessaire de connaitre les détails de l'architecture pour mettre en œuvre des compilateurs, pas plus que l'asm n'est indispensable pour mettre en œuvre des périphériques (et dans le cadre de ce projet, il n'y a qu'un périphérique à mettre en oeuvre : un timer).

Si tu programmes des microcontroleurs sans connaitre les détails de l'architecture, on fait pas la même métier. Atention, c'est pas un jugement de valeur ni une attaque, l'informatique c'est tout à fait respectable, j'en fais de plus en plus d'ailleurs. Mais on parle pas de la même chose.
Quand a la mise en oeuvre des périphs, on s'est mal compris : je dis pas que l'asm est indispensable, je dis qu'en C ou en asm, de toute façon il faut comprendre comment marche le périph. Et que c'est bien ça qui risque de prendre le plus de temps. (parceque sur un prog simple comme celui la, coder 3 heures en asm ou 2 heures en C....d'accord on gagne un peu... mais le débutant qui se tape la datasheet il y passe 3 jours de toutes façon)

Pour répondre à mat qui se demande pourquoi le pic revient de manière incessante sur le tapis, je répondrais que :
- beaucoup de lycéens l'utilisent pour leurs cours, TIPE,...et il y a le cours de bigonof qui les cible parfaitement.
- Les 16F84 ont effectivement eu leur heure de gloire, étant les premiers à êtres abordables avec des outils de développement gratuits. Mais bon, c'était il y a 15 ans
- Si tu vas voir sur des forums allemands, ce sont des inconditionnels AVR, et les anglos-saxons sont aussi nettement moins branchés pic.

Ces explications me vont. La première fois que j'ai du utiliser un micro (j'étais encore à l'école), j'ai lu la datasheet d'un ST ou AVR (je me rappelle plus). Rien compris. Le 68HC11, on l'avait fait en TP, j'en parle même pas. Puis j'ai lu la datasheet du PIC, tout était clair, pas besoin de relire 2 fois. Ce jour la les autres ont perdu un client. Alors peut être que depuis ils se sont mis à niveau... Un jour je regarderais. ça sert d'être le premier sur le coup des fois...

PS: sur le site www.freertos.org, il est mis en évidence dans la section "microcontroller performance comparison" qu'un pic18 est 2x plus lent qu'un ATmega (et 10x plus lent qu'un ARM7 de même prix)

Tu sais, quand je bossais sur les DSP, en gros y'avait Analog et TI qui se tirraient la bourre. Chacun t'expliquait benchmark à l'appui que l'autre était à la rue (c'est marrant, ils étaient tous les 2 "world leader"). Alors les benchmark...C'est trop dépendant de l'appli et du programmeur pour être significatif.

Sinon, pour le reste des propos de thm dans ces posts #10 et #16, je ne me fatigue plus à lui répondre...

Je pense qu'il a tort sur certains points, raison sur d'autres, en tout cas il est fort désagréable dans la manière péremptoire qu'il a de présenter les choses.
Maintenant, il ne s'agit pas de faire une guéguerre pour ou contre tels produits, ni de se chamailler avec thm. Je tiens juste à corriger certaines choses pour celui qui a inité le post et les passants qui liront tout ça...

Je comprends qu'il soit agacé par l'omniprésence des pics sur le forum. Maintenant on peut rappeler qu'il y a d'autres choses qui existent en soulignant leurs qualités, sans pour antant descendre exagérément les autres solutions.

Je réponds PIC parceque je connais. thm, donne des solutions avec d'autres micro mais ça:

Les conseils donnés plus haut par le représentant microchip sont très mauvais

c'est très désagréable.

[DavidDB]

Je demande à voir ta version en "logique classique" capable de gérer et afficher une suite de message sur un LCD!!!

P.S. : faudrait aussi prendre deux minutes pour analyser un LCD alphanumérique du commerce à interface série, et te rendre compte que ce type (oh surprise...) utilse la plupart du temps un registre à décalage pour communiquer avec le contrôleur LCD...

David.

[invite2562e666]

[QUOTE=mat64;1642447]

si, SDCC. gratuit et libre en plus.

Un clic sur ton lien montre le statut de ce compilateur "work in progress".

Tu as l'air d'un professionnel.
En tant que professionnel, utilises-tu ou utiliserais tu ce compilateur, qui fait d'ailleurs l'objet de nombreuses critiques sur d'autres forums, pour tes applications commerciales (sauf si tu es absolument obligé d'utiliser des pics)?

Utiliserais tu un pic à 8 pattes pour l'application proposée ?

Si non, ce n'est pas très honnête de ta part de le défendre.

La première fois que j'ai du utiliser un micro (j'étais encore à l'école), j'ai lu la datasheet d'un ST ou AVR (je me rappelle plus). Rien compris. Le 68HC11, on l'avait fait en TP, j'en parle même pas. Puis j'ai lu la datasheet du PIC, tout était clair, pas besoin de relire 2 fois. Ce jour la les autres ont perdu un client.

Cela explique le côté émotionnel de ta réponse. Pour ma part, j'ai lu le cours de bigonof (j'ai compris) et je me suis dit que ceux qui avaient inventé de telles choses devaient avoir des noeuds dans le cerveau.

Tu sais, quand je bossais sur les DSP, en gros y'avait Analog et TI qui se tirraient la bourre. Chacun t'expliquait benchmark à l'appui que l'autre était à la rue (c'est marrant, ils étaient tous les 2 "world leader"). Alors les benchmark...C'est trop dépendant de l'appli et du programmeur pour être significatif.

C'est un argument émotionnel. Et l'auteur des test ne cherche pas à dévaloriser les pics puisqu'il est même référencé comme "third party" sur le site de microchip.
Cela met quand même en évidence, (sans en faire une généralité à 100% des cas) quand même que l'architecture pic18 ("high performance", "high end") est loin d'être la plus efficace et ce qui se fait de mieux.

Je comprends qu'il soit agacé par l'omniprésence des pics sur le forum

thierry

PS: j'en arrête personnellement là pour ce post.

[mat64]

PS: j'en arrête personnellement là pour ce post.

moi aussi, ça ne mène pas bien loin.... dommage, on aurait pu débattre objectivement des avantages et inconvénients de telle ou telle famille...

Sans rancune ; sur une autre discussion, montre ce qu'on peut faire avec un autre micro, si ils sont mieux qu'un PIC ça apparaitra tout seul. Nous quand on propose une solution "PIC", on dit pas : le micro tartampion est pourri, avec un PIC c'est mieux. On dit juste : voila comment résoudre le problème avec un PIC.

[DavidDB]

Utiliserais tu un pic à 8 pattes pour l'application proposée ?

Cette question ne se pose pas, vu que la question est :
Est-ce faisable avec 6 I/O ?
La réponse est très claire c'est oui. Evidemment c'est faisable mais il faut s'adapter.
Je t'ai donné une solution afin de te monter que c'est possible.

En espérant ne pas être à nouveau censuré.

David.

[Jack]

En espérant ne pas être à nouveau censuré.

Ne voulant pas perdre le contenu utile de la discussion, j'ai tenté d'expurger tout ce qui représentait des attaques personnelles .

J'espère que la suite se fera dans un esprit constructif et de respect mutuel.

Merci

[invite03481543]

Ca serait bien en effet.

Je me disais même que les discussions autour des µC et/ou langages amènent à peu près toujours au même débordement passionnel, pourquoi ne pas mettre en oeuvre cette fois 2 solutions (PIC et freescale) que chacun pourrait intelligemment argumenter afin d'apporter une vrai démonstration?
La problématique n'est pas si compliquée donc la mise en oeuvre ne pose pas de soucis majeur, le tout est de montrer comment une vrai solution peut émerger de plusieurs autres (technique et économique).
C'est notre quotidien à nous ingénieurs de développements, parfois on est fortement inspiré parfois beaucoup moins, c'est humain.

Au moins ça servira utilement de support aux discussions futures qui ne manqueront pas de resurgir un jour ou l'autre.
Une démonstration vaut toujour mieux qu'un long discours stérile.

Et en plus on mettra tout ça dans le forum des projets afin que tout le monde puisse profiter de ce travail.
Jack et moi nous ferions l'arbitrage (objectif et neutre) pour chaque camp.
Alors partant?
Si oui, bravo de vous impliquez et de prouver aux autres vos affirmations, sinon il vaut mieux s'abstenir de tout commentaire virulents, du moins c'est mon point de vue.
Cordialement.
@+

[mat64]

je plussoie.

[invitee2f07892]

Bonjour à tous,

Merci beaucoup pour vos réponses, on sent que vous vous impliquez....
Malgré cette "guerre des marques", je pense me tourner vers un motorola, car c'est là dessus que l'on a été "formé", étant donné que le temps presse....

Encore merci

[invite2562e666]

Bonjour, ceavin

Dans ce cas, n'hésite pas à poser tes questions sur www.68hc08.net où tu trouveras tout le support et l'aide nécessaire pour mettre en œuvre ton µC.

thierry