Galileo : Intel annonce un partenariat avec Arduino autour de ses SoC Quark

Galileo : Intel annonce un partenariat avec Arduino autour de ses SoC Quark

Let's bidouille !

Avatar de l'auteur
David Legrand

Publié dans

Sciences et espace

03/10/2013 3 minutes
60

Galileo : Intel annonce un partenariat avec Arduino autour de ses SoC Quark

Lors de l'IDF, Intel dévoilait un nouveau SoC orienté avant tout sur la basse consommation : le Quark X1000. Certains le voyaient déjà intégrer des plateformes spécifiques à la manière des Raspberry Pi, et les récents pas du constructeur vers le monde de l'Open Hardware allaient dans ce sens. Finalement, c'est un partenariat avec Arduino autour de la carte Galileo dont il est question.

Intel Galileo Intel Galileo

 

Le mois dernier, Intel levait le voile sur son projet Quark mais disait finalement peu de chose au sujet de cette puce orientée basse consommation. Aujourd'hui, on ne sait pas grand-chose de plus, mais les plans du géant de Santa Clara commencent à prendre forme avec l'annonce de Galileo. Derrière cette référence, il ne se cache pas un nouveau système de positionnement, mais bien une carte certifiée par Arduino, équipée d'un Quark X1000.

 

Dérivé du Pentium, celui-ci se limite au traitement sur 32 bits, ne dispose que d'un seul cœur, et fonctionne jusqu'à 400 MHz. Il est conçu dans les usines Irlandaise du fondeur, dispose de 16 ko de cache L1, de 512 ko de SRAM embarquée, mais l'on n'a pour le moment pas droit à plus de détails. La carte exploite un dérivé de Linux, open source, qui fonctionne de pair avec la couche logicielle Arduino. Il sera ainsi possible de la programmer depuis Linux, OS X ou Windows. 

 

Intel Galileo

 

De quoi permettre à l'X86 de se faire une place dans le monde des systèmes compacts et de l'embarqué « maison », dont il était franchement absent ces dernières années. Les « Shields » pour Arduino Uno R3 (3,3 V et 5V) sont supportés. Du côté des E/S, on retrouve de l'USB 2.0, du réseau à 100 Mb/s, du MicroSD, du RS-232, du Mini PCI Express, un connecteur JTAG, etc. Une puce Flash NOR programmable de 8 Mo est aussi présente. Les dimensions de l'ensemble sont de 10,67 x 7,11 cm. Ceux qui veulent en savoir plus pourront trouver tous les détails au sein de ce document.

 

Intel a mis en place un mini site dédié à Galileo. Nous tenterons d'en savoir plus dans les jours qui viennent. En attendant, la société a annoncé un partenariat avec 17 universités sur six continents afin de monter des projets autour de Galileo, ce qui devrait s'étendre. En effet, dans les 18 prochains mois, ce sont pas moins de 50 000 cartes Galileo qui seront distribuées à environ 1 000 établissements. Côté tarif, il est question de moins de 60 dollars, la disponibilité est annoncée pour le 29 novembre prochain.

 

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fermer

Commentaires (60)


A quoi ça sert ?








sofien a écrit :



A quoi ça sert ?





Faire de l’informatique embarquée en x86 ^^



Ça aurait été mieux si la carte pouvait lancer un linux depuis la carte SD, mais du coup l’IDE d’arduino ne serait plus très utile…


Merci. De l’informatique embarqué c’est de l’informatique à l’intérieur d’une voiture part exemple ?








sofien a écrit :



A quoi ça sert ?







je suis assez d’accord avec toi sur un point : c’est un peu “batard” comme produit.




On aurait peut etre plus attendu un espèce d'Atom minimaliste venant s'integrer dans des produits équivalent à une Raspberry PI à un prix plus ou moins équivalent. Cela aurait eu du sens : un linux x86 "classique" sur une carte de très faible cout, très faible puissance.   



La, on à une puce “trop” faible pour beaucoup de chose (ma RPI servant par exemple en ce moment dans des projets de SDR) et trop puissante pour un “simple” Arduino (bien qu’elle apporte de la connectivité en plus !) et surtout, trop cher ! Et puis, un linux embarqué faisant “tourner” un environnement Arduino, la perte de puissance n’est pas négligeable.



A voir donc, mais Galileo me parait etre un peu sans public visé.



@Amfxr0 : c’est juste que je connaissais pas le principe de l’arduino.


C’est intéressant, mais il s’agit effectivement d’un produit un peu bâtard. Les microcontrôleurs Atmega des sont déjà bien costauds compte tenu de l’usage moyen d’un Arduino… Mais ça doit quand même avoir ses applications. Côté prix, ça se tient aussi.








amFXR0 a écrit :



je suis assez d’accord avec toi sur un point : c’est un peu “batard” comme produit.




On aurait peut etre plus attendu un espèce d'Atom minimaliste venant s'integrer dans des produits équivalent à une Raspberry PI à un prix plus ou moins équivalent. Cela aurait eu du sens : un linux x86 "classique" sur une carte de très faible cout, très faible puissance.   



La, on à une puce “trop” faible pour beaucoup de chose (ma RPI servant par exemple en ce moment dans des projets de SDR) et trop puissante pour un “simple” Arduino (bien qu’elle apporte de la connectivité en plus !) et surtout, trop cher ! Et puis, un linux embarqué faisant “tourner” un environnement Arduino, la perte de puissance n’est pas négligeable.



A voir donc, mais Galileo me parait etre un peu sans public visé.





Sauf que c’est du x86 et non du ARM, donc ne pas comparer les fréquences et en déduire des performances ;)



Ceux qui ont des applications embarquées sur FreeDOS doivent être content.



Seul hic, l’USB. Il existe des “drivers” (a.k.a. fichiers .SYS) USB pour DOS, mais je ne connais pas leur statut légal.








sofien a écrit :



Merci. De l’informatique embarqué c’est de l’informatique à l’intérieur d’une voiture part exemple ?







Entre autre, tu peux aussi en avoir dans des process industriels, des tramways, ascenseurs (oui, oui mais pas pour contrôler l’engin <img data-src=" /> )









amFXR0 a écrit :



je suis assez d’accord avec toi sur un point : c’est un peu “batard” comme produit.




On aurait peut etre plus attendu un espèce d'Atom minimaliste venant s'integrer dans des produits équivalent à une Raspberry PI à un prix plus ou moins équivalent. Cela aurait eu du sens : un linux x86 "classique" sur une carte de très faible cout, très faible puissance.   



La, on à une puce “trop” faible pour beaucoup de chose (ma RPI servant par exemple en ce moment dans des projets de SDR) et trop puissante pour un “simple” Arduino (bien qu’elle apporte de la connectivité en plus !) et surtout, trop cher ! Et puis, un linux embarqué faisant “tourner” un environnement Arduino, la perte de puissance n’est pas négligeable.



A voir donc, mais Galileo me parait etre un peu sans public visé.







+1



Intel vise un marché où il brille par son absence.

ARM propose une gamme très complète et étendue à destination du marché embarqué : des microcontrôleurs les moins puissants (Cortex M0, ARM7) aux SoC les plus performants (Cortex A15, futur A57).



Intel n’est pas, ou n’a pas été absent de ce marché, avec les vieux micros 805152 et les multiples dérivés et évolutions (MCS-151251), voire une alternative compatible quelque peu furtive à ARM avec son XScale, dans une gamme plus puissante.

Mais le souci c’est que ces produits ne se sont jamais imposés, faute à une évolution trop timide face au grandissant ARM, qui est devenu ce qu’il est aujourd’hui.



Voilà maintenant qu’il lance un produit bâtard, comme dit amFXR0, car au positionnement tarifaire d’un Raspberry Pi, avec ce qui semble être la puissance d’un processeur à mi-chemin entre le microcontrôleur et le SoC, et pour finir, en visant l’environnement d’un Arduino.



Ceci dit, je salue et encourage fortement l’initiative de se lancer dans le domaine de l’embarqué low-cost, car avoir un positionnement tarifaire accessible au hobbyiste permettra sans doute de reconquérir le marché de l’embarqué.



A quand un Raspberry-like à base d’Atom ?



Par rapport à l’actuel plate-forme Arduino je vois pas la plu-valu qu’Intel apporte ici. Parce que franchement que ce soit de l’ARM ou du X86 sur ce genre d’application…. on s’en f…








fulkony a écrit :



Par rapport à l’actuel plate-forme Arduino je vois pas la plu-valu qu’Intel apporte ici. Parce que franchement que ce soit de l’ARM ou du X86 sur ce genre d’application…. on s’en f…





Bah, les perfs, les Arduino actuels ont des perfs un peu en deça XD









fulkony a écrit :



Par rapport à l’actuel plate-forme Arduino je vois pas la plu-valu qu’Intel apporte ici. Parce que franchement que ce soit de l’ARM ou du X86 sur ce genre d’application…. on s’en f…











eagleofdeath13 a écrit :



Bah, les perfs, les Arduino actuels ont des perfs un peu en deça XD







T’es sûr ?

Il semblerait que Quark soit du niveau pentium d’«autrefois»…



Mais comme les CPUs sur Arduino ne sont pas non plus des foudres de guerre, je dirais plutôt qu’il faut attendre pour (sa)voir.









sofien a écrit :



A quoi ça sert ?





A relancer XP. <img data-src=" />









levhieu a écrit :



Il semblerait que Quark soit du niveau pentium d’«autrefois»…





Oui, Pentium P54C a 400 MHz. Fatalement pour faire du petit avec du x86 faut remonter loin <img data-src=" />



Grrrrrrrrrrrrrrrr. Il manque le ouifi <img data-src=" /><img data-src=" />








eagleofdeath13 a écrit :



Sauf que c’est du x86 et non du ARM, donc ne pas comparer les fréquences et en déduire des performances ;)







Tout à fait !

Néanmoins, je crois que la, nous sommes face à une puce aux performances très limitées. Il faudrait voir rapportée à la consommation.

Je ne dénigre pas le SoC en lui même, plutôt la façon de le présenter et de le vendre !









lolomatic a écrit :



A quand un Raspberry-like à base d’Atom ?







Oui, ca serait intéressant. un SoC x86, donc profitant de tout les drivers et package existant, avec des performances décentes et une consommations bien gérée. Le tout à un prix concurrentiel !

A voir si Intel revient dans la course









sofien a écrit :



@Amfxr0 : c’est juste que je connaissais pas le principe de l’arduino.







Ok pardon !

En effet, c’est destiné à des applications embarquée ou la puissance de calcul n’est pas la pas la priorité. Ces boards là permettent de tester les SoC et de faire des petits projet DIY



:( je m’attendais en voyant le titre à ce que ça cause d’intel qui intègrerait des solutions du concurrent européen du GPS :/








jinge a écrit :



:( je m’attendais en voyant le titre à ce que ça cause d’intel qui intègrerait des solutions du concurrent européen du GPS :/









idem









jinge a écrit :



:( je m’attendais en voyant le titre à ce que ça cause d’intel qui intègrerait des solutions du concurrent européen du GPS :/







[HS]

La plupart des puces GPS vendues depuis quelques années seront compatibles automatiquement ou avec une mise à jour software avec Galilelo dès que celui-ci sera disponible pour le public.

[/HS]









jinge a écrit :



:( je m’attendais en voyant le titre à ce que ça cause d’intel qui intègrerait des solutions du concurrent européen du GPS :/





<img data-src=" />





euh … pareil <img data-src=" />









levhieu a écrit :



T’es sûr ?

Il semblerait que Quark soit du niveau pentium d’«autrefois»…



Mais comme les CPUs sur Arduino ne sont pas non plus des foudres de guerre, je dirais plutôt qu’il faut attendre pour (sa)voir.





Oui, mais un Arduino, c’est basé sur des minuscules Atmel http://en.wikipedia.org/wiki/ATmega328 pour le plus gros ^^)

Donc tu te chope avec une carte compatible Arduino (pin et dev) mais avec des perfs se rapprochant du RaspBerryPi, c’est un produit entre les deux, mais ça m’étonnerait pas qu’il y ait un besoin en ce sens. Un GROS Arduino à pas trop cher.









eagleofdeath13 a écrit :



Oui, mais un Arduino, c’est basé sur des minuscules Atmel http://en.wikipedia.org/wiki/ATmega328 pour le plus gros ^^)

Donc tu te chope avec une carte compatible Arduino (pin et dev) mais avec des perfs se rapprochant du RaspBerryPi, c’est un produit entre les deux, mais ça m’étonnerait pas qu’il y ait un besoin en ce sens. Un GROS Arduino à pas trop cher.







Du coté des Arduino Mega, il y a déja des SoC un peu plus puissant (Cortex-M3).

Et de plus, Arduino à lancer il y a très peu de temps le Yun, qui en plus du Atmel, embarque un processeur Atheros (l’idée étant de faire du DIY avec du réseau).

A voir si il trouve sa place entre les arduinos ethernet et le Yun par exemple.









sofien a écrit :



Merci. De l’informatique embarqué c’est de l’informatique à l’intérieur d’une voiture part exemple ?







quand on parle “embarqué”, ce n’est pas dans le sens “ ca bouge”, mais dans le sens “ caché”

wikipedia



le sens est plus “ c’est de l’informatique sans écran, sans clavier, sans qu’on se rende compte qu’il y a de l’informatique”



Je pense que le petit plus vis à vis des solutions ARM est le port PCIe. Ça laisse de la place pour pas mal de bidouille.








lolomatic a écrit :



des microcontrôleurs les moins puissants (Cortex M0, ARM7) aux SoC les plus performants (Cortex A15, futur A57).







Oui mais non, les A* nécessite un OS complet pour fonctionner. Il suffit de voir la tronche du code démarrage et la tonne de code de drivers qu’il faut pour ce genre de puce.



Les M0 et autre, ont besoin de moins de code de support, ce sont des nouveaux processeurs, qui tourne à 70Mhz avec une fpu, ce qui n’existait pas avant. C’est plus simple, mais pas si il vous faut une pile de protocole comme Bluetooth, IP, usb,…



L’avantage d’un vrai µp, c’est sa très basse latence, impossible à obtenir avec un PC x86.



Par contre, si il veulent développer de la robotique, il faut beaucoup plus d’IO : convertisseur analogique numérique pour les capteurs (même à 10khz, c’est suffisant, si il ne pompe pas 50% du cpu pour lire une trentaine de ligne), et PWM en sortie, pareil, sans consommation de cpu.



Pour information, un moteur classique à besoin d’une sortie PWM +3 IO de contrôle pour la partie puissance (pont en H), un moteur synchrone doit gérer minimum 3 pole de puissance, et donc a besoin de 3 sorties PWM (ces moteurs sont moins chère, plus puissant, et plus fiable que les moteurs à courant continu).



Pour savoir ce que fait le moteur, on a besoin d’une entrée analogique pour un servo-moteur (potentiomètre), ou de 2 entrées numérique en quadrature avec un compteur/decompteur pour un moteur tournant. On peut doubler cela pour mettre une capture après la transmission pour tenir compte des jeux mécanique, voir des glissements. On peut aussi rajouter un ampèremètre (une résistance faible branché sur une entrée analogique) pour mesurer la force déployée par le moteur.



Donc, pour résumer, il faudrait 4 sorties, et 4 entrées analogique par moteur. Nao le robot d’Aldebaran robotique a 25 moteurs…



Mais attention, si vous voulez relier un PC à plein de microcontrôleur. Un robot réactif nécessite une boucle lecture de capteurs/réflexion/correction des actionneurs de ~1khz.



Il existe très peu de norme de communication qui tienne cette vitesse : série, bus CAN ou I2C. Mais quand il faut gérer plus d’une centaine d’IOs, ses bus sont trop lents, l’usb a trop de latence.



C’est pour cela qu’un gros µP avec plein d’IO, est plus rapide qu’un ensemble relier par plein de bus. Un PC peut toujours être utilisé pour des taches moins réactives (communication IP, vidéo, cartographie de l’environnement, mémoire, etc…)



Si vous décidez de découper en sous-tache, “l’intelligence” du robot va être complexe à faire : imaginer la synchronisation de l’asservissement de 2 moteurs pour un simple robot type char, si les 2 asservissements ne sont pas fait ensemble.



Bref, on a besoin de SOC avec plein d’IOs avec ADC (à coté d’une fpu) pour faire de la vrai robotique !









cyrano2 a écrit :



Pour information, un moteur classique à besoin d’une sortie PWM +3 IO de contrôle pour la partie puissance (pont en H), un moteur synchrone doit gérer minimum 3 pole de puissance, et donc a besoin de 3 sorties PWM (ces moteurs sont moins chère, plus puissant, et plus fiable que les moteurs à courant continu).







Par moteur synchrone, tu veut dire moteur pas a pas ?

Mais du coup je vois pas a quoi sert le pwm…



Le prix est pas mal, je suis curieux de voir ce que ça donne par rapport au Arduino Yun, annoncé a 100$. Mais il est vrai que j’ai aussi vite fait de coller un atmega sur un Raspberry pi, et j’aurai un équivalent moins cher.







cyrano2 a écrit :





!





On est d’accord, on ne remplace pas un µC programmable par un CPU generaliste, pour les latences et tout. Encore que je suis sur qu’on doit trouver des ARM rapides capables de temps réel. (d’ailleurs dans certains routeurs, il y en a, avec des GPIO, que certains utilisent pour d’autres projets tels des robots)



Pour ton analyse sur les moteurs, pourquoi 1 pwm + 3GPIO? pour un moteur je vois 1PWM pour le enable, et deux autres pour la direction. Sachant qu’avec un driver optimisé, on pourrait passer à 1PWM pour le enable, et 1 GPIO pour la direction (0=backward, 1=forward, et le PWM pour le régime moteur).



Pour ce qui est de l’analyse sur les multiples IC, je ne suis pas non plus du tout d’accord. Sachant que la plupart des échanges de données ne sont sont pas nécéssaires entre tous les noeuds, on a pas besoin de gros bus. Toutes les fonctions dont tu parles (intensité, contrôle de position, etc) peuvent être faits à très haute fréquence par le µC local qui est chargé de surveiller quelques sous-systèmes du robot. Le µC/CPU central n’a pas besoin de connaitre l’intensité consommée par chaque moteur à chaque moment.



Il faut le voir comme un système nerveux, ou de nombreuses tâches sont gérées localement, et ou les informations importantes sont remontées au noeud supérieur.



Maintenant, autre point, sur les bus. En I²C on peut parvenir à plusieurs mbits/s sur le bus. Largement de quoi faire circuler tout un tas d’opérations!



Et d’autre part, tu n’as pas cité un autre bus : le SPI. Or, le SPI est excessivement plus efficace et rapide, et largement à même de supporter ce type de communications.



Bien entendu, si chaque noeud doit communiquer avec tous les autres tout le temps, il y a une taille limite ou ça va coincer. Maintenant, si on optimise bien, on peut aller très loin…



Sachant que pour moi tu as pris une marge extrêmement haute, avec une lecture des capteurs à 1Khz, quand on sait qu’un capteur de distance ultrasons à une fréquence de rafraîchissement de 20hz, et un capteur de distance IR de 400hz….

De même pour les capteurs des roues, vu qu’on parle de phénomènes physiques, il y a une latence sur ces phénomènes!



Je ne dis pas que ça ne sert à rien d’échantilloner si vite, mais dire que c’est un minimum pour un robot réactif me semble excessif.



Enfin, s’il te faut beaucoup de GPIO, il y a des puces pour ça, pour en rajouter :)

Avec un MCP23017 on rajoute 16GPIO, en I²C, avec plusieurs Mhz de fréquence sur le bus, et on peut en chaîner 7 sur le même bus. On a toute une collection de convertisseurs analogique-&gt;digital pour ajouter des entrées analogiques, qui se connectent en SPI ou I2C a haute vitesse aussi….



Pour le découpage en sous tâches, avec l’exemple char justement, c’est loin d’être complexe. Il suffit d’envoyer des commandes temporisée, et de les ré-évaluer régulièrement. Par exemple “tourne à gauche 1ms”, le µC de gauche l’interprete comme “fait tourner ta roue dans tel sens”, l’autre réagit d’une autre façon, et on tourne 1ms. Mais bon dans ce cas, il serait à mon sens plus logique et intéréssant d’avoir justement un µC pour contrôler cet ensemble fonctionnel, et un autre µC pour contrôler d’autres trucs, par exemple les capteurs. Le µC “moteur” reçoit une commande, l’exécute, et le µC senseurs analyse le mouvement via l’accéléromètre ou autre. Sachant que les fonctions de bas niveau comme la lecture de la conso des moteurs reste dans le µC moteur, qui peut interrompre l’action si la conso dépasse un seuil, alors que le circuit des senseurs se fiche de savoir la conso instantanée 1000 fois par seconde :)



Bref, en conclusion, un SOC avec plein d’IO c’est utile et pratique, mais il y a quand même d’autres solutions. Et justement je pense qu’une conception décentralisée en est une très intéréssante qui peut s’avérer plus simple ou plus complexe, plus ou moins éfficace selon les cas… A mon sens il vaut mieux ne pas être absolu dans son jugement :)









HyD_z a écrit :



Je pense que le petit plus vis à vis des solutions ARM est le port PCIe. Ça laisse de la place pour pas mal de bidouille.







+1









moxepius a écrit :



Par moteur synchrone, tu veut dire moteur pas a pas ?

Mais du coup je vois pas a quoi sert le pwm…







Ca va servir à “simuler” le déphasage qui sert à contrôler la rotation. Pour commander une carte de puissance qui alimentera directement les moteurs.









sky99 a écrit :



Il faut le voir comme un système nerveux, ou de nombreuses tâches sont gérées localement, et ou les informations importantes sont remontées au noeud supérieur.







Non, c’est pas bien ça. L’exemple typique que j’ai en tête, c’est le robot a roue, dont l’asservissement est local. L’AI a envie de savoir si le “I” du PID diverge, car cela serait la preuve d’un blocage. C’est super dure à faire en réparti.





“Maintenant, autre point, sur les bus. En I²C on peut parvenir à plusieurs mbits/s sur le bus. Largement de quoi faire circuler tout un tas d’opérations!”



3.5Mbits, pour 32 bits tu rajoutes l’entête, tu as ~50 bits pour une seul grandeur, 3500000/50/1000 = 70. 70 valeurs, c’est pas énorme pour 1 khz, avec zéro marge.



“De même pour les capteurs des roues, vu qu’on parle de phénomènes physiques, il y a une latence sur ces phénomènes! ”



Oui, mais un asservissement n’a d’effet que si tu as une dizaine de point. Donc une fréquence de 1khz, te donne 100 Hz “mécanique”, ce qui est largement possible (10ms). Si tu tournes à 100Hz, tu as 10 Hz mécanique et ta machine est d’une lenteur monstrueuse. En plus, un algo d’asservissement même mal régler est plus efficace à haute vitesse. C’est plus simple d’aller plus vite que de trouver les bonnes valeurs.



“On a toute une collection de convertisseurs analogique-&gt;digital pour ajouter des entrées analogiques, qui se connectent en SPI ou I2C a haute vitesse aussi…. ”



Et tu as calculé combien cela te prenais de cpu, si tu dois lire 100 ADC, et écrire 100 PWM par cycle ? Tu ne fais plus rien d’autre que faire de la com. Et encore, certain ADC demande tout un protocole à la con, avec des attentes actives.



“Et justement je pense qu’une conception décentralisée en est une très intéréssante qui peut s’avérer plus simple ou plus complexe, plus ou moins éfficace selon les cas… A mon sens il vaut mieux ne pas être absolu dans son jugement :) ”



Non, mais c’est quelques années de compétition e=m6 :) Il y a toujours une info que t’aimerais avoir mais tu peux pas car elle est disponible “ailleurs”. Pour un produit, ce n’est pas un problème, pour de la bidouille, c’est juste chiant, car pas assez flexible.









moxepius a écrit :



Par moteur synchrone, tu veut dire moteur pas a pas ?

Mais du coup je vois pas a quoi sert le pwm…







Non, je déteste les moteurs pas à pas, le couple diminue avec la vitesse. C’est horrible à gérer. Non un moteur synchrone fonctionne avec un champ magnétique que tu fais tourner avec 3 phases.









HyD_z a écrit :



Ca va servir à “simuler” le déphasage qui sert à contrôler la rotation. Pour commander une carte de puissance qui alimentera directement les moteurs.





Donc un seul pwm par moteur est suffisant.









cyrano2 a écrit :



Non, je déteste les moteurs pas à pas, le couple diminue avec la vitesse. C’est horrible à gérer. Non un moteur synchrone fonctionne avec un champ magnétique que tu fais tourner avec 3 phases.





Des moteur synchrones triphasés de petite taille, moins cher qu’un moteur pas a pas, je sait pas ou tu les trouves…









moxepius a écrit :



Des moteur synchrones triphasés de petite taille, moins cher qu’un moteur pas a pas, je sait pas ou tu les trouves…







Moins chère que l’équivalent à courant continu.









cyrano2 a écrit :



Oui mais non, les A* nécessite un OS complet pour fonctionner. Il suffit de voir la tronche du code démarrage et la tonne de code de drivers qu’il faut pour ce genre de puce.



[bla bla bla]







Oui mais non quoi ?



Merci de lire mon post avant de le citer…










lolomatic a écrit :



Oui mais non quoi ?



Merci de lire mon post avant de le citer…







Tu ne peux pas comparer de l’embarqué qui fonctionne sur un µP sans OS, et un système avec OS. Les arm de µP sont lent ~70Mhz, on est loin des ghz des versions A*.









cyrano2 a écrit :



Tu ne peux pas comparer de l’embarqué qui fonctionne sur un µP sans OS, et un système avec OS. Les arm de µP sont lent ~70Mhz, on est loin des ghz des versions A*.







LOL, Ô grand merci pour cette précision, je bosse dans le domaine depuis pas mal d’années mais je ne sais pas différencier un µC d’un SoC <img data-src=" />

Et peux-tu me dire où l’aurais-je faite, cette soit-disante comparaison ?



Encore une fois, si tu avais lu mon post initial, tu aurais compris que je je disais que ARM a une panoplie complète de solutions à destination de l’embarqué, du petit microcontrôleur au SoC puissant. Ceci, contrairement à Intel, qui essaie de conquérir maladroitement ce marché avec une telle offre.



Enfin bon, je ne vais pas ré-expliquer ici ce que j’ai mis dans mon post initial non plus. Si tu ne fais pas l’effort de le lire, je n’y peut rien.



En fait je me suis trompe, ce CPU est un derivatif du 486. Intel innove avec un desgin vieux de 23 ans <img data-src=" />








lolomatic a écrit :



LOL, Ô grand merci pour cette précision, je bosse dans le domaine depuis pas mal d’années mais je ne sais pas différencier un µC d’un SoC <img data-src=" />







10 ans pour ma part.





Et peux-tu me dire où l’aurais-je faite, cette soit-disante comparaison ?

Encore une fois, si tu avais lu mon post initial, tu aurais compris que je je disais que ARM a une panoplie complète de solutions à destination de l’embarqué, du petit microcontrôleur au SoC puissant. Ceci, contrairement à Intel, qui essaie de conquérir maladroitement ce marché avec une telle offre.





En même temps tu compares des 8 bits genre 80c51, les 32 bits arm, et les x86 embarqué, ce n’est pas les mêmes marchés.









sky99 a écrit :







Sachant que les fonctions de bas niveau comme la lecture de la conso des moteurs reste dans le µC moteur, qui peut interrompre l’action si la conso dépasse un seuil, alors que le circuit des senseurs se fiche de savoir la conso instantanée 1000 fois par seconde :)







Et dans le même temps, le µP doit informer la couche du dessus pour sa coupure. Autant remonter l’information directement. En plus, le seuil peut être dépendant d’autre valeur, par exemple, lors d’un démarrage à l’arrêt, information que ne peut pas avoir un µP enterré.



Imagines la posture d’un robot humanoïde, tous les moteurs doivent être ajuster en même temps pour garder l’équilibre, mais l’ajustement change, si le robot doit attraper un objet, marcher, monter un escalier, etc… L’AI de haut niveau n’aura pas une latence assez basse pour contrôler comme il faut les effecteurs avec des ordres de haut niveau.









cyrano2 a écrit :



10 ans pour ma part.





Bravo ! <img data-src=" />







cyrano2 a écrit :



En même temps tu compares des 8 bits genre 80c51, les 32 bits arm, et les x86 embarqué, ce n’est pas les mêmes marchés.







Ha non, non, je ne fais pas une telle comparaison.



Bon, je vais ré-expliquer (enfin, essayer) avec des mots tout simples hein :



Tu sais, l’embarqué c’est vaste ! Et quand je parle de “gamme très complète et étendue à destination du marché embarqué” (ça vient de mon post qu’il faut relire, mais ça je l’ai déjà dit), je ne vais pas parler uniquement de micros 8bits ou de Cortex M0 hein. Je vais parler de toute la gamme à destination du marché de l’embarqué !



Et là ?!?



Ho, surprise ! Je vais du M0 au A57 chez ARM.

Je parle donc de gamme, étendue et complète (je répète, mais ça me semble étrangement nécessaire).



Mais… pourquoi ai-je parlé de gamme étendue et complète ?



Pour préciser qu’ARM est bien implanté sur le marché de l’embarqué (qui est vaste… tu suis toujours ?), et pour la comparer avec celle d’un concurrent, ou d’un acteur voulant concurrencer, qui cherche à investir ce marché (…vaste) de l’embarqué.



Donc, ce que je compare, c’est pas les micros/SoC à l’intérieur d’une gamme, mais une gamme d’un concurrent avec une autre !



Je ne parle pas du marché des micros 8bits VS le marché des SoC 32 (et maintenant 64) bits ! (Bon j’insiste, mais j’ai vraiment l’impression que c’est nécessaire).



Enfin, je termine en disant que la carte proposée par Intel a un positionnement incohérent vis à vis de la concurrence (Arduino), en terme de format, d’offre, et de spécifications.

Le prix d’une carte genre Rpi/BeagleBone

Les fonctionnalités voulues d’un Arduino

Des specs à mi-chemin entre les deux produits (OS allégé, puissance intermédiaire).





Un peu plus clair ?



[mode Troll = ON]

Et les indiens dans tout cela, ils sont grands ou petits ?

[mode Troll = OFF]








ldesnogu a écrit :



En fait je me suis trompe, ce CPU est un derivatif du 486. Intel innove avec un desgin vieux de 23 ans <img data-src=" />



vu que pour chaque Hz le 486 est plus efficace que beaucoup d’archis plus récentes, c’est peut-être pas si con <img data-src=" />









Patch a écrit :



vu que pour chaque Hz le 486 est plus efficace que beaucoup d’archis plus récentes, c’est peut-être pas si con <img data-src=" />





Quand tu vises de l’embarque petit tu ne vises pas la perf, tu vises le prix.



Et j’attends tes benchmarks comparant un 486 a un chip recent :)









lolomatic a écrit :



Pour préciser qu’ARM est bien implanté sur le marché de l’embarqué (qui est vaste… tu suis toujours ?), et pour la comparer avec celle d’un concurrent, ou d’un acteur voulant concurrencer, qui cherche à investir ce marché (…vaste) de l’embarqué.



Donc, ce que je compare, c’est pas les micros/SoC à l’intérieur d’une gamme, mais une gamme d’un concurrent avec une autre !



Je ne parle pas du marché des micros 8bits VS le marché des SoC 32 (et maintenant 64) bits ! (Bon j’insiste, mais j’ai vraiment l’impression que c’est nécessaire).



Un peu plus clair ?









Oui. Mais je voulais juste dire qu’avoir une gamme complète et cohérente, on s’en fout un peu car les domaines d’usages et les marchés sont complètement différents.



ARM était dans le low cost avec ces cpu sans fpu et les téléphones. Dans l’embarqué type avion/train/bateau, c’est plus du PowerPc qu’il y a partout. Concernant les cpu plus petit que 32 bits, il y a tout un tas de marque et ARM est absent.









lolomatic a écrit :



A quand un Raspberry-like à base d’Atom ?











amFXR0 a écrit :



Oui, ca serait intéressant. un SoC x86, donc profitant de tout les drivers et package existant, avec des performances décentes et une consommations bien gérée. Le tout à un prix concurrentiel !

A voir si Intel revient dans la course







ça serait vraiment top, le même type de matos avec plus de puissance et la même communauté ultra active serait un must!







sky99 a écrit :



Le prix est pas mal, je suis curieux de voir ce que ça donne par rapport au Arduino Yun, annoncé a 100$:)







+1 très curieux d’en découvrir les possibilités!







cyrano2 a écrit :



Bref, on a besoin de SOC avec plein d’IOs avec ADC (à coté d’une fpu) pour faire de la vrai robotique !







On se croirait sur le forum de planeterobots.com<img data-src=" />



Si vous ne connaissez pas la rue, je vous la conseil










moxepius a écrit :



Des moteur synchrones triphasés de petite taille, moins cher qu’un moteur pas a pas, je sait pas ou tu les trouves…





sur hobbyking par exemple, mais c’est du brushed souvent pour les petits modeles, le brushless ca va de quelques grammes 15W a 1/2kg pour 1000W









amFXR0 a écrit :



[HS]

La plupart des puces GPS vendues depuis quelques années seront compatibles automatiquement ou avec une mise à jour software avec Galilelo dès que celui-ci sera disponible pour le public.

[/HS]





Merci pour l’info <img data-src=" />









ldesnogu a écrit :



Quand tu vises de l’embarque petit tu ne vises pas la perf, tu vises le prix.



Et j’attends tes benchmarks comparant un 486 a un chip recent :)



faut d’abord trouver un système pour baisser les fréq du chip récent.









Patch a écrit :



faut d’abord trouver un système pour baisser les fréq du chip récent.





J’ai cherché un peu à gauche et à droite et c’est difficile.



En tout cas les 486 étaient donnés pour pouvoir faire en gros 40 millions d’instructions par seconde à 50 MHz. Je pense que c’est équivalent à ce qu’on trouve en contrôleur 32-bit genre Cortex M.









cyrano2 a écrit :



Oui. Mais je voulais juste dire qu’avoir une gamme complète et cohérente, on s’en fout un peu car les domaines d’usages et les marchés sont complètement différents.





Tu en arrives à te contredire dans la même phrase.

Non, justement, ni ARM, ni Intel “s’en fout un peu” car justement “les domaines d’usages et les marchés sont complètement différents”.

Donc ARM comme Intel aimeraient bien s’accaparer tous ces “marchés complètement différents”.



Comme le marché visé par la carte Galileo, où Intel était absent jusqu’à présent.

Comme le marché des SoC pour la mobilité, où Intel était absent jusqu’à présent.







cyrano2 a écrit :



ARM était dans le low cost avec ces cpu sans fpu et les téléphones. Dans l’embarqué type avion/train/bateau, c’est plus du PowerPc qu’il y a partout.





Pour avoir travaillé sur du ferroviaire/automobile/aéro embarqué, de mon humble expérience, seul l’aéro est encore très attaché au PowerPC. Quand on voit la rigidité de cet environnement lourdement normé, rien d’étonnant (les archis matérielles critiques évoluent peu, et les temps de développement sont longs).

Pour le reste, ARM s’implante très très bien, avec des acteurs solides tels que Freescale, par exemple.

Par contre, évidemment, je n’ai pas encore trouvé de Cortex dans un calculo, tout juste du ARM9 ou ARM11.

Je peux citer un acteur très (très très très) connu de la distribution électrique, dont les organes intègrent depuis longtemps une vaste panoplie dans la gamme ARM, en partant du petit ARM7 à l’ARM11. Et cet exemple date d’il y a 5 ans.



Réduire ARM à du low cost sans fpu ou pour les téléphones, ce n’est que voir leurs implémentations low cost justement (où je pense qu’ils sont majoritaires).



Je sais pas dans quel domaine précis de l’embarqué tu bosses depuis 10 ans, mais dans l’industrie, la vraie, force est de constater qu’ils sont bien présents, sans pour autant prétendre qu’ils sont majoritaires.







cyrano2 a écrit :



Concernant les cpu plus petit que 32 bits, il y a tout un tas de marque et ARM est absent.





Oui, il y a tout un tas de marques (Microchip et Atmel pour ne citer que ces poids lourds).

Non ! ARM n’est pas absent [sur ce domaine].

Les Cortex M0 sont bien là pour concurrencer les 8 et 16 bits sur leur terrain, c’est leur but totalement avoué par la marque !









barlav a écrit :



sur hobbyking par exemple, mais c’est du brushed souvent pour les petits modeles, le brushless ca va de quelques grammes 15W a 1/2kg pour 1000W





Merci, mais ça semble être des moteurs asynchrone, donc pas pratique pour des mouvement précis.



Correction du post du dessus, trop tard pour editer, il y a bien ceux dont parle cyrano2.








lolomatic a écrit :



Tu en arrives à te contredire dans la même phrase.

Non, justement, ni ARM, ni Intel “s’en fout un peu” car justement “les domaines d’usages et les marchés sont complètement différents”.

Donc ARM comme Intel aimeraient bien s’accaparer tous ces “marchés complètement différents”.



Comme le marché visé par la carte Galileo, où Intel était absent jusqu’à présent.

Comme le marché des SoC pour la mobilité, où Intel était absent jusqu’à présent.





Pour avoir travaillé sur du ferroviaire/automobile/aéro embarqué, de mon humble expérience, seul l’aéro est encore très attaché au PowerPC. Quand on voit la rigidité de cet environnement lourdement normé, rien d’étonnant (les archis matérielles critiques évoluent peu, et les temps de développement sont longs).

Pour le reste, ARM s’implante très très bien, avec des acteurs solides tels que Freescale, par exemple.

Par contre, évidemment, je n’ai pas encore trouvé de Cortex dans un calculo, tout juste du ARM9 ou ARM11.

Je peux citer un acteur très (très très très) connu de la distribution électrique, dont les organes intègrent depuis longtemps une vaste panoplie dans la gamme ARM, en partant du petit ARM7 à l’ARM11. Et cet exemple date d’il y a 5 ans.



Réduire ARM à du low cost sans fpu ou pour les téléphones, ce n’est que voir leurs implémentations low cost justement (où je pense qu’ils sont majoritaires).



Je sais pas dans quel domaine précis de l’embarqué tu bosses depuis 10 ans, mais dans l’industrie, la vraie, force est de constater qu’ils sont bien présents, sans pour autant prétendre qu’ils sont majoritaires.





Oui, il y a tout un tas de marques (Microchip et Atmel pour ne citer que ces poids lourds).

Non ! ARM n’est pas absent [sur ce domaine].

Les Cortex M0 sont bien là pour concurrencer les 8 et 16 bits sur leur terrain, c’est leur but totalement avoué par la marque !







Sans prendre part à votre discussion (je n’ai très sincèrement pas assez d’expérience dans le domaine pour en parler), juste 2 petites informations :





  • De manière générale, le RISC reste très dominant dans l’embarqué (quelque soit l’architecture) et Intel n’en propose plus !

  • Néanmoins, dans le milieu du spatial (ou je travail), on voit des x86 Intel arriver peu à peu. (OK, on parle de remplacer des Motorola 88k, mais c’est un signe : on voit du CISC arriver dans un milieu ou le RISC était seul présent, et du x86 de plus !



    Voili-voilou









moxepius a écrit :



Merci, mais ça semble être des moteurs asynchrone, donc pas pratique pour des mouvement précis.





Il ne me semble pas non, tu as 3 bobinages fixes et la cage tournante avec des aimants, mais je m’aventure dans des domaines moins connus la.

Pour exemple tu peux chercher nacelle brushless, on peut s’en servir pour faire des mouvements precis dans cet usage, mais le controle est un peu different, il faut bcp de poles, et des fois toucher un peu au bobinage.









amFXR0 a écrit :



Sans prendre part à votre discussion (je n’ai très sincèrement pas assez d’expérience dans le domaine pour en parler), juste 2 petites informations :





  • De manière générale, le RISC reste très dominant dans l’embarqué (quelque soit l’architecture) et Intel n’en propose plus !

  • Néanmoins, dans le milieu du spatial (ou je travail), on voit des x86 Intel arriver peu à peu. (OK, on parle de remplacer des Motorola 88k, mais c’est un signe : on voit du CISC arriver dans un milieu ou le RISC était seul présent, et du x86 de plus !



    Voili-voilou







    Je ferais attention au terme RISC. Si on prend l’exemple de PowerPc, il n’y a que le coté taille de mot fixe qui reste RISC, mais pour le reste, les instructions peuvent être complexes.



    Dans le spatial, ils en ont fini avec l’ERC32 et le Leon ? (compatible sparc ?)



    Je suis étonné de voir arriver du x86, j’aurais plus penser à l’utilisation d’un ARM vendu en tant que source synthétisable (à l’époque c’était l’ARM9, les 2 extrêmes étant optimisé pour des processe de fabrication dédié). Le Leon était plus rapide que l’ARM9.