Développement de synthé
- 13 réponses
- 5 participants
- 5 585 vues
- 8 followers
nirv4nh4ck
Bonjour à tous,
J'aimerais me familiariser au développement hardware dans le but de concevoir un synthétiseur ou sampleur/ synthé majoritairement numérique dans quelques mois/années. J'aimerais donc trouver une technologie évolutive accessible qui ne soit pas bientôt dépassée et puisse donner un résultat "pro" (sans être forcément à la pointe au niveau qualité de son). J'ai beaucoup de mal à trouver mon chemin au milieu de toutes les possibilités (ARM, DSpic, FPGA, etc...).
Je connais assez bien le C++ et pense pouvoir obtenir assez rapidement des résultats avec ce langage. Je ne connais pas du tout le VHDL et n'ai que les bases en traitement du signal, mais je commence à bien connaître les principes de la synthèse sonore (utilisation sporadique de Max/MSP notamment). J'ai également de bonnes bases en électronique, mais pas encore assez pour construire des vrais modules de synthé.
Il y a pas mal de projets basés sur les Arduinos, avec certains résultats assez impressionnants: https://mutable-instruments.net/shruthi1c
D'où ma question: pensez vous que le arduino (ou mbed) soit un bon point de départ? Est-ce vraiment trop limité pour un synthé, si je le fais presque en "tout numérique"? Et pour finir avec une question ouverte, que me conseillez vous (une solution C++ serait la bienvenue ^^)?
[ Dernière édition du message le 28/03/2011 à 01:25:31 ]
- 1
- 2
nirv4nh4ck
Personne? 
Aller, je suis sûr que certain d'entre vous ont des réponses 
.
Anonyme
Question bête : veux-tu développer pour toi ou pour diffuser ta création ? Dans le cas où c'est pour diffuser ta création, envisages-tu de le faire par le biais de kit/DIY ; ou en faisant fabriquer industriellement ? La réponse à cette question déterminera la famille de composants où regarder : monté en surface (indispensable pour bénéficier des chips récents et pour une fabrication industrielle, mais imbitable pour un kit) ou trou traversant (un coup de pied au cul 10 ans en arrière en matière de technologie, mais l'assurance que des centaines de milliers de DIYers vont pouvoir construire ton projet dans leur garage)
En trou traversant, il y a deux familles répandues de microcontrôleurs:
- Les AVR. Très limité en puissance de calcul (8 bits, 20 MHz max.) - permet en gros de faire une ou deux voies de synthèse (Shruthi, Meeblip) ; ou une ou deux voix d'échantillonnage (Where's the Party At, quelques modules offrant des effets de délai/sampling). Gros avantage : les outils de développement sont libres et bien packagés, disponibles sous toutes les plateformes, ce qui explique la popularité de cette famille
- Les dsPIC. Plus grande puissance de calcul (16 bits, 40 MHz, instructions MAC pour le traitement de signal, DMA pour soulager la gestion des I/O). Quelques projets DIY basés là-dessus (dont un VA assez sympa). Point négatif pour les outils de dev, c'est soit payant, soit "brut de décoffrage".
L'Arduino n'est pas un processeur, c'est une platine de développement munie d'un uC AVR + une interface de développement + une bibliothèque de fonctions C dispensant l'utilisateur de comprendre le fonctionnement bas-niveau du uC (au prix d'une perte de performances et de mauvaises habitudes de programmation). Pratique pour du prototypage et de l'initiation, mais ça s'arrête là.
En surface mount, tu as accès en plus à:
- Des microcontrôlleurs à base d'ARM, type LPC175x ou STM32F. On retrouve avec ces processeurs la puissance de calcul qu'on avait sur un PDA il y a 6 ou 7 ans, donc à la louche, 5 ou 6 voies de lecture de samples + quelques effets, ou 3 ou 4 voies de VA correct ; et quasiment tous les uC récents ont une interface i2s pour s'interfacer avec des codecs audio. Il y a des toolchains basées sur gcc/binutils plus ou moins prêtes à l'emploi ; et le développement (en tous cas sur STM32F) est facilité par le fait que le chip a un bootloader qui gère DFU / USB, donc pas besoin d'interface JTAG. Le STM32F est le chip utilisé dans la nouvelle génération de machines Midibox. On trouve des platines de développement pour une trentaine d'euros (Blueboard, Leaflabs Maple).
- Des DSP et SoC orientés traitement de signal, type AD Blackfin, TI Da Vinci... C'est ce genre de chips qu'on trouve dans les produits commerciaux, avec les performances idoines. Attention : les outils de développement sont coûteux. Je ne connais pas de projet DIY bâti là-dessus. Les platines de dev sont dans la centaine d'euros.
- FPGA. Le FPGA permet de s'affranchir des limites en puissance de calcul des DSPs ou CPUs classiques ; en concevant une architecture matérielle spécialisée "en dur" pour la résolution d'un problème. Il y a une petite communauté qui bricole des synthés avec - toutes les folies sont permises... 120 oscillateurs en parallèle, ou fréquence d'échantillonnage de 1 MHz pour éliminer les questions d'aliasing. Mais il n'y a absolument aucune raison d'utiliser un FPGA s'il n'y a pas ce besoin en puissance de calcul (plus compliqué à mettre en oeuvre qu'un bête uC, surtout parce qu'il faut gérer en parallèle deux bases de code, le firmware+la description hardware). Compter une centaine d'euros pour une platine de dev.
Concernant le C++, c'est peu courant en embarqué, probablement parce que quand on ne sait pas bien ce qu'on fait, on risque de créer du code peu performant. Pourquoi pas si tu es familier avec le comportement du générateur de code de gcc sur la plateforme que tu cibles, et que tu es bien au courant de la façon dont les constructions que tu utilises seront compilées. Je fais du C++ embarqué mais il y a 0 octet alloué dynamiquement, presque toutes mes classes sont des singletons statiques, je n'utilise ni STL ni librairie standard - bref, rien à voir avec du C++ sur desktop... juste du C avec des templates, des structs ayant des membres privés, et const & :D
Quelle que soit la plateforme que tu choisisses, tu devras faire le choix entre coder en "bare metal" (à toi d'organiser ton code pour orchestrer tes I/O et tes tâches), ou avec un RTOS qui s'en chargera au prix de 5 à 10% de CPU alloué au système. Dans tous les cas, tu auras probablement à écrire tes drivers pour tes périphériques (codec/DAC, afficheur). Ce n'est pas comme si chaque fabriquant de chip allait te vendre son "framework" de dev tout propre en C++ (ça n'aurait pas de sens vu la diversité des applications)... La seule exception, c'est peut être les librairies qu'on trouve avec Mbed et Arduino - mais ce n'est pas conçu pour des applications intensives (I/O bloquant, beuark).
Et maintenant une question de fond. Ma motivation à faire du hardware, c'est le son analogique "old school". J'ai le sentiment que si je faisais "juste" du numérique avec des technos modernes, je me retrouverai dans la même catégorie qu'Apple ou Dell, et de fait à des années à la traîne derrière ces géants en matière de plateforme matérielle. As-tu exploré la voie PC embarqué ? Il y a des cartes mères Pico-ATX ou des trucs comme le BeagleBoard qui ne prennent vraiment pas de place ! En lui ajoutant une carte récupérée sur un contrôleur MIDI USB (la carte brute doit se vendre en OEM auprès des fabriquants), c'est parti ! Ça te permettrait de garder tes outils de développements et ton OS favori, d'être à la pointe côté performances, pour un coût de développement minimal. Ça fait des années que les workstation sont des PC embarqués, et on voit débarquer d'autres produits (Rhizome) conçus comme ça. Autre option : concevoir une machine dans laquelle se "docke" un iPhone.
Le microcontrolleur, c'est sympa quand il y a quelque chose à... contrôler (des voies de synthèse analogique, miam), mais je crains que si ce que tu veux c'est une "boîte avec des faders qui fait tourner du code", ton créneau soit plutôt celui de l'informatique mobile/embarquée.
[ Dernière édition du message le 29/03/2011 à 13:21:34 ]
nirv4nh4ck
Merci beaucoup pour cette réponse vraiment complète. Je sais maintenant qu'il faut que je prononce le mot Shruthi pour avoir son créateur débarquer à la rescousse ^^. J'ai passé pas mal de temps sur ton message, à regarder et comparer les différentes possibilités, donc j'ai appris pas mal de choses. Je n'ai par contre pas réussi à trouver ce que VA signifiait.
Alors.. à plus ou moins long terme je souhaiterais développer pour diffuser ma création. Je pense plus à une solution industrielle, puisque j'aimerais créer une entreprise. Mais je ne suis pas encore fixé, puisque je trouve que la diffusion en kits a un charme fou, et j'ai surtout beaucoup de choses à apprendre avant cela.
Les deux solutions qui me paraissent les plus adaptées dans ce que tu dis sont les ARM de type LPC175x ou STM32F et les pc embarqués. Je m'intéresse aux instruments aux sons assez expérimentaux, imprévisibles, et pas spécialement au sons analogiques (en tout cas au niveau conception). Je suis d'ailleurs actuellement en train de m'amuser avec un microwave xt et une machine drum. Je pense donc l'image de la "boîte avec des faders qui fait tourner du code" assez adaptée.
C'est ce genre de carte de développement que tu conseilles?
http://www.steitec.net/ARM-Boards/ARM-STM32F103-Cortex-M3-Board.html
L'arm9 a aussi l'air excellent (avec windows/linux/android) :
http://cgi.ebay.fr/Mini2440-Development-Board-for-ARM9-ARM-S3C2440-Z-/160503696346
Ça a l'air vraiment pas mal, mais n'ayant jamais fait de systèmes embarqués, j'ai peur de mettre plusieurs semaines avant de réussir à exécuter une ligne de code. Ça serait aussi une manière d'apprendre (je suis en 4ème année d'école d'ingé électronique et systèmes embarqués et on a jamais réellement fait de développement embarqué, c'est fou quand même).
J'ai beaucoup de mal à imaginer comment ensuite intégrer la puce dans un montage perso, mais j'imagine que après avoir développé dessus je saurais de quoi j'aurais besoin.
La BeagleBoard est également assez impressionnante mais peut être un peu chère pour mon portefeuille actuellement.
Je vais continuer d'étudier les différentes possibilités avant de me décider. Merci pour les conseils en tout cas.
[ Dernière édition du message le 01/04/2011 à 08:01:23 ]
Anonyme
> http://www.steitec.net/ARM-Boards/ARM-STM32F103-Cortex-M3-Board.html
Oui, ce genre de cartes, même si je n'ai pas de modèle à recommander en particulier. Ça serait sympa d'en trouver une avec un bon DAC audio intégré (et peut être un slot de carte SD), auquel cas tu auras tout ce qu'il te fait.
> http://cgi.ebay.fr/Mini2440-Development-Board-for-ARM9-ARM-S3C2440-Z-/160503696346
C'est pas mal effectivement! Toute la machinerie de l'OS va manger du CPU, mais il vaut mieux avoir 75% d'un proc. à 400 MHz que 95% d'un processeur à 100 MHz. Et ça te permet de tourner avec des outils familiers ! Renseigne toi si il existe une communauté de dev active autour de cette carte, ça te permettra de trouver des tutoriels pour l'installation d'un linux et l'installation de gcc sur ta machine de dev pour cross-compiler le code...
C'est un bon intermédiaire entre une carte mère de PC embarqué (plus gourmande) et un STM32F ou LPC moins puissant...
L'inconvénient : il faut penser ensuite en termes de produit fini... Et ça rejoint ta question sur l'intégration dans un montage final. Une fois que tu auras développé ton synthé sur cette carte, avec une ou deux cartes séparées pour les contrôleurs et les sorties audio (tu vas pas utiliser le DAC pourri intégré), comment intégrer ça dans un produit fini ? Il est à parier que cette board vendue $80 n'en coûte pas la moitié à produire, et que la moitié des périphériques intégrés (vidéo...) ne te serviront pas. Il y a donc un intérêt à tout mettre, in fine, sur une seule carte, donc il faudra faire un "copier coller" du contenu de ta board de dev vers ta carte finale - en virant au passage tous les périphériques dont tu n'as pas besoin. Ça peut nécéssiter quelques mois de dev et deux ou trois itérations de prototypes - donc il faut peser les avantages de cette solution vs "je m'en tappe et je colle la board de dev dans mon produit". Je n'ai jamais regardé, mais j'imagine que dans un Korg Kronos la carte mère est une carte mère de PC standard, pas un truc custom routé par Korg... Mais si tu préfères la solution "je refais tout sur une carte", je ne sais pas si il y a des boards de dev comme ça qui sont open-source, se renseigner peut être sur le hardware de la console OpenPandora (tu pourras récupérer les fichier de la carte mère, virer le gras, et rajouter les périphériques nécessaires pour ton synthé...).
mosben
De mon côté je comptait faire un peu la même chose sur la carte snowball qu'on pourra acheter là:
https://shop.strato.com/epages/61428605.sf/fr_FR/?ObjectPath=/Shops/61428605/Products/905-00024-A11
Là c'est un vrai gros processeur (dual cortex A9) qui n'a rien à voir avec les petites bestioles genre costex M3 ou le arm926 de l'autre carte qui gère tout un ensemble multimédia. Vous me direz, que ça sert à rien d'avoir Android qui tourne avec des applis full HD et compagnie pour l'utilisation visée. En fait, je pense que c'est pas si mal, car ça permet une portabilité de l'applie logicielle développée, tout en offrant des possiblités ennorme en terme d'ihm que n'a pas une solution construite autour d'un STM32. Surtout que le delta de prix n'est pas si important que ça.
Un truc bien aussi c'est que tu peux commencer à programmer l'application avec le SDK android sans avoir la carte..... qui ne sera disponible que dans quelques mois, donc tu limites le risque, car si t'arrives pas à développer le soft avant, pas la peine d'acheter la carte.... car si t'as jamais programmé de microcontroleur, ou d'applications pour systèmes embarqués, c'est peut être une bonne idée de tester avant d'acheter, parce que certains n'aiment pas se prendre la tête à configurer les registres en permanence.
Enfin pour développer des cartes avec de gros micros (genre STM32), et parfois des FPGA et cie en loisir, crois moi que ça nécessite un savoir faire par forcément très complexe, mais qui va au delà de ce qu'on apprend en école d'ingé malheureusement.
Anonyme
Si tu compte créer ta propre carte, oublie direct si t'as pas de sérieuses compétences en électronique numérique, leur intégration à un projet est beaucoup plus délicate qu'un microcontrolleur classique tel qu'un pic ou un avr, du fait de leur hautes fréquences (1ghz ou +, 400mhz ou même 100mhz ca pose certaines contraintes lors de la conception de la carte et du routage).
Je connais pas les dspic, mais de ce que j'en ai vu ca a l'air très intéressant, notamment le synthé VA
qu'on peut entendre sur youtube. D'après ce que j'ai vu il y a des ensembles carte + compilateur (et bibliothèque qui vont avec) à des prix à peu près convenable pour l'amateur. Après, si tu veux créer un instrument novateur qui permet d'aller loin dans la bidouille, ils seront peut être un peu limite au niveau puissance.
Mais si tu préfères la solution "je refais tout sur une carte", je ne sais pas si il y a des boards de dev comme ça qui sont open-source, se renseigner peut être sur le hardware de la console OpenPandora (tu pourras récupérer les fichier de la carte mère, virer le gras, et rajouter les périphériques nécessaires pour ton synthé...).
Une association a développé une carte à base d'ARM9 (et avec un fpga à côté) à pas trop cher, j'avais regardé ca il y a quelques temps, il me semble que c'est ouvert et qu'il y a moyen d'avoir une option audio assez sérieuse avec. Ca peut effectivement faire une base de travail intéréssante http://www.armadeus.com/english/index.html
Mais, vu ce que tu veux faire, une solution à la hartmann neuron peut être sympa, un pc avec un linux customisé, une surface de contrôle dédiée à ton projet, et ton code dérrière. le tout dans un joli boitier.
[ Dernière édition du message le 02/04/2011 à 22:02:19 ]
nirv4nh4ck
Dîtes moi si je me trompe, mais si je décide de prendre un OS comme linux ou windows, tout est presque déjà fait. Dans ce cas là, c'est le système qui va lancer mon application, j'aurais donc moins de choses à gérer au niveau "ordonnancement". Je vais également pouvoir développer principalement sur ordi, avec Visual studio configuré pour CE par exemple si je choisi Windows. Idem pour linux.
C'est compliqué de configurer un système pour une application embarquée précise? (Je n'ai jamais compilé de linux ou quoi que ce soit, ni fait de vrai développement système).
Mosben, pour la question de puissance, j'ai beaucoup de mal à m'en rendre compte, puisque je n'ai jamais fait de tel projet. Mais je peux te dire que n'ayant programmé que deux PIC et un AVR, je peux te dire que autant le STM32 que l'ARM920T (max freq. 533 MHz) me font très peur. Je pense que c'est déjà très ambitieux par rapport à mes connaissances actuelles. Avec http://cgi.ebay.fr/Mini2440-Development-Board-for-ARM9-ARM-S3C2440-Z-/160503696346 je suis déjà bien au dessus de la majorité des synthé/sampleurs d'il y a quelques années non?
D'ailleurs je me demandais l'autre jour pourquoi on ne trouvais jamais de schéma de synthé numérique sur le net, ça serait bien utile pour se faire une idée.
Les pédales de gratte il y a les schémas partout, et tout le monde les copie, alors que les synthé, même s'ils étaient diffusés, personne pourrait les construire ^^.
J'ai démonté mon microwave xt, et il y a un DSP mc68331cfc20. J'imagine que c'est pareil pour les clavia, virus, etc.. Maintenant que les processeurs sont beaucoup plus puissants, qu'on a plus de RAM, etc, pourrais-je obtenir un son de qualité comparable, même si je n'ai pas de DSP?
Patrick truelle, je n'ai pas les compétences pour router une carte complexes, je n'ai fait que quelques routages PIC et complètement analogiques. Mais je me dis que si je prend un truc aussi puissant, et que je peux ajouter les périphériques qu'il me faut directement sur la carte de développement, je n'aurais pas besoin de faire ma propre carte avant d'avoir un truc "fini". Et quand j'aurais un truc fini, soit ça déchire, et dans ce cas je cherche quelqu'un pour me faire le routage (une boite, un associé?!), et je tente une industrialisation, soit c'est pas mal pour s'amuser, mais sans plus, et je ne diffuserai pas, et conserverai la carte de développement dans mon montage. Qu'en pensez-vous?
J'imagine que faire faire un routage coûte très cher, mais le montage final, il comportera un uC à 30€ max, un DAC, quelques composants... ça va pas monter très haut.
Bien que les dsPic ont l'air intéressants je me destine à faire du système embarqué plus tard, et les ARM sont vraiment partout dans ce domaine. Je pense qu'il faut que j'apprenne à m'en servir.
De plus, j'aimerais la possibilité de miniaturiser, donc le vrai pc embarqué me semble mal barré. Et puis d'ailleurs, quels seraient l'intérêt par rapport à un arm9 qui peut faire tourner des OS à part la puissance?
J'espère que ce message n'est pas trop imbuvable et que je ne raconte pas trop de bêtises, je répète que je suis presque un noob avec tout cela.
mosben
Anonyme
Ça veut dire que plutôt que de gérer tes I/O, tes périphériques, et l'ordonnancement des tâches via l'infrastructure générique fournie par un OS (avec une notion de processus/tâche, de périphérique, de drivers) tu fais tout avec du code maison - en choisissant toi même d'écrire tel ou tel bloc de code dans une interruption déclenchée par un timer ; et tel autre bloc de code dans une boucle qui tourne en fond ; en décidant si la communication avec tel ou tel périphérique se fera par polling ou par interruption, etc... Ça permet de tirer jusqu'à la dernière goutte de performances de ta plateforme, mais c'est fastidieux et il faut bien savoir ce qu'on fait. Donc non, tu ne codes pas l'OS, tu codes *sans* OS - ton programme manipule directement le hardware.
> Si je prend un truc sur lequel je peux installer un OS (que ce soit Android, Linux ou Windows), j'aurais donc déjà un RTOS
Un RTOS embarqué c'est beaucoup plus minimal qu'un Windows CE ou Android, ça permet de gérer l'éxécution de tâche concurrentes avec une notion de priorité + des primitives de communication et synchro entre tâches et puis basta. À la rigueur, peuvent venir se greffer par dessus des librairies pour gérer des périphériques mais c'est tout...
Un Windows CE ou Android, c'est un OS "lourd" + des tas de bibliothèques pour gérer l'accès aux périphériques + un framework de développement d'application, GUI, etc...
> notamment ajouter des drivers pour s'interfacer avec les codec et prises MIDI, et supprimer des choses inutiles. Mais sur les uC comme le STM32, il existe des RTOS tout fait? Ça correspond aux librairies et aux drivers?
Oui il existe par exemple FreeRTOS. Mais ça ne couvre que le côté "concurrence/multitâche", pas l'accès aux périphériques.
> Dîtes moi si je me trompe, mais si je décide de prendre un OS comme linux ou windows, tout est presque déjà fait. Dans ce cas là, c'est le système qui va lancer mon application, j'aurais donc moins de choses à gérer au niveau "ordonnancement". Je vais également pouvoir développer principalement sur ordi, avec Visual studio configuré pour CE par exemple si je choisi Windows. Idem pour linux.
Oui. D'ailleurs, tu devrais peut être essayer de réaliser tes idées d'algo de synthèses sous forme de plug-ins ou de constructions avec Reaktor/puredata avant même de penser les mettre sur des hardware? Cf l'interview de Roger Linn: http://createdigitalmusic.com/2011/01/how-to-get-poor-with-prototyping-advice-from-mpc-linndrum-adrenalinn-creator-roger-linn/
> C'est compliqué de configurer un système pour une application embarquée précise? (Je n'ai jamais compilé de linux ou quoi que ce soit, ni fait de vrai développement système).
Jamais fait ça sur un Linux embarqué...
> Mosben, pour la question de puissance, j'ai beaucoup de mal à m'en rendre compte, puisque je n'ai jamais fait de tel projet.
Pour te donner une idée, je codais sous PalmOS avec un Palm Tungsten (Un des tous premiers OMAP, 126 MHz) et je pouvais avoir 5/6 voies de polyphonie (deux oscillateurs suréchantillonés x4 + filtre Moog) à 44.1 kHz, sans trop me casser la tête au niveau du code (pas d'assembleur).
Par contre, les sampleurs d'il y a une dizaine d'années fonctionnaient tous avec des ASIC (par exemple le "G-chip" d'E-mu), donc on ne peut pas vraiment comparer.
> D'ailleurs je me demandais l'autre jour pourquoi on ne trouvais jamais de schéma de synthé numérique sur le net, ça serait bien utile pour se faire une idée.
Je vois deux raisons : 1/ l'intelligence est dans le code. Voir un DSP avec une mémoire et des DAC autour, ça ne veut pas dire grand chose. 2/ Les machines numériques se prêtent peu au DIY - chips custom introuvables, DSP/MCU obsolètes ou demandant des programmeurs spécialisés, et bien sûr chips dans des packages minuscules rendant difficile le bricolage.
> Maintenant que les processeurs sont beaucoup plus puissants, qu'on a plus de RAM, etc, pourrais-je obtenir un son de qualité comparable, même si je n'ai pas de DSP?
La RAM ne change pas grande chose, la synthèse ce n'est qu'une histoire de CPU. J'imagine que la plupart des VA d'il y a 5 ou 6 ans sont encore codés en fixed point. L'ARM se prête plutôt bien au fixed point parce qu'il dispose d'un barrel shifter, et qu'on peut appliquer des shifts aux opérandes d'une instruction. Si tu as un processeur récent, regarde s'il a une unité de calcul en virgule flottante. Sur les SoC à base d'ARM récents (OMAP4, NVidia Tegra) il y a même du SIMD (NEON) !
Ça sera probablement LA différence avec du développement sur Desktop... les plug-ins sur PC/Mac sont tous codés en virgule flottante (32 bits pour la majorité) ; sauf à avoir un ARM très récent, tu devras coder en fixed point.
> ... et conserverai la carte de développement dans mon montage. Qu'en pensez-vous?
Oui. Pour te donner un ordre d'idée "à la louche", jusqu'à 100 MHz on peut encore router à la bonne franquette. J'avais des camarades en école qui ont réalisé une carte pour un uC ARM (clocké à 72 MHz) pour un projet de robotique - c'était la première carte qu'ils faisaient, ils n'avait pas eu de cours spécialement là dessus, ils ont eu un truc qui marche sans problème.
> De plus, j'aimerais la possibilité de miniaturiser, donc le vrai pc embarqué me semble mal barré. Et puis d'ailleurs, quels seraient l'intérêt par rapport à un arm9 qui peut faire tourner des OS à part la puissance?
PC emabrqué : 0 efforts de développement, pas de casse tête de cross-compilation, accès à des tonnes de bibliothèques/bases de code/projets open source disponibles pour les archis x86 mais qui ne le sont pas pour ARM.
- < Liste des sujets
- Charte
- 1
- 2