next topic »

[on:]

Bonjour,

Je me pose une question depuis un certain temps...
je ne trouve pas la réponse...

Pourquoi arduino à t'il sorti il y a peu la révision 3 de la UNO, alors que depuis octobre, ils sont censés sortir la léonardo and co ???

Je comprends de moins en moins ce qu'ils font... C'est très décevant, et je pense qu'ils vont perdre pas mal de client à annoncer des nouveauté pour rien...

[Reply #1 on:]

Bonjour

sans explications de l'équipe Arduino on en est réduits aux hypothèses !! en voilà une :

-En passant de R2 à R3 ( plus précisément en remplaçant le mega8u2 par un mega16u2) UNO acquiert les fonctionnalités HID ('keyboard' ou 'mouse') dont Leonardo est doté. Les deux cartes de ce point de vue seront presque au même 'niveau' de fonctionnalités.

-UNO R3 intéressera les utilisateurs souhaitant conserver la possibilité d'échange et de remplacement du processeur principal (en boitier DIP et sur support).

-Leonardo et les cartes compatibles (vinciDuino...) sera moins cher .... mais destiné à la poubelle en cas d'erreur importante de manipulation entraînant la destruction du processeur.

Je vois deux cartes complémentaires. UNO aurait, je pense , été invendable s'il n'avait pas acquis les fonctionnalités USB HID (le mega8u2 s'est avéré trop 'juste' en mémoire flash pour faire cohabiter CDC et HID)

Le blocage pour Leonardo (les cartes sembles prêtes) pourrait être du coté de la 'librairie' HID jugée non aboutie. Les exemples 'keyboard' et 'mouse' présents dans les versions RC de 1.0 ont été enlevées au dernier moment dans la version 1.0.....

[Reply #2 on:]

okkkkk, cool merci pour les infos

[Reply #3 on:]

Salut,

-Leonardo et les cartes compatibles (vinciDuino...) sera moins cher .... mais destiné à la poubelle en cas d'erreur importante de manipulation entraînant la destruction du processeur.

Oui et non, remplacer un µc cms n'est pas infaisable, certes pour un non-expert ce serait trés complexe mais même un carte genre arduino-pro peut être réparé à la main.

Je vois deux cartes complémentaires. UNO aurait, je pense , été invendable s'il n'avait pas acquis les fonctionnalités USB HID (le mega8u2 s'est avéré trop 'juste' en mémoire flash pour faire cohabiter CDC et HID)

Le blocage pour Leonardo (les cartes sembles prêtes) pourrait être du coté de la 'librairie' HID jugée non aboutie. Les exemples 'keyboard' et 'mouse' présents dans les versions RC de 1.0 ont été enlevées au dernier moment dans la version 1.0.....

Difficile de faire mieux que ce qui existe déja -> teensyduino, pour moi l'équipe arduino est partis sur une mauvaise pente, arduino sur SAM7 -> bonne idée, arduino sur m32u4 -> mauvaise idée (déja teensyduino trés aboutit, plein de hardware, ...)

[Reply #4 on:]

pour moi l'équipe arduino est partie sur une mauvaise pente,

+1
N'ayant aucune expérience en  matière de microcontroleur j'ai acheté de confiance une UNO qui s'est trouvée être buggée, la correction existait, il suffisait d'avoir l'honnêteté de le dire mais aucune info officielle n'a été diffusée, j'ai toujours accepté les erreurs reconnues mais j'ai toujours méprisé le manque d'honnêteté.
J'ai su comment la rendre opérationnelle grâce à la communauté, merci à vous. La communauté autour d'arduino est à mon sens ce qu'il a de plus précieux dans l'univers arduino, bien avant le matériel où les bibliothèques.

Je vois que la revision 3 est toujours buggée du point de vue mécanique : impossible de fixer la carte à l'aide de colonnettes métalliques à cause du connecteur ISP de l'atmega8(16) qui est à raz du trou pour la vis de fixation. La colonnette met la broche Reset de l'ISP à la masse !!!!.
Normalement Eagle aurait du hurler sauf s'ils ont désactivé les contrôles de proximité et si c'est vrai qu'ils ont fait ça je vous laisse le soin de qualifié la qualité du travail.

J'ai acheté une carte mais ce sera la seule, cette carte m'a démystifiée les microcontroleurs. La prochaine sera faite maison et sera programmée avec un programmeur ISP. Si éventuellement j'ai besoin de l'USB il existe des petits adatateurs USB/TTL autour de 5€ qui feront parfaitement l'affaire
Au débutants : n'ayez pas peur du fer à souder ça peut brûler au début quand on est maladroit (ou malagauche pour les gens normaux, c'est à dire nous les gauchers) mais on fait un travail incomparablement plus propre, plus stable donc plus performant qu'avec ces boîtes à fils.
Je n'empile pas les shields comme on empile des légos mais je fixe mes cartes sur une plaque epoxy cuivrée simple face qui me sert de support mécanique et surtout de plan de référence de masse.

[Reply #5 on:]

arduino sur m32u4 -> mauvaise idée (déja teensyduino trés aboutit, plein de hardware, ...)

Qu'elle soit issue de Teensy (pionière) , de l'équipe Arduino (à la bourre), développée de manière collaborative comme vinciDuino (mon choix) je trouve qu'il y a aussi la place pour une carte 8 bits à mega32u au format physique UNO (avec des trous pour colonnettes de fixation bien dégagées   ). L'association directe avec les shields existants est intéressante pour de nombreux utilisateurs. Pour d'autres utilisateurs les cartes aux formats breakout sont préférables... Perso : je veux les 2 !!

Ce n'est pas un 'grand bond en avant' , mais juste une sorte de  'UNO ++' donnant accès , grâce a des périphériques intégrés supplémentaires ou améliorés par rapport au Mega328 (USB, PLL, Timer HS, ADC a entrée différentielle...) a des sketches supplémentaires.... a un cout un peu réduit.

SAM7 : OK.... mais le portage des librairies demandra du temps et sans un vaste patrimoine de librairies ça ne décollera pas beaucoup plus vite que les Chipkit, Pinguino....
Sur le papier toutes ces cartes ARM ou MIPS sont excitantes, les prix 'renversants'....vient ensuite la constatation d'un cercle vicieux : peu de libs, petites communautés, peu de contributions, peu d''évolution.... Il faut pouvoir atteindre une 'masse critique' pour que le systéme s'amorce comme ce fut le cas pour le "phénomène" Arduino....

[Reply #6 on:]

SAM7 : OK.... mais le portage des librairies demandra du temps et sans un vaste patrimoine de librairies ça ne décollera pas beaucoup plus vite que les Chipkit, Pinguino....
Sur le papier toutes ces cartes ARM ou MIPS sont excitantes, les prix 'renversants'....vient ensuite la constatation d'un cercle vicieux : peu de libs, petites communautés, peu de contributions, peu d''évolution.... Il faut pouvoir atteindre une 'masse critique' pour que le systéme s'amorce comme ce fut le cas pour le "phénomène" Arduino....

Je code sur plateforme ARM, autant que sur avr/pic (et tout récemment msp430).
Il y a des standards en ARM (lib CMSIS, hardware, ...), des conventions, etc ... qui font que le passage d'un µc à un autre peu ce faire en quelques jours.
Le seul vrai probléme c'est qu'il faut trouver des personnes pour aider au développement/portage, apprendre la convention ARM, etc ... c'est ça le plus dure.

[Reply #7 on:]

Je n'ai pas de grande expérience ARM !!!Juste une impression. J'espère que je me trompe !!
il me semble que le ralentissement au développement des librairies ne vient pas du 'coeur' mais des périphériques : chaque licencié ARM ajoute 'ses' périphériques. Passer des Timers NXP aux Timers ATMEL, Texas ... demande inévitablement d'éplucher les data sheet. Idem pour les SPI, I2C,ADC .....
S'il y a des conventions permettant d'unifier et rapprocher tout ça , tant mieux !
ce serait dommage de retrouver le cloisonnement en 'niches' ou 'chapelles' qui régnait avant Arduino !

[Reply #8 on:]

il me semble que le ralentissement au développement des librairies ne vient pas du 'coeur' mais des périphériques : chaque licencié ARM ajoute 'ses' périphériques passer des Timers NXP aux Timers ATMEL, Texas ... demande inévitablement d'éplucher les data sheet. Idem pour les ADC et autres périphériques.

Les registres ont des fois des noms un peu différents selon l'architecture c'est vrai.
Mais il ya une certaine forme d'homogénéité dans les µc ARM Cortex vu qu'il doivent respecter des standards imposé par arm.com dont l'interface CMSIS : http://arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php qui donne les bases des structures/registres/...

The ARM® Cortex™ Microcontroller Software Interface Standard (CMSIS) is a vendor-independent hardware abstraction layer for the Cortex-M processor series.  The CMSIS enables consistent and simple software interfaces to the processor and the peripherals, simplifying software re-use, reducing the learning curve for new microcontroller developers and reducing the time to market for new devices.