WR703N + VinciDuino

2 excellentes nouvelles concernant le couple WR703N + VinciDuino :

  • J'ai réussi à compiler et flasher des sketches Arduino en ligne de commande sur mon PC Linux Ubuntu 12.04 LTS grâce à ino
  • Et là je pense que c'est une première : j'ai réussi à compiler du code AVR en ligne de commande sur le WR703N (pas encore de sketches, mais j'y travaille !)

Pour le premier point, j'ai commencé par compiler depuis scratch en cible avr sur mon PC Linux binutils + gcc + avr-libc + avrdude, en suivant le tuto d'avr-libc. A part qu'avant de compiler gcc, il faut copier les sources des packages gmp + mpfr + mpc dans l'arborescence de gcc dans des sous-répertoires "gmp", "mpfr" et "mpc", respectivement (cf. la section... "Tools Required for Building the Toolchain for Windows" :D), tout ça se déroule comme décrit.

En ce qui concerne la partie Arduino proprement dite, il faut d'abord installer (si ce n'est déjà fait) le distribution Arduino pour Linux. Il faut également installer Python (probablement déjà présent) et picocom et enfin ino en suivant le tuto ino.

Pour l'utilisation en ligne de commande de l'Arduino, il suffit alors de suivre le QuickStart. Je conseille toutefois de créer dès que possible le fichier "ino.ini" décrit à la fin du QuickStart, pour éviter d'avoir à saisir la carte et le port série pour toutes les commandes.

Pour le deuxième point, à savoir compiler du code AVR sur le WR703N, il a fallut que je cross-compile binutils + gcc dans une configuration appelée "Canadian Cross", c-à-d avec une machine de compilation Linux PC, une machine sur laquelle va s'exécuter le compilateur Mips24Kc, et une cible AVR. Là, je suis tombé sur 2 petits bugs : un problème de warning sur variables masquées dans binutils MIPS32 qui se termine en erreur, et un problème de changement de syntaxe assembleur "gas" dans mpfr. Notez qu'il n'y a pas besoin de recompiler avr-libc pour le MIPS, car les binaires sont déjà destinés à l'AVR. avrdude quant à lui est déjà disponible en tant que package pour OpenWRT, ainsi que picocom.

Il me reste maintenant à faire marcher ino sur le WR703N pour pouvoir compiler des sketches Arduino sur le WR703N... Pour cela, il faut que je fasse marcher Python et les dépendances requises par ino sur OpenWRT.

Notez que vu la taille de la chaîne de compilation, il faut absolument utiliser un "extroot" sur clé USB, cela ne tient pas (et de loin :sweat_smile:) sur la Flash SPI de 4MB.

Squonk42: Pour le build de la toolchain avr-gcc tu t'est cassé la tête pour rien (enfin je crois bien) https://dev.openwrt.org/ticket/8885 (et pour avrdude le package est intégré dans les feeds openWRT)

Pour la compilation arduino en CLI, moyennant un interpréteur ruby il y a un makefile avec générateur de code intégré ici : https://github.com/takanuva/arduino-makefile

Ou encore la version classique en "pure makefile" : http://arduino.cc/playground/OpenBSD/CLI

skywodd: Squonk42: Pour le build de la toolchain avr-gcc tu t'est cassé la tête pour rien (enfin je crois bien) https://dev.openwrt.org/ticket/8885 (et pour avrdude le package est intégré dans les feeds openWRT)

Pour la compilation arduino en CLI, moyennant un interpréteur ruby il y a un makefile avec générateur de code intégré ici : https://github.com/takanuva/arduino-makefile

Ou encore la version classique en "pure makefile" : http://arduino.cc/playground/OpenBSD/CLI

Bon d'accord, ce n'est pas une première alors =( EDIT: si, si, c'est une première ! Le ticket était une demande pour porter avr-gcc sous OpenWRT, mais cela n'a jamais été réalisé, et le ticket a été fermé il y a 8 jours comme "wontfix"...

Mais le ticket en question date de 18 mois, et le script de construction qui y figure de 2009 ! Pire, les packages binutils-2.17, avr-libc-1.4.6 et gcc-4.1.2 datent de 2007 !!!

J'ai vérifié un par un tous les patches cités : ils ont été intégrés depuis belle lurette et sont donc obsolètes. Il y a même encore dedans le support pour le format binaire COFF qui n'est plus utilisé. Il manque aussi la plupart des CPU récents, comme les ATmega128x et ATxmega et je crois aussi le support pour les petits ATtiny1x.

Pour ma part, j'ai compilé la toolchain avec les dernières versions stables, à savoir:

  • avr-libc-1.8.0
  • binutils-2.22
  • gcc-4.7.1
  • gmp-4.3.2
  • mpc-0.8.1
  • mpfr-2.4.2

Je n'ai pas recompilé avrdude pour le WR703N, car j'avais vu qu'il était déjà disponible en tant que package .ipkg.

Par contre, pour la compilation Arduino en CLI, je suis confus :~ Quel est l'outil le plus abouti ? Quelqu'un a-t-il une expérience avec les différentes solutions ?

Vous vous demandez peut-être pourquoi suis-je si excité tout d'un coup par la compilation en CLI ?

Mon but avec le CLI est de pouvoir automatiser la compilation et le flashage de sketches Arduino sur le WR703N, de manière à intégrer cela dans une interface Web basée sur uhttpd et un éditeur Javascript de grande classe (Ace, à voir absolument : la démo live). Comme c'est du Javascript, cela tourne dans le navigateur client, et est donc très interactif, sans nécessiter de ressources de la part du "petit" WR703N.

Ainsi, non seulement le WR703N est un "super shield" Wifi+Ethernet+USB_host pour le VinciDuino, mais on obtient alors un environnement de programmation Arduino complètement autonome, accessible par un navigateur Web sans aucune installation sur le PC/Mac, tout ça dans une boîte de 6 cm x 6 cm (de la même taille que le VinciDuino) :astonished:

Squonk42: EDIT: si, si, c'est une première ! Le ticket était une demande pour porter avr-gcc sous OpenWRT, mais cela n'a jamais été réalisé, et le ticket a été fermé il y a 8 jours comme "wontfix"...

Mais le ticket en question date de 18 mois, et le script de construction qui y figure de 2009 ! Pire, les packages binutils-2.17, avr-libc-1.4.6 et gcc-4.1.2 datent de 2007 !!!

J'avais pas vu, effectivement c'est vieux comme ticket ... Bon reste plus qu'as faire un patch/paquet et tenter de le proposer sur le svn de openWRT :sweat_smile:

Squonk42: Par contre, pour la compilation Arduino en CLI, je suis confus :~ Quel est l'outil le plus abouti ? Quelqu'un a-t-il une expérience avec les différentes solutions ?

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).

Squonk42: Mon but avec le CLI est de pouvoir automatiser la compilation et le flashage de sketches Arduino sur le WR703N, de manière à intégrer cela dans une interface Web basée sur uhttpd et un éditeur Javascript de grande classe (Ace, à voir absolument : la démo live). Comme c'est du Javascript, cela tourne dans le navigateur client, et est donc très interactif, sans nécessiter de ressources de la part du "petit" WR703N.

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.

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 :)

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 :)

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 
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" ;)

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" ;)

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 : http://wiki.openwrt.org/doc/howto/http.overview

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 : http://wiki.openwrt.org/doc/howto/http.overview

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 ;)

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 snap*shit* 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 : https://dev.openwrt.org/ticket/11943

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 ;) 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 ;)

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 ;) (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 ;) 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 : https://dev.openwrt.org/ticket/11943

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 ;) 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