Bonjour tout le monde !
Avant de commencer je tiens à m’excuser pour le retard, relativement gros, voire même énorme que j’ai eu sur cet article.
L’arduino Due étant sortie en novembre 2012 j’ai … 5 mois de retard … oups.
Je tiens aussi à remercier du fond du cœur Johann Colombano-Rut pour la carte qu’il m’a offerte.
Vous pouvez lui dire merci car sans son aide je n’aurai jamais eu les moyens (surtout en ce moment) de m’offrir l’Arduino Due.
Et si vous cherchez à acheter une Arduino Due elle est disponible chez GoTronic : http://www.gotronic.fr/art-carte-arduino-due-18742.htm
—
Avant propos :
L’arduino Due est la dernière version de carte Arduino « made in italy ».
Elle signe un nouveau départ pour toute la série des cartes arduino, fini les petites cartes avec un CPU 8 bits et un hardware « un peu » poussif.
J’ai longtemps craché (à tort) sur l’arduino Due, surtout en voyant les spécifications hardware données par la team arduino au début.
Mais ce qui m’a le plus irrité (et je ne pense pas être le seul) c’est le temps qu’a mis la team arduino à sortir l’arduino Due.
Et vas-y que je fais de la pub, une photo leaké par ci, une autre par là … mais au final pas de carte.
Bon maintenant la carte est sortie depuis un petit moment déjà, c’est donc l’heure du test ! 🙂
—
La sainte boite :
Je doit avoir des gènes de chat en moi … j’adore les boites … pleines 🙂
Et pour mon plus grand bonheur (et aussi pour rafraichir un peu l’image des cartes arduino) la team Arduino a fait pas mal de changement dans les emballages de leurs cartes.
Fini la petite boite blanche et bleu avec un peu de texte et rien d’autre, maintenant les boites sont recouvertes d’une sorte de pixel art (ok ce terme n’est pas le plus adapté) représentant la carte contenue dans la boite et des petits dessins (?) sur les côtés.
Quand on sait que le projet Arduino a été conçu à l’origine par des artistes ça fait plaisir d’avoir une boite un peu plus colorée.
Ps: ils ont du bien s’amuser à vectoriser chaque piste et chaque via.
Autre truc super, ultra, méga cool fourni avec la carte : un gros sticker. Mais alors un très gros sticker !
(je ne sais pas si c’est vraiment fourni avec la carte, ou si c’est un cadeau en plus de la carte quand on l’achète via le store arduino)
Bon pour rester un peu sérieux et conclure sur l’emballage, comme avec les anciennes versions un petit livret est fourni pour vos remercier de soutenir le projet Arduino.
De même qu’un lot de sticker (mais de taille normal cette fois).
—
La carte Arduino Due :
Les choses sérieuses commencent maintenant ! 🙂
Voila à quoi ressemble la bête.
On remarque de suite que la carte est bien remplie, tellement remplie qu’on serait tenter de dire que le routage d’une telle carte a du prendre beaucoup de temps.
Le brochage de la carte reste cependant classique.
Les utilisateurs de cartes Mega2560 révision 3 ne seront pas dépaysés.
Pour comparaison voici une carte Arduino Mega2560 (révision 2) et l’arduino Due :
Même taille, même connecteur, bref une carte Mega2560 améliorée en quelque sorte.
Concernant le silkscreen ça reste simple mais lisible.
Pas de logo Arduino en fondu comme sur les cartes Arduino UNO révision 3, juste un bandeau avec les informations utiles.
—
Le processeur :
Qui dit Arduino Due dit … processeur 32 bits !
Fini les petits processeurs ATmega 8 bits à 20MHz, avec la Due c’est d’un tout autre niveau !
L’arduino Due est propulsée par un SAM3X8E du fabricant Atmel (la team Arduino est restée sur une solution Atmel, question d’habitude et de sponsoring je suppose).
Un bon gros processeur 32 bits ARM Cortex-M3 tournant à 84MHz !
Si on regarde le datasheet du processeur on se rend tout de suite compte de la puissance du monstre :
– 96 Ko de mémoire SRAM (c’est 24x plus qu’une carte Arduino mega !)
– 512 Ko de mémoire flash
– 17 canaux DMA (Direct Access Memory) pour faire des transferts à très haute vitesse entre périphériques sans utiliser le cpu
– port USB 2.0 OTG (Host / Device), 480Mbps à pleine vitesse
– 4 ports série pouvant supporter divers mode de transmission (ISO7816, IrDA, Manchester, …)
– 2 bus I2C
– SPI, I2S (audio), HSMCI (carte SD) …
– 9 compteurs 32 bits avec PWM, comptage et capture de signaux
– 1 décodeur de « codeur en quadrature » (pour moteur pas à pas) hardware
– 8 canaux PWM 16 bits
– un timer RTC (Real Time Clock) avec gestion du calendrier et des alarmes
– 16 canaux de conversion analogique -> numérique 12 bits 1Msps (million de sample par seconde) avec gain programmable
– 2 canaux de conversion numérique -> analogique 12 bits 1Msps
– un contrôleur Ethernet (attention voir ma remarque en fin de chapitre)
– 2 contrôleurs de bus CAN avec 8 « mail box »
– un générateur de nombre aléatoire hardware
Les cartes chipkits peuvent allez ce rhabiller 😉
C’est simple, tout ce qui demandait des librairies avec une carte Arduino classique peut désormais se faire en hardware avec les périphériques du processeur.
C’est une des raisons qui me font tant aimer les micro-contrôleurs ARM Cortex-M, le hardware est toujours monstrueusement complet !
Une autre chose très pratique c’est ce bouton « ERASE ».
Il porte bien son nom, si vous appuyez dessus en même temps que le bouton RESET le programme dans la carte est définitivement effacé.
Quelle utilité me direz vous ?
Combien d’entre vous se sont retrouvé avec un programme bloquant le port série et empêchant le bootloader de se lancer ?
Avec ce bouton plus de problème, si ça bloque on appui et basta.
Autre truc à noter : le bootloader est hardware !
Il est donc impossible de le corrompre (contrairement à celui d’une carte classique qui part en sucette assez rapidement en cas de mauvaise manipulation).
Tant que je suis dans les détails en voici un autre !
Ax : classique c’est une entrée analogique
DACx : … c’est une SORTIE analogique et oui il y a un convertisseur numérique -> analogique dans le processeur !
De quoi ouvrir la porte à toute les folies musicales (j’en parlerai plus tard ;)) !
Mais c’est pas fini, la fête continue !
Un truc que j’ai toujours voulu tester sans jamais pouvoir c’est les bus CAN.
Pour faire simple ceux sont des bus de communication très utilisés dans le domaine de l’automobile.
Et bien comme vous pouvez le voir l’arduino Due possède un bus CAN, de quoi bien s’amuser.
—
Connecteurs et interfaces :
Concernant l’interface ordinateur / arduino Due il y a le choix !
Il y a deux ports usb !
– un port usb « série » classique comme sur n’importe quelle carte arduino
– un port usb OTG comme sur une carte arduino leonardo
Vous pouvez donc sans problème connecter la carte à l’ordinateur, programmer la carte, échanger des informations avec l’ordinateur tout en ayant un périphérique USB sur l’autre port.
Et comme il s’agit d’un port OTG il peut faire office d’usb « host » ou d’usb « device », pas mal non ?
Imaginez un peu la scène : vous envoyez des commandes à la carte via le port série et celle ci viendrait agir sur un autre ordinateur en se faisant passer pour un clavier/souris usb.
Ce serait sympa comme montage vous trouvez pas ?
Et bien avec l’arduino Due c’est possible !
Debug ? Quelqu’un a dit debug ?
Mais non voyons c’est impossible que le connecteur miniature soit un port jtag et le connecteur 4 points un port SWD.
Ou peut être bien que si en fait 🙂
Et oui l’arduino Due a un connecteur de debug, si vous avez une sonde JTAG pour processeur ARM vous pouvez l’utiliser pour faire du debug sur la carte.
Certes il faut utiliser l’ide du fabricant Atmel (AVR Studio 6 minimum) mais qu’importe, pouvoir faire du debug, même s’il faut du matos dédié c’est une sacrée avancée !
C’est la porte ouverte aux projets alternatifs qui utiliseraient la carte mais pas le logiciel arduino, AMEN !
Re-bonne nouvelle, comme sur les cartes Arduino classique c’est un ATmega16u2 qui gère le port série-usb.
On peut donc envisager de le bidouiller pour avoir accès à son port usb natif, comme avec une arduino UNO.
Le connecteur de programmation est soudé de base ! Elle est pas belle vie ? 🙂
Concernant les ports usb justement, pas de panique ils sont annotés au dos de la carte.
« Programming » -> pour la programmation
« Native usb » -> port l’usb OTG soit … tout et n’importe quoi
Concernant les leds et autre voyants sur la carte ils sont tous concentrés vers les ports usb.
Du haut vers le bas : Rx / Tx pour le port usb natif, led « pin 13 », témoin d’alimentation, Rx / Tx pour le port série.
—
Les détails qui tuent :
A première vue l’arduino Due est une véritable tuerie !
Puissante, avec un hardware qui met au tapis toutes les autres carte arduino, bref une bête de course.
Mais … il y a un « mais » !
Premier point qui me laisse perplexe : ce jumper.
Celui-ci me laisse penser que le choix de la référence en tension pour analogRead() ne peut pas être modifié dans le code.
Et manque de bol en lisant la doc sur le site d’arduino.cc je lis :
The AREF pin is connected to the SAM3X analog reference pin through a resistor bridge. To use the AREF pin, resistor BR1 must be desoldered from the PCB.
La broche AREF n’est donc pas utilisable librement comme avec une carte arduino classique … pas cool.
Et en y réfléchissant bien … il manque des choses !
Si si relisez bien le détail des capacités du cpu 😉
– Ou est le port ethernet ? Certes il aurait fallu un PHY Ethernet pour l’utiliser réellement mais pourquoi ne pas avoir prévu un connecteur et une shield annexe ?
– Ou est la carte SD ? Le cpu a un périphérique de communication hardware pour les cartes SD/MMC, pourquoi ne pas avoir prévu un slot pour carte micro SD ?
– Ou est le quartz 32.768KHz pour l’horloge RTC ? Pas de quartz = pas d’horloge, c’est c*n quand même ! Ça aurait évité d’avoir un module RTC externe pour certains projets !
Mais encore tout ça c’est du détail.
Le GROS point noir de l’arduino Due c’est que celle-ci fonctionne exclusivement en 3v3, aucune possibilité de faire fonctionner la carte avec des composants 5v.
Pas de tolérance au 5v, rien, il faut donc choisir soigneusement chacun de ses composants en étant sûr et certain qu’ils marchent en 3v3, sinon pschiiiiit *cramé*.
C’est pas de la faute de la team Arduino, c’est l’évolution des cpu ARM qui veut ça, mais ça fait mal au cœur quand même.
Ça aurait pu être pire ! Les nouveaux cpu ARM fonctionnent pour certain à 1v8 …
—
Le logiciel :
La carte Arduino utilisant un CPU ARM l’ide Arduino a du être revue.
Grosse nouveauté de cette version « spéciale arduino Due » : le supporte de plusieurs architectures cpu.
C’est vraiment THE fonctionnalité que je voulais voir intégré dans l’ide (j’étais même parti à faire un patch pour ça) et voila que c’est officiellement fait !
Fini les clones de l’ide arduino pour les cartes leaflabs, chipkits, launchpad, … cette nouvelle version devrait à terme pouvoir gérer n’importe quelle architecture.
(moyennant un « core arduino » et un compilateur adapté pour l’architecture en question bien sûr)
Ce serait vraiment le pied, un seul ide à télécharger, toutes les dernières nouveautés, bug-fix, patch, etc et plus de problème de conflit entre version.
Ça c’est la théorie, pour le moment on est loin de voir fleurir des « addons » ernergia, chipkit, ou autre pour l’ide officiel, l’ide en lui même étant encore en beta.
Quoi qu’il en soit pour le télécharger il suffit de se rendre sur la page de téléchargement d’arduino.cc :
http://arduino.cc/en/Main/Software
Ps: ne téléchargez pas cette version « spéciale Arduino Due » si vous n’avez pas d’arduino Due, restez sur la version classique 😉
Au niveau du gui « de base » il n’y a eu aucun changement, c’est exactement comme avec l’ide classique 1.0.x.
Comme je le disais cette nouvelle version supporte plusieurs architecture, dont de base les AVR8 (carte arduino classique) et les ARM-SAM (arduino Due).
Le choix de la carte cible se fait via le classique menu « boards » revu et amélioré pour l’occasion.
Autre nouveauté : le choix du cpu cible, en plus de l’architecture.
Exemple : le choix entre ATmega168 (vielles cartes arduino) et ATmega328p (nouvelles cartes arduino).
—
Les changements dans le code arduino :
Changer d’architecture cpu demande forcément du travail pour faire suivre le code.
Tout d’abord au niveau de l’API arduino on voit apparaitre deux nouvelles fonctions :
http://arduino.cc/en/Reference/AnalogReadResolution
http://arduino.cc/en/Reference/AnalogWriteResolution
Celles-ci permettent de choisir la résolution de analogWrite() (sur les sorties DAC) et analogRead().
Sur les cartes arduino classique analogRead() retourne une valeur sur 10 bits (0 ~ 1023), l’arduino Due elle sort une valeur sur 12 bits !
Ces fonctions ont pour but de rendre compatible d’anciens programmes en diminuant la précision des valeurs lues / écrites.
Remarque : vous pouvez aussi « augmenter » virtuellement la précision mais cela ne fera en réalité que donner une valeur « upscalé ».
C’est un peu comme vouloir redimensionner une image de 32×32 en 64×64, ça fait de gros pixels mais en aucun cas un image plus nette 😉
Comme l’arduino Due possède un port USB natif les librairies Mouse et Keyboard sont utilisables :
http://arduino.cc/en/Reference/MouseKeyboard
Et pour l’occasion des librairies spécialisées (pour la Due uniquement) ont vu le jour :
– http://arduino.cc/en/Reference/Audio : qui permet de lire des fichiers audio en utilisant la convertisseur numérique -> analogique (bye bye la WaveShield d’adafruit)
– http://arduino.cc/en/Reference/Scheduler : qui permet de faire du pseudo multi-tache (principe des RTOS, attention c’est encore très expérimental)
– http://arduino.cc/en/Reference/USBHost : qui permet de connecter des périphériques USB en mode host (bye bye la UsbHostShield et l’arduino ADK)
—
Le détail qui tue (seconde édition) :
Tout ce qui semble parfait a forcément des choses à cacher sous le tapis.
La première chose qui me semble inévitable c’est « l’effet chipkit ».
Qui dit nouvelle architecture dit nouvelle façon de coder, les développeurs de librairie bas niveau pour arduino ont pris l’habitude coder sur AVR8 et non sur ARM-SAM.
On a bien vu ce que ça a donné pour les cartes chipkit, sans librairie la carte ne vaut rien. Il y a donc un gros travail à réaliser dans ce sens.
Autre problème : le hardware.
Avoir un hardware qui fait tout c’est bien, mais sans code pour l’utiliser ça ne sert à rien !
Et malheureusement une grande partie (disons 80%) du hardware n’est pas utilisable avec le code arduino et les librairies officielles, c’est ballot.
Et pour finir, un dernier « problème » qui me donne des envies de meurtres : le compilateur.
La team arduino est très forte quand il s’agit de fournir des versions buggées / obsolètes / … de compilateur.
La version classique de l’ide pour windows est fournie avec une version de WINavr datant de 2008 !
Mais bon cette version marche, elle est opensource et si on le souhaite on peut utiliser une version plus récente en l’installant soit même.
Mais pourquoi … pourquoi avoir choisi « Sourcery G++ Lite » comme compilateur pour l’arduino Due !
POURQUOI !
Sourcery n’est pas sous licence libre mais sous une licence spéciale crée par l’entreprise Sourcery.
De plus c’est une version datant de 2010, autant dire obsolète (le domaine des processeurs ARM évolue très vite).
Et si l’on souhaite remplacer le compilateur Sourcery par un équivalent libre tel que Yagarto ou ARM-GCC : ON NE PEUT PAS !
Le code refusera tout simplement de compiler !
Pour un projet opensource comme Arduino je trouve ça un peu abusé !
Du coup c’est bête.
J’étais parti à faire des librairies pour l’arduino Due (les processeurs ARM je connais) mais ne pouvant pas utiliser mon fidèle assistant CoIDE avec le compilateur Yagarto et ma sonde JTAG je me contenterais des librairies officielles … à défaut de pouvoir coder les miennes …
—
Conclusion :
L’arduino Due est vraiment une carte de dingue, avec un cpu puissant et un hardware qui tient la route.
Mais il est clair que c’est une carte ciblant les développeurs et les connaisseurs d’ARM cortex-M3.
Le côté expérimental ne permettant pas de faire un projet de A à Z dessus avec l’API arduino uniquement (ou alors si c’est le cas une carte arduino classique aurait surement suffi).
Je suis assez mitigé, la carte en elle même est vraiment sympa, bien qu’elle ait quelques défauts hardware à mes yeux.
Le logiciel arduino 1.5.x est vraiment bien parti et promet de bonnes choses pour l’avenir.
Mais le code bas niveau et les librairies pour la Due font défauts … et ça me fait un peu peur …
Je ne sais pas si l’arduino Due se vend bien ou non (si j’ai des vendeurs dans mes followers l’info m’intéresse, juste par pure curiosité) mais personnellement je trouverais vraiment dommage que l’arduino Due sombre petit à petit dans l’oublie comme c’est le cas des cartes Chipkit.
Alors un peu de nerf la team arduino !
Arrêtez de sortir des shields GSM à la c*n ou des gamepad à base d’arduino, faites nous donc plutôt des librairies bas niveau pour la Due 😉
Skyduino - Le DIY à la française 
Un excellent résumé qui me donne envie d’y jouer.
Par contre pourras tu nous en dire plus sur ta sonde JTAG, j’aimerai m’en prendre une bientôt mais le choix est vaste.
Publié par mike | 26 mars 2013, 23 h 26 minJ’utilise une sonde Jlink V8 de Segger.
Ce sont des sondes franchement bien foutu qui marchent avec n’importe quel type d’ARM 7/9/11, Cortex A5/8/9 et M0/1/3/4.
Mais je le crie pas sur tout les toits vu que j’ai un clone chinois à 20$ et non une vrai sonde …
(question de budget … j’ai pas l’argent pour une vrai sonde Jlink malheureusement)
Publié par skywodd | 27 mars 2013, 12 h 26 minHonnêtement, ce compte-rendu renforce mon impression sur cette carte, à savoir plus que mitigée…
Quelle est la plus-value d’une telle carte face à un Raspberry Pi, qui a pour elle un port Ethernet, deux
ports vidéos, dont un HDMI, un (pauvre) port audio, deux ports USB, un port GPIO et une carte SD… le
tout pour un prix au moins 2 fois inférieur à une Due…
Bref, toujours pas convaincu par cette Due!
Publié par Damien dit Levaillant | 27 mars 2013, 1 h 34 minMême sentiment ! Carte non aboutie…
Publié par Rodolphe Boulon | 27 mars 2013, 11 h 12 minComment arrives-tu à comparer un « mini pc » et une carte à microcontrôleur ?
Un Raspberry Pi c’est un « mini pc ».
Une carte arduino c’est une carte à microcontrôleur.
Deux architectures différentes, deux utilisations finales différentes, bref aucune similitude entre eux.
Les deux cartes peuvent être complémentaires (R. Pi pour le calcul et Arduino pour l’interfaçage) mais en aucun cas rivales.
Le Raspberry Pi a t-il 4 ports séries ? Un port SPI, I2C et I2S ?
+50 GPIO et des convertisseurs ADC / DAC ?
Une port usb OTG ?
Non, enfin si, une dizaine de GPIO, un port I2C, SPI et série mais pas plus.
De même l’arduino Due a t-elle un port HDMI, ethernet, CSI (caméra), RGB (écran) ?
Non mais ce n’est pas son but, que faire d’un port HDMI quand on a pas de chipset graphique ?
Arduino -> interfaçage bas niveau avec du matériel
Raspberry Pi & autre mini pc -> calcul / affichage et interface utilisateur haut niveau
Publié par skywodd | 27 mars 2013, 12 h 40 minTu peux même ajouter que le rPi fait tourner Linux et je vois mal comment faire quoique ce soit sans (vu la dispo des specs de la puce principale…), la Due et les cartes équivalentes sont faites pour faire du baremetal.
Publié par lapin | 28 mars 2013, 18 h 15 minBien le bonsoir!
Trollons un peu entre amis 😉
Arduino Due : ARM Cortex-M3
Raspberry Pi : ARMv6
La frontière est de plus en plus mince… la similitude entre ces deux cartes est bien réelle!
Lors de mes lointaines études, on m’avait enseigné qu’un microcontroleur était l’assemblage
d’un microprocesseur, de la RAM, et de tous les périphériques d’entrées-sorties, en gros un
microcontroleur était un PC de petite puissance, et je pense que c’est toujours le cas!
Maintenant, je suis bien d’accord avec toi, les deux ont des orientations différentes. Le Due a
des IO à ne plus savoir qu’en faire et le RPi a des sorties vidéos dont on a rien à faire… Mais les
deux ont un port série, un port I2C, un port SPI… les ADC/DAC du Due ont le mérite d’être
présents, mais honnêtement, une résolution de 12bits ne me satisfait guère (mais c’est quand
même mieux qu’un UNO avec ses pauvres 6x10bits), autant utiliser un chip spécialisé en I2C
ou en SPI (ce que je fais avec des UNO/MEGA d’ailleurs)
Quant aux IO… que dire… Je me permets de te poser une question : As-tu déjà utilisé, dans
un même projet, plus de 20-30 IO? Et même si tu me répondais dans l’affirmative, je
rétorquerais que peu d’hobbyistes en auraient besoin ou en seraient capables. De plus, un
ou des chips mcp230008 (plus très sûr de la référence) permettraient (assez facilement)
d’étendre à l’infini quasiment les IO de l’un ou l’autre.
La où je vois un intérêt avec un Due, est que ce dernier n’est presque plus limité dans sa
ROM et RAM comparé à un UNO, mais le MEGA avait déjà comblé ce trou, reste une
fréquence bien plus élevée en faveur du Due. Un autre aspect que j’imagine est probablement
la consommation réduite du Due (par rapport au Raspberry).
Le Raspberry Pi a pour lui, une carte SD, un port Ethernet, deux ports USB (certes pas OTG,
mais honnêtement quelqu’un a déjà expérimenté?), mais surtout, et attention au scoop, son
prix!
Là où je te rejoins totalement est sur l’interface hard, un Arduino est parfait pour!
Mais pour moi, et cela reste absolument subjectif, un Raspberry Pi est parfait pour remplacer
un Arduino UNO+Ethernet, et encore plus si le projet est réellement orienté « connecté ». Le
summum reste, à mon avis et pour le moment, un Raspberry Pi + Atmega328 en SPI, et ce
pour un coût inférieur à celui d’un Due, les possibilités du duo étant clairement exceptionnelles!
Continue à poster, c’est toujours un plaisir de te lire!
Publié par Damien dit Levaillant | 29 mars 2013, 2 h 44 min>> Trollons un peu entre amis
Héhé ça tombe bien c’est ‘dredi 🙂
>> La frontière est de plus en plus mince… la similitude entre ces deux cartes est bien réelle!
L’architecture ne fait pas tout 😉
La taille de la RAM, de la ROM, la possibilité d’exécution depuis un périphérique externe, la puissance du cpu, …
C’est tout autant de critères à prendre en compte.
Il faut aussi prendre en compte les timers hardware (nombreux sur Cortex-M3), les interruptions externes, les canaux DMA …
>> et le RPi a des sorties vidéos dont on a rien à faire…
C’est quand bien pratique quand on veut faire un player vidéo de salon 🙂
>> mais honnêtement, une résolution de 12bits ne me satisfait guère
12 bits c’est déjà énorme, la plupart des DAC/ADC spi ou i2c du commerce sont sur 12 bits.
Excepté ceux prévu pour faire explicitement de l’audio qui sont sur 24 bits voir plus.
>> autant utiliser un chip spécialisé en I2C
Oui mais en I2C tu n’attendras jamais les 1M samples par seconde 😉
En SPI pourquoi pas, mais pas en I2C.
>> As-tu déjà utilisé, dans un même projet, plus de 20-30 IO?
Pas plus tard qu’hier, sur une mega2560.
Quand tu commences à vouloir interfacer des circuits de logique parallèle (dans mon cas une banque SRAM de 1Mbits soit 28 broches) ça commence à faire du monde à câbler.
Dans le genre consommateur de broche les afficheurs matriciels sont de bon gloutons aussi.
>> De plus, un ou des chips mcp230008 (plus très sûr de la référence) permettraient (assez facilement) d’étendre à l’infini quasiment les IO de l’un ou l’autre.
Du moment où tu utilises un bus série tu divises ta fréquence de commutation maximum par le nombre de bits à transmettre pour commander le ci.
En SPI ça reste relativement élevé car la fréquence de base est assez haute.
En I2C par contre ça devient vite quelques KHz grand maximum.
Après ça dépend de l’application finale, si c’est pour commuter une broche toute les 25ms par exemple c’est suffisant.
Si c’est pour faire un affichage matriciel avec un temps de rafraichissement minimum à respecter c’est plus compliqué.
>> mais le MEGA avait déjà comblé ce trou, reste une fréquence bien plus élevée en faveur du Due.
96Ko c’est quand même 24x plus que la mega2560. C’est pas négligeable 😉
Ça ouvre des perspectives pour faire du développement d’algorithmes basaient sur la librairie STL par exemple.
>> (certes pas OTG, mais honnêtement quelqu’un a déjà expérimenté?)
Comme ça ? Faire de l’otg sur Arduino Due ? Sur Raspberry Pi ?
>> mais surtout, et attention au scoop, son prix!
Oui alors là … je serait pas catégorique sur ce point.
Certes le Raspberry Pi est pas chère, 40-45€ mais pour un prix équivalent tu as maintenant des cartes bien plus puissante.
A13-OLinuXino par exemple, qui est 100% opensource et aussi puissante (pour ne pas dire plus) qu’un Raspberry Pi.
Et d’un prix à peine supérieur à celui d’un Raspberry Pi.
Publié par skywodd | 29 mars 2013, 14 h 23 min>>> L’architecture ne fait pas tout 😉
>>> La taille de la RAM, de la ROM, la possibilité d’exécution depuis un périphérique externe, la puissance du
>>> cpu. C’est tout autant de critères à prendre en compte.
>>> Il faut aussi prendre en compte les timers hardware (nombreux sur Cortex-M3), les interruptions externes,
>>> les canaux DMA …
Sans rentrer dans ce débat de qui a le plus grand nombre d’IO, de timers hard, d’interruptions externes et
de canaux DMA, je dirais que tout dépend du projet. Par exemple, ma 2cv me permet bien d’aller d’un point A à un point B, une Ferrari me permet de faire la même chose, dois-je acheter une Ferrari pour me déplacer?
>>> >> et le RPi a des sorties vidéos dont on a rien à faire…
>>> C’est quand bien pratique quand on veut faire un player vidéo de salon 🙂
Bien d’accord, ce n’était qu’un exemple pour mettre dans une même perspective orientée hard les deux
cartes citées
>>> >> mais honnêtement, une résolution de 12bits ne me satisfait guère
>>> 12 bits c’est déjà énorme, la plupart des DAC/ADC spi ou i2c du commerce sont sur 12 bits.
>>> Excepté ceux prévu pour faire explicitement de l’audio qui sont sur 24 bits voir plus.
Excepté ceux qui font de l’instrumentation, excepté ceux qui… Il n’y a pas de règles en fait, le besoin
créé, il faut y répondre. Pour ma part ce sont des ADC 16 bits, mais je peux comprendre qu’un ADC
10-12bits puisse suffire la plupart du temps,
>>> >> autant utiliser un chip spécialisé en I2C
>>> Oui mais en I2C tu n’attendras jamais les 1M samples par seconde 😉
>>> En SPI pourquoi pas, mais pas en I2C.
et j’ai bien écrit « ou en SPI » (que j’affectionne particulièrement 😉 )
>>> >> As-tu déjà utilisé, dans un même projet, plus de 20-30 IO?
>>> Pas plus tard qu’hier, sur une mega2560.
>>> Quand tu commences à vouloir interfacer des circuits de logique parallèle (dans mon cas une banque
>>> SRAM de 1Mbits soit 28 broches) ça commence à faire du monde à câbler.
>>> Dans le genre consommateur de broche les afficheurs matriciels sont de bon gloutons aussi.
Oui, c’est sûr que c’est le genre de projet qui engendre au moins un post journalier sur le forum arduino ^^
>>> >> mais le MEGA avait déjà comblé ce trou, reste une fréquence bien plus élevée en faveur du Due.
>>> 96Ko c’est quand même 24x plus que la mega2560. C’est pas négligeable 😉
>>> Ça ouvre des perspectives pour faire du développement d’algorithmes basaient sur la librairie STL par
>>> exemple.
UNO<MEGA<DUE, soit 32KB<128KB<512K en flash. On est bien d'accord que plus on monte en gamme, plus
c'est mieux, plus les possibilités sont de plus en plus intéressantes, même remarque avec ma 2cv 😉
Tout ca pour dire que bien que différentes dans l'architecture, dans le prix, dans le nombre d'IO etc ces cartes,
Arduino Due, Raspberry Pi, et même cette jolie Olimex que je ne connaissais pas, elles s'orientent clairement
vers des utilisations similaires et dans l'absolu, je suis persuadé que sur un projet déjà conséquent, elles
seraient toutes à même d'y répondre. En partant de ce postulat, laquelle choisir?
Et bien c'est très simple, pour moi ce sera celle qui coute le moins cher, pour le plus de fonctionnalités!
Je suis prêt à parier que le Due ne trouvera pas son public, et puis c'est tout! 🙂
Tiens un gros troll : Pourquoi ne pas avoir utiliser la Due hier pour ta SRAM? XD
Publié par Damien dit Levaillant | 29 mars 2013, 15 h 40 min>> Par exemple, ma 2cv me permet bien d’aller d’un point A à un point B, une Ferrari me permet de faire la même chose, dois-je acheter une Ferrari pour me déplacer?
Dans ce cas pourquoi prendre une Ferrari (-> Raspberry Pi) quand une bonne vielle 2cv « made in italy » suffit ?
>> Pour ma part ce sont des ADC 16 bits, mais je peux comprendre qu’un ADC 10-12bits puisse suffire la plupart du temps.
Quand on fait de l’interface de capteur (99.99% des cas d’utilisation d’une carte arduino) 10 bits c’est suffisant, 12 bits c’est certes mieux, mais bon 16 bits c’est carrément inutile (sauf pour certain capteurs bien particulier).
C’est une question de point de vue et de cahier des charge.
Les fabricants de CI eux regardent au plus rentable en fonction du marché, tout le monde utilise du 10 bits -> on met des ADC 10 bits.
>> et j’ai bien écrit « ou en SPI » (que j’affectionne particulièrement )
On est deux dans ce cas 🙂
L’I2C c’est bien pratique mais c’est une catastrophe en terme de vitesse …
>> Oui, c’est sûr que c’est le genre de projet qui engendre au moins un post journalier sur le forum arduino ^^
Pas journalier certes, mais mensuel oui.
Le truc c’est que ce genre de projet est par définition tellement volumineux qu’ils prennent trois plombent à ce finir …
Moi ça fait presque un an que je réfléchi à mon montage à base de SRAM (un générateur de signal VGA 320×240).
>> Et bien c’est très simple, pour moi ce sera celle qui coute le moins cher, pour le plus de fonctionnalités!
C’est le meilleur moyen d’avoir des mauvaises surprises dans le futur de choisir au moins chère 😉
Le plus de fonctionnalités ok, mais si la carte en question ce transforme en presse papier par manque d’une fonctionnalité critique pour LE projet (final) c’est la loose.
Pour moi il n’y a pas de solution idéal, pour choisir une carte il faut avoir une idée de ce qu’on veut faire sinon le choix sera forcément restrictif pour la suite.
>> Je suis prêt à parier que le Due ne trouvera pas son public, et puis c’est tout!
C’est pas un argument ça 🙂
>> Tiens un gros troll : Pourquoi ne pas avoir utiliser la Due hier pour ta SRAM? XD
Parce que je n’ai pas encore trouvé de doc technique sur la librairie bas niveau utilisé avec le compilateur Sourcery.
Du coup je ne peut/sait pas faire de manipulation de port parallèle (obligatoire pour communiquer avec un SRAM), alors qu’en AVR classique je sait le faire les yeux fermés 😉
Publié par skywodd | 30 mars 2013, 14 h 26 minSuper résumé…
Bon en gros on attend des libs bas niveaux au point et un mod qui intègre la carte SD, le port ethernet, le quartz….. 😉
Publié par thom | 27 mars 2013, 17 h 57 minC’est plus qu’un « mod » … ce serait carrément une nouvelle révision de la carte.
Publié par skywodd | 27 mars 2013, 18 h 02 minBonjour,
Peut on quand même adapter l’ethernet shield qui fonctionne sur les cartes « classiques » dessus ?
Les librairies pour ce shield fonctionne elle sur la due ?
Publié par Touf2638 | 13 Mai 2013, 15 h 04 minDepuis hier, je zieute cette DUE, car bien qu’un peu chère à mon goût, elle fait des promesses. hum… un proc 32 bits / 84MHz… miam pour remplacer ma MEGA! Mais comme tu le dis, pourquoi ne pas avoir routé les ports SD / ETH etc… ?
De plus, je suis tombé sur le c*l, car la grosse erreur de la team sur cette carte, c’est d’avoir posé un µC de 144 pins sur une carte n’en ayant que 69, et tout laisse à penser qu’on n’aura pas accès à des fonctions pourtant essentielles. Déjà, j’avais regardé de très près la MEGA, et ma première grosse déception était que les pins permettant d’utiliser le timer2 en RTC n’étaient pas routées, donc si on ne sait pas souder en direct sur les petites pattes du proc, on ne peut pas rajouter un petit quartz 32,768K. (pour la MEGA, il y a plein d’autres fonctions très utiles qui ne sont pas routées).
Alors moi, je dis qu’ouvrir la porte du 32bits, c’est bien, mais est_ce que ça aurait vraiment coûté plus cher de rajouter un connecteur de plus pour accéder à des fonctions qui auraient fait de cette DUE une vraie tuerie de ouf? C’est comme si en sortant la MEGA, ils avaient gardé le format de la UNO avec ses pauvres 22 I/O…
Je n’ai pas regardé comment c’était organisé, mais j’imagine que comme pour la Léonardo, les ports ont été dispersés dans tous les sens, et que celui qui aurait voulu utiliser un port 32 bits complet (le port C je crois), ben il ne peut pas… Pourtant, un port complet, ça permet d’en faire, des choses, et à une vitesse réellement intéressante… Compatibilité avec les shields et libs existantes? je n’en suis même pas sûr.
Et bien moi, non, je n’achèterai pas cette carte. Pour 10 à 15 fois moins cher, on trouve des cartes 32bits bien mieux pensées. Dommage, c’était l’occasion de mettre Arduino à jour pour rester dans la course.
PS : je fais mon vieux c*n, mais ça ne m’empêche pas de continuer à faire joujou avec arduino. C’est juste que je commence à me trouver limité et que je trouve que la team a du mal à évoluer. Sans rancune!
Publié par Super Cinci | 20 septembre 2013, 7 h 58 minLes broches non routées c’est vraiment dommage.
Mais le plus dommage c’est de laisser en plan la partie code.
L’arduino Yun vient de sortir, de même qu’un robot (que je surnomme affectueusement le « ramasse fric » de part son prix). Je n’ai aujourd’hui plus grand espoir de voir la partie software de l’arduino Due évoluer dans le bon sens (ou dans le mauvais).
Publié par skywodd | 20 septembre 2013, 16 h 47 minJe rejoins ceux qui estiment que la frontière entre l’Arduino Due et le rPi est de plus en plus ténue, si ce n’est la perf globale pour ce que j’ai pu tester. A la lecture de cet article, je m’en suis repris un pour faire mumuse vite fait
http://www.matlog.com/fr/microcontroleurs-arduino/179-cartes-controleurs-arduino.html#/arduino_contrleurs_extensions_et_accessoires-arduino_due
Bon c’est pas leur meilleur mais en même temps pas leur pire non plus, ca peut gérer de petits processus sans trop de soucis. Après c’est clair que pour de plus gros besoins, le rPi tient quand même mieux la route.
Bref, je trouverai bien un truc rigolo à faire avec 🙂
Publié par P1ng B4ck | 7 octobre 2013, 15 h 45 minbonjour .je veu savoir comment configurer arduino DUE pour Quelle fournie 5v .. ya le pin IOREF mais je savait pas comment l utilisé ….
Merciii d avance
Publié par yassine | 16 mars 2014, 21 h 32 minLa Due travaille uniquement en 3v3, il n’y a pas de moyen de la faire travailler en 5v.
Si tu doit interfacer des composants 5v avec la Due il faudra ajouter un étage « tampon ».
Publié par skywodd | 24 mars 2014, 14 h 12 minLa meilleure solution c’est une MEGA + une raspberry PI 2B en i2c ou soi.
Publié par Jean Verrazane | 19 février 2015, 10 h 01 minOu pas.
Les microcontrôleurs c’est pour faire du temps réel, le raspberry pi (et linux en général) c’est pour faire du user-mode.
En règle générale, une application est soit conçue pour faire du temps réel, soit conçue pour faire du user-mode, mais pas les deux (sinon ça devient bordélique).
Publié par Skywodd | 22 février 2015, 19 h 15 minSalut ! Je tiens à préciser qu’ils ont changé de compilateur :
gcc version 4.8.3 20140228 (release) [ARM/embedded-4_8-branch revision 208322] (GNU Tools for ARM Embedded Processors)
Publié par Alexis Paques | 13 décembre 2015, 14 h 03 minBonne nouvelle !
Publié par Skywodd | 25 décembre 2015, 17 h 35 minHello Skywodd,
Tout d’abord, merci pour cet article, même si il a déjà quelques années
J’ai ‘acheté une DUE pour remplacer une MEGA2560… pourquoi ? juste la vitesse d’exécution qui devenais trop lente pour gérer mon projet (ampli 7.1, une volée de relais traditionnels et SSR, ambilight, androbox,… et j’en passe, le tout commandé par bluetooth depuis ma tablette)
Avec tout branché, il y a les 3 UART utilisés (dont un pour un écran Nextion) et 47 I/O pour tout commander… avec la MEGA, le temps de réponse des commandes BT pouvait prendre jusqu’à 3 secondes… avec la DUE, c’est quasi instantané, le changement de pages sur le nextion est très rapide, j’ai juste dû utiliser des levels shifter pour passer du 3.3v au 5v.
Je sais que la DUE n’a pas trouvé beaucoup de preneurs (en tout cas pas autant qu’il auraient souhaité), mais ça reste une carte formidable, et extrêmement rapide par rapport aux autres…
Prochain projet sera sur du MKR pour tester un peu la bebête.
Bonne continuation
Aegnor
Publié par Aegnor | 1 février 2018, 22 h 45 min