[Débutant] MicroPIC ou arduino ?

[invitef5199dde]

Bonjour,

J'ai eu l'occasion il y a quelques temps déjà, lors de ma terminale, de faire un peu d’électronique ( des liaisons Zigbee en bluetooth, des combos d'allumage de leds, bref ce genre de choses ) et j'aimerai m'y remettre tout seul à la maison.

J'avais appris à l’époque à l'aide d'un PICmicro ( voici la DT : http://www.matrixtsl.com/resources/f...EB006-30-9.pdf ) et de différents Eblocks de chez Matrix ainsi que d'un PIC16F877 de chez Microship.

Dans la mesure du possible, j'aimerai recommencer sur ce que je connais déjà ( question de facilité ) mais d'après ce que j'ai pu observer, l'arduino est beaucoup plus présent et populaire sur le net ( par conséquent, l'aide doit également être plus simple à demander. )

Mes questions sont :

Quels sont les différences entre Eblocks et arduino ?

Pourquoi choisir l'un et pas l'autre ?

Quoi acheter pour avoir une valise de remise à niveau pour pas trop cher ?

Les Eblocks sont-ils compatibles avec Arduino ?

Peut-on brancher un Raspberry Pi sur l'un ou l'autre ?

Merci beaucoup.
-----

[antek]

Je ne connais que M BIGONOFF qui propose des cours sur PIC en assembleur : http://www.abcelectronique.com/bigonoff/

[mag1]

Bonsoir,

Toujours la même question: Pour quoi faire??

Approche professionnelle : ça marche pas, mais tu sais pourquoi.
Approche amateur : ça marche, mais tu ne sais pas pourquoi

MM

[invite5637435c]

Dans la mesure du possible, j'aimerai recommencer sur ce que je connais déjà ( question de facilité ) mais d'après ce que j'ai pu observer, l'arduino est beaucoup plus présent et populaire sur le net ( par conséquent, l'aide doit également être plus simple à demander. )

Bonjour,

c'est une fausse impression, l'arduino se répand certes mais est encore très loin coté sérieux des sites traitant de microcontrôleurs dignes de ce nom...
Et une bonne partie des sites et surtout de blogs arduinesque est aussi clownesque, coté conseils vous risquez surtout "d'apprendre" bon nombre de niaiseries.

Optez pour des sites plus sérieux où ce qui circulent est accompagné de conseils de gens qui pratiquent sérieusement et comprennent parfaitement ce qu'ils font et surtout font le ménage parmi la foultitude d'approximations pour rester poli.

Si vous avez déjà pratiqué un peu avec Microchip vous avez donc la base nécessaire pour comprendre la grande majorité des µC 8 bits du moment.
Voici un site sérieux où vous pourrez trouver une montagne de ressources, des platines d'expérimentations, des conseils, des kits, un forum et plein d'autres choses encore:

http://www.mikroe.com/store/

Vous y aurez le choix (arm, PIC, AVR, 8051) ainsi que coté compilateurs où vous ne payez qu'une seule fois (licence à vie), donc bien loin des pratiques habituelles et ce pour un prix bien inférieur.
Ne succombez pas au Mc Do de l'électronique, vous n'apprendrez rien de consistant, même pour des loisirs investissez dans quelque chose qui peut-être vous servira un jour, qui sait? Et le plaisir n'est pas du tout le même quand on peut maîtriser même un petite partie, et peu à peu devenir indépendant, contrairement à ce que propose arduino qui finalement ne fait que vous imposer absolument tout, avec toujours le porte-feuille ouvert... et en utilisant un langage qui se rapproche plus de l'argot que du C.

Sur ce forum vous trouverez également toutes les réponses que vous vous posez, nous sommes là pour ça.

[A voir en vidéo sur Futura]

[RISC]

Salut Densha,
Si tu veux démarrer avec un budget très réduit et des résultats rapides, l'Arduino est très probablement la meilleure voie : des millions d'exemples sur internet, des cartes à des prix très faible, de l'open source soft et hard (si tu aimes la soudure ;=)
Les produits Matrix sont excellents et très utilisés dans l'éducation mais leurs modules sont relativements chers pour un particulier...
a+

[invite5637435c]

Parles nous donc un peu des autres solutions à base de Arm, de 8051, de Zilog, de NXP, de Freescale, etc
Avec des liens vers ces solutions.
Juste pour voir si tu en es capable.

[invite5637435c]

Plutôt que faire la sourde oreille à mon post précédent le tien, argumente un peu ta phrase:

"Si tu veux démarrer avec un budget très réduit et des résultats rapides, l'Arduino est très probablement la meilleure voie".

Tu vois je t'offre la possibilité de chiffrer ton affirmation et ainsi de pouvoir comparer avec les autres solutions que tu tais volontairement.
Le but étant de montrer à tous à quel point tu es intéressé par tout ça, au détriment de la seule chose qui prévaut ici sur ce forum: l'information sans intérêt donc à 180° de ta position.

[invitee05a3fcc]

Plutôt que faire la sourde oreille à mon post précédent le tien....

Sauf que notre ami RISC n'a pas encore lu ta prose :

Dernière activité Aujourd'hui 08h40

[invite5637435c]

Ton ami peut-être mais pas le mien.
Un gars qui vient faire des heures sup pour plébisciter sa marque contrairement à la charte n'est pas mon ami.
Entre temps un de mes posts a été supprimé par la modération ce qui est un paradoxe quand je vois le sien encore présent et pas objectif pour deux ronds.
Donc je persiste à lui demander de se justifier sur sa phrase et à le démontrer sans quoi cela s'appelle de la publicité déguisée.

[bobflux]

Comme d'habitude, ça tourne à la foire d'empoigne.

Je propose un sticky : comment choisir un micro ?

A) Déterminer les besoins spécifiques de l'application, et en tirer les conséquences sur...
1) Les périphériques nécessaires :

ADC - Fréquence d'échantillonnage? bits? nombre d'entrées? single-ended/différentiel? etc.
Choisir le type d'ADC :
- SAR (rapide et échantillonne à un instant précis, mais peu de bits)
- DualSlope (lent, précis, intègre durant une période au lieu d'échantillonner, donc meilleure réjection du bruit)
- SigmaDelta (lent, précis, excellente réjection du bruit...)

Bien considérer le fait qu'un capteur numérique (genre DS18B20) est largement plus simple à utiliser qu'une chaîne d'acquisition analogique.

Périphériques :
- Besoin de PWM triphasé avec machine à états intégrée ? et un comparateur analogique ?
- Ou de N ports série ? SPI? etc?
- 2 ports I2C peut-être ? ou un ?
- Périphériques un peu exotiques genre SGPIO
- Ethernet? USB? Wifi?

2) Les IO
Il faut bien sûr que le uC ait assez de broches d'IO pour ce qu'on veut faire avec ! Parfois un extender I2C est pratique, parfois non.

3) Le flashage et la prog
Regarder comment le uC se programme, le coût du programmateur, si c'est facile de faire un bootloader, etc.
Si le uC ne supporte pas l'ISP, poubelle.
Les outils de dév sont-ils bien foutus et quel en est le prix?
Le programmateur supporte-t-il le debug ISP?

3) Puissance
Estimer le besoin en RAM et en Flash. Pour une application amateur, mettre quelques euros de plus et prendre le modèle qui a le plus de RAM/Flash dans la série considérée, parce que c'est bien de pouvoir compiler en mode debug et rajouter des logs sans péter la flash.
Est-ce qu'il y a une flash SPI externe? Ou interne?
Estimer le besoin en puissance de calcul, savoir si c'est un peu de DSP (ou beaucoup), ou gérer un LCD graphique sans ramer par exemple... ou gérer de l'ethernet 100Mbps sans flancher ?

4) Énergie
C'est alimenté par une pile bouton ou par le secteur ? Les candidats pour ces deux scénarios seront différents !

5) Tension
Il faut que ça tourne sous 1v8 ou 5V?
Si on a des périphériques en 5V, les entrées du uC sont-elles 5V-tolerant? Prendre en compte les complexités additionnelles du "voitage translation", on a vite fait de se retrouver avec plein de chips en plus si on part mal...
Est-ce que la fréquence d'horloge cible est toujours dispo quand l'accu est en fin de décharge ?
etc.

6) Existant
Ton expertise dans l'utilisation d'une certaine famille de uC, ou au contraire, ta volonté d'en apprendre une nouvelle.
As-tu du code existant et non portable?
As-tu déjà le programmateur, le soft sur ton PC?

Tous ces paramètres permettent de mieux cibler le produit dont on a besoin. Bien sûr, si l'application est de type générique et ne nécessite rien de folichon (genre, 99% des applications arduino), alors c'est là qu'on a un problème : il y a trop de choix et tout le monde vend sa soupe.

Personnellement, voilà ma soupe :

- Arduino :

Les Plus :
- Très bien comme plateforme de dév pour le uC qui est dessus. Le fait de trouver un LCD à 5€ qui s'enfiche au lieu de se prendre le chou à le souder est excellent aussi.
- Beaucoup de tutoriels dispo, et énormément de libraries et de code.
- Clones chinois pas chers
- Utilisable aussi par les handicapés de l'anglais

Les Moins :
- L'outil de dév est à chier (un simple éditeur de texte + makefile est largement mieux)
- Le runtime arduino est... super lent... (mais t'es pas obligé de l'utiliser)
- La plupart des libs sont codées avec le pied gauche (je rigole pas!) et certaines ne fonctionnent carrément pas
- Pas de debug
- uC obsolète

- ARM Cortex-M0, M3

Les Plus :
- 32 bits, pas de restrictions débiles style mémoire segmentée, ni PROGMEM... ni rien... tellement simple !
- Puissants, rapides, grosses Flash/RAM en général
- Pas chers pour les perfs
- Environnements de dév: LPCXpresso est pas mal du tout
- Timers 32 bits tout le tour du ventre
- Le contrôleur d'interruption NVIC est une oeuvre d'art
- à partir du M3/M4 c'est la fête du slip sur la connectivité : USB, Ethernet, tout le bazar, ADCs qui déchirent, etc...

Les Moins :
- Manque de tuto et de doc
- Les handicapés de l'anglais sont exclus d'office
- Sur les uC récents (LPC...) les libraries sont parfois un peu ... jeunes. Et buggées. Ça dépend.
- Pas trop de périphériques exotiques

[bobflux]

7) L'OS
On a une échelle dans les OS:
- Pas d'OS du tout (bare metal) : c'est une option qui évite d'apprendre un OS! Tout à fait valide pour une petite appli.
- Un runtime simple (ex. arduino) qui fournit des fonctions basiques (pinMode, etc)
- Un OS de base
En général, on choisira cette option quand on souhaite faire du multitâches sans avoir à se cogner des tonnes de FSM. J'aime beaucoup ChibiOS, qui est un OS temps réel préemptif très petit (quelques Ko), très facile à utiliser, très rapide, et doté des fonctions usuelles (locks, queues, mbox, semaphores, timers, drivers, etc).
- Un OS complet (linux)

Dans le dernier cas, on franchit une grosse ligne. En effet, ChibiOS tourne avec 4K de RAM... linux pas vraiment. D'autre part, même si la distinction entre uC et micro-ordinateurs n'est pas tout à fait nette, personnellement je la place au niveau de la gestion des accès mémoire, par exemple :
- sur un uC il n'y a en général pas de protection mémoire, donc pour accéder à un périphérique, on mappe simplement son adresse, ou on utilise une instruction. L'accès directe aux périphériques est simple, rapide, et directe.
- sur un micro-ordinateur, l'OS et les drivers isolent les programmes, qui tournent en espace mémoire utilisateur, des périphériques. L'accès direct à ceux-ci est donc plus lent et compliqué, et nécessite généralement un passage par l'OS.

Si on veut faire beaucoup d'IO, un truc comme le rPi ne sera pas forcément adapté. Par contre, ça permet de coder en python et d'utiliser toute la puissance de linux (notamment au niveau du réseau).

Tout est fonction de cahier des charges...

[invite5637435c]

Le problème n'est pas dans les comparaisons techniques.Sans quoi il n'y aurait pas de problème.On voit dans la façon dont tu traites le sujet que tu n'as pas à faire de formations sur ces sujets pour rattraper les dégats causés par l'apprentissage façon Arduino dans les écoles d'aujourd'hui.Il faut bien comprendre que quelqu'un qui va débuter avec ça sera habitué à utiliser du pseudo code et ne creusera pas le coté hardware.Le prémachage façon flowcode de chez Matrix ou mettre du pseudo C++ pour un 8 bit est une preuve de non sens et de profonde ignorance.Le niveau des questions que l'on peut lire ici ou ailleurs le démontre, et inutile de parler de 32 bit ou de machine d'état si tu as sauté les apprentissages fondamentaux.La foire d'empoigne comme tu dis ne concerne que RISC et moi sur un point de la charte qu'il ne respecte pas depuis toujours.Chacun reste libre de ces choix mais ce que je supporte mal est l'hypocrisie et le mensonge à des fins de profits.Pour le reste ta description est loin d'être exhaustive mais je pense que le demandeur initial est soit un troll soit il s'en fout.

[bobflux]

Oui, faire une réponse exhaustive sur le sujet demanderait bien plus qu'un simple post de forum, je voulais simplement donner des axes de réflexion. Il faudrait un livre, et encore, car chaque besoin est différent...

> Le prémachage façon flowcode de chez Matrix ou mettre du pseudo C++ pour un 8 bit est une preuve de non sens

Ça... oui !

[invite5637435c]

A) Déterminer les besoins spécifiques de l'application, et en tirer les conséquences sur...
1) Les périphériques nécessaires :

ADC - Fréquence d'échantillonnage? bits? nombre d'entrées? single-ended/différentiel? etc.
Choisir le type d'ADC :
- SAR (rapide et échantillonne à un instant précis, mais peu de bits)
- DualSlope (lent, précis, intègre durant une période au lieu d'échantillonner, donc meilleure réjection du bruit)
- SigmaDelta (lent, précis, excellente réjection du bruit...)

Crois-tu vraiment qu'un novice comprend SAR, Dualslope et SigmaDelta? Quand déjà octet et registre lui sont vaguement familier?

Bien considérer le fait qu'un capteur numérique (genre DS18B20) est largement plus simple à utiliser qu'une chaîne d'acquisition analogique.

C'est ton point de vue, on a pu voir en 10 ans ici que ce type de composant a posé bon nombre de problème au gens à qui on ne donne pas une librairie clé en main ou qui ont la fainiantise d'ouvrir la datasheet.
Utiliser une entrée analogique et une CTN est tout aussi trivial si on connait un minimum les choses et comment fonctionne un micro lambda.

Périphériques :
- Besoin de PWM triphasé avec machine à états intégrée ? et un comparateur analogique ?
- Ou de N ports série ? SPI? etc?
- 2 ports I2C peut-être ? ou un ?
- Périphériques un peu exotiques genre SGPIO
- Ethernet? USB? Wifi?

Idem, Ethernet, Wifi, USB, derrière ces technologies se cachent bon nombres de notions essentielles qui même enrobés du gloubiglouba Arduinesque nécessitera de savoir un minimum comment ça fonctionne surtout que ça ne fonctionnera pas du premier coup évidemment, sans quoi c'est l'echec assuré et une bonne manière de dégoûter celui qui avait cru comprendre que tout serait ultra facile, comme cela lui a été vendu.

3) Le flashage et la prog
Regarder comment le uC se programme, le coût du programmateur, si c'est facile de faire un bootloader, etc.

Faire un bootloader n'est pas le plus simple car cela implique de connaitre intimement le µC, quelqu'un qui est à même de concevoir cela n'a certainement pas besoin de se lancer dans de l'Arduino...
Et un débutant ne saura pas faire un bootloader, au mieux il copiera ce qu'il trouvera sur le net.

Personnellement, voilà ma soupe :

- Arduino :

Les Moins :
- L'outil de dév est à chier (un simple éditeur de texte + makefile est largement mieux)
- Le runtime arduino est... super lent... (mais t'es pas obligé de l'utiliser)
- La plupart des libs sont codées avec le pied gauche (je rigole pas!) et certaines ne fonctionnent carrément pas
- Pas de debug
- uC obsolète

Tu oublies:
-code inexploitable sur d'autres cibles
-ce que tu appelles pied gauche concernerait selon moi un code spaghetti ou n'exploitant pas les ressources offertes par le langage (pointeurs, switch, structures, etc) or en l'occurrence ce langage est exotique, rien à voir avec du C et jamais d'utilisation de l'assembleur.

- ARM Cortex-M0, M3

Les Plus :
- 32 bits, pas de restrictions débiles style mémoire segmentée, ni PROGMEM... ni rien... tellement simple !
- Puissants, rapides, grosses Flash/RAM en général
- Pas chers pour les perfs
- Environnements de dév: LPCXpresso est pas mal du tout
- Timers 32 bits tout le tour du ventre
- Le contrôleur d'interruption NVIC est une oeuvre d'art
- à partir du M3/M4 c'est la fête du slip sur la connectivité : USB, Ethernet, tout le bazar, ADCs qui déchirent, etc...

On est d'accord mais ces arguments sur les 32 bits ne seront pas compréhensibles par des débutants.

Les Moins :
- Manque de tuto et de doc
- Les handicapés de l'anglais sont exclus d'office
- Sur les uC récents (LPC...) les libraries sont parfois un peu ... jeunes. Et buggées. Ça dépend.
- Pas trop de périphériques exotiques

Celui qui se lancera dans cette aventure du 32 bits aura normalement suffisamment de bases pour d'une part lire l'anglais, et contourner les manques en lisant les DS.
Les 32 bits sont à éviter quand on débute ou alors il faut être plus que motivé.

Pour s'initier le matériel minimum requis est:

- un fer à souder (car contrairement aux idées reçues le b-a-ba c'est déjà de savoir se servir de ces mains en électronique ne serait-ce que pour créer un montage)
- un plaque véroboard
- Son µC favori (ça peut aussi très bien être un Atmel)
- quelques résistances de 1K, 10K, 100K, bref un assortiment, pas besoin d'avoir une brouette de composants.
- quelques condensateurs, pareil un assortiment.
- quelques quartz, 4MHz, 10MHz c'est un bon début ou sinon utiliser la base de temps interne.
- un compilateur C, il en existe des gratuits.
- un programmateur type start kit ou par exemple chez Microchip le pickit3 pas cher du tout pour ce qu'il fait et très robuste (permet de faire du debogage)
- sur le net se trouve bon nombre de ressources sérieuses si tant est qu'on cherche un peu (cours, tutoriels, blogs).

Mis bout à bout on doit arriver à moins de 60/70 euros avec les avantages suivants:

- autonomie complète
- travail sur une base saine et non dépendante du programmateur (hormis le brochage du connecteur évidemment).
- possibilité de réexploiter les fonctions créées si on décide de changer un jour de cible (quand on passe des heures ou des jours sur quelque chose autant que ça puisse resservir)
- on démarre avec la led qui clignote comme sur un Arduino, sauf que là on sait pourquoi et on peut ajouter des choses au fur et à mesure en continuant de maîtriser ce qui est produit de manière évolutive, on est en prise direct avec le hardware et on apprendra beaucoup en faisant inévitablement des conneries de câblages.
- On est pas marié avec un éditeur, un langage (on peut aussi faire du Pascal, du Basic).
- On peut échanger des fonctions avec des potes qui bricolent aussi de leur coté sur d'autres plateformes écrites en langages évolués normés.
- On peut être aidé par la grande majorité des développeurs digne de ce nom du moment qu'on écrit dans un langage ayant des règles communes.

Ce ne sont que quelques uns des avantages pour celui qui aura à coeur d'aller à l'aventure à son rythme, en prenant le temps de découvrir le paysage, de poser des questions et de s'en poser, de faire un effort intellectuel valorisant.
Celui qui veut brûler les étapes et faire des copier-coller aura un plaisir bref, suivi rapidement par la frustration de ne pas comprendre comment ça marche et tôt ou tard abandonnera son jouet pour d'autres plaisirs éphémères.
La vraie question de départ est celle-ci:

qu'est-ce que je veux faire, qu'est-ce que je suis près à faire comme effort et investissement personnel, quelle est ma motivation?
C'est indispensable car ce ne sont pas des heures ou des jours d'investissement mais des mois, voir des années pour les plus pugnaces qu'il faudra déployer pour atteindre le plaisir qui aura été imaginé au départ.
Je vois depuis 10 ans sur ce forum des gens qui ont commencé avec les bases et qui aujourd'hui pourraient témoigné de ce que je dis là, car ils ont acquis peu à peu des connaissances et de solides bases et ont très certainement un vif plaisir à réaliser leur propres montages, maquettes et plus encore.
De même un amateur en astronomie aura à coeur de comprendre ce qu'il voit et investira de son temps dans des techniques proches des pro plus le résultat pour lui sera impressionnant et gratifiant, il suffit de voir sur le forum astronomie combien cette constatation est factuelle.
Un amateur, quelque soit le domaine qu'il affectionne, doit être animé par l'effort de l'investissement personnel qui seront le sel de son plaisir à venir et ne dois pas succomber facilement aux sirènes commerciales dont l'objectif n'est pas que les gens apprennent mais qu'ils achètent des "solutions", leurs solutions.

[invite5637435c]

Le temps d'édition (toujours aussi court...) ne m'a pas permis de corriger certaines fautes.
Veuillez donc m'en excuser.

[bobflux]

> Crois-tu vraiment qu'un novice comprend SAR, Dualslope et SigmaDelta? Quand déjà octet et registre lui sont vaguement familier?

LOL c'est pas faux.
Mais déjà savoir qu'il y a plusieurs types d'ADC, c'est mieux que pas le savoir !

> C'est ton point de vue, on a pu voir en 10 ans ici que ce type de composant a posé bon nombre
> de problème au gens à qui on ne donne pas une librairie clé en main ou qui ont la fainiantise d'ouvrir la datasheet.

Ah bah oui c'est ce que j'ai fait quand j'ai eu besoin de faire un logger de température : arduino, shield LCD, 4x DS18B20, et code tout fait piqué sur le net, une heure et c'est plié, le plus dur c'est de souder les pinouilles...

> -code inexploitable sur d'autres cibles

Ah bah oui, quoiqu'il y a des arduino avec d'autres cpu maintenant. Mais leurs macros idiotes (pins numérotées) obligent à passer par une fonction à chaque IO, donc les IO sont ultra lentes mêmes sur les cpu rapides...

> ce que tu appelles pied gauche

C'est la totale de chez totale. algos inadaptés, initialisations en runtime qui devraient se faire à la compil, code bloaté, utilise trop de RAM, variables globales... je n'ai pas d'exemples en tête parce que ça fait un moment, mais certaines libs sont vraiment écrites par des débutants

[invite5637435c]

Que des gens comme toi utilisent Arduino ne me pose aucun problème car je te connais suffisamment à travers tes interventions pour savoir que tu as un niveau de compréhension très largement suffisant et que tu sais pertinemment ce que tu fais.Et aussi que la prog n'est pas ton coeur de métier à priori @+

[bobflux]

Merci

> Et aussi que la prog n'est pas ton coeur de métier à prior

Ça l'eu été il fût un temps, mais maintenant plus trop. Je trouve le hardware et l'analogique plus amusants.

[bobflux]

Tiens, un exemple de library arduino. Le décodage des télécommandes infrarouges. Il y a une grosse lib, avec quasi tous les standards du marché... vas-y que je te mets 15 fichiers .cpp... bien sûr avec tant de codes à vérifier, c'est plein de bugs. Je teste : échec.

Je code donc une lib infrarouge, dans un esprit "uC".
Réception des pulses -> décision sur la valeur du bit en fonction de la durée (un #define) -> CRC/hash des bits reçus -> code correspondant à la touche pressée.

Les codes ne correspondent pas aux valeurs numériques style RC5, mais... on peut facilement utiliser le code reçu dans un switch/case, faire un apprentissage, etc. Ça marche avec toutes les télécommandes... Donc, en gros, ça fait le job.
100 lignes de code (dont un tiers de déclarations C++), et utilisation de RAM : 6 octets.

[jiherve]

Bonsoir
Pour être sur que cela tienne dans la flash et de ce que l'on fait : assembleur, assembleur et encore assembleur!
Il ne faut que quelques heures pour démarrer un projet à partir du µC nu(Atmel),l'essentiel étant câblage et mécanique.
JR

[masterclassic]

Mais où est donc Densha?

Dernière activité 22/08/2016 22h36

Date d'inscription 22/08/2016

C'était donc juste pour poster son seul et unique post sans y revenir pour lire les réponses?

[gienas]

Bonjour à tous

... C'était donc juste pour poster son seul et unique post sans y revenir pour lire les réponses?

Pour éviter l'auto entretien inutile, la discussion est close.