Les écrans LCD ne fonctionnent pas de toutes manières en 60Hz ?
En tout cas, dans la doc du mien, c'est bien spécifié qu'il accepte du 75Hz, mais qu'il préfère du 60Hz.
Le prix, je connait bien sur les différence de prix entre la piece unique et l'industrielle et justement jen ai tenuie compte au moment de faire mes choix.
les choix technologiques permettent d'avoir un système qui coute tout de même tres peut cher à faire même en piece unique 50¤. - 70¤. Fabriqué de manière industrielle, il couterait effectivement beaucoup moins cher.
Ta license interdit de le produire en série. On trouve des cartes beaucoup plus puissantes (qui, elles, permettent d'en faire un petit ordinateur) pour moins cher. Ton but de faible coût n'est pas atteignable.
même chose ce que tu voit c'est une version que tout le monde peut faire simplement avec des composant que l'on trouve partout.
en utilisant des composant CMS.
la carte ne serait plus de 10 * 15 mais peut etre 3,4,5,6 fois plus petite.
Idem, ta license (NC) interdit à quiconque de modifer ton projet pour lke mettre en CMS sans ton accord. Et je ne suis pas sûr que tu donnerais ton accord pour ce genre de chose, vu que ça s'écarte de ton objectif d'avoir quelquechose de réalisable par n'importe qui.
Les peroformance sont revut en hausse de version en version et j'espère bien pouvoir continuer ce projet.
j'espre qu'il continurat et que d'autre version plus performante sortiront
Aucune version de 18F n'ayant plus de RAM ne sortira, parce que l'architecture ne le permet pas. Je t'invite à lire un datasheet de 18F (chapitre 4.9 "Data Memory Organisation") pour savoir pourquoi.
Il faudra donc changer de processeur, donc réécrire une bonne partie du code. Et apparamment, tu n'as pas l'air de te rendre compte que l'ère du DIP est terminée. Tous les nouveaux circuits ne sortent qu'en TQFP (CMS avec pattes sur le côté) ou BGA (billes sous le composant, quasiment insoudable à la main). Donc tu ne trouvras rien de plus rapide tout en étant soudable par un amateur.
si tu le trouve médiocre, insufisant et dépassé je ne t'oblige pas a l'aprécier.
Ce n'est pas le problème que je l'apprécie ou non. Tu remarqueras que je n'ai pas posté les critiques suite au thread http://linuxfr.org/2006/09/05/21278.html dans ton site. Ce que tu fais est un petit projet d'électronique sympa et qui peut apprendre des choses à des gens.
Le hic, c'est que tu le présentes comme un ordinateur/console de jeux, alors qu'un PIC ne pourra jamais faire un ordinateur. Et tu arrives à convaincre des gens qui ne connaissent rien aux µC. Les modéros de Linuxfr ont même accepté une dépêche en première page alors qu'il est évident que ce projet n'a aucune chance d'arriver à ses objectifs (cf les commentaires ici: soit des questions, soit des mise en doute des choix, pas un commentaire technique positif).
D'ailleurs, dès qu'on te pose des questions précises sur des problèmes de base que pose ton projet (cf: multiplication signée 16bits, adressage de la RAM,...), tu ne réponds pas, ou par des réponses qui prouvent que tu n'as pas bien lu le datasheet. Ta réponse la plus fréquente est "la technique évoluera", alors qu'elle a déjà évolué (cf: les exemples ARM7/9 ou AVR32), mais pas dans la direction nécessaire à ton projet.
Ton simulateur permet il de programmer en assembleur ? Permet il de programmer avec CC8E (espèce de C pas du tout ANSI, mais bien pratique pour optimiser sans passer par l'assembleur) ? Permet il de voir des bugs du compilo (multiplication signée sous C2C, certaines fonctions de bibliothèque de CCS,...) ? Si tu compiles avec Borland C++, GCC ou autre, les réponses sont évidemment non. Donc un programmeur va écrire ses programmes qui vont parfaitement tourner sur ton "simulateur", mais ils ne pourront jamais tourner sur ta carte s'ils sont trop gourmands.
Ce qui me gêne donc, c'est la publicité mensongère que tu fais (même c'est apparamment de l'ignorance, pas de la méchanceté). Cela risque d'attirer des gens qui vont s'investir pour faire des programmes non triviaux, et qui vont être déçus. Tu vas leur faire gâcher leur temps et éventuellement leur argent (acheter les composants, outils et instruments de mesure électroniques représente un investissement de départ non négligeable: plusieurs centaines d'euros).
Présenter ton projet plus modestement permettra aux gens que ça intéresse d'y participer (et non d'avoir l'impression d'avoir à faire à des rigolos qui ne se sont pas posé les questions de base), et aux autres d'éviter la déception et la frustration.
Ce qui me gêne dans ton projet, c'est que tu induis les gens en erreur. Sur 2 points essentiellement: sur la liberté, mais ça ne me gêne pas que tu publie une dépêche ici, la plupart des gens le savent et rectifient d'eux mêmes. Mais surtout sur les possibilités du 18F, et je n'aimerais pas être à la place des non électroniciens qui vont te croire et commencer à développer des softs pour finalement se rendre compte qu'ils ne pourront jamais les faire tourner sur un PIC.
Liberté:
La plupart des outils de développements sont proprios, alors qu'il existe des alternatives libres:
- Kicad ou gEDA, voire KTechLab,... pour la partie électronique, au lieu d'Orcad
- sdcc, Piklab pour la programmation du PIC, gpsim pour la simulation, au lieu de C18, DevCpp,...
Comme dit plus haut, il y a plus d'alternatives libres pour AVR que pour PIC. Et certains AVR sont disponibles en DIP: ATmega644 par exemple (20MIPS, 4Ko de RAM), donc parfaitement soudable.
Et ta licence est NC, comme citée plus haut, ce qui n'est pas libre. De plus, dans ton argumentaire "Pourquoi DOGS?" tu dis que tu veux faire une plate forme pas chère. La seule possibilité, c'est de la fabriquer en série (oui, une carte électronique fabriquée en série est moins cher que la faire soi même, à cause de la différence entre prix de gros et prix de détail des composants) Exemple: le projet "one laptop per child" :ordinateur complet pour 100¤ n'est possible que grâce à des capacités de fabrication industrielles. Il me semble que tu confonds gratuité et liberté; et si tu veux un système pas cher, entre le portable à 100¤ et les vieux PC/concoles de jeux reconverties, on trouve plus puissant pour moins cher que ton projet.
Puissance de calcul:
Comme cité plus haut, elle est ridicule. Si tu veux faire des calculs en 16 bits ou plus (autrement dit, faire de vrais calculs, pas de la gestion de mémoire ou de chaînes de caractères), on n'arrive pa du tou à 10MIPS. On est loin d'un µC à base d'ARM7: 50MIPS en 32 bits, et à un facteur de plusieurs 100aines par rapport à un VIA C3 de mini PC.
Ce qui est encore plus embêtant, c'est l'espace addressable: un 18F ne peut pas addresser plus de 4Ko.
Tu dis que tu veux en faire un ordinateur: comment comptes tu éditer un fichier ascii de 200 lignes de 25 caractères = 5Ko (fichier C courant) ?
J'espère que tu ne vas pas me parler de swap, parce qu'avec de la Flash, tu ne vas pas pouvoir swapper bien longtemps (100 000 écritures max)
Et je ne parle même pas d'éditer une image, ou d'éditer un fichier .odf. Quant à SDL et la 3D...
Donc:
- console de jeux: OK, si on prend des jeux de consoles des années 80
- base d'apprentissage: OK
- système nomade: non: tu pourras à la rigueur lire de la musique ou afficher des images (sous réserve qu'il ne faille pas bcp de RAM pour décompresser), mais rien d'autre. Et ta carte n'a pas la compacité d'un balladeur ou d'un téléphone portable.
- ordinateur: absolument pas
Ce serait bien que tu parles de ces limitations sur ton site, ça éviterait des méprises à des gens qui ne connaissent pas grand chose à l'électronique, et qui vont poser des question comme celle de Victor STINNER.
Pour voir les posters de l'année 2006, tu peux suivre le lien que j'ai donné plus haut, rubrique posters. Mais c'est vrai que pour atteindre cette page, il faut la chercher.
Gérer des puces qui communiquent à haute fréquence n'est pas facile du tout, et en général ces puces n'existent qu'en packages quasi impossible à souder sans materiel adéquat (et le coup de patte). C'est sûr que ce serait bien d'avoir ces designs à disposition, surtout pour l'industrie, mais la plupart des équipes à la coupe ne pourront pas les réaliser eux même: ils devront le sous traiter. Je ne suis pas sûr qu'on gagne vraiment en prix, et s'il y a un problème sur la carte, cela risque d'être délicat à réparer.
Si tu veux des cartes avec des processeurs assez puissants, il en existe à qqs 100aines d'¤. Par exemple les classiques EPIA, ou des cartes à base de Geode, ARM, Coldfire, Blackfin, ... ou même processeur+fpga. Il suffit de fouiner sur le Net. Et je pense que cette tendance aux cartes avec processeur 32 bits pour l'embarqué à prix raisonnable ne fait que commencer (et un PC embarqué ou un bon DSP permet de gérer la vision).
Il ne reste plus que l'interfaçage avec les capteurs et actionneurs, ou les montages plus spécialisés comme ton exemple, qui doivent être adaptés au cas par cas. Il pourrait effectivement y avoir une bibliothèque de montages classiques gérée par une communauté. Mais pour ces montages classiques, on peut trouver beaucoup de choses sur les datasheets et application notes des constructeurs; et pour les montages spéciaux... il sont spéciaux ;). Il faut trouver quelqu'un qui a eu le même problème et qui l'a résolu.
Une standardisation des solutions est souhaitable du point de vue des performances des robots (et arrivera plus ou moins à terme, vu que les µC standard pourront petit à petit gérer pratiquement tout), et utiliser des protocoles et schémas bien pensés permet de passer à côté de plein d'erreurs potentielles (et très chiantes). Mais je pense que l'esprit de la coupe est d'apprendre en s'amusant, et en comprenant ce qu'on fait plutôt que savoir intégrer des solutions toutes faites (même si les 2 ne sont pas incompatibles), ou de gagner la coupe. Donc l'idéal est d'expliquer ce que l'on fait, comment on le fait, mais pas de donner des schémas "sur étagère": exactement ce que font les contributeurs du forum.
Un autre problème avec l'électronique, qui est moins prononcé en informatique (si on écrit des programmes portables), c'est l'obsolescence des composants, et leur disponibilité chez les revendeurs. Si tu changes un composant sur une carte, il faut que tu fasses attention à ce que tu fais (sauf s'il est clairement compatible pin à pin). Il faut avoir les compétences pour le faire. Je dirais que ça reviendrait en informatique à modifier le code, pas seulement changer la configuration. Donc une base de donnée de cartes utilisant des composants exotiques n'a de valeur que pour des gens capables de le comprendre et de faire les bidouilles éventuelles nécessaires.
Par exemple, la carte bilda pour gérer des lasers sous Linux ( http://www.linux-laser.org/ ) utilise un µC qui se programme directement par USB, mais qui est considéré comme obsolète par le fabricant, et qui risque de disparaître d'ici qqs années. Il faudra modifier la carte en conséquence avec un nouveau µC.
Quant aux composants classiques, celui qui ne sait pas l'utiliser peut regarder sur le Net, ou poser une question sur le forum de PlaSci ou autre site électronique.
Transposer l'Open source au sens strict à l'électronique (hors schémas pour FPGA/ASIC) n'est donc pas aussi simple que cela. Et autant Eurobot permet de former des gens ouverts au Libre, autant je ne pense pas que ce soit là qu'on crée ou qu'on impose des standards ou des designs Open source.
Cela fait déjà 2 ans que chaque équipe doit réaliser un poster et l'afficher sur son stand, en plus de le donner sous forme électronique à l'organisation. De plus, il y a beaucoup d'échanges de tous niveaux techniques sur le forum de Planète Science. La diffusion des connaissances est donc déjà bien en place, avec des bénévoles qui aident ceux qui ont le courage de tenter l'aventure seul, ou qui bricolent des trucs mécano-électroniques.
Le principe de l'Open Source s'applique de la même manière (voire mieux) à l'électronique qu'à la mécanique: on peut diffuser les schémas et typons sous licence libre. Cela permet de réaliser soi même ses cartes et les modifier, et apprendre plein d'astuces en étudiant les schémas d'autres personnes. Bref, beaucoup de ce que procure le libre pour les logiciels. Par contre, effectivement, à l'instar de la mécanique, il faut mettre les mains dans le cambouis pour faire une carte soi même. Et il faut avoir le matériel adéquat, même si un fer à souder, insoleuse et graveuse prennent moins de place qu'un tour et une fraiseuse (si si, il y en a qui ont ces bêtes là chez eux :) ). Et pour faire cela à grande échelle et à moindre coût, il faut des moyens industriels, on ne peut pas directement télécharger la carte ou le système mécanique.
Ceci dit, Eurobot n'a pas pour vocation de créer ou d'imposer des standards libres, il a une vocation éducative (et ludique :) ). Les Gourous (sur le forum de Planète Science, par exemple) préfèrent montrer la Voie à leurs Disciples: leur expliquer ce qu'il faut faire et pourquoi il vaut mieux le faire de telle manière. Ils rechignent à donner des solutions clés en main. De ce point de vue, cela s'écarte du logiciel libre. Et aussi, vu que les robots (et les systèmes embarqués en général) n'ont pas vocation de communiquer entre eux, chacun fait un peu ce qu'il veut. Dans la coupe, on reprend en général les standards des anciens du club.
Pour les curieux, il y a possibilité de venir à la Ferté Bernard pendant la coupe (en mai) voir les matchs et les robots dans les stands, discuter avec les équipes,... Il y a aussi chaque année une conférence le jeudi ou vendredi soir. L'année dernière, le sujet était plusieurs robots contrôlés par réseaux neuronaux qui apprenaient ensemble, suivant un algorithme évolutionnaire (mais le tout présenté très simplement, rassurez vous ).
Juste par curiosité: pourquoi autant de machines ?
A ma connaissance, la plupart des fermes de calcul (dans les entreprises pas trop grosses en tout cas) ne sont pas constituées de beaucoup plus de processeurs.
Tu cherches savoir mettre ce genre de chose en place, ou comparer les perfs des différentes solutions ?
Posté par Vinbre .
En réponse au message gcc et cc.
Évalué à 1.
Heu... Je ne l'ai jamais fait.
Je pense qu'il faut choisir le bon paquet (lis bien les descriptifs) et vérifier que LIRC va chercher le fichier de configuration qui correspond aux options avec lesquelles le noyau a été compilé (présent dans /boot ) au bon endroit, ou alors copier ce fichier à l'endroit attendu par LIRC.
Posté par Vinbre .
En réponse au message gcc et cc.
Évalué à 1.
Par défaut, il est imposible de compiler sous Ubuntu (enfin, pas essayé sur la nouvelle versoin).
Pour cela, il faut installer le paquet "build-essential" ( sudo apt-get install build-essential )
Oui, c'est une spécificité d'Ubuntu dont on se passerait bien, surout qu'il faut chercher longtemps avant de trouver la solution.
Après, il te manquera peut être d'autres paquets.
Si tu veux connaitre les appels systèmes propres à Linux et à la libc, je te recommandes "Programmation système en C sous Linux" de Cristophe Blaess.
Il y a vraiment tout, sauf ce qui concerne X et c'est très bien expliqué. Par contre, c'est du C pur (mais bon, cela reste tout à fait utilisable en C++)
Quant à utiliser les APIs de X, à ce que j'en sais, plus personne ne le fait, sauf cas spécifiques. Si ton appli est déjà écrite en Qt, tu n'aura de toutes manières pas besoin de retoucher à la couche graphique.
Si c'est pour le plaisir de comprendre X, je laisse des experts te donner une bonne référence.
Par contre, si tu veux "parler" Linux (et Unix), tu peux aussi t'interesser au shell: c'est la base de l'administration système, ça te permettra de comprendre commentles admins Unix raisonnent. Il y a plein de bons tutos Bash sur le Net.
Comme dit précédemment, on peut trouver des AVR très facilement en france. En cherchant un peu, il doit être possible de rouver certaines références d'ARM ou coldfire (ou autres µC 32 bits bien supportées par gcc). Parmi les distributeurs connus, on a par exemple radiospares, farnell, digikey,...
La puissance pure du µC et sa quantité de mémoire conditionnent le type de jeu que l'on peut faire tourner dessus (et sa qualité graphique). Je doute que l'on puisse faire tourner d'autres jeux que ceux des années 80 sur un PIC. Si tu arrives à me prouver le contraire, je te tire mon chapeau.
Le 18f n'a pas de multiplicateur 16 bits intégré, seul 8 bits * 8 bits, et encore, non signé.
Le propre des µC, c'est d'être spécifique (et, dans une moindre mesure, le compilo C aussi), en tout cas, famille par famille. Si vous changez de composant en cours de route, il faudra réécrire les portions de code qui correspondent au bas niveau pour la nouvelle puce. Je doute que vous y gagniez en temps de développement.
Au niveau materiel, vous êtes loin de concurrencer les consoles, les PDA actuels ou les petits ordinateurs embarqués (dont les prix chutent rapidement). Et au niveau logiciel, les gens qui veulent coder de petits jeux peuvent le faire sur une vieille console ou un vieux PC, ou encore une calculette programmable pendant les cours chiants leur temps libre. Un PIC n'a pas la puissance nécessaire pour faire tourner un traitement de texte, un navigateur web, un player mp3, ou un jeu un peu évolué.
C'est un très beau projet, vous vous amuserez et apprendrez sûrement beaucoup (et je repiquerai peut être qqs idées ;) ), mais ne pensez pas révolutionner le monde, comme le laisse à penser votre site.
On est d'accord sur la distinction entre microcontroleur et microprocesseur. Je suis tout à fait d'accord avec toi que concevoir une carte à base de microprocesseur avec mémoire externe et tout le tralala est non seulement plus chère qu'un microcontroleur, mais surtout difficile à concevoir par l'amateur (pour des vitesses de bus élevées, tout au moins).
Mais il existe maintenant des microcontroleurs à base d'ARM (va voir chez Atmel ou Philips (qui a fait un buzz par ses µC ARM à 2$), par exemple, mais beaucoup de constructeurs en font). Le seul bémol est qu'ils n'existent qu'en boitier TQFP ou similaire, (ou BGA pour les masos) dont il faut soigneusement vérifier l'écartement des pattes si on veut pouvoir le souder à la main: 0.8mm, c'est soudable; moins, il faut que la carte soit vernie pour éviter les ponts de soudure, ce qui signifie carte gravée industriellement. Mais ça n'est pas si cher que ça, même pour des protoypes.
Quant au 8 bits vs 32 bits et nombre d'instructions par cycle d'horloge, il faut aussi voir la puissance du jeu d'instruction.
Il faut 40 cycles pour faire un multiplication 16 bits signé *16 bits signé sur un PIC. Je ne parle même pas de la division, qu'il faut faire à la main: décalages et soustractions. Et les PICs ne permettent pas d'adresser rapidement beaucoup de mémoire: il faut changer de banque en permanence. Si tu veux gérer beaucoup de RAM (>256 octets sur la plupart des 8bits, ou plutôt 368 sur 18F), un processeur (dans le sens d'architecture) 16 ou 32 bits est beaucoup plus confortable et permet de perdre moins de temps.
Si tu veux rester dans des boitiers DIP, pourquoi ne pas avoir pris des ATmega (Atmel), qui sont légèrement plus rapides, ou des 30F (programmés avec WinPic), qui sont carrément des DSP 16 bits ?
[^] # Re: Je ne crois pas
Posté par Vinbre . En réponse au message Utilisateurs, levez-vous !!!. Évalué à 1.
En tout cas, dans la doc du mien, c'est bien spécifié qu'il accepte du 75Hz, mais qu'il préfère du 60Hz.
[^] # Re: Pauvres visiteurs...
Posté par Vinbre . En réponse à la dépêche projet Dogs : ordinateur - console de jeux libre. Évalué à 8.
Ta license interdit de le produire en série. On trouve des cartes beaucoup plus puissantes (qui, elles, permettent d'en faire un petit ordinateur) pour moins cher. Ton but de faible coût n'est pas atteignable.
Idem, ta license (NC) interdit à quiconque de modifer ton projet pour lke mettre en CMS sans ton accord. Et je ne suis pas sûr que tu donnerais ton accord pour ce genre de chose, vu que ça s'écarte de ton objectif d'avoir quelquechose de réalisable par n'importe qui.
Aucune version de 18F n'ayant plus de RAM ne sortira, parce que l'architecture ne le permet pas. Je t'invite à lire un datasheet de 18F (chapitre 4.9 "Data Memory Organisation") pour savoir pourquoi.
Il faudra donc changer de processeur, donc réécrire une bonne partie du code. Et apparamment, tu n'as pas l'air de te rendre compte que l'ère du DIP est terminée. Tous les nouveaux circuits ne sortent qu'en TQFP (CMS avec pattes sur le côté) ou BGA (billes sous le composant, quasiment insoudable à la main). Donc tu ne trouvras rien de plus rapide tout en étant soudable par un amateur.
Ce n'est pas le problème que je l'apprécie ou non. Tu remarqueras que je n'ai pas posté les critiques suite au thread http://linuxfr.org/2006/09/05/21278.html dans ton site. Ce que tu fais est un petit projet d'électronique sympa et qui peut apprendre des choses à des gens.
Le hic, c'est que tu le présentes comme un ordinateur/console de jeux, alors qu'un PIC ne pourra jamais faire un ordinateur. Et tu arrives à convaincre des gens qui ne connaissent rien aux µC. Les modéros de Linuxfr ont même accepté une dépêche en première page alors qu'il est évident que ce projet n'a aucune chance d'arriver à ses objectifs (cf les commentaires ici: soit des questions, soit des mise en doute des choix, pas un commentaire technique positif).
D'ailleurs, dès qu'on te pose des questions précises sur des problèmes de base que pose ton projet (cf: multiplication signée 16bits, adressage de la RAM,...), tu ne réponds pas, ou par des réponses qui prouvent que tu n'as pas bien lu le datasheet. Ta réponse la plus fréquente est "la technique évoluera", alors qu'elle a déjà évolué (cf: les exemples ARM7/9 ou AVR32), mais pas dans la direction nécessaire à ton projet.
Ton simulateur permet il de programmer en assembleur ? Permet il de programmer avec CC8E (espèce de C pas du tout ANSI, mais bien pratique pour optimiser sans passer par l'assembleur) ? Permet il de voir des bugs du compilo (multiplication signée sous C2C, certaines fonctions de bibliothèque de CCS,...) ? Si tu compiles avec Borland C++, GCC ou autre, les réponses sont évidemment non. Donc un programmeur va écrire ses programmes qui vont parfaitement tourner sur ton "simulateur", mais ils ne pourront jamais tourner sur ta carte s'ils sont trop gourmands.
Ce qui me gêne donc, c'est la publicité mensongère que tu fais (même c'est apparamment de l'ignorance, pas de la méchanceté). Cela risque d'attirer des gens qui vont s'investir pour faire des programmes non triviaux, et qui vont être déçus. Tu vas leur faire gâcher leur temps et éventuellement leur argent (acheter les composants, outils et instruments de mesure électroniques représente un investissement de départ non négligeable: plusieurs centaines d'euros).
Présenter ton projet plus modestement permettra aux gens que ça intéresse d'y participer (et non d'avoir l'impression d'avoir à faire à des rigolos qui ne se sont pas posé les questions de base), et aux autres d'éviter la déception et la frustration.
# Pauvres visiteurs...
Posté par Vinbre . En réponse à la dépêche projet Dogs : ordinateur - console de jeux libre. Évalué à 10.
Liberté:
La plupart des outils de développements sont proprios, alors qu'il existe des alternatives libres:
- Kicad ou gEDA, voire KTechLab,... pour la partie électronique, au lieu d'Orcad
- sdcc, Piklab pour la programmation du PIC, gpsim pour la simulation, au lieu de C18, DevCpp,...
Comme dit plus haut, il y a plus d'alternatives libres pour AVR que pour PIC. Et certains AVR sont disponibles en DIP: ATmega644 par exemple (20MIPS, 4Ko de RAM), donc parfaitement soudable.
Et ta licence est NC, comme citée plus haut, ce qui n'est pas libre. De plus, dans ton argumentaire "Pourquoi DOGS?" tu dis que tu veux faire une plate forme pas chère. La seule possibilité, c'est de la fabriquer en série (oui, une carte électronique fabriquée en série est moins cher que la faire soi même, à cause de la différence entre prix de gros et prix de détail des composants) Exemple: le projet "one laptop per child" :ordinateur complet pour 100¤ n'est possible que grâce à des capacités de fabrication industrielles. Il me semble que tu confonds gratuité et liberté; et si tu veux un système pas cher, entre le portable à 100¤ et les vieux PC/concoles de jeux reconverties, on trouve plus puissant pour moins cher que ton projet.
Puissance de calcul:
Comme cité plus haut, elle est ridicule. Si tu veux faire des calculs en 16 bits ou plus (autrement dit, faire de vrais calculs, pas de la gestion de mémoire ou de chaînes de caractères), on n'arrive pa du tou à 10MIPS. On est loin d'un µC à base d'ARM7: 50MIPS en 32 bits, et à un facteur de plusieurs 100aines par rapport à un VIA C3 de mini PC.
Ce qui est encore plus embêtant, c'est l'espace addressable: un 18F ne peut pas addresser plus de 4Ko.
Tu dis que tu veux en faire un ordinateur: comment comptes tu éditer un fichier ascii de 200 lignes de 25 caractères = 5Ko (fichier C courant) ?
J'espère que tu ne vas pas me parler de swap, parce qu'avec de la Flash, tu ne vas pas pouvoir swapper bien longtemps (100 000 écritures max)
Et je ne parle même pas d'éditer une image, ou d'éditer un fichier .odf. Quant à SDL et la 3D...
Donc:
- console de jeux: OK, si on prend des jeux de consoles des années 80
- base d'apprentissage: OK
- système nomade: non: tu pourras à la rigueur lire de la musique ou afficher des images (sous réserve qu'il ne faille pas bcp de RAM pour décompresser), mais rien d'autre. Et ta carte n'a pas la compacité d'un balladeur ou d'un téléphone portable.
- ordinateur: absolument pas
Ce serait bien que tu parles de ces limitations sur ton site, ça éviterait des méprises à des gens qui ne connaissent pas grand chose à l'électronique, et qui vont poser des question comme celle de Victor STINNER.
[^] # Re: Question que tout le monde se pose:
Posté par Vinbre . En réponse à la dépêche Sortie de la solution Os-Café 0.9. Évalué à 4.
Heureusement que ça tourne sur PC et pas sur Nes.
------->[]
# BIOS
Posté par Vinbre . En réponse au message Mandriva. Évalué à 1.
# svn:ignore ?
Posté par Vinbre . En réponse au message Dé-versionner un fichier sous SVN. Évalué à 2.
Je ne sais pas si cela marche. Ca a l'air d'être prévu pour ignorer les fichiers qui ne sont pas gérés par svn dès le départ.
[^] # Re: Petites précisions
Posté par Vinbre . En réponse à la dépêche Coupe de France et d'Europe de Robotique 2007. Évalué à 2.
Gérer des puces qui communiquent à haute fréquence n'est pas facile du tout, et en général ces puces n'existent qu'en packages quasi impossible à souder sans materiel adéquat (et le coup de patte). C'est sûr que ce serait bien d'avoir ces designs à disposition, surtout pour l'industrie, mais la plupart des équipes à la coupe ne pourront pas les réaliser eux même: ils devront le sous traiter. Je ne suis pas sûr qu'on gagne vraiment en prix, et s'il y a un problème sur la carte, cela risque d'être délicat à réparer.
Si tu veux des cartes avec des processeurs assez puissants, il en existe à qqs 100aines d'¤. Par exemple les classiques EPIA, ou des cartes à base de Geode, ARM, Coldfire, Blackfin, ... ou même processeur+fpga. Il suffit de fouiner sur le Net. Et je pense que cette tendance aux cartes avec processeur 32 bits pour l'embarqué à prix raisonnable ne fait que commencer (et un PC embarqué ou un bon DSP permet de gérer la vision).
Il ne reste plus que l'interfaçage avec les capteurs et actionneurs, ou les montages plus spécialisés comme ton exemple, qui doivent être adaptés au cas par cas. Il pourrait effectivement y avoir une bibliothèque de montages classiques gérée par une communauté. Mais pour ces montages classiques, on peut trouver beaucoup de choses sur les datasheets et application notes des constructeurs; et pour les montages spéciaux... il sont spéciaux ;). Il faut trouver quelqu'un qui a eu le même problème et qui l'a résolu.
Une standardisation des solutions est souhaitable du point de vue des performances des robots (et arrivera plus ou moins à terme, vu que les µC standard pourront petit à petit gérer pratiquement tout), et utiliser des protocoles et schémas bien pensés permet de passer à côté de plein d'erreurs potentielles (et très chiantes). Mais je pense que l'esprit de la coupe est d'apprendre en s'amusant, et en comprenant ce qu'on fait plutôt que savoir intégrer des solutions toutes faites (même si les 2 ne sont pas incompatibles), ou de gagner la coupe. Donc l'idéal est d'expliquer ce que l'on fait, comment on le fait, mais pas de donner des schémas "sur étagère": exactement ce que font les contributeurs du forum.
Un autre problème avec l'électronique, qui est moins prononcé en informatique (si on écrit des programmes portables), c'est l'obsolescence des composants, et leur disponibilité chez les revendeurs. Si tu changes un composant sur une carte, il faut que tu fasses attention à ce que tu fais (sauf s'il est clairement compatible pin à pin). Il faut avoir les compétences pour le faire. Je dirais que ça reviendrait en informatique à modifier le code, pas seulement changer la configuration. Donc une base de donnée de cartes utilisant des composants exotiques n'a de valeur que pour des gens capables de le comprendre et de faire les bidouilles éventuelles nécessaires.
Par exemple, la carte bilda pour gérer des lasers sous Linux ( http://www.linux-laser.org/ ) utilise un µC qui se programme directement par USB, mais qui est considéré comme obsolète par le fabricant, et qui risque de disparaître d'ici qqs années. Il faudra modifier la carte en conséquence avec un nouveau µC.
Quant aux composants classiques, celui qui ne sait pas l'utiliser peut regarder sur le Net, ou poser une question sur le forum de PlaSci ou autre site électronique.
Transposer l'Open source au sens strict à l'électronique (hors schémas pour FPGA/ASIC) n'est donc pas aussi simple que cela. Et autant Eurobot permet de former des gens ouverts au Libre, autant je ne pense pas que ce soit là qu'on crée ou qu'on impose des standards ou des designs Open source.
# Petites précisions
Posté par Vinbre . En réponse à la dépêche Coupe de France et d'Europe de Robotique 2007. Évalué à 9.
Le principe de l'Open Source s'applique de la même manière (voire mieux) à l'électronique qu'à la mécanique: on peut diffuser les schémas et typons sous licence libre. Cela permet de réaliser soi même ses cartes et les modifier, et apprendre plein d'astuces en étudiant les schémas d'autres personnes. Bref, beaucoup de ce que procure le libre pour les logiciels. Par contre, effectivement, à l'instar de la mécanique, il faut mettre les mains dans le cambouis pour faire une carte soi même. Et il faut avoir le matériel adéquat, même si un fer à souder, insoleuse et graveuse prennent moins de place qu'un tour et une fraiseuse (si si, il y en a qui ont ces bêtes là chez eux :) ). Et pour faire cela à grande échelle et à moindre coût, il faut des moyens industriels, on ne peut pas directement télécharger la carte ou le système mécanique.
Ceci dit, Eurobot n'a pas pour vocation de créer ou d'imposer des standards libres, il a une vocation éducative (et ludique :) ). Les Gourous (sur le forum de Planète Science, par exemple) préfèrent montrer la Voie à leurs Disciples: leur expliquer ce qu'il faut faire et pourquoi il vaut mieux le faire de telle manière. Ils rechignent à donner des solutions clés en main. De ce point de vue, cela s'écarte du logiciel libre. Et aussi, vu que les robots (et les systèmes embarqués en général) n'ont pas vocation de communiquer entre eux, chacun fait un peu ce qu'il veut. Dans la coupe, on reprend en général les standards des anciens du club.
Pour les curieux, il y a possibilité de venir à la Ferté Bernard pendant la coupe (en mai) voir les matchs et les robots dans les stands, discuter avec les équipes,... Il y a aussi chaque année une conférence le jeudi ou vendredi soir. L'année dernière, le sujet était plusieurs robots contrôlés par réseaux neuronaux qui apprenaient ensemble, suivant un algorithme évolutionnaire (mais le tout présenté très simplement, rassurez vous ).
Ceux qui veulent connaitre l'ambiance de la coupe peuvent aller voir les photos et vidéos ici: http://www.planete-sciences.org/robot/coupe2006/
Merci à Christian pour cette dépêche et merci aux bénévoles de PlaSci.
# Pourquoi 100 pièces ?
Posté par Vinbre . En réponse au message Ordinateur portable ... en vente publique.. Évalué à 1.
A ma connaissance, la plupart des fermes de calcul (dans les entreprises pas trop grosses en tout cas) ne sont pas constituées de beaucoup plus de processeurs.
Tu cherches savoir mettre ce genre de chose en place, ou comparer les perfs des différentes solutions ?
[^] # Re: build-essential
Posté par Vinbre . En réponse au message gcc et cc. Évalué à 1.
Je pense qu'il faut choisir le bon paquet (lis bien les descriptifs) et vérifier que LIRC va chercher le fichier de configuration qui correspond aux options avec lesquelles le noyau a été compilé (présent dans /boot ) au bon endroit, ou alors copier ce fichier à l'endroit attendu par LIRC.
# build-essential
Posté par Vinbre . En réponse au message gcc et cc. Évalué à 1.
Pour cela, il faut installer le paquet "build-essential" ( sudo apt-get install build-essential )
Oui, c'est une spécificité d'Ubuntu dont on se passerait bien, surout qu'il faut chercher longtemps avant de trouver la solution.
Après, il te manquera peut être d'autres paquets.
# Appels systèmes et libc
Posté par Vinbre . En réponse au message Livres d'apprentissages pour développeur. Évalué à 2.
Il y a vraiment tout, sauf ce qui concerne X et c'est très bien expliqué. Par contre, c'est du C pur (mais bon, cela reste tout à fait utilisable en C++)
Quant à utiliser les APIs de X, à ce que j'en sais, plus personne ne le fait, sauf cas spécifiques. Si ton appli est déjà écrite en Qt, tu n'aura de toutes manières pas besoin de retoucher à la couche graphique.
Si c'est pour le plaisir de comprendre X, je laisse des experts te donner une bonne référence.
Par contre, si tu veux "parler" Linux (et Unix), tu peux aussi t'interesser au shell: c'est la base de l'administration système, ça te permettra de comprendre commentles admins Unix raisonnent. Il y a plein de bons tutos Bash sur le Net.
[^] # Re: Console de jeu alternative
Posté par Vinbre . En réponse à la dépêche Le succès du libre est-il transposable au jeu vidéo?. Évalué à 1.
La puissance pure du µC et sa quantité de mémoire conditionnent le type de jeu que l'on peut faire tourner dessus (et sa qualité graphique). Je doute que l'on puisse faire tourner d'autres jeux que ceux des années 80 sur un PIC. Si tu arrives à me prouver le contraire, je te tire mon chapeau.
Le 18f n'a pas de multiplicateur 16 bits intégré, seul 8 bits * 8 bits, et encore, non signé.
Le propre des µC, c'est d'être spécifique (et, dans une moindre mesure, le compilo C aussi), en tout cas, famille par famille. Si vous changez de composant en cours de route, il faudra réécrire les portions de code qui correspondent au bas niveau pour la nouvelle puce. Je doute que vous y gagniez en temps de développement.
Au niveau materiel, vous êtes loin de concurrencer les consoles, les PDA actuels ou les petits ordinateurs embarqués (dont les prix chutent rapidement). Et au niveau logiciel, les gens qui veulent coder de petits jeux peuvent le faire sur une vieille console ou un vieux PC, ou encore une calculette programmable pendant les cours chiants leur temps libre. Un PIC n'a pas la puissance nécessaire pour faire tourner un traitement de texte, un navigateur web, un player mp3, ou un jeu un peu évolué.
C'est un très beau projet, vous vous amuserez et apprendrez sûrement beaucoup (et je repiquerai peut être qqs idées ;) ), mais ne pensez pas révolutionner le monde, comme le laisse à penser votre site.
[^] # Re: Console de jeu alternative
Posté par Vinbre . En réponse à la dépêche Le succès du libre est-il transposable au jeu vidéo?. Évalué à 3.
Mais il existe maintenant des microcontroleurs à base d'ARM (va voir chez Atmel ou Philips (qui a fait un buzz par ses µC ARM à 2$), par exemple, mais beaucoup de constructeurs en font). Le seul bémol est qu'ils n'existent qu'en boitier TQFP ou similaire, (ou BGA pour les masos) dont il faut soigneusement vérifier l'écartement des pattes si on veut pouvoir le souder à la main: 0.8mm, c'est soudable; moins, il faut que la carte soit vernie pour éviter les ponts de soudure, ce qui signifie carte gravée industriellement. Mais ça n'est pas si cher que ça, même pour des protoypes.
Quant au 8 bits vs 32 bits et nombre d'instructions par cycle d'horloge, il faut aussi voir la puissance du jeu d'instruction.
Il faut 40 cycles pour faire un multiplication 16 bits signé *16 bits signé sur un PIC. Je ne parle même pas de la division, qu'il faut faire à la main: décalages et soustractions. Et les PICs ne permettent pas d'adresser rapidement beaucoup de mémoire: il faut changer de banque en permanence. Si tu veux gérer beaucoup de RAM (>256 octets sur la plupart des 8bits, ou plutôt 368 sur 18F), un processeur (dans le sens d'architecture) 16 ou 32 bits est beaucoup plus confortable et permet de perdre moins de temps.
Si tu veux rester dans des boitiers DIP, pourquoi ne pas avoir pris des ATmega (Atmel), qui sont légèrement plus rapides, ou des 30F (programmés avec WinPic), qui sont carrément des DSP 16 bits ?
[^] # Re: Console de jeu alternative
Posté par Vinbre . En réponse à la dépêche Le succès du libre est-il transposable au jeu vidéo?. Évalué à 2.
Le PIC 18f est un microcontroleur 8 bits. Il n'a même pas la puissance d'un processeur 68000 (amiga, atari ST, calculette TI89,...)
Si on veut faire une console de jeux, il vaut effectivement mieux partir sur un processeur 32 bits, comme ARM par exemple.