WR703N + VinciDuino

skywodd:
Bon reste plus qu'as faire un patch/paquet et tenter de le proposer sur le svn de openWRT :sweat_smile:

C'est en cours ! Je vais tenter d'écrire 3 packages OpenWRT, pour copier la structure de Debian : "binutils-avr", "gcc-avr" et "avr-libc" (cherchez l'intrus :D)

Puis probablement un méta-package "arduino" qui inclut ces 3 là plus "avrdude" et les drivers USB pour l'Arduino.

Je suis en train de compiler le package "binutils-avr".

skywodd:
La version makefile + générateur de code en ruby est la plus aboutie, mais il faut l'interpréteur ruby ...
La version makefile pure est un peu plus restrictive mais elle marche (c'est le principal).

J'ai jeté un coup d'oeil aux différentes solutions. Franchement, le bout en ruby est assez facile à traduire en Shell pur... Ils ont vraiment utilisé ruby pour se faire plaisir ! C'est vrai que celle-ci a l'air plus aboutie que la seconde, mais les 2 ne gèrent pas bien certaines choses que ino semble gérer mieux :

  • la détection automatique des librairies
  • la numérotation des lignes par rapport au source original, et non au .cpp généré
  • l'inclusion automatique des prototypes en tête des fichiers .cpp générés

J'ai bien réussi à installer le package "python_mini" pour ino, mais bon quand même, c'est lourd...

skywodd:
Projet trés intéréssant cet éditeur javascript !
Un duo nginx + makefile en FastCGI et cet éditeur pourrait donner quelque chose de trés intéressant.
Une sorte de Codebender fait maison en gros.

Voui !

Je ne connais pas nginx... C'est un serveur HTTP ? Qu'est-ce qu'il peut apporter par rapport à uhttpd qui est utilisé par Luci ?

Et oui, il faut toujours que je ne fasse pas comme tout le monde : au lieu de remonter le compilateur vers le "Cloud", je le descend vers le matériel !

bonsoir
je n'ai pas tout bien suivi/assimilé de la manip, mais si j'ai bien compris il s'agi(rai)t de (re)programmer un .INO sur une base arduino distante connectée au WR703N et ça par la liaison ethernet (filaire ou WiFI) ?

Squonk42:
C'est en cours ! Je vais tenter d'écrire 3 packages OpenWRT, pour copier la structure de Debian : "binutils-avr", "gcc-avr" et "avr-libc" (cherchez l'intrus :D)

Ok ok ça semble prometteur tout ça :slight_smile:

Squonk42:
Puis probablement un méta-package "arduino" qui inclut ces 3 là plus "avrdude" et les drivers USB pour l'Arduino.

Bonne idée, par contre pour le driver usb c'est juste du serial CDC classique (intégré de base).
Il ne devrait donc pas y avoir de modif à faire (si ce n'est de s'ajouter au groupe dialout) ?

Squonk42:
J'ai jeté un coup d'oeil aux différentes solutions. Franchement, le bout en ruby est assez facile à traduire en Shell pur... Ils ont vraiment utilisé ruby pour se faire plaisir ! C'est vrai que celle-ci a l'air plus aboutie que la seconde, mais les 2 ne gèrent pas bien certaines choses que ino semble gérer mieux :

Il existe un autre makefile "arduino" plus poussé avec un utilitaire en perl pour parser boards.txt.
Mais la méthode pour intégrer le .mk à son makefile est un peu ... méli mélo :
http://mjo.tc/atelier/2009/02/arduino-cli.html

Squonk42:
Je ne connais pas nginx... C'est un serveur HTTP ? Qu'est-ce qu'il peut apporter par rapport à uhttpd qui est utilisé par Luci ?

Ouaip, c'est un serveur HTTP hyper léger mais trés puissant, surtout pour faire des applications CGI-bin.
J'utilise pas Luci personnellement, ya plein de module mais je trouve ça trop usine à gaz.

Squonk42:
Et oui, il faut toujours que je ne fasse pas comme tout le monde : au lieu de remonter le compilateur vers le "Cloud", je le descend vers le matériel !

De même, faire comme tout le monde c'est pas mon truc :grin:

Artouste:
bonsoir
je n'ai pas tout bien suivi/assimilé de la manip, mais si j'ai bien compris il s'agi(rai)t de (re)programmer un .INO sur une base arduino distante connectée au WR703N et ça par la liaison ethernet (filaire ou WiFI) ?

Oui, en gros, voici la situation existante: le WR703N peut être relié au Vinciduino par la console série et/ou l'USB, ce qui permet d'utiliser le WR703N comme un "super shield" Wifi+Ethernet+USB_host et donc au vinciDuino d'accéder au réseau Internet par le Wifi, l'Ethernet filaire ou même la 3G (avec une clé USB connectée au WR703N, chose pour laquelle il est prévu à l'origine...).

Mais en plus, avec cette manip, c'est comme si on installait l'IDE Arduino SUR le WR703N!!! Par le réseau, on édite le sketch .INO à l'aide d'un éditeur Javascript (cf. ci-dessus) servi par le serveur HTTP du WR703N, puis celui-ci lance le compilateur avr-gcc pour compiler le sketch et enfin avrdude pour le flasher sur le VinciDuino, avant d'offrir la possibilité se connecteur au VinciDuino par la voie série/le port USB...

Squonk42:
Oui, en gros, voici la situation existante: le WR703N peut être relié au Vinciduino par la console série et/ou l'USB, ce qui permet d'utiliser le WR703N comme un "super shield" Wifi+Ethernet+USB_host et donc au vinciDuino d'accéder au réseau Internet par le Wifi, l'Ethernet filaire ou même la 3G (avec une clé USB connectée au WR703N, chose pour laquelle il est prévu à l'origine...).

Mais en plus, avec cette manip, c'est comme si on installait l'IDE Arduino SUR le WR703N!!! Par le réseau, on édite le sketch .INO à l'aide d'un éditeur Javascript (cf. ci-dessus) servi par le serveur HTTP du WR703N, puis celui-ci lance le compilateur avr-gcc pour compiler le sketch et enfin avrdude pour le flasher sur le VinciDuino, avant d'offrir la possibilité se connecteur au VinciDuino par la voie série/le port USB...

Bon OK
merci Squonk42, je suis rassuré encore à cette heure sur au moins ma capacité à comprendre :grin:
Challenge sympa 8)

skywodd:

Squonk42:
C'est en cours ! Je vais tenter d'écrire 3 packages OpenWRT, pour copier la structure de Debian : "binutils-avr", "gcc-avr" et "avr-libc" (cherchez l'intrus :D)

Ok ok ça semble prometteur tout ça :slight_smile:

Ca y est ! Le plus dur c'était de faire le premier package :sweat_smile: En tous cas, c'est comme ça que je me rassure ! J'ai le binutils-avr qui s'installe et qui a l'air de fonctionner, à tester plus en profondeur :

root@TL-WR703N:~# opkg info binutils-avr
Package: binutils-avr
Version: 2.22-1
Depends: libc, zlib
Provides:
Status: install user installed
Section: devel
Architecture: ar71xx
Maintainer: Michel Stempin <michel.stempin@wanadoo.fr>
MD5Sum: 6a73a66a67960ee9287a00f5c5567bf2
Size: 6098030
Filename: binutils-avr_2.22-1_ar71xx.ipk
Source: feeds/packages/devel/binutils-avr
Description: Binary utilities supporting Atmel''s AVR targets
Installed-Time: 1345064729

root@TL-WR703N:~# avr-readelf --version
GNU readelf (GNU Binutils) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

skywodd:

Squonk42:
Puis probablement un méta-package "arduino" qui inclut ces 3 là plus "avrdude" et les drivers USB pour l'Arduino.

Bonne idée, par contre pour le driver usb c'est juste du serial CDC classique (intégré de base).
Il ne devrait donc pas y avoir de modif à faire (si ce n'est de s'ajouter au groupe dialout) ?

Bon, tant mieux!

skywodd:

Squonk42:
J'ai jeté un coup d'oeil aux différentes solutions. Franchement, le bout en ruby est assez facile à traduire en Shell pur... Ils ont vraiment utilisé ruby pour se faire plaisir ! C'est vrai que celle-ci a l'air plus aboutie que la seconde, mais les 2 ne gèrent pas bien certaines choses que ino semble gérer mieux :

Il existe un autre makefile "arduino" plus poussé avec un utilitaire en perl pour parser boards.txt.
Mais la méthode pour intégrer le .mk à son makefile est un peu ... méli mélo :
http://mjo.tc/atelier/2009/02/arduino-cli.html

Y en a marre de tous ces pseudos langages, les vrais programmeurs écrivent en C ou en Shell :grin:

skywodd:

Squonk42:
Je ne connais pas nginx... C'est un serveur HTTP ? Qu'est-ce qu'il peut apporter par rapport à uhttpd qui est utilisé par Luci ?

Ouaip, c'est un serveur HTTP hyper léger mais trés puissant, surtout pour faire des applications CGI-bin.
J'utilise pas Luci personnellement, ya plein de module mais je trouve ça trop usine à gaz.

Oui, mais cela a l'air d'être le standard sur OpenWRT pour la configuration par interface Web :relaxed:

Le principal, c'est que cela soit plutôt léger en mémoire, sachant qu'il n'y aura pas énormément de connexions simultanées, et que le trafic sera faible : je comptais utiliser ACE pour la partie édition, et un maximum de JQuery + Twitter Bootstrap, en stockant les CSS/Javascript dans des fichiers séparés sur le WR703N pour bénéficier du cache navigateur. Je cherche si il n'y a pas déjà en OS une espèce d'IDE Web basée sur ACE ou équivalent...

Squonk42:
Y en a marre de tous ces pseudos langages, les vrais programmeurs écrivent en C ou en Shell :grin:

Les vrai programmeurs codent en assembleur, faut savoir parler directement avec la machine 8)
Sérieusement, tout langages à ses avantages et ses inconvénients, il n'y as pas de "pseudo langages" :wink:

Squonk42:
Oui, mais cela a l'air d'être le standard sur OpenWRT pour la configuration par interface Web :relaxed:

Sérieux ?
Moi j'arrête pas de voir du lighttpd ou du nginx sur mes routeurs/switchs, ce serait bien d'avoir un comparatif des différents serveur web et de leur empreinte mémoire.

skywodd:

Squonk42:
Y en a marre de tous ces pseudos langages, les vrais programmeurs écrivent en C ou en Shell :grin:

Les vrai programmeurs codent en assembleur, faut savoir parler directement avec la machine 8)
Sérieusement, tout langages à ses avantages et ses inconvénients, il n'y as pas de "pseudo langages" :wink:

Je blague :), j'ai arrêté de compter vers les 20 (après, je n'ai plus assez de doigts et d'orteils) ! Non, ce qui est embêtant, c'est que sur une plateforme embarquée comme ici, on ne peut pas se permettre d'avoir du compilé C/C++, du Shell, du Lua, du Python, du Perl, du Ruby, du Tcl, du JavaScript, etc.

Surtout que vu la complexité du script Perl en question, c'est tout à fait possible de faire la même chose en Shell !

skywodd:

Squonk42:
Oui, mais cela a l'air d'être le standard sur OpenWRT pour la configuration par interface Web :relaxed:

Sérieux ?
Moi j'arrête pas de voir du lighttpd ou du nginx sur mes routeurs/switchs, ce serait bien d'avoir un comparatif des différents serveur web et de leur empreinte mémoire.

Je crois que Luci peut tourner sur lighttpd aussi. Le problème, c'est que c'est difficile pour pas mal d'utilisateurs qui ne veulent pas toucher aux fichiers de config en direct de se passer de Luci, à moins de re-écrire l'équivalent, mais là c'est une autre histoire...

skywodd:

Squonk42:
Oui, mais cela a l'air d'être le standard sur OpenWRT pour la configuration par interface Web :relaxed:

Sérieux ?
Moi j'arrête pas de voir du lighttpd ou du nginx sur mes routeurs/switchs, ce serait bien d'avoir un comparatif des différents serveur web et de leur empreinte mémoire.

Ici : Web Server Overview [Old OpenWrt Wiki]

La question que je me pose c'est : Le but étant de créer un équipement dédié connecté (station météo, contrôleur domotique à-la BlyssBox etc...), associée à une (ou plusieurs Arduino) qu'est-ce qui est le plus simple/efficace ?

  1. Utiliser un serveur light comme ceux déjà listés + cgi-bin
  2. Faire un environnement (bibliothèque) tel que celles utilisées sur l'Arduino (Ethernet.server) et intégrer dans un seul exe le serveur Web, la communication avec la/les Arduino et la gestion d'ensemble de l'application.

Notamment ce qui me gène dans le cas 1, c'est l'intégration globale.
Je vois 3 composantes majeures :

  • les interactions de l'utilisateur avec le navigateur web et donc avec le serveur Web : complètement asynchrone avec le déroulement de l'application
  • les communications entre WR703 et Arduino: peut être synchrone (question/réponses) ou asynchrone (évènement extérieur, utilisateur qui presse un bouton hard / telco Blyss, ...)
  • la gestion du contexte

Le cgi-bin est entièrement lié aux requètes web. Donc la gestion de contexte et tout ce qui est indépendant de l'interaction utilisateur ne peuvent pas s'y trouver. Il faut donc une application globale qui tourne en permanence.

De la même façon que cette appli va gérer les communication avec les Arduino (serial), elle va devoir aussi communiquer avec l'utilisateur Web donc avec les cgi-bin (ou plutot ce sont les cgi-bin qui vont communiquer avec elle). Des sockets (ou des pipes ?) semble la solution la plus simple à utiliser mais cela crée une lourdeur supplémentaire car il y a un protocole de plus a gérer.

L'avantage c'est que ca peut migrer facilement sur une plateforme plus grosse ensuite en utilisant Apache+PHP par exemple.

Le cas 2 peut être suffisant pour gérer de petites applications. C'est déjà ce que l'on fait sur une Arduino Ethernet. Donc finalement pourquoi ne pas reproduire la même structure en dual-core (WR + Arduino) ?
A partir d'une certaine "taille" il est sur que ce n'est plus la bonne solution mais par exemple si on reste sur une petite application qui a 2 ou 3 pages a présenter (station météo, contrôle de porte de garage ... comme certains on envisagé) ca me semble encore une solution acceptable.

Qu'en pensez-vous ?

barbudor:
Ici : Web Server Overview [Old OpenWrt Wiki]

Pas aussi léger que ce que je pensai nginx ... en faite le plus léger / adéquat pour un site à faible traffic c'est mini-httpd d'aprés ce tableau.

barbudor:
La question que je me pose c'est : Le but étant de créer un équipement dédié connecté (station météo, contrôleur domotique à-la BlyssBox etc...), associée à une (ou plusieurs Arduino) qu'est-ce qui est le plus simple/efficace ?

  1. Utiliser un serveur light comme ceux déjà listés + cgi-bin
  2. Faire un environnement (bibliothèque) tel que celles utilisées sur l'Arduino (Ethernet.server) et intégrer dans un seul exe le serveur Web, la communication avec la/les Arduino et la gestion d'ensemble de l'application.

Notamment ce qui me gène dans le cas 1, c'est l'intégration globale.
Je vois 3 composantes majeures :

  • les interactions de l'utilisateur avec le navigateur web et donc avec le serveur Web : complètement asynchrone avec le déroulement de l'application
  • les communications entre WR703 et Arduino: peut être synchrone (question/réponses) ou asynchrone (évènement extérieur, utilisateur qui presse un bouton hard / telco Blyss, ...)
  • la gestion du contexte

Le cgi-bin est entièrement lié aux requètes web. Donc la gestion de contexte et tout ce qui est indépendant de l'interaction utilisateur ne peuvent pas s'y trouver. Il faut donc une application globale qui tourne en permanence.

De la même façon que cette appli va gérer les communication avec les Arduino (serial), elle va devoir aussi communiquer avec l'utilisateur Web donc avec les cgi-bin (ou plutot ce sont les cgi-bin qui vont communiquer avec elle). Des sockets (ou des pipes ?) semble la solution la plus simple à utiliser mais cela crée une lourdeur supplémentaire car il y a un protocole de plus a gérer.

L'avantage c'est que ca peut migrer facilement sur une plateforme plus grosse ensuite en utilisant Apache+PHP par exemple.

Le cas 2 peut être suffisant pour gérer de petites applications. C'est déjà ce que l'on fait sur une Arduino Ethernet. Donc finalement pourquoi ne pas reproduire la même structure en dual-core (WR + Arduino) ?
A partir d'une certaine "taille" il est sur que ce n'est plus la bonne solution mais par exemple si on reste sur une petite application qui a 2 ou 3 pages a présenter (station météo, contrôle de porte de garage ... comme certains on envisagé) ca me semble encore une solution acceptable.

Qu'en pensez-vous ?

En gros tu veut faire un deamon avec serveur web et gestionnaire de communication intégré ?

skywodd:
En gros tu veut faire un deamon avec serveur web et gestionnaire de communication intégré ?

En gros comme sur Arduino : seul exécutable qui gère l'interface Web, la comm. avec les périphériques (Arduino sur Serial ou autres GPIO) et l'application elle même.
Tout se qui serait "gros web" pourrait être déchargé d'ailleurs sur un hébergement externe full-LAMP.

Ca resterait une appli de type loop() qui est un noeud d'échange entre les différents modules.

Squonk42:
Quelques précisions: l'UART console du WR703N est en LVTTL (3.3 V) et pas en 2.7 V

Ayant quitté l'Ile de Beauté et mes montagnes savoyardes, de retour dans la gridsille francilienne (on sent bien le désapointement hein ?), je ressort mon WR703N, mon multimètre.
Je persiste et persiffle : je mesure bien un TXD (TP_OUT) à 2,7V ainsi que le VCC sur la résistance de pull-up R82 a coté de RXD (TP_IN).

Mon modèle est indiqué "Ver:1.6" sur l'étiquette derrière le boitier et "Rev:1.1" sur le PCB :wink:

Je viens de télécharger le Image Generator d'OpenWRT (version stable 10.03.1) mais je suis pas sur que ce soit ce qu'il faut car ce package est daté de décembre 2011.

Pouvez vous me confirmer ce qu'il faut prendre ?

1ère étape pour moi : apprendre à configurer OpenWRT pour réduire au minimum a ce qui m'interesse.
En effet l'intérêt d'OpenWRT pour moi est d'avoir une distri Linux toute prête qui support la plateforme mais je n'ai pas besoin de toute la partie WRT (Wireless Router).
Ce que je veux obtenir dans un premier temps c'est :

  • Linux
  • Busybox, shell
  • SSHd (dropbear)
  • USB Mass Storage (pour mettre une clé USB ou un adaptateur de carte uSD)
  • USB CDC Serial pour Arduino ou autres USB/TTL (CP21xx, FTDI, etc...)
  • Ethernet
  • Client Wifi (une configuration statique par fichier de config me convient très bien)

Je compte le faire d'abord avec Image Generator sans recompiler
Puis ensuite installation de OpenWRT BuildRoot, pas tant pour recompiler OpenWRT lui-même que pour faire ma propre appli qui va discuter avec l'Arduino.

A+

BOn
Ca commence bien :

  • Le WR703N (et le MR3020) ne sont pas supportés dans la backfire 10.03.1 mais uniquement dans le trunk
  • je viens de récupérer le snapshit du jour et ca ne génère pas :

Building package index...
(cd /home/barbu/openwrt/OpenWrt-ImageBuilder-ar71xx_generic-for-Linux-x86_64/packages; /home/barbu/openwrt/OpenWrt-ImageBuilder-ar71xx_generic-for-Linux-x86_64/scripts/ipkg-make-index.sh . > Packages &&
gzip -9c Packages > Packages.gz
) >/dev/null 2>/dev/null
make[2]: *** [package_index] Error 126
make[2]: Leaving directory /home/barbu/openwrt/OpenWrt-ImageBuilder-ar71xx_generic-for-Linux-x86_64' make[1]: *** [_call_image] Error 2 make[1]: Leaving directory /home/barbu/openwrt/OpenWrt-ImageBuilder-ar71xx_generic-for-Linux-x86_64'
make: *** Erreur 2[/quote]

problème qui ne vient pas de moi apparemment : #11943 (28-Jul-2012 /snapshots/trunk/x86/OpenWrt-ImageBuilder-x86_generic-for-Linux-x86_64 make error) – OpenWrt

Donc apparemment il va falloir que je me mette à Buildroot plus tôt que prévu =(

Vous n'avez pas eu de problème particulier ?
Il suffit de suivre les indications ?

PS: Je suis partit sur un host en Xubuntu (simple, facile pour un non Linuxien comme moué). Mais apparemment la team OpenWRT est plutôt Arch linux qui me semble un peu trop "streamline" pour moi :wink:
Vous utilisez quoi de votre coté ?

barbudor:
Je persiste et persiffle : je mesure bien un TXD (TP_OUT) à 2,7V ainsi que le VCC sur la résistance de pull-up R82 a coté de RXD (TP_IN).

Mon modèle est indiqué "Ver:1.6" sur l'étiquette derrière le boitier et "Rev:1.1" sur le PCB :wink:

Il n'y a eu a priori que 2 versions de PCB: 1.0 (peu répandue) et 1.1, donc ce n'est pas un problème de version. J'ai d'ailleurs détaillé le PCB 1.1 composant par composant dans le Wiki OpenWRT, et d'après les points de tests dûment étiquetés, il y a du 3,3 V, du 2,5 V, du 2,0 V et du 1,2 V, toutes ces tensions ayant une utilité identifiée.

C'est peut-être tout simplement un problème d'alimentation ? Ou alors ton multimètre qui a une résistance d'entrée trop faible ? j'ai déjà eu le cas avec un multimètre chinois à 10 euros... J'ai plus tendance à croire un scope avec une sonde calibrée 1 Mohms /20 pF, d'abord parce que c'est calibré et ensuite parce que je peux voir le résultat !

Mais après tout, qu'importe ? Mon WR703N tourne avec une adaptateur LVTTL (3,3 V) / USB depuis 6 mois sans soucis :grin:

barbudor:
Je viens de télécharger le Image Generator d'OpenWRT (version stable 10.03.1) mais je suis pas sur que ce soit ce qu'il faut car ce package est daté de décembre 2011.

Pouvez vous me confirmer ce qu'il faut prendre ?

1ère étape pour moi : apprendre à configurer OpenWRT pour réduire au minimum a ce qui m'interesse.
En effet l'intérêt d'OpenWRT pour moi est d'avoir une distri Linux toute prête qui support la plateforme mais je n'ai pas besoin de toute la partie WRT (Wireless Router).
Ce que je veux obtenir dans un premier temps c'est :

  • Linux
  • Busybox, shell
  • SSHd (dropbear)
  • USB Mass Storage (pour mettre une clé USB ou un adaptateur de carte uSD)
  • USB CDC Serial pour Arduino ou autres USB/TTL (CP21xx, FTDI, etc...)
  • Ethernet
  • Client Wifi (une configuration statique par fichier de config me convient très bien)

Je compte le faire d'abord avec Image Generator sans recompiler

Le "Image Generator" est plutôt fait pour rajouter des packages que pour en enlever. Le système de base est assez interdépendant au niveau des packages installés, et la seule façon d'enlever des choses va passer par une configuration des options de ces packages et une recompilation :sweat_smile:

Et de toutes façons, il faut absolument partir du "trunk" avec Subversion ou un "snapshot" (vaut mieux le SVN !), car le WR703N n'est pas encore supporté dans les versions stables.

Après, il suffit de suivre à la lettre le Wiki OpenWRT (installation et utilisation).

barbudor:
Vous n'avez pas eu de problème particulier ?
Il suffit de suivre les indications ?

Ouaip,

cd ~
svn co svn://svn.openwrt.org/openwrt/trunk/ openwrt
cd openwrt
./script/feeds update -a
./script/feeds install -a
make menuconfig
# --> tu fait ta config comme tu l'entend
make -Jx (remplace x par le nombre de cœur de ton cpu)
# --> tu patiente entre 10 minutes (i7 8 coeurs) et 4 heures (celeron dual core)
# Ton firmware et son rootfs se trouve dans le dossier "bin/lenomducpu"
# Ta toolchain pour la compilation se trouve dans le dossier "staging_dir"

Si tu veut je peut te faire un screencast :wink:
(mais avec la ngw100 comme cible pour la compilation)

barbudor:
PS: Je suis partit sur un host en Xubuntu (simple, facile pour un non Linuxien comme moué). Mais apparemment la team OpenWRT est plutôt Arch linux qui me semble un peu trop "streamline" pour moi :wink:
Vous utilisez quoi de votre coté ?

MINT 13 avec plein de modif kernel / paquets custom de partout :sweat_smile:

barbudor:

Building package index...
(cd /home/barbu/openwrt/OpenWrt-ImageBuilder-ar71xx_generic-for-Linux-x86_64/packages; /home/barbu/openwrt/OpenWrt-ImageBuilder-ar71xx_generic-for-Linux-x86_64/scripts/ipkg-make-index.sh . > Packages &&
gzip -9c Packages > Packages.gz
) >/dev/null 2>/dev/null
make[2]: *** [package_index] Error 126
make[2]: Leaving directory /home/barbu/openwrt/OpenWrt-ImageBuilder-ar71xx_generic-for-Linux-x86_64' make[1]: *** [_call_image] Error 2 make[1]: Leaving directory /home/barbu/openwrt/OpenWrt-ImageBuilder-ar71xx_generic-for-Linux-x86_64'
make: *** Erreur 2[/quote]

problème qui ne vient pas de moi apparemment : #11943 (28-Jul-2012 /snapshots/trunk/x86/OpenWrt-ImageBuilder-x86_generic-for-Linux-x86_64 make error) – OpenWrt

Donc apparemment il va falloir que je me mette à Buildroot plus tôt que prévu =(

Vous n'avez pas eu de problème particulier ?
Il suffit de suivre les indications ?

PS: Je suis partit sur un host en Xubuntu (simple, facile pour un non Linuxien comme moué). Mais apparemment la team OpenWRT est plutôt Arch linux qui me semble un peu trop "streamline" pour moi :wink:
Vous utilisez quoi de votre coté ?

[/quote]
J'utilise Ubuntu 12.04 LTS, remis à jour périodiquement depuis au moins 2 ou 3 ans.

Un piège classique avec les xxxUbuntu est que ceux-ci remplacent le Shell "bash" par un Shell "dash" qui est sensé être plus rapide pour le boot (ça reste à prouver :~), mais qui casse les scripts shell de compilation...

Un moyen de vériefier est de taper :

ls -l /bin/sh

lrwxrwxrwx 1 root root 4 août  11 19:25 /bin/sh -> bash




Si le tiens point sur "dash": bingo !

Il faut alors changer de shell en tapant:


sudo update-alternatives --install /bin/sh sh /bin/bash 100

skywodd:

make -Jx (remplace x par le nombre de cœur de ton cpu)

En fait, il faut faire :

make -j x (remplace x par le nombre de cœurs de ton cpu + 1)

Ou mieux, utiliser "ccache", mais c'est plutôt délicat à faire marcher comme il faut :stuck_out_tongue:

Squonk42:
En fait, il faut faire :

make -j x (remplace x par le nombre de cœurs de ton cpu + 1)

J'ai jamais compris ce +1, puisse qu'au final tu as un nombre limité physiquement de threads ... +1 ou non ton cpu peut pas exécuter un nombre illimité de chose en parallèle ...
Du reste en regardant le man de make et les différentes doc sur le web tu trouve de tout, nb_threads, nb_threads + 1, ... :zipper_mouth_face:

Ps: en argument CLI unix que tu fasse -J8 ou -J 8 ça revient à la même chose.

Squonk42:
Ou mieux, utiliser "ccache", mais c'est plutôt délicat à faire marcher comme il faut :stuck_out_tongue:

J'utilise ccache, mais c'est utile uniquement pour les recompilations incrémentielles, pas pour la premier compilation complète.
Mais c'est un gros bordel pour activer ccache dans menuconfig donc je préfére pas perdre barbudor avec.

skywodd:

Squonk42:
En fait, il faut faire :

make -j x (remplace x par le nombre de cœurs de ton cpu + 1)

J'ai jamais compris ce +1, puisse qu'au final tu as un nombre limité physiquement de threads ... +1 ou non ton cpu peut pas exécuter un nombre illimité de chose en parallèle ...
Du reste en regardant le man de make et les différentes doc sur le web tu trouve de tout, nb_threads, nb_threads + 1, ... :zipper_mouth_face:

D'après ce que j'ai pu voir à droite et à gauche (j'ai du mal à me souvenir où :blush:), cela correspond effectivement au nombre de "jobs" (et donc de "threads"), mais il y a toujours un thread principal qui lui ne fait qu'attendre la fin des autres.

skywodd:
Ps: en argument CLI unix que tu fasse -J8 ou -J 8 ça revient à la même chose.

Oui, par contre, n'est ce pas "j" minuscule et pas "J" majuscule ?

skywodd:

Squonk42:
Ou mieux, utiliser "ccache", mais c'est plutôt délicat à faire marcher comme il faut :stuck_out_tongue:

J'utilise ccache, mais c'est utile uniquement pour les recompilations incrémentielles, pas pour la premier compilation complète.
Mais c'est un gros bordel pour activer ccache dans menuconfig donc je préfére pas perdre barbudor avec.

C'est vrai que c'est un peu brutal comme mise en bouche :grin:

Squonk42:
D'après ce que j'ai pu voir à droite et à gauche (j'ai du mal à me souvenir où :blush:), cela correspond effectivement au nombre de "jobs" (et donc de "threads"), mais il y a toujours un thread principal qui lui ne fait qu'attendre la fin des autres.

... ouai, faudrait que je regarde ça de plus prés.

Squonk42:
Oui, par contre, n'est ce pas "j" minuscule et pas "J" majuscule ?

Oui c'est j et non J ... petit bug de l'interface chaise / clavier :grin:

Squonk42:
C'est vrai que c'est un peu brutal comme mise en bouche :grin:

Bon par contre quand la première compilation est finit les suivantes sont hyper rapide 8)