Voir la version complète : communication Ethernet
Bonjour,
Je recherche µC pour faire une communication Ethernet.
Il me faut :
- un port MAC Ethernet MII ou RMII
- Mémoires intégrées : ROM (j'ai besoin 125Ko juste pour les pages web) et RAM (j'ai besoin de 30Ko juste pour stocker mes données)
- assez puissant pour gérer les communications cryptées type SNMP V3 ou HTTPS (je ne vaux pas que ça mette dix ans à afficher mes pages web)
- 4 entrées analogiques avec un convertisseurs A/N
- temps de boot faible
- faible encombrement
- prix entre 10/15 euros par faibles quantités
=> après quelques recherches, il semblerait que le AT91SAM7XC512 puisse subvenir à mes besoins.
Pour l'instant, je n'ai travaillé que sur des PIC : je ne connais donc pas les outils qu'il faut utiliser (IDE, bibliothèques, programmateurs...)
=> que me faut-il pour débuter (qu'est-ce qui est payant ? cbt ?) ?
=> quelle bibliothèque pour la gestion du flux Ethernet dois-je utiliser (j'ai besoin des protocoles suivants : HTTPS, SNMP V3, DHCP, ICMP, SMTP, SNTP, DNS, FTP, TELNET) ? Est-ce qu'elle va rentrer dans ce composant ?
Si vous connaissez un autre composant plus adapté, je suis preneur...
C'est de l'arm7, donc des tonnes d'outils dispo gratuitement... Cependant pour la mise au point il est vivement conseillé de partir sur un reference design (kit) avec un chip identique, ou similaire.
tu devrais trouver ton bonheur ici : http://www.lextronic.fr/P1695-platine-sam7-sam7-ex256.html
Investissement initial de 116€, mais qui te pemrettra de baser des cartes sur le ref design (schéma fourni)
Tu as ça également : http://www.pragmatec.net/catalog/index.php?cPath=28
Ensuite, tu as tout intérêt à partir sur un OS linux, pour lequel tu auras toutes les librairies, les drivers et les outils dont tu as besoin...
Le principe de développement, tu as un environnement de développement (IDE, ou autre), qui te permet de tout compiler, et de créer une distrib' (contenu de la flash) que tu iras copier ensuite sur la flash. Il te restera plus qu'à booter pour tester... Une fois bootée ta carte sera accessible par telnet pour debugger...
a plus
Merci, la carte d'eval a 116€ sera parfaite pour faire des tests.
Par contre dans la jungle des OS et des libraries Ethernet, il faut prendre quoi exactement ? je suppose qu'il existe plusieurs versions de linux et pour les libraries ethernet, je ne sais pas quoi prendre...
Niveau soft, ce que je recherche, c'est :
- stable
- consommation des ressources minimes
- bonne documentation
- un forum actif pour demander de l'aide en cas de besoin
- mis à jour régulières
J'ai besoin d'un temps de boot court (inférieur à 5 sec) : le fait de mettre un OS comme linux ne risque t-il pas de faire dépasser ce temps ? de plus est-ce que ça ne va pas consommer des ressources inutilement ? ... n'existe t-il pas des OS plus light qui seraient plus adaptés (j'ai vu qu'il y avait l'OS freeRTOS qui à l'air d'être pas mal) ?
Je peux bien faire le programme/compiler/programmer l'arm7 avec un OS linux à partir de windaube (le tout avec des outils gratuits) ?
Tout ce que je demande de faire peut-il tenir dans 512Ko de ROM et 128Ko de RAM (sachant que j'ai besoin de 125Ko de ROM pour mes pages web et 30Ko de RAM pour le stockage de donnéées) ? a votre avis qu'elle place va prendre l'OS + les libraries Ethernet ?
L'avantage de linux, c'est que tu peux tailler ta distrib' sur mesure, et surtout bénéficier des drivers/librairies existants, dans ce cas opte pour la carte pragmatec(par exemple).
Si tu veux partir sur rtos plus léger, ça posera pas de problème, à condition d'utiliser la carte lextronic, parce que visiblement ils fournisent une appli tcp/ip. Ensuite il faut surtout vérifier que tu puisses trouver toutes les librairies dont tu as besoin sousrtos : (ssl pour https, ftp, dhcp telnet, ...). Et la, je pense que 512K de ROM risquent de faire juste...
Par contre, ce que tu peux déjà faire, avant de te décider pour quoi que ce soit, c'est commencer à compiler une version linux avec les librairies indispensables et une version rtos, tu auras une idée de l'empreinte mémoire de ton appli... Tu peux aussi regarder du côté de ecos, un OS light supporté par les archis arm7
A plus
Bonjour.
Il y a aussi µC/OS (http://www.micrium.com/).
Mais le plus important est de définir précisément tes besoins.
Pour info toute communication cryptées type SSL / HTTPS est gourmande en temps CPU. Est-ce vraiment utile sur ton appli? C'est ça qui risque de poser problème.
C'est effectivement une très bonne idée de commencer par compiler/linker des images pour voir ce que ça peut donner en terme de taille.
L'idéal sera peut-être de trouver un couple carte d'éval / OS tout fait et qui fonctionne déjà. Ce sera beaucoup moins galère.
Sylvain
Je viens de regarder la partie soft livrée avec la carte d'éval : il y a uniquement FreeRTOS de fournis => il y a quelques fonctions Ethernet mais c'est loin de faire tout ce que je veux. A priori, on peut facilement utiliser les bibliothèques uIP et IwP avec FreeRTOS mais elles ne gèrent pas le cryptage.
Le cryptage est indispensable : c'est d'ailleurs l'une des principales raisons qui m'oblige à abandonner les PIC qui sont quand même très bien si on veut juste utiliser les protocoles HTTP et SNMP V1 (remarque : la pile TCP/IP microchip gère le SSL (utilisé pour crypter les infos du client SMTP) mais certains protocoles comme le SNMP V3 ne sont pas encore gérés... la pile évolue assez rapidement, peut-être que dans un futur proche il y a aura tous les protocoles... mais je vois mal un PIC18 faire le cryptage. De plus le PIC18 est trop limité en ROM et RAM et utiliser un plus gros ne me semble pas rentable comparé a un ARM7 avec mémoires intégrés).
Personne n'a essayé d'utiliser un ARM7 pour faire du HTTPS ? est-ce que le temps d'affichage reste correcte ?
Je vais suivre vos conseils et essayer de compiler tout ça pour voir la place que ça prend. Après faudra voir si le cryptage ne fais pas trop ramer le µC
Tu peux te rendre sur le site de pragmatec (cité dans mon post #2), il y a un forum, tu pourras poser tes questions... Cela dit, je te conseille dans un premier temps de trouver un environnement de développement arm7, et de builder toutes les librairies dont tu as besoin (en arm7, pas en x86).... Il ne faut pas oublier de stripper les lib pour avoir la taille mini... De là, tu verras l'empreinte mémoire... Ensuite si ça convient, tu commandes une carte pragmatec, l'investissement est vraiment minime, et tu testes en live... L'idéal étant de commander directement la carte et de faire les tests grandeur nature.
De toutes façons le calcul est vite fait, soit tu prends une version d'OS mini (rtos, ecos), dans ce cas, il faudra choisir ton hardware en fonction de ce qui est supporté, ou coder les drivers toi même... Et bien sûr il faudra faire pareil pour les librairies... Tu auras une version taillé juste en terme de mémoire, mais cela impose des limitations sur le hard et un temps de développement ralongé (lib manquantes, drivers manqaunts).
Autre option, tu pars sur linux (µcLinux pour arm7), et là, tout existe... Tu fais ton marché dans la boutique de l'open source et tu compiles... L'empreinte mémoire sera un peu plus importante, mais le temps de développement total porté à quelques jours. Une journée si tu maîtrises les outils...
A plus
Bonjour.
Est-ce que tu as pu faire des essais?
Est-ce que tu as choisi une carte en particulier?
Le sujet m'intéresse, je pense aussi m'amuser avec un µP couplé à une interface ethernet. Mon but sera de présenter des infos récupérées par le µP (genre températures) sur une page web simple. Rien n'est bien figé pour l'instant, mais en tout cas, je n'aurai pas besoin de liaisons cryptées (SSL et autres).
Si tu as fait des tests dans un sens ou un autre ça pourra m'avancer dans mon choix.
Sylvain
Salut, si tu n'as pas besoin de liaison non cryptée, tu devrais partir sur un PIC18F97J60
avantages :
- c'est pas chère
- pile TCP/IP de microchip est déja developpée et gratuite (en plus il y a tous les outils qui vont bien)
- IDE microchip est gratuit
inconvénient
- tu ne peux pas mettre autant de variables en RAM que sur un ARM (mais a priori pour ton appli ça devrait largement suffire)
- le compilateur MCC18 est payant
- si tu veux le raccorder ton PIC à une liaison RMII ou MII, il faut mettre une interface (qui prend pas mal de place) car le PIC à une sortie PHY => donc le cout global sera le même que pour un ARM
Re.
Mon idée est plutôt de trouver une carte d'essai toute faite. Donc une ARM pourquoi pas!
Il faut que je vois jusqu'où je veux aller.
Merci pour ta réponse rapide en tout cas.
Sylvain
Microchip propose des cartes de demo : http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en028217
=> elle est déja programmée et tu peux donc te faire une idée des performances
Pour ce qui est du compilateur, c'est ici qu'il faut regarder pour les prix : http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014
Il faut aussi acheter un programmateur : http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005
Pour les ARM, pour le moment je suis entrain de galérer pour installer la toolchain donc je ne connais pas trop les ressources que peuvent prendre un uClinux : mais j'ai bien peur qu'il faille utiliser de la mémoire externe (donc encombrement et prix plus élevé).
Aussi il existe des bibliothèques réseau + OS plus légés (sans cryptage) : http://www.freertos.org/
=> je ne sais pas ce que ça vaut
Tu vas partir sur quelle solution ? tiens moi au courant si tu parts sur une solution ARM
Une solution ARM sera plus adaptée pour l'appli de relevés de températures... Tu pourras y stocker un serveur web, et des pages actives... J'ai déja fait ce genre d'appli pour surveiller des onduleurs... A l'époque, j'avais utilisé des png représentant des leds, et des afficheurs.
Ca permettait d'avoir une page web sympa ressemblant à un tableau de contrôle électronique. Les outils sont gratuits, la stack ip, et le serveur web aussi...
Et comme mentionné plus haut, l'avantage d'utiliser une solution ARM+µClinux, c'est qu'on peut savoir précisément sans investir de temps ou d'argent la taille que prendra la distrib' finale. L'autre gros avantage, c'est qu'il y a une foultitude de périphériques supports en natif (radio, audio, vidéo i2C wifi, bluetooth, IRDA, ethernet, ....) donc pas besoin de se casser la tête pour le pilotage, ou les drivers...
Ce qu'on perd en resources, on le gagne très très très largement en temps de développement.
Pour des petites séries, le calcul est vite fait, il suffit de comparer l'overhead du prix de la carte par le nombre de carte avec le gain sur le temps de développement.
Un exemple simple, lorsqu'on est habitué à développer en environnement crosscompilé :
On reçoit son kit, le matin, on l'installe et l'après midi, on a une distrib qui boote en stand alone avec le réseau, un serveur web installé... Le lendemain, on a rajouter ssl, telnet, nfs, ftp. Il reste plus qu'à coder l'appli proprement dite...
A plus
Pazcal, l'appli que tu as faite, c'est du linux + ARM9 ou uClinux + ARM7 ou autre ?
Une solution ARM sera plus adaptée pour l'appli de relevés de températures... Tu pourras y stocker un serveur web, et des pages actives... J'ai déja fait ce genre d'appli pour surveiller des onduleurs...
Pas forcement...une solution PIC peut faire ça sans aucun problème (on peut même envoyer des mail en cas de détection d'erreur) et vu que la pile TCP/IP est déja développée, ça va assez vite a développer (une fois qu'on maitrise les outils/fonctions).
=> La solution PIC est bien si tu as besoin d'un faible encombrement et d'un prix de composant faible (si on ne prends pas en compte le prix des outils de développement). Par contre, c'est vrai qu'au niveau évolution et ajout de périphériques/fonctions, tu es vite limité comparé à une solution ARM.
Oui, mais sur un pic, je doute qu'on puisse mettre un serveur web des pages actives, et une présentation de pages web un peu sympa... Ce sera le truc mini, pas cher, limité, et assez figé... L'avantage sera par contre le prix, et le temps de boot...En fait tout dépend des besoins. Une solution ARM, est idéal pour une développement rapide, et surtout pour une simulation efficace...
Ce qui me plait dans cette solution, c'est de pouvoir tout anticiper... On télécharge une toolchain arm7 on récupère une distrib basée sur µClinux, et on installe tous les softs/drivers/librairies nécessaires... Pour un investissement en temps minimum, on connait précisément la taille de l'empreinte mémoire... Il ne restera plus qu'à ajouter son propre code et ses pages web (si nécessaire)... Ca offre vraiment beaucoup de souplesse.
A plus
Merci pour ces infos, très intéressant tout cela!
Pour info j'ai déjà programmé sur PIC16Fxxx, assembleur et C, j'ai aussi développé sur cartes windriver à base de PowerPC et vxworks.
Je ne vais pas me lancer dans l'immédiat, pour l'instant je me renseigne.
Emcy je suis tes essais avec attention!
Sylvain
Oui, mais sur un pic, je doute qu'on puisse mettre un serveur web des pages actives, et une présentation de pages web un peu sympa... Ce sera le truc mini, pas cher, limité, et assez figé...
=> pour info : avec un PIC on peut faire des pages web dynamiques très sympa à condition de ne pas mettre des images de partout ;). En générale, une page web bien conçue fait entre 10Ko et 30Ko (hors images) => le PIC les affiche sans problème. Je fais des rafraichissements automatiques de ma page web pour afficher l'état d'une quinzaine de variables et ça ne prends pas plus de 200ms. Les pages web peuvent être stockées dans une EEPROM externe de 128Ko max ou dans la ROM du PIC. La pile peut être aussi utilisée avec un PIC24 (ou + gros) et un ENC28J60.
Emcy je suis tes essais avec attention!
=> ça risque de prendre un peu de temps car j'ai du mal a démarrer et en plus j'ai d'autres choses à faire en même temps :(
Pazcal, j'ai installé eclipse avec les plugins CDT GNU toolchain et Zylin Embedded CDT.
Le problème maintenant est de créer mon premier projet avec uClinux (pour AT91SAM7XC512-AU) et là, je bloque (le site de uClinux) : que dois-je faire ?
Voici 2 liens qui devraient t'être utiles :
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3902
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4343
Pour résumer, il te faut 2 choses, un environnement de développement qui te permettra de crosscompiler tes sources, ou les librairies dont tu as besoin... En général cette toolchain se compose des librairies standard (glibc), et des binutils (gcc, as g++, ln, ...).
Une fois installé, cela te permet de compiler ce que tu veux... Il faut cependant faire attention à faire abstraction de ton propre environnement (celui du PC) afin de ne pas utiliser tes includes, ou tes libs pour x86 (ton PC) alors que tu compiles pour ARM7.
C'est l'utilité d'un environnement de développement, en général chrooté (un linux dans ton linux). En général cet environnement te fournira également ce qu'on appelle un rootfs qui sera la distrib' finale qui ira sur la flash de ta carte.
Pour résumer, une toolchain te pemrettra de builder toutes les applis que tu veux pour arm7.
Un environnement te pemrettra d'utiliser cette toolchain de façon décolrrélée de ta machine, elle te donenra également toute facilité pour installer ta distrib sur ta carte ARM7. D'autre part, il fournira un kernel adapté à ta carte, autrement dit qui prendra compte du hard particulier de ta carte... Sans cet environnement, il faudra copier toi même le contenu de ta distrib sur la flash de boot, et créer les fichiers de boot, ....
Dans un premier temps jette un oeil aux 2 liens que je t'ai filé, il y a des tonnes d'infos sur la cross compilation, les distrib, les toolchains, etc etc...
Un autre lien incontournable : http://www.uclinux.org/ucsimm/
Pour info on est obligé d'utiliser µClinux et la µClibc (au lieu de linux+glibc) tout simplement parce que l'ARM7 ne possède pas de MMU.
A plus
A plus
ok je vais regardé tout ça...par contre le probleme c'est que le site uClinux est vérollé (il marche 1 fois sur 10 chez moi)
merci
Il me semble que parfois il rame un peu... Enfin les rares fois où j'y suis allé... La rançon du succès ;o)
A plus
Salut,
Je fais un peu de pub pour ma distro préférée mais vous me le pardonnerez, je veux parler de Gentoo.
L'un des sous projet de cette distro s'appel Gentoo Embedded, vous pouvez accéder à la page du sous projet ici : http://www.gentoo.org/proj/en/base/embedded/index.xml
L'un des avantages quand on utilise cette distro est la communauté, et la facilité avec laquelle on peut communiquer avec les developeurs (ne pas hésiter à s'abonner à la mailing list).
De plus, on peut trouver un handbook (récemment édité et encore incomplet) pour la mise en place d'un système embarqué : http://www.gentoo.org/proj/en/base/embedded/handbook/
A noter la liste des émulateur, qui permettent de tester le système embarqué sans avoir besoin de matériel.
Enjoy!
Salut,
Je fais un peu de pub pour ma distro préférée mais vous me le pardonnerez, je veux parler de Gentoo.
Tu as bien raison, très bonne distrib' :-D...
Surtout idéale pour l'embarqué, et la cross compile puisqu'on compile tous les paquets, avec possibilité de mettre des options d'optimisation pour la target...
Bon, faut aimer jongler avec emerge...
A plus
...on compile tous les paquets, avec possibilité de mettre des options d'optimisation pour la target...
On a aussi la possibilité, grace à "emerge", l'outil d'installation des paquets, d'installer en plusieurs étapes:
1 : téléchargement des sources
2 : modif des sources si besoin
3 : installation des sources modifiées
Le tout avec des outils intégrés à la distro donc pas besoin de s'occuper des "config" et autre "make".
En d'autres termes, c'est une distro idéale pour les developeurs.
On a aussi la possibilité, grace à "emerge", l'outil d'installation des paquets, d'installer en plusieurs étapes:
1 : téléchargement des sources
2 : modif des sources si besoin
3 : installation des sources modifiées
Le tout avec des outils intégrés à la distro donc pas besoin de s'occuper des "config" et autre "make".
En d'autres termes, c'est une distro idéale pour les developeurs.
Tu prêches à un converti, je l'utilise tous les jours pour cross compiler... ;o)
En fait j'ai une gentoo chrootée dans une ubuntu
A plus
Ayant l'habitude de bosser sur windaube, j'avoue avoir énormément de mal a comprendre toutes ces histoires de compilation (sur PIC je n'ai pas tout ces problèmes). J'ai commencé à lire les doc d'atmel mais je n'arrive toujours pas à me visualiser comment tout ça fonctionne (dépendance entre l'OS utilisé pour développer, l'OS à installer sur le système embarqué, les bibliothèques, le compilateur, les fichiers sources et les fichiers de configurations).
J'ai quelque "petites" notions du fonctionnement de linux : j'ai réussi à installer kubuntu en dual boot (pas très compliqué) et je connais quelques commandes shell mais c'est tout.
Please help me....
En effet, même pour moi qui utilise et admin Gentoo tous les jours sur ma babasse perso, je me sens pas très à l'aise avec la notion de cross-compil (je n'ai jamais franchis le pas pour acheter le matériel).
Je te conseillerai de commencer à installer une gentoo sur un pc de base, il y a un très bon handbook qui explique pas à pas comment se déroule l'installation. A partir de là tu commenceras un peu à comprendre les histoires de compilation de pacquets, parce que Kubuntu par exemple, télécharge des pacquets précompilés et les installe sur ton système, du coup aucune compile ne se fait en locale.
Je pense que la différence entre la compile d'un asm pour un PIC ou d'un package pour linux n'est pas si énorme que ça dans le principe global. Tu pars de fichiers source (.asm pour le PIC ou .c pour linux) et grace à un compilo (gcc par exemple sous inux) tu obtient des fichiers binaires (.hex pour le PIC, des executables sous linux).
Si tu veux te lancer dans l'aventure, je te conseillerai de prendre le temps nécessaire pour lire des livres sur l'embedded ( http://www.amazon.com/dp/059600222X?tag=deviceforge-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=059600222X&adid=0Q6M37YJAK8CKP0RMVYD& ), poser des questions sur les mailing-list et les forums spécialisés... y a du boulot !
Je pense que la différence entre la compile d'un asm pour un PIC ou d'un package pour linux n'est pas si énorme que ça dans le principe global. Tu pars de fichiers source (.asm pour le PIC ou .c pour linux) et grace à un compilo (gcc par exemple sous inux) tu obtient des fichiers binaires (.hex pour le PIC, des executables sous linux).
il n'y a pas que les fichiers .c, j'ai vu aussi qu'il y a des makefiles (il ya peut etre aussi d'autre fichiers de config).
J'ai téléchargé un fichier d'exemple chez ATMEL. Il y a un dossier contenant des bibliothèques et un dossier contenant les fichiers du projet (un fichier .c , un fichier make.bat et un fichier Makefile).
=> J'ai donc créer sous eclipse un nouveau projet de type "New CDT project Wizzard" en sélectionnant le compilateur cygwin mais après je ne sais pas quoi faire : je pense qu'il faut charger le fichier makefile a quelque part non ?
En fait c'est un peu plus compliqué qu'une compile sur PIC.... J'essaye de détailler ...
Sur ton pic, tu as un environnement bien clos, un éditeur, un compilateur/assembleur/debugger, et un soft qui te pemret de flasher ton code sur le pic... Ca c'est tout simple, pas d'interférence possible entre ta machine et ton code cross compilé... D'autre part le micros "low end" n'ont pas de gros problème de compilation/linkage étant donné leur faible resources mémoire (le code réside toujorus à la même adresse).
Sur un système "high end" embarqué avec un OS, le problème est un peu différent...
La tailel du code, des librairies est nettement plus importante... On est sur un système équivalent à un PC, avec des drivers, des modules, un noyau, de la mémoire de masse, des librairies partagées, un file system, de la mémoire virtuelle, un cache, etc etc...
Donc pour compiler, il te faut une toolchain, qui contient un compilateur/assembleur/linker/debugger... Mais il te faut également (entre autre) la glibc, grosse librairie générale utilisée en C, plus toutes les autres librairies graphiques, tcp, ...
Comme tu compiles une distrib linux sur une machine linux, il ne faut pas que ton compilateur prenne tes headers/librairies pour compiler/linker, sinon, ca risque de créer des conflits... idem, lorsque tu installes les librairies cross-compilées, il ne faut pas que tu les installes sur le file system de ta machine...
Il faut donc un environnement de développement qui fasse abstraction de ta machine...
C'est pour cela qu'en général on travailel en environnement dit "chrooté"... Tu te connectes dans un environnement linux qui est dans ton environnement linux... De fait, une fois loggé dans cet env, tu ne voit plus du tout ton disque dur, et tu ne peux plus avoir de confusion de librairies/header/install...
Ensuite une fois que tu as compiler tes applis, librairies, etc etc, il faut le sintégrer sur une distrib' linux... L'arborescence qui figurera sur le filesystem de ta machine embarquée linux... Cette distrib s'appelle en général le rootfs (root file system)....
Donc pour résumer , tu as ta machine linux, sur laquelle tu installe un environnement chrooté, qui te permettra de crosscompiler de façon sécurisée... Dans cet envioronenemnt tu as un rootfs qui contient toute l'arborescence linux qui figurera sur ton système final. Le cross compilateur s'exécute en x86 (sur PC) mais génère du code ARM7 (dans ton cas) non exécutable/compatible sur une machine x86...
Pour la compilation, il y a des outils très utilisés sous linux (utilisé entre autre par gentoo), qui sont les autotools....
Le principe, tu téélcharges une librairies/paque/exécutable, et tu genères ton makefile à partir des paramètres de configuration que tu passes....
Donc les commandes très connues des linuxiens sont :
./configure
make
make install
Tu télécharges par exemple la lib toto.tar.gz
Tu las détarres ca te crée un répertoire toto. Tu fais un cd toto...
Le script "configure" vérifies en premier lieu que tu as tout ce qui est nécessaire pour compiler le module qui t'intéresse... Outil de compil, et toutes les dépendances des librairies... A ce script tu indique également si tu cross compiles, et ou il doit installer le résultat de la compil (dans ta distrib finale = rootfs)...
une fois que tout est OK, le scripte génère un Makefile...
Tu 'nas plsu qu'à faire "make" pour compiler/linker, et "make install" pour l'installer à l'endroit que tu auras précisé à ton script configure.
Tu epux prnedre un exemple pour tester...
tu télécharges la libz sur ta machien linux :
wget http://www.gzip.org/zlib/zlib-1.2.3.tar.gz
tu la detarres, et tu entres dans le rép détarré
tar -xzvf zlib-1.2.3.tar.gz
cd zlib-1.2.3
Et la tu fais ton configure, en premier lieu avec la page d'aide :
./configure --help
configure [--shared] [--prefix=PREFIX] [--exec_prefix=EXPREFIX]
[--libdir=LIBDIR] [--includedir=INCLUDEDIR]
voilà, les options --prefix indiquent là ou tu installeras la lib... les autres options indiquent ou aller chercher les librairies/headers pour compiler/linker il faudra que ce soit celel de la target (ARM7).
Ensuite tu fais ton configure :
./configure --prefix="TonRootfsArm7/usr" --includedir="TonRootfsArm7/usr/include" --libdir="TonRootfsArm7/usr/lib" --shared
Ca te génèrera une librairie partagée (.so) en utilsiant les header de ton rootfs, et les librairies de ton rootfs... Pour la générer :
make
Pour l'isntaller,
make install
Ca copiera la lib libzXXX.so dnas ton rootfs... Elle porura ensuite être utilisée par les autres paquets cross compilés....
C'est ce que fait de façon sous-jacente une distrib gentoo....
Ouf.....
a plus
C'est ce que fait de façon sous-jacente une distrib gentoo....
Pour détailler un peu, sous gentoo il y un utilitaire qui s'appel ebuild, qui t'évite, d'utiliser les wget, tar, configure, make, etc... en gros tu dis à ebuild ce que tu veux faire et c'est lui qui gère les wget, make, etc... ça aide.
Ok merci pour toutes ces explications.
Pourquoi vous travaillez tous sous linux ? il y a une raison particuliere ? j'ai vu que grâce a l'IDE eclipse, on pouvait l'installer sur windows (mais je n'arrive pas à le configurer pour le moement)
Pour détailler un peu, sous gentoo il y un utilitaire qui s'appel ebuild, qui t'évite, d'utiliser les wget, tar, configure, make, etc... en gros tu dis à ebuild ce que tu veux faire et c'est lui qui gère les wget, make, etc... ça aide.
C'est pour cela que j'ai mis de façon sous-jacente, mais ebuild (comme tous les gestionnaires de paquets) fait automatiquement ce que j'ai décrit... Gentoo ayant l'avantage/inconvénient de récupérer les sources pour el scompiler en local, contrairement aux gestionnaires apt/rpm...
Pourquoi vous travaillez tous sous linux
Linux (mais aussi unix, bsd, ...) offrent des outils, des environnements, des facilités de développement natives loin, très très loin de ce qu'offre Micro$oft... enfin Micro$oft n'offre rien, ils vendent...
Bref, la richesse des filesystems supportés(ext, reiser, jffs, ....), des langage de script natif (perl, python, bash, tcl, ruby, ...) des bureaux (kde, gnome, ..) des windows managers (xfce, enlightenment, compiz, ....) des outils ip (ssh, ftp, nfs, bootp, tftp, hostap, ...) les chaines de compilation gnu, la possibilité de tailler une distrib, un kernel sur mesure facilement, la possibilité de booter sur une clé USB, ou un CD live, le nombre de cibles supportées (x86 32/64, powerpc, arm11, alpha, freescale, ....).... Le tout gratuitement, avec une bonne dose de sécurité et sans servir les intérêt financiers d'une minorité... Mais bon, la cerise sur le gâteau, c'est surtout le travail collaboratif, le fait de bosser sur des projets open source et de reverser son code, à la communauté. Cela permet d'avancer vite, en servant des intérêts communs (sans spyware, ni gros monopole...)....
Après, c'est sur que en dehors du développement (compta, gestion, bureautique, jeux, ...) , windaube est plus intéressant mais plus cher...
Pour le développement, il n'y a pas photo, la majorité des applis (console, jeux, téléphonie mobile, ...) sont développées sous unix-like
A plus
Pourquoi vous travaillez tous sous linux ?
Tous ?! Je savais pas qu'on était aussi nombreux... :-)
Pour les raisons qu'a ennoncé Pazcal, et en ce qui me concerne, pour être libre (dans tous les sens du terme).
Emcy, où en es tu ?
Emcy, où en es tu ?
J'ai téléchargé Gentoo (je n'ai pas trouvé la version Embedded : c'est un pluggin qu'il faut telecharger après avoir installé la version standrard ?).
Maintenant il faut que je le grave et que je l'installe chez moi (je verrais ça ce week-end) : ça risque de prendre un peu de temps avant que je comprenne toutes les subtilitées de l'install (c'est ce que j'ai lu dans les commentaires).
J'ai déjà kubuntu d'installé sur mon PC donc je pensais faire comme pazcal et chrooté Gentoo depuis Kubuntu : comment on fait ?
Si j'ai bien compris, il faut que je chroote la version standard de gentoo et non pas la version embedded (la version embedded etant une distri qui installe Gentoo en OS principale + une version de Gentoo chrootée), non ?
J'ai une autre question : il y a moyen de passer rapidement de windows a gentoo sans avoir à redemarrer le PC (chrooter Gentoo depuis windows ?) ? ... ayant besoin de tester l'affichage de mes pages web fréquemment sous IE, j'aurai souvent besoin de passer de l'un a l'autre.
Tiens un moyen plus simple, tout es déja fait, pour installer un env chrooté gentoo dans /media/data :
cd /media/data
wget http://www.sand-labs.org/downloads//env_gentoo/haineko2.tar.bz2
sudo tar -xjvfp haineko2.tar.bz2
md5sum -c haineko2.tar.bz2.digests
sha1sum -c haineko2.tar.bz2.digests
./env_login.sh
Et tu es loggé dnas un env chrooté gentoo.
Il est un peu ancien, il faut donc faire un petit update (assez long)
emerge --sync
Il faudra aussi installer certains paquets manquants, ainsi que tes outils de dév.
Une fois que tu es chrooté, tu ne vois plus ton disque dur local... Le /usr par exemple est le répertoire de l'environnement. Par contre (de mémoire) les répertoires /proc, /sys, et /dev sont binder dans l'environnement.... Lorsque tu quittes l'environenment (exit) ça "debind" les répertoires. donc si par hasard tu ne quittes pas proprement, et qu'ils ne sont pas "débindés" et que pour une raison ou une autre, tu effaces tout l'environnement (répertoire haineko), ça va effacer le contenu de /dev avec tous les noeuds des devices montés... bon, c'est pas dramatique, mais faut les réinstaller...
Donc avant d'effacer haineko, vérifier avec un "mount" que plus aucun répertoire n'est bindé sur l'environnement.
Et pour finir, tu as également le répertoire /tmp qui est bindé, ce qui fait que une fois loggé dans l'environnement tu peux faire des échanges de fichiers avec ta machine.
Pour avoir le réseau, il faudra peut être que tu copies le /etc/resolv.conf de ta machine à la place de celui de l'environnement :
cp /etc/resolv.conf /tmp
./env_login.sh
sudo cp /tmp/resolv.conf /etc/
C'est ce que j'utilise tous les jours pour crosscompiler dans le même environnement et en toute sécurité sur x86, arm9, arm11, et sh4.
Il est à noter qu'il existe des tas d'autres environnements de dév sécurisés, et basé sur le même principe... scratchbox, openembedded, ltib,...
A plus
En effet, si c'est juste un environnement chrooté, pas besoin de faire une installation complète.
J'ai une autre question : il y a moyen de passer rapidement de windows a gentoo sans avoir à redemarrer le PC (chrooter Gentoo depuis windows ?) ? ... ayant besoin de tester l'affichage de mes pages web fréquemment sous IE, j'aurai souvent besoin de passer de l'un a l'autre.
Installes wine sur ta kubuntu et fais tourner IE à partir de Wine, comme ça, plus besoin de retourner sous Windows.
Je vais de me rendre compte d'un problème : ça fait tellement longtemps je n'ai pas utilisé Kubuntu, que je ne me rappelle plus du mot de passe :(... et puis, il faut que je partitionne tout histoire de repartir sur de bonnes bases.
Par contre j'ai besoin de vos conseille pour partitionner, comment me conseillez-vous de faire mes partitions (taille mini) ? ...il me faut aussi une partition commune a windows et a linux pour faire des transfères de fichiers.
Je vais peut-etre partir sur un système 100% gentoo (pas de kubuntu) sauf si vous voyez des inconvénients (j'ai très peu utiliser kubuntu donc je n'ai encore aucun automatismes) ?
mamac, tu l'installes comment ta distribution Gentoo Embedded (je ne trouve pas de lien de téléchargement pour cette version) ?
Pour installer l'OS chrooté depuis gento, il faut faire ça, non ?
emerge --sync
emerge -av portage-utils crossdev
=> ça marche aussi depuis Kubuntu ?
Remarque : j'aimerais pouvoir récupérer tous les fichier d'installe sur CD car la connection internet au boulot est a 512Kb.
Tu n'as pas besoin de partitionner pour un environnement chrooté, mais je ne peux que t'encourager à installer Gentoo sur ton PC, je pense que c'est un bon entrainnement de commencer par une installe sur PC avant de passer à l'embedded.
Quel processeur as-tu sur ton PC ? La procédure d'installation (et surtout les sources à télécharger) dépendent de ton proc.
En fonction de ça je te donnerai un lien vers la procédure d'installation.
Pour l'emnedded, c'est ni un plugin, ni une distro particulière, c'est la même que ce que tu vas installer sur ton pc mais tu devras la personnaliser.
Mais, saches que l'installation de Gentoo sur ton pc vas te prendre plusieurs jours, donc n'hésites pas à me contacter en mp, je me ferai un plaisir de te guider (et ça évitera de polluer cette discution).
emerge --sync
emerge -av portage-utils crossdev
=> ça marche aussi depuis Kubuntu ?
Non, emerge est un outil propre à Gentoo. Cela fonctionnera seulement une fois chrooté dans ta Gentoo.
Confus?
Confus?
ça commence a rentrer mais ce n'est pas encore ça ;)
Sur mon PC perso j'ai un A64 et sur mon PC boulot, j'ai Pentium 4 : si je télécharge la version X86, ça pourra marcher sur les deux PC, non (avec quelques pertes de preformances sur mon A64) ? ... j'aimerai avoir qu'un seul liveCD
Mais, saches que l'installation de Gentoo sur ton pc vas te prendre plusieurs jours,
oula, ça fait peur tout ça... mais j'ai cru comprendre que la version stage 3 s'installait assez rapidement, non (mais c'est moins didactique)?
On peut faire des pause pendant l'install au moins (avoir accès en windows) ?
Pour ce qui est du partitionnement, j'ai cru comprendre qu'il fallait mieux créer différentes sections pour des raisons de sécurités (isoler l'OS des données persos).
Saches que si tu installes une gentoo, ou n'importe quelle autre distro, il sera tout de même plus prudent d'avoir un environnement chrooté pour développer... tu peux très bien mettre une gentoo sur ta machine et un env chrooté gentoo dans ta gentoo...
A plus
L'installation proprement dite te prendra quelques heures (1 ou 2 si tu te débrouilles bien) pendant lesquels tu ne pourras pas rebooter ton pc. Mais après cette première étape, tu auras un système de base (pas d'interface graphique). Donc j'imagine que tu voudras une interface graphique (kde comme sous kubuntu), et des softs, là, ça te prendra plus de temps. Il faut savoir (comme Pazcal l'a dit plus haut) que Gentoo installe un paquet en téléchargeant les sources et en compilant en local sur ton pc, donc ça prend du temps d'installer un paquet.
Deux processeurs différents, deux CD différents, surtout qu'il y en a un en 64 bits... c'est comme si tu essayais d'envoyer un .hex pour PIC dans un ARM.
Pour l'installation du AMD64, télécharges l'iso ici :
http://bouncer.gentoo.org/fetch/gentoo-2008.0-minimal/amd64/
Pour l'installation du Pentium, télécharges l'iso ici :
http://bouncer.gentoo.org/fetch/gentoo-2008.0-minimal/x86/
Ensuite, suis les guides d'installation:
l'installation x86 (en français s'il vous plait!):
http://www.gentoo.org/doc/fr/handbook/handbook-x86.xml
l'installation amd64 (en français s'il vous plait!):
http://www.gentoo.org/doc/fr/handbook/handbook-amd64.xml
Tout est indiqué en détail dans ces handbook, comment partitionner, comment installer les pilotes, configurer le réseau, etc...
Voilà, tu goutes déjà aux bienfaits de la communauté sous Linux ;-)
Je te conseil vivement de te créer un compte sur le forum de gentoo.org, et si l'anglais n'est pas ton fort c'est pas grave, il y a une communauté francophone prête à t'aider.
Allez, au boulot !
Aussi, dans le handbook tu verras comment configurer manuellement le kernel, je pense que c'est indispensable pour l'embarqué, non ?
Ok c'est parti ;)
Par contre il y a une solution pour lire le manuel pendant l'install (ça fait beaucoup de feuilles a imprimer...sauvons la planète ;) )?
Tu pourras accéder au manuel avec le navigateur en mode texte "Lynx", c'est décrit dans le handbook.
L'idéal est quand même d'avoir un deuxième pc pour lire le handbook ou de l'imprimer parce que l'illustration en couleur permet une meilleur lecture.
Je viens de découvrir ça : http://www.tuxgraphics.org
Intéressant.
C'est pour cela que tu aurais dû installer ta gentoo dans ta kubuntu... :-D
Tu pouvais utiliser toutes les resources de ta machine pendant qu'elle compiler ta distrib...
A plus
C'est vrai que ça aurait été plus simple ;)
... mais tous les commentaires que j'ai lu sur Gento disent que faire une installation sous Gentoo permet d'apprendre plein de choses sur le fonctionnement de linux : donc c'est bien pour débuter
... et là, je suis entrain d'apprendre plein de choses sur le partitionnement (voir mon post dans la section informatique) mdr...
Voui, mais il y a un hic lorsque tu débutes... Tu bosses sans filet sur ta machine et sans accès au net, et ses richesses (lynx mis à part)... Donc en étant newbie (sans préjuger de tes compétences bien sûr) il faut pas se louper au risque d'être découragé...
Je pense aussi qu'il ne faut pas t'éloigner de ton but qui est d'installer un environnement de cross compilation. Donc tu gardais ton ubuntu, tu installais haineko2 (gentoo), et tu avais ton environnement gentoo, sur lequel tu pouvais te livrer à toutes les expérimentations sans risque... ensuite, une fois que tu es rodé à l'environnement gentoo, tu fais ton install gentoo sur ta machine...
Il faut savoir que l'avantage de gentoo, c'est la compilation de tous les paquets...
Mais c'est également un inconvénient... Donc ça permet d'avoir des paquets taillés pour ta machine, je pense que ça a un réel intérêt lorsque tu cross compiles pour ajouter les paramètres d'optimisations spécifiques à ton CPU (mmx, sse1, sse2, 3Dnow, etc etc...). Donc à moins d'avoir des besoins très particuliers en terme d'optimisation (proc multicore, etc) il n'y a pas trop d'intérêt sur les machines actuelles... enfin surtout compte tenu du temps d'installation...
Bon, après, c'est sûr que tous les geeks te diront que c'est la classe, et que tu optimises le petit machin caché au fond de ton CPU dont 95% des utilisateurs lambdas n'ont rien à faire...
Celà dit, c'est tout à ton avantage de te jeter dans une install gentoo, en espérant que ça ne te décourage pas.. Mais bon, si tu aimes ça, il n'y a pas de raison... :-D
A plus
bon, j'ai réussi a recuperer mes partitions windows et j'ai installé Gentoo.
Resultat : l'install en ligne de commande proposée par le liveCD ne correpondait pas au manuel. J'ai donc lancé l'installation GTK => très simple d'utilisation (même pas besoin de lire le manuel) mais ça ma viré le boot sur windows xp (plus de dual boot). Le pire dans tout ça, c'est que je ne pouvais même plus booter sur mon CD de windows xp...mon PC n'acceptait plus que les CD bootable de type linux (la, je ne comprends pas comment c'est possible : le MBR est bien sur le DD et non pas dans le BIOS ? donc je ne vois pas ce qui empechait mon CD de windows de demarrer... a moins que le CD de windows ne soit pas vraiment un CD de boot ?). Autre remarque : impossible de configurer le clavier en azert : j'ai bien fait alt+f2 pendant l'install puis selectionné azerty mais il ne le prenait pas en compte)
Finalement, j'ai opté pour une solution : réinstaller kubuntu... et la rien à voir : une installation simple, rapide et fiable (configuration automatique de GRUB : la partiton de windows a été integrée automatiquement au menu de grub).
Bon maintenant j'ai un probleme pour installer Gentoo en chroot :
[QUOTE=pazcal]
cd /media/data
wget http://www.sand-labs.org/downloads//env_gentoo/haineko2.tar.bz2
sudo tar -xjvfp haineko2.tar.bz2
md5sum -c haineko2.tar.bz2.digests
sha1sum -c haineko2.tar.bz2.digests
./env_login.sh
[/QUOTEl]
=> ça marche po...
il ne faudrait pas plutot faire :
sudo su
cd /media
mkdir data
cd data
wget http://www.sand-labs.org/downloads//env_gentoo/haineko2.tar.bz2
wget http://www.sand-labs.org/downloads//env_gentoo/haineko2.tar.bz2.digests
tar -xf haineko2.tar.bz2
md5sum -c haineko2.tar.bz2.digests
sha1sum -c haineko2.tar.bz2.digests
./env_login.sh
je n'ai pas bien compris ce qu'il faut faire ensuite.
1- j'ai lancé env_login.sh
=> j'ai eu le message : copy your resolv.conf file to /etc directory (je n'ai rien fait, je ne savais pas trop quoi faire)
2- do you want to install portage tree => yes
3- j'ai selectionné le serveur a partir duquel telecharger la distro
4- une fois le portage tree decompressé, il me demande un nouveau mot de passe Unix pour le groupe developer
5- ensuite il me demande un nouveau mot de passe pour root
6- do you want to bind a project directory in your environment [Y/N]? => yes
7- enter the directory to bind: => ./gentoo_emb
8- enter the destination directory in environment (may not exist): => ./gentoo_env
=> je n'ai pas trop compris les etape 7 et 8 ce que c'etait : il faut que je mette quoi (je ne coprends pas trop ce que je fais) ?
quand est-ce que je suis chrooté ? c'est quand je rentre dans le repertoire avec un cd non_du_repertoire ? ou c'est quand je lancerai env_login.sh ?
comment fait-on aussi pour supprimer l'environement chrooté ?
Bon, dommage de ne pas avoir percévéré avec Gentoo, ça t'aurai apris à te servir de Linux en ligne de commande et du coup tu comprendrai mieux ce que tu es en train de faire.
Tu sais que tu es chrooté quand tu as l'invite chroot#
Pour sortir de l'environnement chrooté, c'est 'exit'.
Voila ce que je te propose pour créer une gentoo chrootée dans ta kubuntu (je viens de tester avec succès sur ma Gentoo):
On créé le dossier dans lequel on va chrooter:
# mkdir /mnt/gentoo
# cd /mnt/gentoo/
On télécharge tous les fichiers qui vont servir au fonctionnement de la Gentoo:
# wget ftp://ftp.free.fr/mirrors/ftp.gentoo.org/releases/x86/2008.0/stages/stage3-i686-2008.0.tar.bz2
# wget ftp://ftp.free.fr/mirrors/ftp.gentoo.org/releases/x86/2008.0/stages/stage3-i686-2008.0.tar.bz2.DIGESTS
# wget ftp://ftp.free.fr/mirrors/ftp.gentoo.org/releases/x86/2008.0/stages/stage3-i686-2008.0.tar.bz2.CONTENTS
# md5sum -c stage3-i686-2008.0.tar.bz2.DIGESTS
# tar xvjf stage3-i686-2008.0.tar.bz2
# wget ftp://ftp.free.fr/mirrors/ftp.gentoo.org/snapshots/portage-latest.tar.bz2 && wget ftp://ftp.free.fr/mirrors/ftp.gentoo.org/snapshots/portage-latest.tar.bz2.md5sum
# md5sum -c portage-latest.tar.bz2.md5sum
# tar xvjf /mnt/gentoo/portage-latest.tar.bz2 -C /mnt/gentoo/usr
On édite les options de config en suivant les indications sur http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=5#doc_chap4
On copie le fichier de conf du réseau de la kubuntu vers l'environnement chrooté:
# cp -L /etc/resolv.conf /mnt/gentoo/etc/
On chroot:
# mount -t proc none /mnt/gentoo/proc/
# mount -o bind /dev /mnt/gentoo/dev
# chroot /mnt/gentoo/ /bin/bash
# env-update
# source /etc/profile
# export PS1="(chroot) $PS1"
Pour tester, on met à jour le portage tree avec la commande:
# emerge --sync
Pour sortir du chroot:
# exit
# cd
# umount /mnt/gentoo/dev /mnt/gentoo/proc
Lorsqu'on veut chrooter à nouveau après un redémarrage du pc:
# mount -t proc none /mnt/gentoo/proc/
# mount -o bind /dev /mnt/gentoo/dev
# chroot /mnt/gentoo/ /bin/bash
# env-update
# source /etc/profile
# export PS1="(chroot) $PS1"
Et voila, tu as une Gentoo chrootée dans une kubuntu, prête à l'emplois.
Une fois l'environnement créé, tu peux le nettoyer (lorsque tu es chrooté):
# cd /
# rm portage-latest.tar.bz2*
# rm stage3-i686-2008.0.tar.bz2*
aurelienr 27/09/2008, 09h37 Faut vraiment se coltiner tout ça pour programmer un ARM avec un OS Linux ?
Pas forcément, mais Emcy a choisi de chrooté dans une Gentoo à partir d'une kubuntu pour avoir un environnement sécurisé afin de cross-compiler pour son ARM, je lui propose ma solution.
Mais plus haut j'ai décri comment chrooter dans une Gentoo pour x86.
Mais si j'ai bien compris le but est de chrooter dans une distro pour arm.
N'est-ce pas Pazcal ?
P.S. je regarde comment ça se passe pour utiliser un émulateurs comme QEMU ( http://bellard.org/qemu/ ). Je trouve sympa qu'on puisse télécharger une image d'un linux pour ARM pour tester QEMU !
Mais plus haut j'ai décri comment chrooter dans une Gentoo pour x86.
Mais si j'ai bien compris le but est de chrooter dans une distro pour arm.
N'est-ce pas Pazcal ?
Heuu non pas du tout en fait :-D
L'idée c'est d'avoir en environnement chrooté gentoo (ici) qui tourne dans une ubuntu. La version haineko2 que j'ai proposée est en fait un tar.gz d'un environnement gentoo fait suivant le même genre de procédure que celle que tu as décrite... Sauf que le script de login et de bind est déja écrit, et que le resolv.conf est copié, etc...
Ensuite une fois l'environnement installé, Emcy pourra installer sa toolchain, qui lui permettra de compiler sa distro arm, et son kernel... donc il aura dans cet environnement des outils arm-linux-gcc, arm-linux-g++, etc....
Il aura également son rootfs correspondant au root de sa distro arm, qu'il pourra copier sur la flash, le disque de sa board ARm, ou qu'il pourra monter en nfs pour booter en réseau (tftp).
L'avantage de l'environnement c'est de se soustraire à sa propre machine. Par exemple dans le cas où il voudrait compiler un truc bien tordu du style fontconfig, ça évitera que la compilation utilise des headers/binaires locaux à la machine au lieu des version arm.
PArce que une fois loggé dans un environnement chrooté, on ne voit plus le reste de la machine (sauf les répertoire bindés /tmp, /proc, /dev, /sys)
A plus
Pazcal a donné le lien pour installer Haineko2 : c'est ni plus ni moins qu'une image d'une gentoo avec un script qui permet de la monter en chroot => donc pas besoin de faire toutes ces manip : il suffit de lancer le script et de suivre les instructions ... cependant j'ai les warning suivants lorsque je me log
mon_log@mon_log-desktop:/media/data$ ./env_login.sh
copy your resolv.conf file to /etc directory
`/etc/resolv.conf' -> `./etc/resolv.conf'
copy your .ssh directory to local root directory
cp: ne peut évaluer `/root/.ssh': Aucun fichier ou répertoire de ce type
copy your .ssh directory to developer home directory
cp: ne peut évaluer `/home/mon_log/.ssh': Aucun fichier ou répertoire de ce type
copy your .subversion directory to local root directory
cp: ne peut évaluer `/home/mon_log/.subversion': Aucun fichier ou répertoire de ce type
copy your .subversion directory to developer home directory
cp: ne peut évaluer `/home/mon_log/.subversion': Aucun fichier ou répertoire de ce type
mounting file system
entering chroot environment
mon_log-desktop login:
Il cherche a copier les fichier .ssh et .subversion qui devraient se situer soit dans le repertoire /root soit dans le repertoire ~/mon_log => mais je n'ai pas ces fichier alors que ssh et subversion sont bien installés sur mon PC.
=> je me log bien : ce n'est pas grave d'avoir ces messages
maintenant il me reste a installer la tool-chain
Pazcal,
Merci pour les infos.
Emcy,
Tu ne dois pas avoir utilisé ni ssh ni subversion au moins une fois en tant que root sur le host system, c'est pour ça que ces directory n'existent pas. Au pire je pense que tu peux enlever la copie de ces directory du script.
Bon, je vais installer la toolchain aussi, on va voir comment ça se passe...
Pazcal, tu utilises crossdev comme cross-compiler ?
Non, en fait j'utilise les toolchain gnu en général...
J'ai juste essayé crossdev sous XP, mais c'est payant, alors j'ai laissé tombé ;o)
A plus
Ok, curieux d'avoir crossdev payant...bref.
Mais je m'apperçois qu'en fait le package crossdev sous Gentoo n'est pas un cross-compiler en lui-même mais un outil qui permet de simplifier la mise en place de la toolchain.
Une fois crossdev installé, il faut utiliser une commande du genre (tout dépend de la target):
crossdev --target arm-unknown-uclinux-uclibc
et crossdev va installer binutils, gcc, linux-headers, glibc, etc... en fonction de la target sélectionnée.
Non, en fait j'utilise les toolchain gnu en général...
=> c'est a dire ? pour chaque famille de composant, tu utilises une toolchain donnée par le fabricant ? ce n'est pas possible de n'installer qu'une toolchain qui fait tout (il y a des avantages inconvenants) ?
la toochain comprend un IDE graphique ou tout est traité en ligne de commande ?
... j'ai regardé les doc chez atmel mais ça ne parle que de IDE pour windows (eclipse et IAR)
En fait, je crois que j'ai besoin d'un exemple complet pour tout bien comprendre...
Il n'existe pas un cours pour les arms (style cours pour les PIC de bigonoff ?)
=> c'est a dire ? pour chaque famille de composant, tu utilises une toolchain donnée par le fabricant ?
Oui et non... tout dépend des applis. Dans le cas d'applis nécessitant un grand nombre de librairies, et des drivers/kernel particulier, on a tout intérêt à utiliser leurs outils, et parfois leur environnement. Cela évite de recompiler toutes les librairiers, et de se taper les patches sur le kernel, ou les modules pour leur hardware particulier. Il m'est arrivé d'utiliser une bonne 10 aine d'environnement différents pour compiler sur le même coeur ARM11 par exemple. Mais en fait ARM11 est un des coeurs les plus utilisés par les constructeurs (presque tous les téléphones cellulaires, consoles, pda, ...) Ca fait du monde. Compiler une grosse appli utilisant des libraireis crypto, grapqhique, décompression, parsing, etc etc prend une matinée dans l'environnemnt constructeur. Si on doit tout faire from scratch, on y passe une bonne semaine... sans parler du kernel, et des modules.
ce n'est pas possible de n'installer qu'une toolchain qui fait tout (il y a des avantages inconvenants) ?
Ben si tu optes pour une board donnée (un reference design) tu utilises la toolchain constructeur... Si tu veux faire tes propres cartes ensuite autant les baser sur ce ref design, tu pourras utiliser les mêmes outils, et le même environnement.
la toochain comprend un IDE graphique ou tout est traité en ligne de commande ?
Il y a les deux... Tu peux utiliser kdevelop, ou eclipse, et consor, ou la ligne de commande... J'utilise la ligne de commande (juste à taper make) avec un éditeur (emacs).
... j'ai regardé les doc chez atmel mais ça ne parle que de IDE pour windows (eclipse et IAR)
IAR c'est payant, eclipse existe sous linux...
En fait, je crois que j'ai besoin d'un exemple complet pour tout bien comprendre...
Il n'existe pas un cours pour les arms (style cours pour les PIC de bigonoff ?)
Ce ne sont pas les docs qui manquent... Pour les toolchains, 2 sites principaux, celui de gnu, et de arm...
Voici quelques exemples :
http://www.arm.com/support/
http://www.arm.com/gnu/
http://www.gnuarm.org/
http://www.codesourcery.com/gnu_toolchains/arm
http://www.arm.linux.org.uk/
A plus
Bonjour à tous.
Je refais un petit up sur ce topic pour savoir où tu en es Emcy. As-tu réussi à configurer un environnement de développement finalement?
Tu t'es décidé pour une carte ou une autre?
De mon côté j'ai été intéressé à un moment par le digibutler d'elektor (http://www.elektor.fr/digibutler_fr) qui est une solution clé en main hard/soft à un prix raisonnable (~50 euros avec de quoi reprogrammer la carte).
Je ne sais pas si ça supporte le cryptage par contre, faudrait voir dans les specs de la pile TCP/IP.
Cela dit le soft risque d'être limité en terme de support, par exemple si je veux ajouter une carte flash pour stocker des ficheirs, il faudra que je me débrouille pour ajouter le driver et le support du file system... une solution linux embarqué est évidemment plus complète.
Bye!
Sylvain
Bonjour,
Je suis entré sur ce sujet pour l'ethernet.. mais là je vais continuer pour l'histoire de linux et cie..
Ne voyez pas cette intervention comme un cheveux dans la soupe..
- C'est quoi cross-compiler ?
- On peut faire de l'OS linux (pour µC) à partir d'un PC windows ?
- Quand on parle de linux, c'est pour l'environnement de developpement (PC) ou pour l'environnement cible (µC) ?
- Est-ce que la chaîne de dev est gratuite (conformément à l'univers linux)
Je crois comprendre qu'avec tout ça (ce dont vous parlez, linux et cie.. -j'ai un peu de mal à tout suivre en fait-) il y a un potentiel plus grand...
Et comme je veux progresser en électronique, autant continuer là où il y a un meilleur potentiel...
Question : Comment je pourrai m'informer sur ce sujet ? Avez-vous des liens ou des références d'ouvrages à communiquer ?
PS : Peut-être que mes questions ont déjà leur réponses dans les posts précédents mais c'est assez difficile à digérer et j'ai surtout survolé dès que le sujet de linux à pris le dessus... donc désolé..
Merci bien.
Bonjour!
Je vais essayer de t'éclairer un peu.
Bonjour,
- C'est quoi cross-compiler ?
C'est compiler du code dans un langage compréhensible par un processeur autre que celui sur lequel tu te trouves. Par exemple, compiler pour processeur ARM sur PC.
- On peut faire de l'OS linux (pour µC) à partir d'un PC windows ?
Oui. Je n'ai pas fait la manip, mais c'est ce que je ferai sans doute quand je me serai décidé pour un modèle de carte pour µclinux.
- Quand on parle de linux, c'est pour l'environnement de developpement (PC) ou pour l'environnement cible (µC) ?
Les 2. On peut cross-compiler pour µclinux (ou RTlinux) depuis linux PC ou depuis windows PC.
- Est-ce que la chaîne de dev est gratuite (conformément à l'univers linux)
Ca dépend. Il y a des chaines de compilation GNU pour certains proc, ou encore codewarrior pour les proc freescale qui sont gratuits. Mais il y en a aussi des payants. Certains vendeurs de cartes toutes faites vendent le kit avec toute la chaine de compil et les outils qui vont bien.
Je crois comprendre qu'avec tout ça (ce dont vous parlez, linux et cie.. -j'ai un peu de mal à tout suivre en fait-) il y a un potentiel plus grand...
Et comme je veux progresser en électronique, autant continuer là où il y a un meilleur potentiel...
Question : Comment je pourrai m'informer sur ce sujet ? Avez-vous des liens ou des références d'ouvrages à communiquer ?
[...]
Merci bien.
Faut pas t'emballer comme ça à propos de linux et cie. Tout dépend de ce que tu veux faire. Pour faire clignoter une led, pas besoin de linux! Faut s'adapter suivant ton projet!
Maintenant si tu veux des infos, effectivement tu peux suivre les liens qui ont été donnés dans ce fil. Le site de µclinux c'est www.uclinux.org.
Il y a d'ailleurs d'autres OS qui tournent sur µC. FreeRTOS, µC/OS-II pour ne citer que des OS libres. Dans le payant tu auras par exemple vxworks, QNX, nucleus, ...
Voir http://fr.wikipedia.org/wiki/Syst%C3%A8me_temps_r%C3%A9el
Sachant tout de même que µcLinux a une empreinte mémoire plus grande par rapport à d'autres solutions. Linux c'est quand même la cavalerie lourde!
Mais avant tout, inutile de lancer dans µclinux qui est une solution lourde si tu n'en a pas les besoins! Moi je vise cette solution car je voudrais avoir le minimum de dev à faire et disposer:
- d'un serveur web
- d'une horloge RTC
- d'un accès à une mémoire de masse type SD/MMC card
- d'un systeme de fichier (FAT ou autre) et de pouvoir gérer des fichiers
- de pouvoir faire des mise à jour facilement de mon soft, par ftp par exemple
- le tout avec une conso électrique raisonnable car c'est pour une appli qui va tourner 24/24.
- et aussi parce que j'ai envie de m'amuser un peu avec µclinux ;-)
Sylvain
Merci pour ces infos...
Ca veut dire lorsque on "fait" du PIC on cross-compile aussi : pentium vers PIC ?
J'envisage d'apprendre tout ça un peu pour la même chose... Pas pour faire clignoter une led..
Mais justement, si je voulais juste faire clignoter une led, avec un environement linux c'est pas possible ? Pour des simples PIC par exemple ? Il n'y a pas les outils qu'il faut ?
Le monde du libre est-il présent concernant l'électronique ?
J'ai déjà travailler sous RTLinux mais la cible, c'était le PC lui même, c'était surtout pour étudier le temps réel.. Pas vraiment de l'embarquée..
J'ai aussi déjà manipuler des piles TCP-IP (ceux de Microchip) avec µC Microchip..
Et je me disais pourquoi ne pas essayer quelque chose de différent et plus pratique..
En fait j'aimerai bien passer à linux et si je le fait grâce à l'électronique ça ferait d'une pierre deux coups..
Merci bien.
Merci pour ces infos...
Ca veut dire lorsque on "fait" du PIC on cross-compile aussi : pentium vers PIC ?
Si tu compiles un language évolué (C, basic), oui tout à fait. Si tu fais de l'assembleur par contre, on ne peut pas à proprement parler de compilation. Mais bon on va pas chipoter.
J'envisage d'apprendre tout ça un peu pour la même chose... Pas pour faire clignoter une led..
Mais justement, si je voulais juste faire clignoter une led, avec un environement linux c'est pas possible ? Pour des simples PIC par exemple ? Il n'y a pas les outils qu'il faut ?
Je ne suis pas certain de bien comprendre ta question. Si tu parles d'outils disponibles sous linux pour programmer des PICs, oui ça existe. Vois du côté de http://www.gnupic.org .
[...]
En fait j'aimerai bien passer à linux et si je le fait grâce à l'électronique ça ferait d'une pierre deux coups..
Merci bien.
Il y a moyen oui. Il y a plein de solutions, c'est peut-être ça la plus grande difficulté!
Sylvain
Le monde du libre est-il présent concernant l'électronique ?
Biensur, je tourne exclusivement sous Linux et n'utilise que des softs du genre open source (ou pas) et/ou gratuits pour le dévelopement sur PIC avec Pikdev, schéma et circuit imprimés avec Eagle, et aussi tous les outils pour l'embarqué (des outils propres à ma distro).
Les logiciels cités ici ne sont biensur pas les seuls, une recherche rapide te montrera qu'il y a du choix dans le domaine.
Pour la documentation l'une des références semble être http://www.amazon.fr/Building-Embedded-Linux-Systems-Yaghmour/dp/0596529686/ref=sr_1_1?ie=UTF8&s=english-books&qid=1224858232&sr=8-1
Tu peux en lire pas mal de pages ici : http://books.google.com/books?id=I-hVqkX6A9cC&printsec=frontcover&dq=embedded+linux
Ok, merci pour le lien..
Je vais commencé à lire un peu..
Mais vu le titre je pense qu'ils vont plus parler de RTOS etc.. plutôt que d'outils pour PIC (et cie) sous linux...
Je vais déjà lire un peu...
|
