-ms-

Un petit ordinateur pour piloter vos projets !!!

Messages recommandés

Pour ceux qui veulent s'essayer à la programmation // sans se ruiner, la carte Parallella contient tous les ingrédients.

Il existe déjà sur le marché des cartes où le processeur multi-coeurs (ARM ou x86) est accompagné d'un circuit FPGA mais l'originalité de cette carte c'est que vous pouvez programmer son accélérateur multi-coeurs Epiphany directement dans votre langage // préféré (C/C++, Open CL, Erlang, Go, Numba, Scala, Julia, ...) au lieu de vous attaquer à la programmation indigeste du circuit FPGA en VHDL.

Les applications de ce petit ordinateur très puissant sont nombreuses :
- optimisation d'algorithmes,
- traitement d'images et de vidéos,
- pilotage de votre future monture direct drive,
- robot,
- etc ...

Comment ça marche :
L'IHM de votre application tournera sous Linux Ubuntu c'est à dire utilisera surtout le processeur ARM A9.
Les parties critiques utiliseront les services de l'accélérateur Epiphany.
Rien ne vous empêche cependant d'attaquer directement la programmation du FPGA en VHDL pour contrôler votre caméra CMOS sans passer par la connexion Giga Ethernet.
Bref cette carte vous laisse beaucoup de liberté pour développer votre application. Bien plus par exemple qu'une carte ZedBoard qui vous oblige à pratiquement tout coder en VHDL.

J'oubliai le prix ... $99 pour une carte Parallella-16 à partir de novembre 2013.
http://www.adapteva.com/parallella/

La carte Parallella-16 c'est la puissance d'un Core i5 et la carte Parallella-64 c'est la puissance d'un Core i7 si on se réfère au CoreMark. En fait, elle est bien plus puissante quand il faut optimiser des algorithmes contenant des matrices dont les éléments sont en virgule flottante par exemple.
http://www.adapteva.com/white-papers/more-evidence-that-the-epiphany-multicore-processor-is-a-proper-cpu/

[Ce message a été modifié par ms (Édité le 12-09-2013).]

Partager ce message


Lien à poster
Partager sur d’autres sites
Salut ms,

Intéressant, de mon cote je regardais les cartes proposées par Armadeus.
Je suis plus intéressée par le codage VHDL justement.
Mais le prix refroidi un peu. 99$ voila une alternative intéressante si les outils de développement sont à la hauteur pour l'intégration d'IP dans le FPGA.

Partager ce message


Lien à poster
Partager sur d’autres sites
C'est pas un peu overkill ce genre de trucs pour les applications que tu suggères ? Un Rapsberry Pi (pour la caméra) ou même un Arduino (pour le pilotage de monture) fait le boulot pour la moitié du prix de ton bazar, pas besoin d'un FPGA pour ça.

Par contre c'est le truc rêvé pour les barbouzes qui veulent déchiffrer deux-trois trucs sur place, ou repérer la tronche d'un (futur ex) fauteur de trouble dans un flux video

Ah oui, détail, c'est un projet kickstarter qui vient tout juste de sortir de la phase "prototype", pas une carte fabriquée en série. Expect some glitches ...

Sinon dans l' absolu c'est encore une petite plateforme d'évaluation sympa à un prix dérisoire, c'est vraiment une période bénie pour ceux qui veulent bidouiller, quand on pense au prix de ces trucs là il y a quelques années ...

[Ce message a été modifié par PascalD (Édité le 12-09-2013).]

Partager ce message


Lien à poster
Partager sur d’autres sites
ARMadeus systems (Mulhouse) c'est très bien et en plus l'assistance technique est possible. Si j'avais une application avec IHM embarquée (QT4) et plus axée FPGA (VHDL) c'est la solution que je retiendrais même si le coût est un peu plus élevé quand tu ajoutes le module processeur et autres modules nécessaires. Maintenant si tu fais partie de l'association "ARMadeus", tu as un tarif préférentiel.

Ce que je recherche c'est une carte au format "carte de crédit" pour embarquer un logiciel de traitement de la turbulence dans un petit boitier qui sera relié à la camera (CCD/CMOS/sCMOS/EMCCD) par le port GigaE. J'ai pas d'IHM mais des algorithmes d'extraction des "lucky regions" à optimiser. Après avoir utilisé Scala pendant un an, je suis passé à Julia qui va me permettre de sortir une maquette en fin d'année.

Pour répondre à ta question, le travail d'intégration en VHDL de l'accélérateur Epiphany 16/64 a été fait par adapteva (voir le projet complet sur GitHub). Pour l'intégration d'IP dans le FPGA, tu auras le même genre de boulot à faire.

Pascal, Rapsberry Pi et Arduino c'est génial mais l'intérêt de Parallella est à mon avis ailleurs. Je suis en train d'écrire mon application en Julia ainsi que l'interface nécessaire pour profiter des services de l'accélérateur Epiphany. J'aurais pu très bien faire le même travail avec C/C++, OpenCL, Erlan ou Scala ... c'est ça l'intérêt de ce système.
http://github.com/adapteva

Rapsberry Pi (le petit ordinateur) et la carte Arduino c'est le bon couple pour faire de petites applications domotiques avec Python ou Lua par exemple.

Bref dans tous les cas, il y a de quoi s'amuser ... pour ceux qui aiment cela bien sûr.

Partager ce message


Lien à poster
Partager sur d’autres sites
En effet, ca n'est pas comparable a la carte RasberryPi, mais pour du calcul embarque ca s'annonce plutot pas mal !

Partager ce message


Lien à poster
Partager sur d’autres sites
Quel est le capteur de la camera de la RasberryPi ? Est-ce utilisable en astro ? et dans quelle "mesure" ?

Partager ce message


Lien à poster
Partager sur d’autres sites
Un petit exemple d'application 'client/serveur' avec les cartes Parallella et Rapsberry Pi ... comme dit PascalD cela présentera un intérêt que si des traitements sont demandés au serveur :

Partager ce message


Lien à poster
Partager sur d’autres sites
Sinon, les cartes Beaglebone/Beagleboard sont dans le même créneau de prix et permettent aussi de faire des trucs (avec un CPU Cortex, donc plus musclées d'un Raspberry Pi). Alternative intéressante pour qui n' a pas besoin de faire du traitement du signal intensif "à la ms".
http://beagleboard.org/bone

[Ce message a été modifié par PascalD (Édité le 12-09-2013).]

Partager ce message


Lien à poster
Partager sur d’autres sites
Pascal, la Beagleboard (Cortex-A8) est de moins en moins utilisée au profit de cartes guère plus coûteuses mais plus musclées (Cortex-A9) comme la Wandbord :
http://wandboard.org/

Tu as encore les cartes PandaBoard, Snowball Board, Origen4 Quad Board, ... mais les prix sont un peu plus élevés.

De toute façon ce marché va exploser car les circuits utilisés se retrouvent dans les téléphones portables Android qui demain feront de plus en plus d'applications en temps réel et des traitements //.

Partager ce message


Lien à poster
Partager sur d’autres sites
bonjour a tous,
je travaille actuellement sur un projet de motorisation altazimutale
a faible cout, en utilisant les ports GPIO de la raspberry Pi.
Plusieurs librairies sont disponibles, suivant le besoin et la vitesse
d'attaques (C, Python, ou directement devices /dev, etc..)
sous linux, on a tout..
Il y a quand même plusieurs hic
- le nombre limités de ports ( a moins de programmer en liaison série UART
ou via le port I2C mais c'est pas à la portée de tout le monde..) la black est mieux a ce niveau là.
- l'absence d'horloge interne , mais cela va être palié dans mon
projet par une entrée horloge de synchro
- des erreurs I/O aléatoires et assez contraignantes pour une utilisation
long time, heureusement, la carte SD peut être refaite en 30 seconde !
un fsck est rébarbatif ..
Je vous en dirai plus si cela fonctionne, et suis preneur d'infos ou bien d'idées, puisque en cours d'essai sur platines d'essai.
Je me base sur l'idée suivante : attaquer une autre carte pour le contrôle des moteurs en modulant la vitesse par un nombre de bits suffisant.
stephane

Partager ce message


Lien à poster
Partager sur d’autres sites
ms, ton post m'intéresse vivement..

J'étais précisément en train de chercher une carte capable de faire du traitement en ligne sur un flux CameraLink (entre une em-ccd et un pc).

Ce que je veux faire ce n'est pas de la mesure de turbulence ou de l'extraction de lucky regions comme toi mais de l'interférométrie des tavelures (par DVA typiquement). J'ai cherché des frame-grabbers sur lequel on pouvait programmer le FPGA sans trop de succès.

Ce genre de solution pourrait dc être intéressant. Ce qui n'est pas trop clair - mais je n'ai pas encore épluché la doc - c'est comment on programme concrètement le FPGA (ie comment une interface un design flow classique VHDL avec les outils proposés). Le hic pr moi, pr ailleurs, c'est que ledit FPGA est du Xilinx alors que mes collègues et moi-même travaillons plutot sur Altera, mais bon..

Jocelyn

Partager ce message


Lien à poster
Partager sur d’autres sites
quote:
J'étais précisément en train de chercher une carte capable de faire du traitement en ligne sur un flux CameraLink (entre une em-ccd et un pc).

Dans ce cas, tu as peut-être plus simple avec CUDA et la programmation multi-coeurs coté GPU (cartes NVIDIA GeForce, Quadro ou Tesla). La moindre carte offre déjà quelques centaines de coeurs.

Ce pdf de 2010 explique le problème :
http://www.cs.berkeley.edu/~volkov/volkov10-GTC.pdf

La carte Parallella c'est bien pour faire une boite noire qui traite un problème particulier comme l'extraction et la fusion de "lucky regions", ce dispositif s'intégrant directement en sortie d'une caméra CCD, sCMOS ou EMCCD. Pour l'instant, j'explore la piste CUDA (poste fixe et portable) sous Windows 7 et Ubuntu 12.04 LTS. Il y a aussi une solution embarquée sous Linux qui me semble aussi très séduisante :
http://developer.nvidia.com/content/kayla-platform

[Ce message a été modifié par ms (Édité le 12-11-2013).]

Partager ce message


Lien à poster
Partager sur d’autres sites
> Dans ce cas, tu as peut-être plus simple avec CUDA et la programmation multi-coeurs coté GPU
> (cartes NVIDIA GeForce, Quadro ou Tesla). La moindre carte offre déjà quelques centaines de coeurs.

Pour avoir pratiqué les deux (GPGPU et FPGA), je préfère nettement la seconde approche dès qu'il s'agit d'implanter du traitement temps-réel sur le flot. La gestion des transferts mémoire avec les GPUs est svt un goulot d'étranglement.. Bien sur le style de programmation n'est pas le même, mais j'ai développé des outils capables de générer du VHDL à partir de descriptions plus haut niveau (plus d'info ici si tu es intéressé..).

> La carte Parallella c'est bien pour faire une boite noire qui traite un problème particulier comme
> l'extraction et la fusion de "lucky regions", ce dispositif s'intégrant directement en sortie d'une
> caméra CCD, sCMOS ou EMCCD.

C'est exactement ce que je veux faire : me placer à la sortie de la caméra.
Je suis en train de voir si je ne pourrais pas utiliser une architecture de caméra intelligente développée par un collègue pr faire cela. J'ai juste besoin d'une interface CameraLink dans les deux sens..

Merci pr ton feedback, en ts cas.

Jocelyn

Partager ce message


Lien à poster
Partager sur d’autres sites
Les transferts mémoire avec les GPUs sont effectivement un des points faibles de cette technique. L'autre point faible c'est l'aspect très propriétaire de CUDA (NVIDIA).

Il y a quelques mois, je m'étais intéressé au couple Chisel/Scala qui me semble partager de nombreux points communs avec CAPH/Caml.
Ces environnements sont capables de gérer de façon élégante et efficace les FPGA.

Finalement, j'ai décidé (depuis un an) de faire quelque chose d'analogue avec Julia en ciblant FPGA et GPU.

D'un autre coté, les GPUs ne sont peut-être qu'une étape intermédiaire dans l'attente de CPUs beaucoup plus musclées ou d'approches type Epiphany à 1024 coeurs.

Partager ce message


Lien à poster
Partager sur d’autres sites
quote:
J'ai juste besoin d'une interface CameraLink dans les deux sens..

Tu as un exemple d'implémentation dans le lien suivant :
http://proceedings.spiedigitallibrary.org/proceeding.aspx?articleid=1693625

Mais cela a aussi été fait par EM Photonics pour des systèmes basés sur l'analyse des tavelures :
http://www.vision-systems.com/articles/print/volume-15/issue-6/Departments/Technology_Trends/IMAGE_PROCESSING_FPGAs_enable_real-time_atmospheric_compensation.html

Partager ce message


Lien à poster
Partager sur d’autres sites
Très intéressant ! Merci

* le papier de Maignan (SPIE) ressemble pas mal - mis à part l'appli - à ce que j'ai en tête : une "blackbox" que l'on insère ds le flux.

* l'article de Carmano (EM phot) est plus éloigné; au passage, il montre bien l'intérêt des approches GPGPU dès qu'il y a du calcul flottant à faire (pas trivial sur du FPGA..).

* j'ai aussi jeté un œil sur Chisel/Scala. J'aime bien les approches DSL en général; mais ici, vu le niveau d'abstraction offert -- ie la quantité de détails liés à l'architecture qui "remontent" -- je me demande si on aurait pas intérêt à décrire directement en SystemC par exemple.


Jocelyn

[Ce message a été modifié par legalet (Édité le 20-11-2013).]

Partager ce message


Lien à poster
Partager sur d’autres sites
J'ai aussi jeté un oeil à Caph, cette façon d'aborder les algorithmes de vision via un langage d'acteurs puis de cibler les FPGA pour les performances, est très séduisante. Le seul point qui me gène c'est que tu auras du mal à réutiliser l'énorme existant écrit en Matlab/Octave, IDL, Python, ...

Avec Julia, c'est presque un jeu d'enfant de réutiliser ou d'adapter des algorithmes existants Matlab/Octave avec à l'arrivée des performances proches du langage C :
http://julialang.org/benchmarks/

quote:
au passage, il montre bien l'intérêt des approches GPGPU dès qu'il y a du calcul flottant à faire (pas trivial sur du FPGA..).

Pour le calcul flottant, l’accélérateur Epiphany lié à un circuit FPGA me semble être une bonne approche.

[Ce message a été modifié par ms (Édité le 21-11-2013).]

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant