Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[Embarqué] C ou C++ ?
Salut à tous,
On entend dire par monts et par vaux que pour le domaine de l'embarqué, le C est plus adapté que le C++.
1 - Est-ce vrai ?
2 - Si oui, Pourquoi ?
J'ai dans l'idée que les deux langages produisent de l'assembleur, donc pourraient être équivalent.
Je vous écoute !
EDIT : J'aurai bien mis cette discussion dans C et C++ mais je crois pas que ce soit faisable !
Personnellement, je ne pense vraiment pas que l'un soit plus approprié que l'autre... par contre, la plupart des compilateurs pour l'embarqué (pour microcontroleur s'entend) sont des compilateurs C ... du coups, en général, c'est plus par défaut que par choix qu'on fait du C sur l'embarqué.Envoyé par poukill
Salut à tous,
On entend dire par monts et par vaux que pour le domaine de l'embarqué, le C est plus adapté que le C++.
1 - Est-ce vrai ?
2 - Si oui, Pourquoi ?
J'ai dans l'idée que les deux langages produisent de l'assembleur, donc pourraient être équivalent.
Je vous écoute !
Je pense aussi que déjà que certaines fonctions C des bibliothèques standard ne sont pas disponible dans l'embarqué, les fabricants de compilateurs n'ont pas en plus envie de refaire les bibliothèques C++ (encore que je suis pas sûr de savoir ce qu'il y a a refaire).
D'autre part, un programme embarqué doit être de petite taille... ce qui est incompatible avec des mécanismes tel que les exceptions.
Enfin (et surtout) pas mal de chips embarquée... ne supportent pas l'allocation dynamique (puisque pas de système d'exploitation) du coups, la seule feature que peut fournir le C++ est d'ajouter des méthodes au struct: pas de strings, pas de conteneurs, pas de iostream. Eventuellement, on peut avoir des listes (statiques-_-') et des itérateurs (mais sur des tableaux statiques... on perd un peu l'intérêt) et garder les algorithmes qui vont avec.
Je suppose que c'est ça. Ensuite, certains templates m'auraientt quand même facilité la tâche lorsque je codais sur microcontroleurs, mais les cas étaient rares.
Peut-être un gentil modo pourra-il mettre un lien :p ?EDIT : J'aurai bien mis cette discussion dans C et C++ mais je crois pas que ce soit faisable !
Cordialement.
Salut,
En embarqué, j'ai croisé aussi bien des projets C que C++. Si ton projet consiste en quelques milliers de ligne, peut être pourras-tu construire une version C plus performante en terme de taille et de vitesse (je n'ai jamais fait l'essai mais je veux bien être crédule). Mais pour un projet complexe, les 'surcouts' de taille et de vitesse induits par le compilateur/langage seront probablement négligeables au regard de la conception mise en place.
Cependant, en embarqué, on ne prend souvent pas 'tout' le C++ pour de bonnes ou de mauvaises raisons :
-> Les exceptions sont écartées : elles génèrent un surcout de taille de code et performance (raisons valables) mais sont souvent aussi mal comprises et écartées à cause de ça (raison typique : non déterminisme de l'appel, approche programmation défensive récurrente, etc.)
-> Les templates : les 'vieux' compilateurs avaient des comportements très variables avec les templates et donc les projets ont eu tendance à les écarter à cause de ça. Je soupçonne aussi une maîtrise aléatoire. Certains (vieux) compilateurs pouvaient générer le code d'un template instancié avec le même jeux d'arguments autant de fois que d'unité de compilation où il était utilisé => d'où une méfiance de leur tendance à l'inflation de code. Enfin, l'approche générique tend à favoriser le polymorphisme de surcharge au détriment de la coercition ou l'inclusion (il me semble). D'où encore une inflation possible. Tout cela aujourd'hui perd de son sens par l'utilisation de compilateur performant et par une meilleure maîtrise de l'approche générique.
-> L'héritage multiple : j'ai vu des projets dans lesquels l'héritage multiple était désactivé soit disant pour le surcout mémoire que cela engendre. Même s'il y a un léger surcout je soupçonne que cela est dû à une mauvaise maîtrise de ces concepts.
-> RTTI : souvent désactivé pour minimiser l'emprunte mémoire des objets instanciés (adieu downcast de toute façon considéré comme probablement conception problématique).
La question de l'allocation dynamique est indépendante du langage (C ou C++). Et elle est traitée de différentes façons : allocation totalement interdite, allocation gérée par des pools de bloc mémoire de taille fixe, etc. Souvent la méfiance de l'allocation dynamique tient au coût (en temps d'exécution) que peut avoir une allocation ou une libération ainsi qu'au risque d'un échec d'allocation. Ceci est plus un problème de ton système que du langage.
Pour conclure, choisis C ou C++ en fonction de la qualité des compilateurs que tu peux trouver, des compétences de l'équipe de dev (pas la peine de faire du C++ si tu n'as que des cadors en C ou le contraire). Certaines parties pourront être mixes (routines C/asm pour des ITs, approches C++ ailleurs).
Ressources proposées par 3DArchi - Les fonctions virtuelles en C++ - Cours et tutoriels C++ - FAQ C++ - Forum C++.
Certes. Cependant dans le cas de l'interdiction totale, cela a un énorme impact sur les possibilités du C++...gestion de Pool souvent laissé à la charge de l'utilisateur
Ainsi qu'a l'absence de système d'exploitation non ? car je ne vois pas comment avoir d'allocation dynamique sans système d'exploitation ...
Heureusement, de plus en plus de systèmes embarqués intègrent la possibilité d'utiliser des systèmes d'exploitation "standard" comme linux ou autre... et là, on a vraiment le choix
C'est une raison !
J'aurai pensé qu'il existerait un compilateur pour embarqué, possédant un paquet de cibles différentes pour s'adapter au projet. Un compilateur respectant un minimum le standard pour que quelques bibliothèques tierces vraiment adaptées puissent être intégrées.Je pense aussi que déjà que certaines fonctions C des bibliothèques standard ne sont pas disponible dans l'embarqué, les fabricants de compilateurs n'ont pas en plus envie de refaire les bibliothèques C++ (encore que je suis pas sûr de savoir ce qu'il y a a refaire).
Effectivement.D'autre part, un programme embarqué doit être de petite taille... ce qui est incompatible avec des mécanismes tel que les exceptions.
C'est pour ça que je pose la question. Le C ne me posera pas plus de problèmes des ça, mais la conception est plus "souple" en C++...
OK, Mephistopheles et toi êtes d'accord la dessus. C'est pas spécialement génant, à partir du moment où l'on sait que l'on doit faire sans.-> Les exceptions sont écartées : elles génèrent un surcout de taille de code et performance (raisons valables) mais sont souvent aussi mal comprises et écartées à cause de ça (raison typique : non déterminisme de l'appel, approche programmation défensive récurrente, etc.)
Je note l'apparition multiple du mot "vieux compilo". Je sais que le C++ évolue plus vite que le C, m'enfin quand même il y a un comitee alors c'est pas si rapide que ça.-> Les templates : les 'vieux' compilateurs avaient des comportements très variables avec les templates et donc les projets ont eu tendance à les écarter à cause de ça. Je soupçonne aussi une maîtrise aléatoire. Certains (vieux) compilateurs pouvaient générer le code d'un template instancié avec le même jeux d'arguments autant de fois que d'unité de compilation où il était utilisé => d'où une méfiance de leur tendance à l'inflation de code. Enfin, l'approche générique tend à favoriser le polymorphisme de surcharge au détriment de la coercition ou l'inclusion (il me semble). D'où encore une inflation possible. Tout cela aujourd'hui perd de son sens par l'utilisation de compilateur performant et par une meilleur maîtrise de l'approche générique.
L'héritage multiple est pratique dans certaines conceptions mais en général on peut s'en passer.-> L'héritage multiple : j'ai vu des projets dans lesquels l'héritage multiple était désactivé soit disant pour le surcout mémoire que cela engendre. Même s'il y a un léger surcout je soupçonne que cela est dû à une mauvaise maîtrise de ces concepts.
Effectivement, le pattern visitor est plus adapté de toute façon.-> RTTI : souvent désactivé pour minimiser l'emprunte mémoire des objets instanciés (adieu downcast de toute façon considérée comme probablement conception problématique).
OK je comprends.La question de l'allocation dynamique est indépendante du langage (C ou C++). Et elle est traitée de différentes façons : allocation totalement interdite, allocation gérée par des pools de bloc mémoire de taille fixe, etc. Souvent la méfiance de l'allocation dynamique tient au coût (en temps d'exécution) que peut avoir une allocation ou une libération ainsi qu'au risque d'un échec d'allocation. Ceci est plus un problème de ton système que du langage.
Tu as parfaitement raison pour les compétences. Personnellement, c'est vraiment cette histoire de compilateur qui m'interroge. Chaque marque de carte a son propre compilateur qu'ils n'arrivent pas à mettre à jour ?Pour conclure, choisis C ou C++ en fonction de la qualité des compilateurs que tu peux trouver, des compétences de l'équipe de dev (pas la peine de faire du C++ si tu n'as que des cadors en C ou le contraire). Certaines parties pourront être mixes (routines C/asm pour des ITs, approches C++ ailleurs).
Il existe DES compilos pouvant cibler un ou des micro différents.
Ces compilos respectent plus ou moins le standard (comme les compilos windows ou linux d'ailleurs, cela n'a rien à voir avec l'embarqué) selon leur ancienneté et donc tu peux utiliser des bibliothèques tierces. Mais tu as probablement une étape de qualification avant.
En entreprise, il est courant de rester sur un compilo 'ancien' comprendre fin des années 90 début 2000. A cette époque, le C++ n'était pas encore normalisé ou la peinture était encore fraîche. Et les templates sont la feature du langage ayant probablement la plus grande volatilité sur ces compilateurs. Note qu'aujourd'hui, la plupart des vendeurs proposent des versions plus récentes et plus respectueuses de la norme (en revanche, je ne saurais pas te dire s'il existe déjà des compilo ciblant l'embarqué avec du C++0x).
Les compilateurs ciblent en général un ou des micro et les éditeurs ont des versions récentes. A toi d'identifier ceux candidats pour ta plateforme hard cible et voir si le compilo C++ a le bon niveau par rapport à ce que tu attends. Si tu as le temps, probablement qu'il faut conduire une phase de qualification des outils en cohérence avec la définition hardware de ton système.Chaque marque de carte a son propre compilateur qu'ils n'arrivent pas à mettre à jour ?
@méphistopheles : l'utilisation de l'allocation dynamique n'a rien à voir avec un OS 'lourd' (type Linux ou Windows Mobile). Certains projets embarqués utilisent de l'allocation dynamique gérée par un gestionnaire de mémoire sans avoir d'OS lourd de ce type. Les systèmes embarqués ne disposent pas forcément de mode noyau, d'adressage virtuel, de notion de processus etc. Ce qui fait que la notion d'OS comme définie pour un PC se trouve diluée. D'ailleurs souvent, le code regroupé sous OS est juste le gestionnaire de tâches (au sens thread) avec un ordonnanceur, de quoi sauvegarder un contexte (pile, registres...). La gestion de la mémoire, les 'drivers' (flash, RTC, watchdog, carte réseaux, LCD, etc..) sont des tâches comme les tâches applicatives... ou parfois tout est pris en charge par l'OS. Tout dépendBref, la gestion dynamique mémoire peut être indépendante de ton OS.
Et pour répondre à une autre de tes remarques, on peut très bien faire de bonnes applis C++ sans allocation dynamique (en embarqué). On n'a pas toujours ce besoin.
Ressources proposées par 3DArchi - Les fonctions virtuelles en C++ - Cours et tutoriels C++ - FAQ C++ - Forum C++.
Salut,
Pour ce que je crois en savoir, C a longtemps été considéré comme... un assembleur plus facile à relire.
En tout cas, on croise encore souvent des gens pour le prétendre
Ceci dit, je me demande si la raison n'est pas, tout simplement, à un problème d'offre et de demande.
Si je me mettais à la place des fondeurs de chips embarqué, je suivrais sans doute un raisonnement proche de
Je ne dis absolument pas qu'un tel raisonnement soit juste ni même qu'il soit, simplement, judicieux, mais, comme il est tellement encré dans les mentalités que seul C est réellement adapté aux exigences de l'embarqué, on peut réellement se demander si ce n'est pas le raisonnement suiviLorsque tu crées un nouveau chip embarqué, il est déjà "suffisamment difficile" de fournir un compilateur C, dont on sait qu'il sera utilisé par... la grosse majorité des développeurs pour l'embarqué, et l'on peut donc se demander s'il est vraiment utile de... mouiller sa chemise pour ajouter un compilateur C++ qui ne sera sans doute utilisé que par une minorité
Si tu peux estimer qu'un compilateur puisse être prévu pour être capable de fournir des exécutables pour différentes cibles (comme, par exemple Gcc, qui peut être compilé de manière à en supporter un grand nombre), il faut cependant considérer le fait que tu dois déterminer les (groupes de) cibles prévues au moment où tu... compile ton compilateur:J'aurai pensé qu'il existerait un compilateur pour embarqué possédant un paquet de cibles différentes pour s'adapter au projet. Un compilateur respectant un minimum le standard pour que quelques bibliothèques tierces vraiment adaptées puissent être intégrées.
Un compilateur compilé pour fournir des exécutables utilisables sous linux ne pourra pas... fournir d'exécutables utilisables sous windows ou sous spark, et inversément, même si tu peux compiler un compilateur croisé (capable de fournir des exécutables utilisables sous des cibles différentes que celle sur laquelle le compilateur est utilisé).
Or, quand tu rentres dans le domaine de l'embarqué, tu dois d'office travailler sur un compilateur croisé, car il est peu probable que tu sois capable de... faire tourner le compilateur sur ton composant embarqué
Le problème des bibliothèques tierces est similaire: Si l'on peut envisager de leur permettre de s'adapter au chipset sur lequel elles seront utilisées, il faudra toujours... la fournir dans une version utilisable par le système cible, avec tout ce que cela peut comporter de besoin de compilation conditionnelle
A méditer: La solution la plus simple est toujours la moins compliquée
Je ne parlais pas forcément d'un os lourd, mais à partir du moment ou il y a gestion de la mémoire et scedueler, c'est pour moi déjà un os.@méphistopheles : l'utilisation de l'allocation dynamique n'a rien à voir avec un OS 'lourd' (type Linux ou Windows Mobile). Certains projets embarqués utilisent de l'allocation dynamique gérée par un gestionnaire de mémoire sans avoir d'OS lourd de ce type. Les systèmes embarqués ne disposent pas forcément de mode noyau, d'adressage virtuel, de notion de processus etc. Ce qui fait que la notion d'OS comme définie pour un PC se trouve diluée. D'ailleurs souvent, le code regroupé sous OS est juste le gestionnaire de tâches (au sens thread) avec un ordonnanceur, de quoi sauvegarder un contexte (pile, registres...). La gestion de la mémoire, les 'drivers' (flash, RTC, watchdog, carte réseaux, LCD, etc..) sont des tâches comme les tâches applicatives... ou parfois tout est pris en charge par l'OS. Tout dépend
Certes, les templates permettraient justement de définir des static-array ou autres objets permettant de gérer plus facilement nos objets non allouable. De même l'héritage reste valable et utilisable, même si l'utilisation de fonction virtuelles perd beaucoup de son intérêt (tous les objets sont connus dès le départ). Par contre,la majeure partie de la stl saute et la notion de RAII et de RFID aussi avec les constructeurs et destructeurs... Bref, ça reste limité.
Je confirme des "compilateurs Assembleurs" (oui, oui, pas seulement des traducteurs) fournissant tout un panel de "super-macros" sont aussi souvent fournies avec... il faut dire que ces fondeurs travaillent justement en assembleur sur leur puce et il parait logique qu'ils se dotent d'un outil convenable pour ça.Pour ce que je crois en savoir, C a longtemps été considéré comme... un assembleur plus facile à relire.
En tout cas, on croise encore souvent des gens pour le prétendre
Parfaitement. D'autant que la plupart des demandes exigent un langage plus évolué tournent sur des puces plus puissantes... et souvent à même de pouvoir faire tourner un os du genre µclinux ou autre. Il est certain que quand on a une mémoire de 8ko, le programme qui ira dedans à peu de chance d'être extrêmement complexe.
Encore que de ce coté, on commence justement à voir apparaitre pas mal de puces basées sur (ou intégrant un) ARM qui peuvent être cross compilées à partir de gcc... donc de beaucoup plus de systèmes d'exploitations
encore une fois, ça dépend de la cible. Comme dit plus haut, de plus en plus de chips peuvent faire tourner un µclinux ou autre.Or, quand tu rentres dans le domaine de l'embarqué, tu dois d'office travailler sur un compilateur croisé, car il est peu probable que tu sois capable de... faire tourner le compilateur sur ton composant embarqué
pas forcément, on peut se contenter de générer le code machine en cross-compilation... ce qui ne dépend pas du type du système source mais seulement du composant cible.
On est bien d'accord, mais, si tu dois faire tenir sur un chips donné µclinux et gcc, même réduit à "sa plus simple expression", + les sources du logiciel et tous les fichiers de compilation, il risque de ne plus rester énormément de place
Je n'ai pas dit le contraire, mais je voulais attirer l'attention sur le fait que la génération du code machine elle-même peut nécessiter des aménagements en fonction de la cible.pas forcément, on peut se contenter de générer le code machine en cross-compilation... ce qui ne dépend pas du type du système source mais seulement du composant cible.
Regarde simplement du coté des macros que toute bibliothèque un temps soit peu portable trimbale rien que pour assurer une compatibilité entre linux et windows et entre les différents compilateurs supportés (quand ce ne sont pas carrément des fichiers sources propres à chaque cible ou compilateur)... Je serais surpris s'il n'y avait pas des problèmes similaires pour intégrer les autres bibliothèque dans les différents systèmes embarqués
Je ne dis pas que c'est impossible, je dis juste que ça demande une sérieuse dose de travail et... un grand nombre de gens suffisamment habitués aux différents chips
Ou de gérer des tableaux allouables dynamiquement, mais uniquement pendant une phase d'initialisation. Ou encore des tableaux de taille variable mais à la taille maximale fixée.
Là, je ne vois franchement pas pour quelle raison... Le RAII sert à gérer d'autres ressources que la mémoire aussi, et dans un programme embarqué, il peut y avoir des ressources à prendre et relâcher, et les relâcher correctement peut être crucial.
Et certains systèmes embarqués peuvent se permettre l'allocation de mémoire partout. J'ai déjà bossé sur un système embarqué composé de 11 PC reliés en réseau, et où les contraintes temps réelles, bien que présentes, étaient telles que l'allocation dynamique, on ne s'en privait pas la plupart du temps.
Tout ça pour dire qu'embarqué est un terme un peu vague, mais que quel que soit le type d'embarqué sur lequel bosser, quelles que soient les contraintes associées, je pense que le C++ bien maîtrisé peut apporter une simplicité (et donc une fiabilité) par rapport au C, à condition d'être disponible sur l'architecture cible.
Ce n'est pas tant lié à leur vitesse d'évolutions (qui sont à peu près comparables, un standard tous les 10/15 ans...), mais à la complexité de réalisation d'un compilateur C++, au moins d'un ordre de grandeur de plus qu'un compilateur C.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Salut,
Sauf que la gestion de la mémoire (statique et dynamique) peut être complètement gérée par le projet et ne pas dépendre d'une couche tierce identifiée comme OS et qui ne contiendrait rien pour cela.
Ce n'est pas parce que tu n'as pas d'allocation et que tu connais donc le type de tes objets que l'héritage et les fonctions virtuelles n'ont pas d'intérêt : tu peux être amené à manipuler des objets par leur classe de base et ils peuvent correspondre à des instances de classes dérivées différentes.
Le polymorphisme d'inclusion a beau s'appuyer sur les pointeurs ou les références, cela ne doit pas forcément passer par de l'allocation dynamique.
Et même ce n'est pas tout à fait vrai que tous les objets sont connus au départ. Il y a des projets où certaines parties du code peuvent être reflashée et donc mise à jour indépendamment d'autres parties, et là, l'héritage tu en as sacrément besoin pour respecter le principe ouvert/fermé.
Comme le dit Loïc, le RAII ça ne sert pas qu'à la gestion mémoire. Exemple : les mutex n'utilisent pas d'allocation dynamique mais ton code gagnera grandement à utiliser une enveloppe RAII pour le lock.
Attention cependant aux compilateurs C++ qui ne sont que des compilateurs d'Embedded C++
Ressources proposées par 3DArchi - Les fonctions virtuelles en C++ - Cours et tutoriels C++ - FAQ C++ - Forum C++.
Sachant qu'embedded C++ n'est pas vraiment quelque-chose qui est encouragé par le comité C++. Le standard C++ a une version "freestanding", destinée à ce marché, mais bien moins restrictive (qui va principalement enlever quelques bibliothèques dans la STL). Et dans C++0X il y a des fonctions spécialement destinées à ce marché (par exemple, constexpr).
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
quel embarqué exactement?
Salut,
De quel embarqué il est question:
développement sans noyaux? (rtos, linux,windows)juste 2-3 routines ASM sont fournis+libc.développement d'une application sur OS embarqué?aucun développement de driver n'est à faire(joujou avec les registres)développement de driver pour un OS?
Est-ce qu'une mmu est présente?
quel compilateur est utilisé?certains compilateurs n'intègrent pas ou pas correctement le c++.Est-ce une application critique(process indus, véhicule ,médical ou frigo USBUn compilateur C++ est considéré moins fiable qu'en C.Pour le moment, je pense que les deux amener à cohabiter et qu'il ny a pas de meilleur langage.
Le mot embarqué est devenu beaucoup large qu'il y a 12ans.
12 ans: proc 8-16 bits ou 32 bits tout neuf,que des os proprios fermé avec compilo dédié non c ansi, et sans c++, sinon buggé. Secteur assez simple.
now:proc 8bits avec compilo C ANSI pouvant compiler plusieurs familles de proc + compilos gratuits/libres. RTOS sans mmu possible.C'est lorsque que l'on a toutes ces réponses que l'on peut répondre pour un projet donné.
proc 32-64 avec mmu, OS de bureau, PC miniaturisé, drivers entièrements livrés (ex: adventech).
En mélangeant tout cela, on peut dire que C++ n'est pas fait pour du très bas niveau, Et que le C++ n'est pas fait pour le "très haut niveau embarqué" si puissance disponible( script shell, python, c#).
info: sur carte 9*9 cm, on peut obtenir un vrai PC.
Je sais pas si je suis très clair
Ben le C++ est fait pour marcher aussi bien à bas niveau qu'à haut niveau ( d'où la partie C du C++ ).
Après "l'embarqué" oui c'est vague, il faudrait qu'on connaisse ses contraintes:
- quel materiel, quel compilateur, est-ce que les compilateurs C++ sont corrects?
- va-t-il utiliser 5 matériels différents ou juste un?
Ma question se voulait volontairement ouverte.
S'il y a des domaines de l'embarqué ou le C++ n'a pas sa place, je suis content de le savoir, même si je ne vais pas bosser dessus !
Comme nikko34, je dirais que C++ contient une grande partie du C, donc y'a moyen de le faire cavaler et le prendre par le côté "bas-niveau".En mélangeant tout cela, on peut dire que C++ n'est pas fait pour du très bas niveau, Et que le C++ n'est pas fait pour le "très haut niveau embarqué" si puissance disponible( script shell, python, c#).
Pour le très haut niveau, si une grosse puissance est disponible, je trouve que le C++ serait assez bien adapté aussi. Pourquoi gaspiller du temps d'éxécution ? Perso, si le système n'en bave pas assez avec les traitements que je fais actuellement (comprendre, le temps-réel passe tranquille), je réfléchis à intégrer des routines plus gourmandes et plus efficaces.
Python, je l'utilise comme langage de script (intégré via boost.Python) pour permettre de maquetter. Mais C++ permet une conception robuste, ouverte à la modification, en gardant un côté performance qui lui va bien...
Salut trois_1, est-ce que tu peux préciser ?
Le sujet m'intéresse
Il parle probablement de chose comme le BeaglBoard.
Mais sur celui-ci on peut faire tourner un OS (Linux). Le choix C/C++ revient donc au développeur, en fonction de ses goûts.
Quel sujet précisement?Salut trois_1, est-ce que tu peux préciser ?
Le sujet m'intéresse
oui, une carte comme BeagleBoard xM.
D'ordre général, je conseil pour l'avenir des cartes avec des procs de nouvelle génération comme ARM cortex M3,A8, coldfire V1/V2/V4.
Typiquement un samsung wave ou galaxy S avec un cortex A8 est très fun(proc idem que IPad et Iphone4), mais orienté mobile/tablette.
Je ne travaille pas encore sur des procs aussi intéressants.
C'était simplement sur cette carte de 9*9cm.
En fait je cherche quelque chose de ce genre pour faire tourner une petite JVM du coup ça m'intéressait, mais cette carte est trop puissante pour les besoins que j'ai.
En tous cas c'est du beau matos, et pas si cher
tu as le beagle board standard qui est beaucoup moins puissant...C'était simplement sur cette carte de 9*9cm.
En fait je cherche quelque chose de ce genre pour faire tourner une petite JVM du coup ça m'intéressait, mais cette carte est trop puissante pour les besoins que j'ai.
En tous cas c'est du beau matos, et pas si cher
sinon regarde ce que fait
gumstix
muvium
fox board
ATMega
des cartes sur arm, ppc.... tu en trouves des milliers
tel que déjà dit, un système embarqué de nos jours ne veut plus dire grand chose....
tu peux trouver des systèmes à 40Mhz avec 8K de ram..... et d'autre qui sont dual core à 1.5Ghz avec 2 gig de ram....
tu peux en trouver qui gère le c, d'autre le c++, java, basic...
Répondre avec citation
Partager