Arduino 1.0 et UNO Rev3, les changements qui changent tout !

Bonjour tout le monde !

Aujourd’hui je vais vous parler d’un sujet qui fait polémique depuis maintenant quelques temps, à savoir la sortie de l’ide arduino 1.0 et les changements qui y ont été introduits !

Mais avant ça je vous propose un petit test de la carte Arduino UNO Rev3 histoire de voir un peu les changements hardware avant de s’attaquer aux changements software 😉

Niveau packaging aucun changement, la petite boite bleue et blanche est toujours la même, avec son sticker « made in italy ».

Comme avec la UNO Rev1 & 2 lors de l’ouverture on se retrouve avec un flyer « Thanks for supporting open source ».

Avec le flyer se trouve un lot de sticker, c’est très « gadget », ça fait juste office de décoration …
Mais ce genre de petites attention rappelle qu’ arduino n’est pas seulement une carte mais aussi une philosophie soutenue par une grande communauté 😉

Bon allez on rentre dans le vif du sujet !
A première vue la UNO Rev3 et identique à la UNO Rev2. A première vue seulement 😉

Si vous regardez bien vous verrez qu’il y a eu de petites modifications, certes minimes (enfin pas tellement pour certaines) mais qui changent beaucoup de choses !
Regardons tout ça en détail !

Tout d’abord le « vieux » et inutilisable ATmega8u2 a été remplacé par un ATmega16u2, avec deux fois plus de ram et de flash.
Conséquence directe pour le bricoleur expérimenté, pouvoir utiliser le port usb natif du 16u2 pour développer des applicatifs usb !
Pour l’arduiniste lamba cela n’aura pas énormément d’impact, mais le fait que la team arduino zit jugée intéressant d’écouter les Arduinistes amateurs d’usb est un bon point !

Autre modification qui cette fois touche l’utilisateur expérimenté tout comme l’utilisateur lamba, le résonateur céramique des cartes UNO Rev2 a été remplacé par un vrai quartz !
Vrai quartz = meilleure stabilité = moins d’erreurs de communication usb/série = meilleur upload et la possibilité d’utiliser à 100% le m16u2.

Ajouté à cela que désormais le port ISP du m16u2 est pré-soudé, ce qui permet au bricoleur de faire mumuse facilement, ou pour l’utilisateur lamba de pouvoir transformer (via le bootloader DFU du m16u2) la partie usb en programmateur d’AVR ISP et directement « sauver » une carte arduino Rev3 dont le bootloader serait brické sans aucun autre matériel !

On remarquera que le bouton de reset a « migré » vers le coin haut-gauche de la carte, cela le rend plus facile à manipuler lorsque plusieurs shield sont empilés par dessus l’arduino, et laisse une grande zone libre au milieu de la carte.

Il aurait pu être intéressant d’utiliser cette zone libre pour mettre un vrai quartz en lieu et place du résonateur pour l’ATmega328p, cela aurait était en accord avec le choix fait pour la partie usb, dommage …

Il n’y a pas que le bouton reset qui a été modifié, le circuit de reset a lui aussi était amélioré !
Avec les cartes Rev2 il était impossible sans modification d’utiliser le sketch ArduinoISP par exemple, cela était du au circuit de reset mal conçu dont une diode avait été oubliée.
Avec la Rev3 le problème est désormais réglé et au passage le circuit tout entier a bénéficié d’un petit coup de neuf !

On remarquera l’apparition de deux nouvelles broches sur la gauche du reset, une sans nom et un autre « IOREF », la 1er sera vraisemblablement utilisée dans les prochaines versions de cartes arduino (arduino Due, …). Pour le moment son utilité est indéterminée.
La seconde broche IOREF permettra lors de la mise sur le marché de carte Arduino 5v et 3v3 de « dire » aux shield sous quelle voltage de référence marche la carte arduino, cela permettra de concevoir des shield utilisables aussi bien en 3v3 qu’en 5v, à l’heure actuelle les fabricants « sérieux » comme sparkfun font déjà des shield 3v3 / 5v il ne devrait donc pas y avoir de gros problèmes.

Autre modification propre au nouveau pinout arduino 1.0, les broches SDA SCL du bus I2C ont été déportées sur le coin haut-gauche de la carte.
Pourquoi ? Pour quelle utilitée ? Le mystère reste entier … En tout cas cela ne représente selon moi qu’un ajout supplémentaire de connecteurs inutiles qui auront plus vite fait de perdre les débutants comptant le nombre de « trous » depuis la gauche qu’autre chose …

On l’attendait tous, c’est chose faite !
Désormais la révision de la carte est notée en toute lettres sur le dos de la carte !
C’est bête et méchant mais au moins il n’est plus nécessaire de comparer sa carte avec le schéma des différentes révisions pour savoir laquelle on possède !

Au passage la team arduino s’est fait un petit plaisir en inversant le skillscreen blanc/bleu par rapport au version Rev1 & 2.

On retrouve aussi écrit en toute lettres les broches du bus I2C (SDA SCL) plus besoin de chercher pour savoir qui est qui (bien que se rappeler que SDA = A4 et SCL = A5 ne soit pas très compliqué ;)).
J’aurai apprécié voir le même genre de « commentaires » pour le bus SPI, cela aurait était plus facile lors d’un câblage de repérer les différentes broches MISO/MOSI/SCK/SS.

Voici un petite comparaison entre la Rev2 et la Rev3, on remarque que certain composants ont migré, que d’autre ont été remplacés, que le nouveau régulateur semble plus petit que l’ancien, qu’il manque le « Made in italy », etc etc …
(Je vous laisse chercher les autres modifs :))

Petit détail qui pour moi est bon à préciser, le skillscreen bleu est de bien meilleur qualité que l’ancien !
L’ancien était « baveux », d’un bleu délavé et les via étaient mal recouvertes, la Rev3 n’a plus aucun de ces mauvais points !

Alors vous vous demandez sûrement ce que ça change concrètement ?
Skillscreen de meilleure qualité = meilleure protection = durée de vie / résistance aux rayures accrues + un aspect visuel plus « joli » et surtout plus de risque de faire un cours-circuit entre deux via si un morceau de métal touche la carte.

—

J’en est fini avec les changements hardware, passons maintenant aux changements software !

Au niveau de l’ide :
– nouvelle extension de fichier, les .pde (extension des programmes processing à l’origine -> conflit d’extension) laisse la place aux .ino (derniére lettres de arduINO),
– nouveaux icônes « vérifier », « upload » plus joli et lissés,
– nouvelle charte graphique avec de nouvelles couleurs « fluo », une nouvelle image de démarrage et un icône lissé,
– affichage du nom de la carte et du port série en cours d’utilisation en bas à droite de l’ide,
– les liens url sont désormais clickable (commentaires avec un lien -> click -> ouvre le navigateur par défaut),
– une barre de progression affiche l’état de la compilation (en réalité elle ne signifie pas grande chose, c’est juste pour occuper l’œil le temps de la compilation ;)),
– possibilité d’utiliser un programmateur non-arduino (en ISP sans bootloader par exemple) directement par un shift+click sur le bouton « upload » ou depuis « upload using programmer » depuis le menu « tools »,
– possibilité de choisir le niveau de verbosité du compilateur et de l’upload directement depuis le menu préférences.

Au niveau de l’architecture de fichier :
– WProgram.h et Wiring.h ont été supprimés pour laisser place à Arduino.h,
Cela a une conséquence directe et immédiate que toute les librairies crées avant arduino 1.0 ne pourront plus compiler sans modifier la ou les lignes :

#include <WProgram.h> en #include <Arduino.h> 

(même chose pour Wiring.h)
– les fichiers de définitions des ports et des broches ont été séparés en différents sous fichiers afin de pouvoir « créer » des variantes de pinmapping très facilement.
Il suffit alors de choisir le pinmmaping via la ligne ####.build.variant de la carte voulu dans boards.txt.
Par la même occasion des macros ont pu être créées permettant de récupérer différentes informations sur le type de carte choisie et les spécifications qu’elle possède.

Au niveau de langage et de l’api arduino :
– la fonction Serial.write() est désormais non bloquante, c’est à dire qu’elle laisse continuer le reste du programme tout en envoyant les données en parallèle,
– La fonction Serial.flush() ne « vide » plus le contenu du buffer d’entrée comme c’était le cas avant mais attend la fin des transferts de données série sortant en cours.
Cette modification fait partie des changement incompréhensibles de la part de la team arduino, en fait désormais Serial.flush() se comporte comme une fonction d’attente de fin de transmission … ce qui n’est pas représentatif de son nom .flush(), en fait cette fonction devrait plutôt s’appeler .wait() par exemple …
Cela va avoir pour conséquence de créer d’énormes bug dans les sketch précédemment écrit utilisant Serial.flush() pour vider le buffer entrant …
– La librairie SoftSerial qui ne marchait jamais n’est plus ! NewSoftSerial la remplaçait en reprenant son nom !
– Les librairies Matrix et Sprite ont été supprimés,
– Serial.print(byte) affiche désormais le byte sous la forme d’un nombre et non d’un caractère,
– Serial.print(xx, BYTE) n’existe plus et laisse la place à Serial.write(xx) faisant la même chose mais de manière plus rapide,
– write(), print(), and println() retourne désormais un size_t (unsigned int) égale au nombre d’octets écrits.
Conséquence immédiate, toute les librairies utilisant la classe « Print » en « extends » ne compileront plus, le problème c’est qu’a moins d’être le développeur de la librairie vous aurez un mal fou à tout refaire en renvoyant un size_t … c’est le problème le plus embêtant de tous …,
– write(str) de la classe « Print » n’est plus déclarée comme « virtual », les librairies utilisant « Print » ne peuvent et ne doivent plus surcharger .write(str).
(Même problème que pour la ligne au dessus),
– les fonctions getWriteError(), clearWriteError(), et setWriteError() ont été ajoutées à la classe « Print », ces fonctions permettent aux dév de gérer la présence d’erreurs lors de l’exécution,
– la possibilité de faire « client == NULL » ou « client != NULL » avec un objet Client de la librairie Ethernet a été supprimée, il faut désormais utiliser if(client) ou if(!client),
– la classe « String » a été entièrement revue et amélioré,
– une macro F(« blabla ») permettant de placer du texte directement en PROGMEM a été ajoutée,
– la librairie Ethernet supporte désormais le DHCP et le DNS, l’utilisation d’une ethShield est donc désormais un vrai jeu d’enfant,
– Les objets Client, Server et UDP de la librairie Ethernet ont été renommés en EthernetClient, EthernetServer et EthernetUDP afin d’éviter tout conflit lors de l’utilisation de plusieurs librairies orientées réseaux,
– modification dans la classe UDP de la librairie Ethernet :
— beginPacket() / endPacket() pour la création manuelle de paquets UDP,
— utilisation de write(), print(), and println() pour la mise en forme des données du paquet UDP,
— parsePacket() pour vérifier la présence d’un nouveau paquet reçu et si possible le « parser » (décompacter),
— available(), read(), peek() pour lire les données reçues dans le paquet UDP,
— remoteIP(), remotePort() pour obtenir les informations réseau du paquet reçu,
– Ajout d’une classe « IPAddress » pour la gestion et la mise en forme « simple » d’une adresse IP,
– la librairie Wire est désormais une sous classe de Stream, par conséquent Wire.receive devient Wire.read(), Wire.send() devient Wire.write(), et il devient possible d’utiliser Wire.print(), Wire.println(), etc etc …,
– la librairie SD supporte désormais l’ouverture de plusieurs fichiers en parallèle et une fonction pour parcourir un répertoire,
– une interruptions serialEvent() a été ajouté, elle se déclenche dés que des données sont reçues sur le port série (+ serialEvent1(), serialEvent2(), and serialEvent3() sur les cartes mega),
– les routines find(), findUntil(), parseInt(), parseFloat(), readBytes(), readBytesUntil(), and setTimeout() ont été ajoutées à la classe Stream.
L’avantage de ces nouvelle fonctionnalités est que comme Serial utilise Stream il devient possible de faire des réceptions d’int, de float, … depuis le port série via Serial.parseInt() par exemple ! Il en est de même pour toutes les librairies utilisant Stream.
– la librairie Firmata a été mise à jour vers la version 2.3 (R7), les broches analogiques sont désormais numérotées à partir de 14 (et non plus à partir de 16) lorsqu’elles sont utilisées en entrées/sorties digitales.

Au niveau de la toolchain WinAVR :
– mise à jour de avrdude vers la version 5.11 et utilisation de la config « arduino » à la place de la config « skt500 » qui nécessitait une modification du code source.

pfffffiou! Que de changements hein !
Je vais pas partir dans le débat du pourquoi tant de changement si radicale qui rendent la version 1.0 non rétrocompatible.
Ce qu’il faut se rappeler c’est que les versions pré-1.0 était des béta, avec la version 1.0 l’ide arduino passe en statut « stable », il est donc normal qu’il y ait tant de changements.

En gros il y a désormais deux époques, l’avant et l’après arduino 1.0.
Pour le moment je conseille à tous les débutants de rester sous arduino 0022/0023, les tutoriels, exemples, etc étant faits avec ces versions et non compatibles avec la 1.0.
La pensée derrière ces changements était la suivante, la team arduino vise plus haut, du coté des ARM7, des m32u4, … les nouvelles librairies vont donc devoir s’adapter pour gérer des I/O en 3v3, des plateformes multiples (ARM, AVR, …) voire même des compilateurs multiples !
Le hardware va lui aussi devoir s’adapter, le projet arduino est en train de décoller, soit les dév mettront à jour leurs libraires pour fonctionner sous arduino 1.0 soit elles finiront dans l’oubli, c’est ainsi que ça marche !

A défaut de pouvoir créer une couche d’abstraction matériel totale qui permettrait de pouvoir coder aussi bien sur un pic, un pic32, un avr, un arm7, etc de la même façon il va falloir que les dév gèrent plusieurs versions de leur code, et ce sur plusieurs plateformes, chose que peu feront malheureusement …

Je rappelle aussi qu’en plus de tous ces changements s’annonce l’arrivé cette année de l’arduino Due (Arduino avec un ARM7) et de l’arduino Leonardo (Arduino avec ATmega32u4), autant dire que 2012 s’annonce riche en bouleversement !

Il est aussi très net que la communauté arduino à totalement dépassé la team arduino, les communautés Arduinistes internationale montrent qu’elles existent, les projets hardware et software « arduino like » se multiplient en particulier autour de la futur leonardo qui possède déjà 3 « clones » avant même sa sortie officielle ! (dont une version faite par olimex que je vais m’empresser de tester courant février si mes finances le permettent)