Beaucoup parleront d’un simple clone du Raspberry Pi, mais il serait plus pertinent de le définir comme un cousin. Le BananaPi n’a pas la prétention de révolutionner le monde des SBC (Single Board Cumputer), mais d’y apporter les améliorations attendues : de la modularité, de la simplicité et de très bonnes performances.
Avec 1 Gio de mémoire vice, les soucis de rapidité de certaines cartes sont oubliés, son processeur ARM A20 offre une multitude de possibilités en termes d’applications et un excellent rapport entre puissance de calcul et performance énergétique. Il possède également une prise SATA pour brancher un disque dur qui nous permettra aussi de stocker plus de données que sur une simple carte SD. Nous pourrons aussi y installer le système d’exploitation, pour un démarrage et un accès aux données plus rapide.
Grâce à ses atouts, le BananaPi pourrait devenir un des mini‐ordinateurs les plus utilisés. Il a fait une entrée plutôt réussie dans le monde des SBC puisque, d’après un sondage de Linux.com, il se classe cinquième des mini-ordinateurs préférés des lecteurs du site, et ce seulement quelques mois après sa sortie.
Aller plus loin
- TOP10 des SBC (3208 clics)
- BananaPi.fr (5531 clics)
# Où est ce qu'on achète
Posté par pamputt . Évalué à 3.
Ça a l'air intéressant mais je n'ai pas réussi à trouver comment on fait pour acheter le BananaPi. S'il n'est pas encore en vente, est ce qu'on a une idée de son prix ?
[^] # Re: Où est ce qu'on achète
Posté par zyphos . Évalué à 1.
Il est déjà en vente sur un site chinois très connu (il faut compter 2 semaines pour la livraison)
€38,65/piece, livraison gratuite.
C'est le premier lien si on cherche "buy banana pi" sur G..gle (attention les versions moins chères ont 20€ de frais de port)
[^] # Re: Où est ce qu'on achète
Posté par Matthieu . Évalué à 1.
Je confirme.
J'en ai commandé 1 il y a plus d'un mois sur ce site (en vente uniquement sur ce site en fait). Reçu.
[^] # Re: Où est ce qu'on achète
Posté par Didrik Pining . Évalué à 10. Dernière modification le 04 juillet 2014 à 08:52.
Questions stupides:
-Pourquoi ne pas simplement site le nom ou l'adresse du site, au lieu de renvoyer à une recherche google avec des keywords ?
Tu fais la même chasse au trésor avec tes amis ? "Hey les gars, je sais où trouver du moltonel triple epaisseur vachement moins cher ! C'est au super marché avec un logo bleu et rouge, du côté de la forêt près de la clairière là où y'a une grosse pierre qui ressemble à une miche de pain."
-Pourquoi G..gle ? Tu as peur que écrire google ne fasse monter son pagerank ? Oh wait !
Non, sans rire, on dirait une mauvaise émission de TV des années 80…
[^] # Re: Où est ce qu'on achète
Posté par DerekSagan . Évalué à 0.
En fait de mauvaise émission TV des années 80, n'est-ce pas plutôt une façon amusante de répondre STFW de façon moins abrupte ?
Parce que demander où acheter un truc sans taper "buy le truc" dans google c'est surprenant en 2014, non ?
[^] # Re: Où est ce qu'on achète
Posté par gnx . Évalué à 6.
Quand on tape « buy le truc », le premier résultat est surprenant aussi : « Buy a Truck, Get a Free AK-47 ».
[^] # Re: Où est ce qu'on achète
Posté par BananaPi . Évalué à 4.
Salut !
Tu peux acheter un BananaPi directement chez le distributeur officiel français sur e.banana-pi.fr.
( le site est encore un peu en construction vu que le produit est très récent mais tu peux les contacter par mail ou téléphone qu'il y a sur le site)
[^] # Re: Où est ce qu'on achète
Posté par daeavelwyn . Évalué à 1.
heu…oui mais là il côute 53€ …..
[^] # Re: Où est ce qu'on achète
Posté par wolf359 . Évalué à 5.
ça fait 15€ de soutien pour une entreprise Française …. avec un interlocuteur joignable. Cette solution sera la mienne.
[^] # Re: Où est ce qu'on achète
Posté par gnx . Évalué à 2.
Déjà, sur Aliexpress, je ne le trouve pas (aujourd'hui) au prix indiqué plus haut mais minimum à 46 €. Ensuite vous comparez un prix HT et un prix TTC ! Vous êtes censé rajouter 20% de TVA à l'importation (OK, par la poste classique, ça passe en général à l'as mais sinon en plus des 20%, on se fait estamper avec des frais à la con, des minimums à percevoir, etc.). Et hop, ça fait 55€.
Du coup le revendeur français est au même prix et (pour une fois !) ne s'est pas trop sucré au passage, même sur les frais de port.
[^] # Re: Où est ce qu'on achète
Posté par Zenitram (site web personnel) . Évalué à 1.
Bizarre, je le trouve à 35-37€ chez moi.
soit avec la TVA 42-45€.
Sachant que le revendeur va prendre un tarif de gros (sinon, à quoi ça sert un revendeur? Autant prendre directement en Chine), ça va faire encore un peu de marge. Il reste 10€ (soit 20% de marge).
Après, faut se décider : on compare à un produit concurrent de Raspberry Pi ou Cubieboard? On s'y perd… L'auteur de la dépèche compare à un Raspberry Pi, donc on imagine pouvoir l'avoir autour de 30€ TTC… Sinon, ben euh…
[^] # Re: Où est ce qu'on achète
Posté par gnx . Évalué à 2.
À l'unité, fpdin ?
Ben c'est les tripes d'une Cubieboard, avec les connecteurs d'un Raspberry. Et pour les quantités produites, ça doit taper dans les mêmes catégories qu'une Cubieboard, le Raspberry étant probablement hors-concours. Donc le prix (enfin, plutôt le coût de revient) me semble devoir être dans les mêmes eaux qu'une Cubieboard, oui.
# Réseau
Posté par madhatter (site web personnel) . Évalué à 4.
Et contrairement au RPi, le Banana a une interface Gigabit Ethernet.
There is no spoon...
[^] # Re: Réseau
Posté par FRLinux (site web personnel) . Évalué à 10.
Pour connaitre les performances des processeurs ARM, je serais curieux si tu peux effectivement obtenir du gigabit soutenu sur cette carte.
[^] # Re: Réseau
Posté par aktawarrior . Évalué à 7.
La réponse est simplement non :)
J'ai une cubietruck avec une interface Gigabit et le même SoC… le max que j'ai pu atteindre est autour des 300Mbps en udp avec le vent dans le dos… Par contre avec un A31 ou un A80 ça devrait être bien mieux!
[^] # Re: Réseau
Posté par tao popus . Évalué à 4.
Est-ce que le test à été fait avec l'utilisation des DMA ? Dans quelle version du noyau, allwinner ou sunxi ? Parce-que :
* La version Allwinner des pilotes gère d'avantage de matos, mais n'est visiblement pas optimale
* La version de la communauté Linux-Sunxi qui veut du libre est toujours en cours de dev sur plusieurs points de base (le support de la nand est récent, pas encore de DMA sur la NAND, un patch existe, mais pas encore intégré, etc…
Pour le moment la version stable considéré comme la plus complète est stable à la fois est le noyau version sunxi-3.4.x. ça progresse à grand pas, la majorité des éléments fonctionnent, certains pilotes sont plus rapides qu'avec ce qu'avait fait ARM et AllWinner (G2D pour les opérations géométriques 2d comme le blit par exemple).
Voir la page sur les efforts pour intégrer dans le tronc commun Linux officiel :
http://linux-sunxi.org/Linux_mainlining_effort
Perso, je suis très content de ma Cubieboard2 (A20 aussi) dans l'état actuel, je ne cherche pas les perfs réseau, mais plus un serveur léger pour différentes taches. Le bureau LXDE et les applis fonctionnent aussi carrément bien dessus, même si ça n'était pas ce que je cherchais, 1Go de RAM est un peu juste, et même si il y a des limitations (pas d'OpenGL, uniquement de l'OpenGL ES, pas un FPU surpuissant, convient pour 99% des taches, mais pas top pour tout ce qui demande beaucoup de calcul flottant (traitement lourd d'images par exemple). après peut être que quand le DSP CedarX sera bien géré, on pourra lui déléguer pleins de taches de traitement d'images lourdes. Reste le pilote libre pour Mali (Mali driver) inexistant, après avoir été à 2 doigts de le mettre dans Mesa, l'auteur semble ne plus être intéressé, il l'a laissé en état depuis plus d'1 an, il disait il y a 1 an que le fork c'est mal™, mais il préfère éditer de la doc Sunxi, j'espère que quelqu'un pourra reprendre le flambeau. Son neveu avait commencé le pilote pour les Mali T6xx, qui devient plus utile que le Mali 4xx sur les nouveaux SoC ARM.
[^] # Re: Réseau
Posté par deasy . Évalué à 0. Dernière modification le 03 juillet 2014 à 21:18.
Moui il ne faut pas oublier que le support des soc allwinner est pas mal communautaire avec une entreprise ou deux aussi et que les perfs ne sont pas forcément ce qu'elles pourraient être.
à voir…
arf en fait je suis grillé et avec plus de technique oops j'avais pas fait attention
[^] # Re: Réseau
Posté par Sylvain Briole (site web personnel) . Évalué à 3.
Connectée directement sur le microcontrôleur via une interface Gigabit (typiquement: GMII ou RGMII) ou alors via de l'USB (comme sur le Raspberry Pi si je ne m'abuse)?
[^] # Re: Réseau
Posté par aktawarrior . Évalué à 2.
De mémoire, directement sur le Soc. Contrairement au Rpi il y a un vrai PHY/MAC.
Ce qui est sur c'est que ce n'est pas de l'USB :)
# Manque le plus important
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 03 juillet 2014 à 08:14.
Moi j'ai un SBC avec 16 Go de RAM, un processeurs quad-core et j'en passe, 2 ports 10 Gbps, 10 ports USB 3, BananaPi c'est nul.
Ben oui, quand on ne donne pas le prix ni de disponibilité, on peut proposer tout et n'importe quoi.
Bon, j'ai fait une recherche, ça a l'air un peu plus cher que le Raspberry Pi donc c'est pas mal pour les specs, mais je n'ai pas trouvé de revendeur en Europe et ça c'est bien moins sympa (le gros avantage du Raspberry est… Qu'on peut l'acheter en Europe sans prise de tête avec la douane)
Je me pose une question : pourquoi les "pubs" ne font pas, très souvent, état du prix (moyen) et de la disponibilité? C'est quand même une des choses les plus importantes pour un produit…
[^] # Re: Manque le plus important
Posté par BananaPi . Évalué à -10. Dernière modification le 03 juillet 2014 à 09:29.
Salut,
Il est vrai que ces informations manquent sur la dépêche mais si tu vas sur la page Facebook BananaPi France tu pourras trouver des liens pour les acheter en France et en Europe.
https://www.facebook.com/BananaPiFrance?ref=hl
[^] # Re: Manque le plus important
Posté par Zenitram (site web personnel) . Évalué à 6.
Niveau référencement dans Google, il y a du travail…
Dur de passer par Facebook pour pouvoir acheter du libre.
bon, du coup on a le prix : plus de 50€.
Plus de choses que le Raspberry Pi, mais plus cher aussi.
Donc plutôt à comparer à une CubieBoard.
Du coup, à la vue du prix (en France du moins), c'est moins révolutionnaire qu'il ne parait : "juste" une version haut en gamme du Raspberry Pi. C'est bien, à condition que le besoin en perf justifie la différence de prix.
Je reste donc à conseiller le Raspberry Pi pour les petits besoins (quand le CPU ne tourne pas, pour faire des petits trucs qui ne demandent pas de ressources, cible à la base du Raspberry Pi auquel tu compares).
[^] # Re: Manque le plus important
Posté par flagos . Évalué à 2.
Le prix vise par le projet est de 29,99 $. Sur Aliexpress, en mode Chine, on le trouve a ce prix, il faut ajouter des frais de port si j'ai bien compris. C'est quand même pas mal, quand tu compare a la R-Pi, c'est quasiment le meme prix avec un SoC plus puissant.
Les autres revendeurs doivent profiter du buzz pour faire une jolie bascule, si ca prend, ca devrait baisser.
La pour le coup, je pense qu'on tient un possible successeur a la R-Pi qui se fait vieillissante désormais.
[^] # Re: Manque le plus important
Posté par X345 . Évalué à 10.
Sérieusement ? Une page Facebook pour un produit orienté hack/DIY ?
Monde de merde.
[^] # Re: Manque le plus important
Posté par Stef . Évalué à 10.
Cool merci ça m'avance beaucoup un lien facebook.
Et il possible d'avoir un lien plus sérieux svp?
[^] # Re: Manque le plus important
Posté par Maxime (site web personnel) . Évalué à 4. Dernière modification le 03 juillet 2014 à 19:45.
BananaPi : 53€
http://e.banana-pi.fr/index.php?id_product=11&controller=product
[^] # Re: Manque le plus important
Posté par Sylvain Briole (site web personnel) . Évalué à 3. Dernière modification le 03 juillet 2014 à 14:28.
pas trouvé de revendeur en Europe
Si l'allemand ne te rebute pas, on peut le trouver chez reichelt.de:
http://www.reichelt.de/Programmer-Entwicklungstools/ALLNET-BANANA-PI/3//index.html?ACTION=3&GROUPID=5514&ARTICLE=144326&SHOW=1&OFFSET=16&
[^] # Re: Manque le plus important
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 03 juillet 2014 à 14:37.
Ca ça devrait aller :).
euh… 70€???
J'espère que c'est une version plaquée or et numérotée…
Ce n'est pas à la Raspberry Pi qu'il faut alors comparer, mais clairement une cubieboard.
Si les sponsors de la carte pouvait dire en quoi c'est mieux que la cubieboard… Parce que comparer à une machine 2x moins cher, c'est facile, mais c'est comparer face à une machine de même gamme de prix qui est interessant.
Bref, dans toutes ces cartes, ce qu'il manque est un gros comparatif de fonctionnalités/taille/conso/prix/dispo dans un tableau pour trouver celles qui sortent vraiment du lot.
[^] # Re: Manque le plus important
Posté par tao popus . Évalué à 2.
Heu, c'est plutôt dans les 40~50€ la cubieboard2, enfin, sur des sites comme Aliexpress… certesça met 2 ou 3 semaines à arriver, mais bon, je vois pas l’intérêt de laisser des marges aussi colossales à un revendeur qui va commander au même endroit et envoyer au même endroit ??? à 70€, c'est plutôt un cubietruck avec 2 Gio de RAM, 3 fois plus de connecteur, un emplacement pour pile etc… je ne serais pas étonné que la cubieboard 8 à base d'A80 (octocore) tourne dans ces prix là également (pas de SATA, moins de connecteurs que la Cubietruck. Dans cette gamme de prix, Il y a aussi les boîtiers basés sur le Rockchip 3288 (quadcore A17, plusieurs distro aussi, communauté linux-rockchip active aussi) qui semblent prometteurs.
[^] # Re: Manque le plus important
Posté par windu.2b . Évalué à 10.
Ou si tu te fais chier, apprends l'allemand. C'est bien connu que l'allemand, ça occupe…
[^] # Re: Manque le plus important
Posté par BananaPi . Évalué à 4.
Le site pour acheter des BananaPi chez le distributeur francais est maintenant disponible et fonctionne totalement.
http://e.banana-pi.fr/index.php
[^] # Re: Manque le plus important
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Et le site pour trouver une fiche technique détaillée, il arrive bientôt ?
# CubieBoard
Posté par Mimoza . Évalué à 9.
Il existe depuis un moment d'autre board qui lui ressemble fortement aux niveaux des specs/perf.
Par exemple la Cubieboard est relativement répendu et bien supporté. http://cubieboard.org
Elle est en place et dipo (à l'international et revendeur européen) depuis un petit moment et pas mal de chose se font avec la communauté. Et le prix est tout a fait raisonable (~60€)
Donc finalement cette nouvelle SBC n'apporte rien de neuf
[^] # Re: CubieBoard
Posté par BananaPi . Évalué à 0.
Je ne dit pas le contraire, CubieBoard est un très bon produit et comme le dit l'article le BananaPi n'a rien de révolutionnaire mais viens juste se faire une place dans la communauté pour faire ses preuves.
Mais vous pouvez toujours tester le produit pour vous faire une opinion du BananaPi car la plupart des gens ne se font des idées que par la lecture d'articles trouvés dans presse basés sur des specs. Très peu de personnes ont réellement testées le BananaPi.
[^] # Re: CubieBoard
Posté par Mimoza . Évalué à 1.
Après il semble qu'elle ai une possibilité intéressante de mon point de vue, l'installation du système entier sur un DD, avec la Cubie il ne semble pas (encore) possible de se passer du /boot sur la Nand ou µSD
# Pilotes libres ?
Posté par khivapia . Évalué à 8.
Est-ce qu'on peut le faire fonctionner avec des pilotes libres ? (notamment pour la partie graphique, le cas échéant. )
C'était il me semble un point faible du Raspberry Pi.
[^] # Re: Pilotes libres ?
Posté par Maz (site web personnel) . Évalué à 10.
C'est un SoC Allwinner A20 avec GPU Mali400.
J'ai refait le tour vite fait, et mon commentaire sur le OLinuXino d'il y 1 an semble toujours d'actualité.
Soit un pilote pour le Mali400 qui semblait prometteur mais est au point mort, en tout cas publiquement. Dernier message sur la mailing list de Mars, et dépot gitorious avec 2 commits en 1 an qui ne sont même pas sur le code du pilote.
Pour le VPU CedarX, il y a eu un début de pilote libre, mais il n'a pas l'air d'évoluer très rapidement.
Bref, si comme moi, vous cherchez à faire un HTPC pas cher et libre, passez votre chemin.
[^] # Re: Pilotes libres ?
Posté par Sylvain Briole (site web personnel) . Évalué à 3.
Bref, si comme moi, vous cherchez à faire un HTPC pas cher et libre, passez votre chemin.
Que recommenderais(utilises?)-tu?
[^] # Re: Pilotes libres ?
Posté par claudex . Évalué à 8.
Si tu veux du libre, il faut miser sur un processeur Intel ou AMD si tu veux monter le truc toi-même ou un NUC. Dans tous les cas, ce sera plus cher (mais plus performant).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pilotes libres ?
Posté par tipic . Évalué à 1.
Le Nuc, beaucoup plus performant à taille égale
[^] # Re: Pilotes libres ?
Posté par Plume . Évalué à 1.
Si j'ai bien compris, le but est d'abord de comprendre le comment du pourquoi de tout ce bordel. Avec les specs non-publiques, il semblerait qu'il soit impossible d'écrire le driver comme ça. Du coup, le projet ne semble pas avancer rapidement tout simplement parce qu'il n'y a rien à partager pour le moment.
[^] # Re: Pilotes libres ?
Posté par tao popus . Évalué à 2.
Autant pour le pilote Mali, il y a sérieusement besoin d'un fork (ou d'une remotivation de l'auteur ?), concrètement aucun changement depuis plus d'un an (début juin 2013), autant pour la pilote CedarX il y a un véritable travail de fond et par plusieurs contributeurs (voir la page CedarX/Reverse Engineering de linux-sunxi). Pas mal de gens l'utilisent en HTPC avec pilotes proprio, et le pilote libre évolue réellement. Ça ne se fait pas non plus avec un simple claquement de doigt.
[^] # Re: Pilotes libres ?
Posté par claudex . Évalué à 4.
Si je ne me trompe pas, ce qui a « tué » le développer de Lima, c'est ARM qui a dit qu'ils n'en ont rien à foutre d'un pilote libre, que s'ils en voulaient un, ils pouvaient libérer le leur et qu'ils n'aideraient pas du tout le développement du pilote libre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pilotes libres ?
Posté par tao popus . Évalué à 1.
Je ne pense pas, ou bien alors il aime tellement les défis que ça l'a démotivé (ou alors c'est une excuse procrastinatoire). Auparavant, ARM était plutôt opposé à toute version libre de leur pilote, craignant, comme beaucoup de concepteurs de circuits, que cela donne trop d'informations sur le fonctionnement interne de leur architecture, donc ce changement de vision est au contraire un progrès.
En tous cas les progrès fait par d'autre ssvb, etc.. autour de l'affichage, on montré qu'il était possible d'améliorer beaucoup de choses par rapport aux pilotes libres officiels ARM (la couche X11) et des concepteurs de chips également (les couches bas niveau). Les ressources sont mieux généralement mieux gérées avec la version libre communataire qu'avec les versions libres d'entreprise (ou parfois fermés et d'entreprise, selon le niveau d'avancement du projet libre).
[^] # Re: Pilotes libres ?
Posté par gnx . Évalué à 4.
Je crois qu'il y a méprise. Ce qu'ils ont dit c'est plutôt « Non, on ne vous aidera pas. Si on voulait un pilote libre, on aurait libéré le nôtre, mais on n'en veut pas. ». Donc pas de changement de vision mais au contraire toujours campés sur cette position crétine.
[^] # Re: Pilotes libres ?
Posté par GCN (site web personnel) . Évalué à 1.
C'était au FOSDEM en février 2014: https://archive.fosdem.org/2014/schedule/event/lima_driver/
Pas trouvé d'activité plus récente…
[^] # Re: Pilotes libres ?
Posté par floreal . Évalué à 1.
Oui, j'aimerai bien savoir si cette bestiole sait marcher avec etna_viv.
# embarqué ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pour l'embarqué, il faudrait une carte avec plein d'IOs comme des convertisseurs analogique numérique (pour la lecture de capteur), des compteurs (pour les roues codeuses), et des sorties PWM (pour le contrôle de moteur).
Le tout devrait être géré sous Linux avec des bonnes latences (<10ms pour lire tous les capteurs, puis pour modifier tous les PWM en sortie). Ce problème de latence est le plus difficile à atteindre, mettre des paquets de puces I2C, des µcontrollers par USB, ne permet pas d'atteindre ses latences surtout avec plusieurs dizaines d'IO. C'est pourtant nécessaire pour la moindre rétroaction mécanique.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par gyscos . Évalué à 3. Dernière modification le 03 juillet 2014 à 10:07.
A ce niveau, c'est un microcontrolleur et non plus un ordinateur qu'il te faut…
Un OS complet comme Linux n'est pas idéal quand tu veux vraiment de la faible latence.
Et pour le petit coup de pub, la carte Tiva C de TI (anciennement Stellaris Launchpad) est une très bonne carte comme ça pour une dizaine d'euros, relativement performante et programmable en C++ :)
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 03 juillet 2014 à 10:15.
Non, je parle bien de linux. Un linux RT tient très bien les 10ms. Cela permet d'avoir des drivers comme ceux d'une camera ou du wifi.
En plus, les microcontrôleurs sont en général très limité en RAM.
Il est possible d'avoir une architecture avec un Linux esclave d'un µcontroller, mais cela augmente la complexité avec 2 systèmes, cela rend difficile le debug, et il faut 1 liens assez rapide entre les 2.
Les cartes à base de STM32, peuvent faire le job, si on peut se passer de linux. Mais elles n'ont pas forcément un très grand nombre d'IO.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Julien Boibessot (site web personnel) . Évalué à 2.
La solution idéale dans ce cas est une carte à base d'ARM+FPGA, genre (au hasard ;-)), les modules APF d'Armadeus: http://www.armadeus.com/francais/produits-cartes_microprocesseur-apf27.html
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
mouais. Il n'y a pas tellement d'IO, pas de ADC. Et j'imagine que tu dois tout faire tout même (VHDL + drivers), ce qui n'est pas si simple. La connection ARM-FPGA est parfois pas top (pseudo lien série lent).
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par gnx . Évalué à 2.
Sérieux, ça serait bien de consacrer 3 minutes à s'informer avant de poster ; 3 minutes, avec le lien donné dans le message auquel tu réponds, ça suffit pour trouver :
Bon, je pense qu'il n'y a pas de CAN, car les CAN, généralement, ça se trouve sur des µC, pas des SoC.
Par contre, attention, ça reste un module (auquel tu peux ajouter une carte de dév), pas quelque chose d'immédiatement prêt à l'emploi comme un SBC ou beaucoup de cartes µC. Et c'est pas mal plus cher aussi.
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
J'avais déjà regardé à l'époque et rien n'a changé. Dans ma description, je décris un moyen simple et pas chère de faire de la robotique issue de 10 ans de coupe e=m6 (ou presque) et une formation en ingénieur microélectronique. Et la carte que tu pointes ne répond pas du tout, à ce dont je parles.
Pas de CAN/ADC veut simplement dire pas d'entrée ! C'est ballot pour un robot ! Oui, tu peux rajouter une paquet de merde utilisant des I2C ou des UART, mais jamais tu pourras mettre des dizaines d'entrée lisible en quelques millisecondes sans pomper tout le cpu disponible.
Donc, toutes "IOS" dédié I2C, USB, UART, je m'en fiche complètement. Cela ne répond pas du tout à ce dont je parle au dessus. Tu devrais aussi mieux lire les demandes.
Pour les entrées, tu as bien une centaine d'IO du FPGA en 3.3V, ok. Il ne reste plus qu'à coder la centaine de PWM qui va avec, ce n'est pas le plus simple à faire !
Le bus interne 16 bit pour parler au FPGA semble assez rapide.
Tu remarques enfin ce que je cherche vraiment ?
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par gnx . Évalué à 2.
T'es gentil… Si j'ai répondu à ce message dans lequel tu racontes des âneries, c'est pour corriger ces âneries. Si j'avais voulu répondre à ta « demande », je l'aurais fait en répondant à un message dans lequel tu l'aurais exprimée.
Non, pas 100, moins. Comme je l'ai écrit. Comme c'est écrit sur le site du module que tu « avais déjà regardé à l'époque et rien n'a changé ».
Quand tu en a codé 1 (ou recopié le code dispo ailleurs), que tu en instancies 2 ou 100, c'est le même travail.
Tu cherches quelque chose qui (pour ce que j'en connais) n'existe pas ou presque :
Les SoC sont conçus pour les tablettes, ils n'ont donc pas besoin d'entrées analogiques.
Les µC sont conçus pour faire le boulot qu'on leur demande, pas vraiment pour faire tourner des scripts Python sur un Linux.
À partir de là, la solution est d'associer les 2, mais tu n'aimes pas.
Il reste à explorer les composants où sont associés un cœur de SoC et un cœur de µC, comme les Vybrid VF6xx de Freescale que l'on trouve par exemple sur la carte Cosmic + de Phytec. Mais je ne sais pas quelle mesure leur complexité est moindre que d'avoir le SoC et le µC séparés sur une carte.
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il y a tout le décodage à faire proprement et être sur que cela rentre. 100 compteurs 16 bits, cela n'est pas petit.
Il y a beaucoup de raisons à cela : lenteur des communications entre les 2. Mon but est de lire tous les capteurs puis tout écrire pendant un cycle. Un cycle dure entre 1 à 10 ms maximum (retroaction). Et pendant ce temps là le cpu doit être libre, ou presque pour faire des calculs (il existe des ADC sous I2C qui demande beaucoup de temps cpu pour du pulling).
Ensuite, si tu as un lien rapide entre les 2, cela sacrifie beaucoup d'IO, donc cela veut dire des gros package couteux. Lier un µP et µcontroller demande aussi de coder le µcontroller sans quasiement d'aide au debug, c'est bien plus long et complexe que sous un Linux, par exemple.
Après si le boulot difficile est fait par le producteur de la carte pourquoi pas. Mais il faudra montrer que le driver Linux qui permet d’accéder au ADC ou au PWM d'un µcontrolleur à bien 1 ms de latence max, ou plus exactement que toutes les IO peuvent être lu/écrite en moins de 10 ms, sans prendre plus de 10% de cpu.
Les cortexM tourne à 70-100Mhz, j'ai commencé la robotique sous linux avec des Pentium 75. Il faudrait juste utiliser une plateforme de µC et y mettre un Cortex A7 ou lieu d'un M.
Il y a 2 ADC sur 4 lignes, c'est très peu. Je n'ai pas vu de PWM. Mais l'idée est là.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par gnx . Évalué à 1.
As-tu besoin d'une précision de 1/65536=0,0015% de période sur tes sorties ? et ce sur toutes tes sorties ?
De toutes façons, même si l'on compte pour être tranquille le double de ce qui doit être nécessaire, disons 32 bascules par compteur, ça rentre dans le plus petit des Spartan 6 qui en compte 4800, ou dans un Spartan 3A 200 qui en compte un peu moins.
De plus, utiliser n compteurs 16 bits pour n sorties, c'est la méthode bourrine calquée sur le fonctionnement des timers de µC. Pour obtenir la même précision, on peut par exemple utiliser 1 compteur principal (genre 8 ou 10 bits) et n compteurs plus petits (les bits qui manquent : 8 ou 6) ou n registres à décalages s'il manque peu de bits, en consommant de la RAM à côté (il y a plus de 200kb de RAM en blocs sur le plus petit des Spartan 6).
Cycle de 10ms dont 1ms consacrée aux E/S, donc ?
Si on prend une liaison SPI à 40 MHz et qu'on suppose arbitrairement qu'une lecture/écriture de message comporte 8 octets et qu'on doit attendre l'équivalent de 4 octets entre 2 messages ; ça nous fait un message toutes les (12x8=64)/40.106=2,4µs. On peut utiliser plusieurs bus SPI (un avec le SoC maître et l'autre avec le µC maître, par exemple).
Si on prend un bus // arthritique entre SoC et µC : 8 bits de données, quelques bits d'adresse, 10 MHz ; disons qu'un mot 32 bits est transféré en moyenne en 6 coups d'horloge; ça nous fait un message tous les 6/10.106=0,6µs.
Dans les 2 cas ça doit être suffisant pour lire 100 entrées et mettre à jour 100 sorties en utilisant un maximum de 0,5ms.
Si c'est un cycle de 1ms dont 100µs consacrée aux E/S, c'est plus tendu, mais s'il y a moins d'E/S que 100 et 100, ça peut rentrer.
S'il faut tout tout fait, ça réduit encore les possibilités de solution :-)
Tu as listé combien d'entrées et de sorties il te faut, avec leur type, leur précision et leur vitesse/latence ? Ça sera plus pratique pour essayer de déterminer une solution que beaucoup/plein de/le plus possible :-) Pour la vitesse, on a ce total de 1 ms max, mais ça ne concerne peut-être pas toutes les E/S, il y en a probablement qui ne demanderaient pas à être actualisées à chaque cycle.
Ben j'ai l'impression (juste avec ce que tu as dit) que tu t'embarrasses d'un OS de type mammouth alors que ce que tu fais tourner dessus a le fonctionnement d'un automate et se contenterait d'un mini-micro-nano OS ou de pas d'OS du tout. Alors du coup t'as besoin d'une fréquence 10 fois supérieure.
Je ne sais pas s'il y a d'autres raisons pour ce choix que le fait du confort et de l'habitude de développer sur une plateforme riche et familière. Ces raisons sont parfaitement compréhensibles mais dans le cas présent, il est possible qu'elles conduisent à une impasse (en l'état des composants et des cartes toutes faites sur le marché).
Ah oui, merde, là c'est moi qui n'avait pas vérifié, m'étant dit que puisqu'il avaient mis un cœur de µC, ils avaient assurément mis aussi des interfaces de type µC. Bah non :-/
À voir chez d'autres fabricants.
[^] # Re: embarqué ?
Posté par gnx . Évalué à 0.
Sinon, dans un genre différent, quelque chose à base de Zynq ? Double cœur Cortex-A9 + une grosse partie FPGA + ce que j'avais oublié, c'est-à-dire une petite partie analogique. 2 ADC sur 17 lignes. Est-ce que ça suffirait ?
Si oui, il faut voir ensuite quelles cartes sortent les signaux en question.
- la Zybo de Digilent, c'est mort (ils servent à la sortie VGA) ;
- MicroZed ou Zedboard ça devrait aller (reste à vérifier combien des 17 entrées analogiques sont disponibles sur des connecteurs et s'il reste suffisament d'E/S numériques disponibles pour le reste).
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Non, c'est dans l'ordre de grandeur de ce qui existe déjà. Le problème est d'être sûr de pouvoir faire 17 mesure toutes les ms. C'est parfois très lent de changer de ligne, par exemple.
Par exemple, pour un seul moteur, il faut mesurer le courant, il faudrait mesurer la tension en entré, mesurer la position du moteur (pour un servomoteur) ou sa vitesse de rotation (pour un truc qui roule), et mesurer la position de l’élément mécanique (roue libre pour un déplacement, position d'un bras) pour mesurer les contraintes mécaniques (glissement, jeu,…). Ensuite, il faut 3 PWM pour un moteur synchrones.
C'est seulement pour un moteur. On peut ensuite ajouter des choses comme des télémètres, des capteurs de couleurs, une central inertiels, …. Il existe des blocs tout fait, mais cela serait bien plus compact et moins couteux d'interfacer la partie analogique directement avec le SoC.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Disons qu'en retro action mécanique, 10 ms est une réactivité basse, 4 ms est assez rapide, et 1 ms gère tous les cas.
Si, tous, c'est bien trop compliqué sinon. Imagine une machine synchrone qui commande un robot humanoïde.
De mémoire, NAO a 25 moteurs. Il est pseudo statique, mais si tu avais besoin de faire l'équilibre du robot, il faudrait une rétro action complète de sa position. Tu as donc besoin de connaitre la position réels des articulations (genre un potentiometre avec un ADC derrière), plus une mesure du courant du moteur pour avoir une idée de la force déployée, une mesure de la vitesse de rotation du moteur ou de sa position (le but est de tenir compte du jeu de l'articulation), puis 3 PWM si tu as un moteur synchrone.
Donc ton programme pour gérer ce genre de chose, tourne entre 100 et 1000Hz, prend en entré tous les capteurs, et calcule ensuite toutes les sorties. Tu peux faire un peu de masquage de latence, avec la lecture au temps n, le calcul des données n-1, et l'écriture des données n-2. Mais dans ce cas, le cpu doit être libre.
Il y a des solutions ou un gros µP est maitre, et un PC est esclave. Mais cela reste une architecture un poil compliqué. Un truc sous Linux permet d'avoir le réseau (wifi ou filaire) qui permet de bien connaitre l'état interne du robot. Avec un simple µP, il faut + moins tout écrire : gestion de l'extraction des données vers un hote, affichage, etc… C'est quasi impossible d'avoir des logs à cause de la mémoire trop faible.
Un µP ne permet pas non plus de faire de la cartographie à cause de la taille de la RAM, ou du traitement d'images même léger. On peut aussi imaginer l'usage du Bluetooth.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par gnx . Évalué à 2.
Tu es conscient que tu cherches la quadrature du cercle ?
Déjà, tu n'arrives pas à chiffrer combien d'E/S il te faut, on revient encore à « beaucoup », « plus », etc. Personne ne peut te trouver de solution ainsi.
Si on prend tes 25 moteurs, avec 3 capteurs analogiques et 3 sorties numériques chacun, ça fait déjà 75 entrées analogiques et 75
sorties numériques. + d'autres capteurs + d'autres sorties, donc au moins 100 entrées analogiques et 100 sorties numériques. Et tu voudrais que tout ça rentre directement dans un seul composant (200 pattes rien que pour ça, sans compter masses ou entrées différencielles) alors que tu voudrais un boîtier sans trop de pattes ? Et tu veux aussi que le composant soit fourni en RAM (donc large bus d'adresse), et très véloce (donc bus de données 32 ou 64 bits), alors que tu voudrais un boîtier sans trop de pattes ?
En plus tu ne veux pas optimiser en hiérarchisant les entrées/sorties ni en les multiplexant, du coup toutes au max de précision et il faut toutes les caser dans un bref laps de temps. => bouffage de ressources et restriction du choix.
Même en mettant de côté le coup du nombre de pattes, de tels composants n'existent pas. Les SoC n'ont pas d'E/S du type que tu veux, même en nombre insuffisant, ils ne sont pas fait pour ça. Les µC ne peuvent pas soutenir tout le bazar que tu veux faire tourner et de toutes manières, bien qu'ils soient fait pour ce type d'E/S, je n'en connais pas avec autant d'E/S (une trentaine de CAN n'est pas fréquent, alors 100…). Les FPGA, parfaits pour toutes tes E/S numériques par leur grand nombre d'E/S, comportent très rarement des parties analogiques ; on peut cependant faire des CAN avec du Sigma-Delta, mais ça doit bouffer des ressources.
Donc il te faudrait un composant spécialisé pour tes spécifications, autant dire un marché de niche et c'est là que ça va être « coûteux ». Autant dire que pour le beurre et l'argent du beurre, ce n'est pas possible, il faut supprimer une ou plusieurs exigences.
Donc pour réconcilier la plupart des fonctionnalités que tu demandes, il te faut tout ça : 1 SoC + 1 FPGA + n µC/CAN.
Enfin, tu parles de « compact ». Je ne suis pas sûr que relier 200 ou 400 fils à une unique carte centrale soit pratique, que ce soit à l'arrivée sur la carte ou pour les passer dans les structures, surtout des structures articulées/mobiles. Sans même parler de la tronche des signaux analogiques dans ce merdier. Au contraire il me semble qu'il faut réduire le nombre de fils an multiplexant les infos sur de simples lignes numériques.
Donc on revient aux solutions que tu n'aimes pas, du genre :
- une carte principale avec SoC + FPGA, et n CAN déportés reliés par SPI1.
- une carte principale avec SoC, et n µC déportés reliés par SPI1.
- une carte principale avec SoC + l'aide d'un µC ou FPGA pour libérer le SoC de toute la gestion des E/S, et n µC déportés reliés par SPI1.
Sinon, la seule possibilité « simple » que je vois, en gardant la touffe de fils, c'est le combo [Soc+FPGA] ou [Zynq], en faisant du Sigma-Delta. Mais toujours le même problème : ça demande énormément d'E/S disponibles. 100 sorties + 3 x 100 entrées = 400 pattes dédiées ! Et ça, ça n'existe pas en Zynq à prix raisonnable. Donc [SoC+FPGA maousse2] ou [SoC+2xFPGA moyens] ou [SoC+3/4xFPGA petits] ou [Zynq+FPGA moyen] ou [Zynq+2/3 FPGA petits].
pour conserver une bonne vitesse, passer en différentiel si la distance est peu longue. ↩
par exemple, un EP4CE30F29C7N, pas spécialement cher, mais en boîtier BGA à 780 billes. Gloups. De toutes façons, BGA obligatoire (plus de QFP) au delà de 160 E/S (100 E/S seulement pour les dernières générations). ↩
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Oui et non, c'est surtout que les fabricants de puce n'ont pas vu d’intérêt pour la robotique.
Je suis conscient que les procédés de SoC ne sont pas adapté au ADC, et que les procédés de µP ai du mal avec le wifi. Mais bon, 160 Mhz, cela irait. Et un BGA tient les 500 broches, si le PCB est petit cela ne devrait pas être trop couteux.
Je veux surtout un truc pas trop chère et si tu as 2 puces, tu as 30 pattes pour communiquer entre les 2.
Tu es un vrai hardeux qui croit que le soft est magique :) Si tu gère l'équilibre d'un robot humanoïde tout bouge en même temps et tous les moteurs sont ajustés.
C'est pas faux. En même temps, 8 ou 10 bits c'est suffisant, et 1 000hz, c'est que dalle. Un adc de base à 10 bits doit pouvoir tourner à plusieurs MHz, à multiplexer sur plein de lignes. Ensuite, souvent le signal est sur la tension, un pull-up pour avoir un peu d'intensité, permet de masquer le bruit.
Si tu as un robot de 50 cm, tu ne gagnes rien. Et tu as une pelleté de mini carte en plus, et de connecteurs (c'est chère les connecteurs).
Le SPI est un peu pourris, cela bouffe beaucoup de cpu. J'ai vu des CAN spi qui avait des attentes actives, c'était rédhibitoire, surtout pour une dizaine. Tu as donc besoin de truc spi qui fonctionne avec DMA, c'est pas évident. Il faudrait un CAN à ~4 entrées qui envoient en flux ses données, pour y gagner, et les pwm dans l'autre sens.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par gnx . Évalué à 1.
Euh, ouais, mais ce qui coûte, ça risque de ne pas trop être le PCB1 et ses couches, mais d'une part (dans le cas de quelques protos) de faire souder la cochonnerie de BGA, et d'autre part dans tous les cas ce qu'il y a dans le composant et à combien d'exemplaire il est produit. Quand j'évoquais un gros Zynq à prix déraisonnable, c'est un composant qui va taper dans les 3000 à 5000€, pareil pour les FPGA les plus puissants ; quand aux processeurs/contrôleurs, s'ils sont vraiment spécialisés dans une petite niche, ils peuvent coûter plusieurs centaines d'€. Donc bon, si on devait être dans ce genre de cas, le prix des connecteurs serait accessoire :-)
J'entends bien qu'il faut « ajouter » des pattes mais ce n'est pas très grave dans la mesure où ce n'est pas trop difficile à router tant que c'est juste entre 2 composants. À partir de 3 ça serait plus pénible. Cependant, j'ai mis « ajouter » entre guillemets parce que les interfaces et les pattes sont de toutes manières généralement présentes sur les SoC, donc à moins de vouloir et pouvoir affecter les pattes correspondantes à une autre fonction, ça ne va rien changer (du moins, côté SoC).
Ça me soucie un peu ça. OK, les signaux analogiques à mesurer sont quasi-statiques, donc on devrait pouvoir les filtrer à mort. Sauf qu'il y a cette histoire de réactivité qui m'ennuie à double titre. D'abord parce que du coup on n'a plus le droit de retarder des masses le signal, ni d'affecter sa valeur, ce qui limite la possibilité de filtrage. Ensuite parce que si on veut capter le peu de mouvement possible en 1/1000e de seconde2, il faut pouvoir mesurer des variations très faibles avec une très bonne précision, parce que sinon ça ne sert à rien de capter& réagir toutes les millisecondes ; et donc ça veut dire un signal très propre, sans bruit, et des ADC dont les derniers bits sont fiables.
Et avec tout ça, on se trouver avec un filtre qui risque de ne pas filtrer la fréquence des PWM qui sont juste à côté, alors qu'on ne peut pas tolérer de bruit.
Dans la mesure où le composant magique à 500 pattes n'existe pas, pour la carte de base il faut de toutes manières ajouter plusieurs µC ou CAN et même si l'on opte pour la solution FPGA, il faut quand même un étage pour l'adaptation des entrées analogique à la gamme demandée par les CAN et pour le filtrage.
Implanter ces composants sur la carte de base est plus coûteux que de les implanter sur plusieurs petites cartes séparées identiques. La surface prise sur la carte du SoC est du 6/8 couches, alors que la carte séparée est en 2/4 couches et on en fabrique plus d'exemplaires.
Avoir des modules est généralement une bonne idée. Déjà pour le développement, ça permet de tester séparément les fonctions, de ne pas les faire en même temps, etc. Ensuite, ça peut éviter, en cas de problème, de griller l'ensemble. Enfin, avoir de modules permet de s'adapter à différents projets, soit en changeant le nombre de modules connectés, soit en remplaçant les modules par d'autres ayant des fonctions variant en nombre ou en nature. Ça évite de devoir reconcevoir et refaire une carte à 800€…
De plus, tant qu'à avoir des modules, autant les déporter, ça arrangera bien les éventuels problèmes de qualité des signaux analogiques.
Tu peux préciser un exemple de composant problématique ?
même si, pour sortir 200 à 400 fils, les connecteurs vont consommer pas mal de place ! ↩
j'ai du mal avec cette histoire de devoir mesurer des déplacements et réagir aussi rapidement dans le même cycle, alors que si on prend une voiture allant à 100 km/h en photo au 1/1000, on la voit arrêtée, sans pouvoir discerner de mouvement. Alors, pour des mouvements encore moins rapides… ↩
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
L'avantage d'aller plus vite que la mécanique est aussi de pouvoir faire du filtrage numérique. C'est bien plus simple à modifier.
Oh non. C'est une très très mauvaise idée. Je suis d'accord pour la facilité de développement. Mais au niveau de la fiabilité, cela n'est plus la même chose. Moins il y a de connections mieux on se porte.
J'ai vu des archis de robot avec plein de µP chacun sur sa carte, c'est bien plus simple d'avoir une seul carte et tout dessus. Il y a bien moins de fils et bien moins de problèmes.
C'est vrai que cela a du sens pour chaque moteur ou groupe de moteur, couplé à la partie puissance, mais il faut des cartes numériques stupides, pas d'asservissement par exemple.
J'en ai pris un au hasard http://www.ti.com/lit/ds/symlink/tlc1518.pdf . J'ai vu qu'il y a un mode "repeat" qui peut être intéressant pour 8 voies, mais j'ai l'impression que l'envoie est contrôlé par 3 bits externe (INT, CSTART, FS). C'est autant de bit pris sur le SoC. Et j'ai peur que pour gérer l'entrée, il faut commander ses bits, ce qui prend tout le cpu, pendant ce temps là.
D'ailleurs, je n'ai jamais compris que personne n'est fait encore de bus d'extention série de µP avec adressage. Électriquement, cela peut être du SPI (2 ou 3 fils), mais ensuite, qu'il n'y ai rien besoin d'autre. Cela serait une sorte de mini PCI-express. L'I2C fait un peu ça, mais c'est lent, et l'espace d'adressage est petit, rarement inclus dans l'espace d'adressage du µP, et il faudrait du DMA.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par gnx . Évalué à 2.
Là aussi, c'est encore une solution de facilité (on acquiert les entrées aussi vite qu'on peut même si elles sont dégueulasses comme des bourrins et ensuite on verra bien comment on les filtre à l'intérieur) et on bouffe des ressources et ça explique qu'on ait besoin d'un gros CPU, de RAM, et de rentrer plus de données.
Et du coup, le temps de réactivité annoncé est à moitié bidon, puisque on ne réagit qu'après avoir pris en compte les 10/20/30 derniers échantillons (et donc 10/20/30 cycles) et viré/lissé/filtré les mauvais. Il est flottant, en fait.
« Bien moins de fils » avec un fil pour chaque entrée venant de chaque capteur et un fil allant à chaque commande par rapport à une liaison série à 1/2/3 fils qui transporte l'ensemble des infos de 15 capteurs et 15 sorties ???
Bon, de toutes manières tu n'en démordras pas. Alors je te souhaite bien du plaisir à concevoir ta carte mère (utilise au moins un module CPU venant s'enficher dans la carte mère pour ton [(SoC/SoC+FPGA/Zynq)+RAM]) avec ses 200 ou 400 connections. Et le jour où tu auras besoin d'un de plus que ce que tu as prévu, ben tu refais toute une carte mère.
OK. Remarque : c'est un composant qui a plus de 15 ans. Il ne fait pas d'échantillonnage simultané (simultaneous sampling) et il ne sait pas enchaîner les différents canaux tout seul, donc il faut lui envoyer 1 coup de CS ou CSTART ou FS par canal en respectant des temps minimums (600ns/1,4µs). Ces temps d'attente sont perdus si tu ne sais pas faire autre chose en attendant. Par contre, le même signal peut servir à tous les TLC1518 présents sur la carte. Et la lecture, elle, ne pose pas ces problèmes d'attente (mais il faut des CS différents pour chaque TLC1518).
Sinon, si je prend aussi au hasard un composant plus récent comme le MAX11060 : 4 voies seulement, mais il fait le simultaneous sampling, il gère un peu tout tout seul et tu peux même en mettre plusieurs en cascade sans avoir besoin d'interface supplémentaire.
Note quand même qu'il va falloir une bonne quantité de ces CAN car il n'ont que 4 ou 8 entrées, alors qu'un µC peut gérer 16 voire 32 entrées et ce, en plus, pour un coût unitaire moindre. Faut les programmer, c'est sûr, mais si on ne leur fait faire que ça (lire leurs entrées analogiques, éventuellement signaler au SoC qu'elles sont prêtes, et envoyer les données quand le SoC leur demande), ce n'est pas bien compliqué.
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 10 juillet 2014 à 09:37.
Tu es bon en hard, mais tu n'es pas la moindre notion de conception de système embarqué ? C'est ça ? Le fait de lisser sur 1 ou 10 cycles,est un choix de conception, qui peut arriver bien après la conception du hard.
Dans ce genre de système, tu as des taches à vitesse fixe. 1 khz a été choisi par beaucoup d'équipe e=m6, car c'est en gros la vitesse qu'il faut pour qu'un PID soit assez réactif, et tout mettre en commun permet de faire bien plus (asservissement 2D ou plus, détection de glissement, de choc,…).
Si tu veux faire complexe, tu peux toujours avoir une tache à 1kz qui dialogue avec une autre à 10Hz, si tu as besoin de plein de temps cpu.
sauf que tu oublis les fils liant ta carte fille et les capteurs. Donc tu as tout les fils d'avant, plus les fils numériques, sauf si tu mixes la carte puissance et la carte capteur.
C'est pareil, si tu manques de lien spi.
Il faut voir si la latence du cycle complet est assez rapide. En général, ce genre d'architecture est lente, (tu n'utilises pas de SPI à 40Mhz à travers des fils de base, si ?)
Cela existe des composants spi avec ADC + PWM en sortie ?
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par gnx . Évalué à 1.
Faut le dire vite.
Le rapport entre la conception de système embarqué et un régulateur/asservissement d'automatisme ???
Il y a plus de quinze ans que je n'ai pas utilisé une quelconque compétence d'automaticien, en effet. Et ça ne risque plus d'arriver puisque comme tu l'illustres, c'est devenu une activité d'informaticien et non d'électronicien.
De plus, je n'étais pas sûr que tu parles bien de ça, car il faut t'arracher les vers du nez pour avoir des infos, ce n'était pas clair jusqu'ici (juste on lit, on réagit en écrivant dans le même cycle).
C'est un non- choix de conception, plutôt. Un choix de conception qui arrive après qu'une partie ait déjà été fixée et réalisée… ça explique qu'on fait peser des contraintes fortes sur la partie matériel parce que la conception du reste n'est pas déterminée.
Non, même si tu n'as plus de bus SPI séparé, tu peux rajouter d'autres sur le même bus, il faut juste pouvoir générer un CS par esclave (inconvénient du SPI par rapport à des « vrais » bus série).
Il ne vaut mieux pas, en effet, c'est pour ça que je disais dans un précédent message de passer en différentiel (RS422/485, LVDS, etc) si on voulait aller vite et que la distance était un peu longue.
Mais avec un système numérique, chaque port est identique, interchangeable et complet : au lieu de devoir par exemple choisir x emplacements de borniers et x fils séparés pour aller vers tel membre ou tel moteur, et y vers un autre, tu peux utiliser un connecteur et un câble uniques pour chaque module (comprenant SDI+SDO+SCK+GND+Alim_module+2 ou 3 CS pour pouvoir chaîner autant de modules+Alim_puissance si pas trop dégueulasse).
Pour transmettre 15 capteurs x 1 octet, disons 160 cycles, à 10 MHz, ça prend 16µs, à 1 MHz 160µs. Guère besoin d'aller plus vite. Et le CPU du SoC n'est pas utilisé pendant ce temps là, il suffit d'écrire en bloc dans la FIFO de son module SPI pour émettre, et pour recevoir, de la lire la FIFO en bloc lorsque le transfert est fini.
Ça s'appelle un microcontrôleur :-D Sinon, sérieusement, ça ne me dit rien, non.
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pourquoi ils ne font pas de vrai bus d'extension série, avec possibilité de chainage ? Si la partie d'adresse prend trop de place, il faut un encodage type UTF-8. Ensuite, il faut trouver un moyen de démarrer pour faire de l'allocation de zone mémoire, mais cela se fait depuis le PCI.
Tu oublis les fils qui partent de chaque module pour aller vers les capteurs ou les moteurs.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Sylvain Briole (site web personnel) . Évalué à 5.
Il y a embarqué et embarqué.
Pour moi un des critères serait aussi la garantie d'approvisionnement dans le temps et la tenue en température (typ. max. 85°C en gamme industrielle) sans dispositif ajouté (radiateur ou ventilo).
# Compatible module Raspi ?
Posté par cm-t . Évalué à 2.
Bonjour, est-ce que vous savez si la BananaPi est compatible avec les modules d'extension du Raspberry Pi (exemple: CAM, piscreen, …) ?
[^] # Re: Compatible module Raspi ?
Posté par BananaPi . Évalué à 1.
Bonjour,
Comme je le dit dans l'article le BananaPi n'est pas un clone du Raspberry Pi donc il ne sera jamais 100% compatible mais des modules BananaPi sont en cours de conception et commence à sortir.
# Mes premières impressions
Posté par Matthieu . Évalué à 10.
J'ai commandé un banana pi il y a plus d'un mois pour remplacer mon raspberry et avoir ainsi plus de puissance.
J'ai téléchargé l'image raspbian depuis le site http://lemaker.org/ . Vous installez ensuite l'image sur une sdcard et vous bootez dessus. N'essayer pas de vérifier si le banana pi fonctionne sans y mettre de carte sd, il ne se passera rien du tout, le banana pi n'a pas de bios, il se base sur des fichiers de la sdcard (pareil pour le raspberry).
J'utilisais mon raspberry pour faire de la domotique, en utilisant les gpio et des capteurs de températures Dallas ds18b20. La bibliothèque wiringpi est en cours de finalisation (où l'es à l'heure actuelle ?). Il manque encore les modules w1-therm et w1-gpio pour pouvoir récupérer les données des capteurs de températures, mais ceux-ci vont être intégrés très prochainement (http://forum.lemaker.org/viewthread.php?tid=897&extra=page%3D1)
Si vous voulez brancher un disque SATA (SSD par exemple), sachez qu'il vous faudra un câble d'alimentation spécifique. Mais rassurez-vous, ça se fabrique, c'est juste du 5V en sortie qu'il faut raccorder au 5V de la prise d'alimentation SATA.
Pour le moment, je n'ai pas pu le tester plus en avant. J'avais besoin de puissance pour faire tourner un tomcat dessus, mais je n'ai pas encore trouvé le temps d'avancer sur le développement de mon soft de domotique. Et il me manque encore le wiringpi et le w1-therm.
[^] # Re: Mes premières impressions
Posté par Matthieu . Évalué à 4.
Il vient d'être publié la version 3 de raspbian qui intègre les gpios et le w1-therm (normalement).
Idem, publication de la version 3 de lubuntu pour la banane.
http://www.lemaker.org/index.php?m=content&c=index&a=show&catid=9&id=38
PS : le site banane fr n'est pas à jour par rapport à lemaker au niveau page de download.
[^] # Re: Mes premières impressions
Posté par BananaPi . Évalué à 0.
Effectivement nous sommes entrain de mettre à jour le site banana-pi.fr en ce qui concerne les nouvelles images téléchargeables.
# La wandboard est sortie du top 10
Posté par Ant . Évalué à 1. Dernière modification le 03 juillet 2014 à 11:37.
J'étais intéressé par une wandboard pour faire tourner un serveur "Logitech Media server" (ex-squeezeboxserver) avec une distrib arch, et je constate qu'apparemment cette carte est sortie du top 10 par rapport à l'année dernière (http://www.linux.com/news/embedded-mobile/mobile-linux/732197-top-10-open-source-linux-boards-under-200), où elle était en queue de peloton.
Du coup, je vais peut-être revoir mon projet.
# Mouais...
Posté par aktawarrior . Évalué à 4.
Le seul intérêt de cette carte est le form factor copié du raspberry. Pour le reste, mieux vaut se tourner vers la cubieboard (j'en ai quelques une depuis le Day1 :) pas beaucoup plus grande) qui dispose d'un bon support et d'une communauté déjà bien établie…(surtout si on ne peut réutiliser tel quel les modules Raspberry) avec biens plus de GPIO (ce qui manque au raspberry pi actuel par ailleurs!).
Autrement, pour les fans de puissance en low-power, Cubietech (la société derrière la cubieboard) va sortir la cubieboard8 basée sur le tout dernier AllWinner A80… une bête de course!
# Olimex/Olinuxino
Posté par Gilles G. . Évalué à 10.
Quel est l'intérêt par rapport à la série Olinuxino de chez Olimex ?
Parce que Olinuxino, c'est toute une série de cartes:
C'est une vraie question, hein!
[^] # Re: Olimex/Olinuxino
Posté par aktawarrior . Évalué à 6.
Je suis bien d'accord!
Le problème des cartes basées sur les chip Allwinner, c'est qu'il y en a pleins. Bien évidemment toutes câblées différemment. Donc déjà que pour pouvoir se servir des GPIO c'est pas super évident (vive la documentation AllWinner :) ).
Ce que je trouve dommage avec la "Banana" c'est d'avoir choisi de se passer de la NAND dont disposent les autres cartes (vraisemblablement pour le coût!) et d'avoir stripper les IO. Mais une carte à 50€ sans NAND alors qu'on trouve la même base (en France) à 60€ avec 4GB on-board et bien plus d'IO, personnellement je préfère bricoler un peu pour adapter les modules ADAfruit et autres.
Maintenant, tous les goûts sont dans la nature :) mais j'ai peur que la banane fasse… flop.
[^] # Re: Olimex/Olinuxino
Posté par daeavelwyn . Évalué à 1.
Et avec du Gigabit natif pour l'éthernet, ce qui n'est pas une évidence pour le banana à première vu :-/
# Hummingboard
Posté par mosfet . Évalué à 1.
http://www.nextinpact.com/news/88531-hummingboard-trois-concurrents-au-raspberry-pi-a-partir-4499-dollars.htm
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.