[LA-discussions] Re: [LA-discussions] Fonera avec OpenWrt et bus I2C - Appel à l'aide !!

[RAULT Alexandre <rault.alexandre@xxxxxxxxx>]

Le 11 mars 2009 15:15, neomilium <neomilium@xxxxxxxxx> a écrit :
> Salut Alex,
>
> Le mardi 10 mars 2009 21:27:54 RAULT Alexandre, vous avez écrit :
>> dans mes "amusements", je cherche à modifier un routeur wifi pour en
>> faire un petit serveur d'interface avec le monde extérieur....
>> [...]
>> Dans la pratique, je me base sur un routeur Fonera dont le firmware
>> est remplacé par Open-WRT ( http://fr.wikipedia.org/wiki/OpenWrt )

> Tu as quel modèle de Fonera ? Et quelle version d'OpenWrt tu utilise ?
Fonera version 1 alias la 2100, compilation de quelques infos sur
http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera
associé à Open-WRT 8.09 ou Trunk (mais j'ai pas trouvé de différence,
donc, ce sera 8.09)

>
> Tu dis pouvoir utiliser les GPIO 3 , 4 , 1 et 7, as tu tester de les faire
> changer d'état avec gpioctl et de voir si tu as bien le niveau logique voulu
> sur la broche correspondante ?
>
Et bien je viens d'essayer avec quatres p'tiotes led alimentés par un
repiquage du +5 de la Fonera et une résistance dans chaque ligne GPIO
:

Lignes GPIO 3, 4, 1 et 7 respectivements sur leds #1, #2, #3, #4

Au boot, les états sont 'incertains', puis, passe visiblement à 0
(sorties à collecteurs ouverts à priori)
Dans la console ça fini en
i2c /dev entries driver
i2c-gpio: probe failed: -19

gpioctl set 3  => Led #1 s'allume franchement gpioctl clear 3  => Led
#1 s'éteint vaguement (je n'ai pas mis de pull-up)
Pareil pour toutes les autres

gpioctl dirin 3 puis 4 puis 1 et 7 suivi d'un gpioctl get => etat High
reporté (les leds tire un +5V)
déconnexion des leds, gpioctl get => etat Low reporté

Donc, tout ça est OK

>
>> Dans Open-WRT, j'ai la possibilité d'inclure des modules qui sont en
>> principe la solution, mais impossible de trouver de la doc pour les
>> exploiter !
> As tu essayer de flasher ta fonera avec la version utilisée dans l'article ? À
> defaut d'avoir un firmware dernier cri, tu auras peut-être un truc fonctionnel.
>
Non... c'est peut-être une solution, mais je prefère aller de l'avant :D
En fait, Denis lui même regarde car ça à pas mal changé et par rapport
à ce qu'il avait fait, ce serais plus efficace...

>> Par exemple, dans le module
>> https://dev.openwrt.org/browser/trunk/package/i2c-gpio-custom/src une
>> ligne décrit les arguments à passer, mais aucune info détaillées
>> d'utilisation du module :s
> Malheureusement, la doc c'est le code dans ce cas ^^
>
>> Par exemple, dans le montage de Denis Bodor, pour chaque ligne du bus
>> (Sda et Scl) qui doivent être bidirectionnelles, il utilise un GPIO en
>> entrée, et un autre en sortie, mais a priori, avec les nouveaux
>> modules ce n'est plus le cas !

> D'après ce qui est écrit dans les sources de i2c-gpio-custom, ce module permet
> de créer jusqu'à quatre bus i2c mais chaque bus i2c se voit attribuer 1 seul
> GPIO par ligne (SDA, SCL). Ce qui ne correspond pas au montage fourni sur
> lefinnois.

En fait, étrangement, gpio-custom ne semble pas compilé avec open-wrt.....
Tout ça semble remplacé par I2C-Core et la suite , et c'est un peu ce
qui me pousse à ne pas reprendre le travail de Denis mais à regarder
un peu plus loin, car il y a des packages liés qui permettent à priori
de faire exactement ce que je veux ! : i2c_algo_pcf par exemple
devrait simplifier le pilotage du PCF8574
>

> Si le module I2C est bien fait, il placera lui même les GPIO dans la bonne
> config.
>
Comme tu dis, si le module est bien fait... et qu'on lui passe les
bons paramètres peut-être (c'est là que la doc me manque !)
Donc, au boot, j'ai actuellement pour la partie GPIO / I²C :    (le
pastebin complet est disponnible sur http://pastebin.com/m40d7d4cb )
[.....]
ar531x: Registering GPIODEV device
[.....]
io scheduler noop registered
io scheduler deadline registered (default)
gpiodev: gpio device registered with major 254
gpiodev: gpio platform device registered with access mask FFFFFFFF
[.....]
Registered led device: gpio1
Registered led device: wlan
Registered led device: gpio3

Registered led device: gpio4
Registered led device: gpio7
[.....]
i2c /dev entries driver
i2c-gpio: probe failed: -19

un p'tit lsmod nous ressort :
i2c_algo_pcf            4336  0
i2c_algo_pca            4080  0
i2c_algo_bit            5264  0
i2c_dev                 4400  0
i2c_core               12912  4 i2c_algo_pcf,i2c_algo_pca,i2c_algo_bit,i2c_dev




>
> Sinon, il est possible faire quelques recherches pour voir s'il n'est pas
> possible de faire un bus i2c sur 2 fils avec la fonera. Il a d'ailleurs un
> commentaire sur le site lefinnois qui pose la question de la pertinence de
> l'utilisation de 4 pins + un CI, voici la réponse donné par Denis Bodor :
>
> " Le composant TTL permet aussi et surtout d’adapter les tensions. Sauf erreur
> de ma part, un bus i2c est en standardisé en 5V or La Fonera est en 3.3 (avec
> une tolérance au 5V). Pour ce qui est de l’économie des pins, La Fonera est
> déjà très lente, changer le sens des GPIO risque de ralentir encore davantage
> les choses. Enfin, rien ne montre que les GPIO du routeur sont à collecteurs
> ouverts ou peuvent être configurés comme tel (comme sur un microcontrôleur AVR
> ou autre, tri-state machin-truc). Mais oui, effectivement, il faudrait pousser
> les recherches dans ce sens. Pouvoir utiliser 2 pins au lieu de 4 est très
> intéressant vu le nombre réduit d’E/S. On pourrait ainsi avoir deux bus i2c
> très facilement.
> Enfin, question vitesse, je viens de me rendre compte que les connecteurs sur
> SW1 disposent de résistances de rappel à la masse et de capa CMS. Le tout
> formant donc un réseau RC il me semble. Les problèmes de lenteur proviennent
> sans doute de là. De plus, différentes discussions sur le forum OpenWRT
> Kamikaze concernant l’utilisation de carte SD/MMC précisent qu’il faut
> déssouder ces capa et ces résistances… encore une piste à suivre…"
>
Oui, les condos qui doivent servir d'anti rebond sont déjà dessoudés
chez moi :D (je les avais repérés avant de lire cette infos :p)
Pour ce qui est de la tension j'ai fait la même remarque à Denis, le
PCF8574 et le DS75, d'après les datasheet, sont données pour
fonctionner à partir de +2,7V, donc, je serais bien partant de rester
en 3.3V partout

> En espèrant que ça puisse t'aider...
>
Oui, j'avance

> PS: Tiens nous au courant de l'évolution du projet, il m'interresse beaucoup
> pour un éventuel futur projet ^^
>
> --
> neomilium
>
Tu risque d'en entendre parler plus que tu ne pourra en supporter.... Héhéhé :p
Dans tout les cas, comme tu va venir à SL (hein que tu viens..?) tu
verra le proto, peut-être en cours de dev :p

J'aimerais d'ailleurs bien pouvoir présenter une maquette avec une
ampoule pilotée par la fonera qui fait chauffer un carré de tole sur
laquelle on aurait un DS75 (la tôle sert à donner un peu d'inertie
simulant le temps de réaction de la chaudière)

Alors, en admettant que la suite "i2c_core" et ses enfants
"i2c_algo_pcf,i2c_algo_pca,i2c_algo_bit,i2c_dev" fonctionnent, comment
que je cause avec pour définir que je veux fabriquer un bus I2C
arbitrairement nommé 'bus 0' :
Le top :
 Sda0 = GPIO 3 et Scl0 = GPIO4 si le bus se contente de 2 I/O et en
3.3V direct non bufferisé
Ça ira quand même :
 Sda0out = GPIO 3 et Sda0in = GPIO4  +  Scl0out = GPIO 1 et Scl0in =
GPIO7 si le bus à besoin de 2 sorties et 2 entrées , et si c'est le
cas, il faut que les 'out' soient logiciellement inversées pour passer
la première porte du 74SL05 et sortir dans le bon sens...

Pour le moment, j'ai un /dev/gpio mais qui ne sort rien avec un cat...
Si j'enlève tout les modules et que je les recharges les uns après les
autres avec un dmesg entre chaque j'ai :
insmod i2c-core > ras
insmod i2c-dev  > i2c /dev entries driver  (cat /dev/gpio ==> cat:
read error: Invalid argument)
insmod i2c-gpio  vomis :
--i2c_gpio: Unknown symbol i2c_bit_add_numbered_bus
--insmod: cannot insert '/lib/modules/2.6.26.8/i2c-gpio.ko': unknown
symbol in module (-1): No such file or directory
et dmesg > i2c_gpio: Unknown symbol i2c_bit_add_numbered_bus
insmod i2c-algo-bit > RAS
insmod i2c-algo-pcf > RAS
insmod i2c-algo-pca > RAS
insmod i2c-gpio
i2c-gpio: probe failed: -19
 - insmod: cannot insert '/lib/modules/2.6.26.8/i2c-gpio.ko': No such
device (-1): No such device
i2c_gpio: Unknown symbol i2c_bit_add_numbered_bus
i2c-gpio: probe failed: -19

La grosse interrogation actuelle : i2c-gpio a peut-être besoin de
paramètres voir d'un bus I2C réellement connecté....

Avant d'essayer de connecter quelquechose, je pense mettre tout en
gpioctl dirin pour éviter de balancer un VCC ou du +5 sur une sortie à
l'état 0V.... ?
Dans tout les cas, si j'arrive à gérer un peu ce bazard, j'ai
l'oscillo pour 'voir' ce qui se passe avant de brancher quoi que ce
soit.

Allez, pour ce soir, je laisse :D

Alex.

---
Liste de discussions de LinuxArverne
http://wiki.linuxarverne.org/listes_de_diffusion