Et bien la version 2.0 de l'ensemble logiciel du projet vient de paraître. On notera comme nouveautés :
- U-Boot en version 1.1.6 ;
- La mise à jour de la version de Buildroot (30/10/2006) ;
- Le noyau Linux ARM en version 2.6.18.1 ;
- Le support de nouveaux écrans LCD 320x240 (TFT & STN) ;
- De nouveaux pilotes Linux : contrôleur SPI, PWM, chargement du FPGA, RTC DS1374, ADC MAX1027 ;
- La correction de plusieurs bugs suite aux retours des nouveaux adhérents.
Avec cette nouvelle version logicielle, le projet gagne en maturité et est enfin prêt à être facilement intégré dans des exemples concrets d'applications.
Les outils pour faire fonctionner les différents interfaces matérielles sont désormais tous là et les idées des membres aidant, d'intéressants prototypes devraient voir le jour dans les mois qui viennent.
Si vous êtes fans de logiciel embarqué, n'hésitez pas à visiter le Wiki de l'association et poser vos questions/apporter vos remarques !
Aller plus loin
- Wiki du projet (8 clics)
- Le projet SourceForge où télécharger la nouvelle version (4 clics)
- Annonce de la naissance du projet sur linuxfr (2 clics)
# Pour de la robotique
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Mais il y a plusieurs soucis. Déjà le manque de FPU, si on utilise un truc plus gros qu'un PIC ou qu'un ATMEGA, c'est pour faire du calcul et souvent des calculs géométriques super chiant à faire en entier. Ou en sont vos tests pour la puissance en fpu ?
Ensuite, on rève toujours de faire de la vision. Ici, il y a un port intégré pour capteur CCD mais je pense que le capteur en question doit être introuvable. Le fpga serait un super point pour faire un prétraitement mais encore faut-il avoir accés à la camera. Ou en est l'intégration de cette camera ?
Ensuite, mais c'est un problème général, il faut plusieurs sortie pwm pour controler moteur et autre servomoteurs, le fpga peut fournir cela. Au niveau des entrées, plein de CAN simplifie les problèmes potentiels pour lire des capteurs.
Une sortie I²C pour causer avec des pic pourrait être bien, quoi que le spi pourrait suffir.
"La première sécurité est la liberté"
[^] # Re: Pour de la robotique
Posté par salocin68 . Évalué à 1.
Nous n'avons pas encore eu besoin d'effectuer de calcul flottant donc les mesures n'ont pas été faites :(.
Le port CCD est compatible avec les capteurs standards du marché utilisés dans les téléphones portables. Ces composants sont dispos chez les distributeurs (ex: mouser). La encore, aucun essai n'a été effectué par manque de temps. Nous avancons par priorité et suivant les demandes. Si plusieurs personnes sont intéressées par un dev alors on le planifie.
Le FPGA est idéal pour faire du traitement d"image et pour la robotique. Dans le premier cas on peut profiter du calcul parallèle pour appliquer des filtres sur des matrices et dans le second cas, de nombreux PWM, SPI peuvent être implémentés. Il faut quand même, pour le moment, avoir des connaissances en programmation VHDL/Verilog.
Pour information, deux clubs de robotiques sont depuis peu, "membres" de l'association.
[^] # Re: Pour de la robotique
Posté par M . Évalué à 2.
IIRC il existe une FPU optionnel sur les arm9 : le VFP (Vector Floating Point)
Il y a aussi le arm926ejs qui supporte des extensions "dsp".
[^] # Re: Pour de la robotique
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pour de la robotique
Posté par salocin68 . Évalué à 1.
[^] # Re: Pour de la robotique
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
L'avantage des geodes est leur très faible consomation et le fait d'être des x86, donc n'importe quelle distrib tourne dessus. (et la puissance de calcul par rapport à un arm)
http://www.soekris.com/net5501.htm va en produire un, mais c'est destiné à en faire des appliances réseaux. En général, il manque des IO pour faire de la robotique. (CAN, pwm, compteur, control de servo moteur, I²c/SPI/RS-232)
J'imagine que c'est encore un autre projet en soit d'une autre dimension. A moins de faire une carte PCI "propre" à brancher dans le soekris.
"La première sécurité est la liberté"
[^] # Re: Pour de la robotique
Posté par Julien Boibessot (site web personnel) . Évalué à 2.
Une architecture x86 est loin d'être un avantage en embarqué (sous- entendu: sans alimentation secteur): taille, conso, connectivité -> c'est pas la joie.
Même si le Geode consomme moins qu'un proc x86 classique ça reste énorme comparé à un ARM9 (<1Watt).
[^] # Re: Pour de la robotique
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Une geode LX de 600Mhz est annoncé à 0.9W. (un geode LX est proche d'un athlon il me semble)
Donc, si on regarde le rapport mips/whats, ce genre de solution x86 est loin d'être mauvaise en comparaison. Si on a besoin de fpu, il n'y a pas photo. Un arm9 266 doit être comparable à un pentium 100 en entier. Et encore.
Donc, certe un geode bouffe un peu plus, il aura du mal dans un téléphone portable mais c'est globalement aussi très interrescant pour des équipements plus gros.
"La première sécurité est la liberté"
[^] # Re: Pour de la robotique
Posté par Julien Boibessot (site web personnel) . Évalué à 2.
ça reste 5 à 10 fois supérieur à un système à base d'ARM :-)
> Une geode LX de 600Mhz est annoncé à 0.9W.
0.9W minimum, 1,8W typique et ça juste pour le processeur. Quand je parle de moins de 1W c'est pour le système complet pas juste le proc en fait.
> Un arm9 266 doit être comparable à un pentium 100 en entier. Et encore.
un ARM9 type i.MXl est donné à 200Mips @ 180Mhz. C'est quoi les perfs d'un pentium ?
Bon c'est vrai que les chiffres ça veut pas dire grand chose sortis du contexte :-) Après tout dépend de comment ton système est architecturé...
[^] # Re: Pour de la robotique
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Le double de la fréquence. Un pentium est dual issue in order. Un arm9 est un simple issue.
C'est vrai que l'arm et le x86 ne sont pas trop comparable.
"La première sécurité est la liberté"
[^] # Re: Pour de la robotique
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Le double de la fréquence. Un pentium est dual issue in order. Un arm9 est un simple issue.
C'est vrai que l'arm et le x86 ne sont pas trop comparable.
Mais en robotique, avec des moteurs qui bouffent plusieurs dizaines de whatt, c'est pas l'informatique qui consomme 1W au lieu de 10 qui fait vraiment la différence.
"La première sécurité est la liberté"
[^] # Re: Pour de la robotique
Posté par Julien Boibessot (site web personnel) . Évalué à 1.
C'est sûr que si tu es dans la construction de Tanks ça ne joue pas mais si jamais tu es dans le plus fin, genre insectes explorateurs, ça peut aider... ;-)
[^] # Re: Pour de la robotique
Posté par salocin68 . Évalué à 1.
;) quand je disais "en standard " je parlais de la grande majorité des uC ARM9 dispo sur le marché.
Dans pas mal de produits on trouve des unités spécialisées MAC ou DFT. L'iMX en est un exemple.
# Temps réel
Posté par scls19fr (site web personnel) . Évalué à 1.
je voudrais savoir s'il est possible de faire un chronomètre fiable (précision inférieure à la milliseconde) avec une telle carte.
On arrive avec un PIC ou un AVR à de telles choses car il y a des timers dédiés mais là ?
J'avais commencé un projet de chrono embarqué pour les sports mécaniques (karting, moto, auto) commandé par une sonde à effet Hall... mais je n'ai malheureusement pas trop de temps
http://www.celles.net/wikini/wakka.php?wiki=OpenChrono
Cordialement
[^] # Re: Temps réel
Posté par Julien Boibessot (site web personnel) . Évalué à 2.
La carte pemet de faire tout ce qu'on fait avec un PIC ou un AVR, pas de soucis là-dessus ;-)
tu en étais resté où dans ton projet ?
on peut regarder pour te donner un coup de main sachant qu'on a déjà tout ce qu'il faut pour piloter un LCD graphique et une MMC. Reste l'inconnu de tes besoins "temps réel" car pour l'instant seul Linux tourne sur la carte (sans extension RT).
[^] # Re: Temps réel
Posté par scls19fr (site web personnel) . Évalué à 2.
De même que le compte-tour.
Ce qui me manque actuellement ce sont des lib haut-niveau pour gérer l'afficheur.
Un peu comme sur
http://www.segger.com/emwin.html
Pour les lib bas niveau de gestion de LCD on arrive à trouver mais les lib haut-niveau sur l'AVR c'est un peu le désert...
On peut en discuter en privé si tu veux
http://www.celles.net/contact
(désolé je n'ai pas trouvé ton mail)
@+
[^] # Re: Temps réel
Posté par scls19fr (site web personnel) . Évalué à 0.
De même que le compte-tour.
Ce qui me manque actuellement ce sont des lib haut-niveau pour gérer l'afficheur.
Un peu comme sur
http://www.segger.com/emwin.html
Pour les lib bas niveau de gestion de LCD on arrive à trouver mais les lib haut-niveau sur l'AVR c'est un peu le désert...
On peut en discuter en privé si tu veux
http://www.celles.net/contact
(désolé je n'ai pas trouvé ton mail)
@+
# Yann
Posté par Yannovitch . Évalué à 1.
Je viens de vous envoyé un mail sur le mail de votre association.
Je souhaitais juste savoir ce qui a motivé le choix pour ce uP plutôt qu'un autre ARM. Je pensais comme je l'ai déjà dit au AVR32, qui fait 210MIPS/150 Mhz contre 200MIPS/180Mhz pour cet ARM9, mais qui a l'avantage d'avoir déjà un DSP intégré ...
Merci :D
Yann
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.