I2C

Nah, not precisely that device, but quite close.

I've been lucky working on embedded systems over the last 7 years (wow. Yeah. that many already), and being part of the engineering of one for at least the last 4. I mean, my colleagues really put together chips on a multi-layer PCB following chipmaker's guidelines and their tools advice and their knowledge so that high-speed signals would arrive clean and timely where they are expected.

We eventually received a first batch of prototype and I felt like I was part of the Playstation design team while we were bringing up the board, one chip at a time, adding custom software scripts so that the hardware teams would have signals to monitor and assess whether the hardware produced was meeting the expected quality (sometimes it did, sometimes it didn't. Hopefully, there were plenty of 0-ohm resistor and not-stuffed-pull-up/low resistors on the PCB design to adjust things. Clever they).

Many of the chips we used (like HDMI receiver/transmitters, power management IC, audio CODEC and even the FPGA) are meant to work mostly standalone, but they still need to get configuration at some point. Like telling the codec which samplerate it should run at and whether it should produced 8-bit or 16-bit values. Sometimes we want to read information from them, like the board temperature or the signal resolution the HDMI receiver got. For all this, I had I2C.

And not quite that SoC, but an OMAP anyway...

I2C is a bus, connecting 2 or more chips. I has one master chip and multiple subordinate chips. Communication always happens when the master says so. It either reads (asks for data) or writes (sends data), but there is no 'interrupt' signal flowing back part of the I2C bus, nor can you have sub-to-sub communications over the bus. Unlike ISA that connected my soundBlaster and my trident SVGA cards to my 80386 CPU, the I2C uses only 2 lines: one clock line and one data line. The goal is obviously to make it as cheap as possible for chips to support it.

Let's think of it from a network guy perspective. ISA and PCI busses (and even USB) try to offer as much bandwidth as technically possible because they'll have to transmit bulks of data. I2C is the out-of-band technology you'd use next to a (r/h)igh(t) bandwidth solution you use for your data blasts. The audio CODEC chip had I2S lines dedicated to sound transport. The HDMI chip had BT1120 interface for the same purpose. At best these media busses had additional lines notifying 'start of frame', but you couldn't use them to deliver status information, and most of the time, chips using them were hard-wired as either transmitter or receiver on those lines, so using them to send configuration would be electrically dangerous to the chips.

The brilliant part in I2C is that the two chips using it don't need to agree on any speed nor be clocked with the same crystal: bits from the DATA line are sampled only when the CLK line rises. That gives the opportunity to have special 'START' and 'STOP' encoding that would otherwise be invalid. For instance, changing the DATA line while the CLK line is in a-priori requesting the DATA not to change.

Most of the systems I've worked with had dedicated I2C driving units that would handle bits transmission after you indicated one or more bytes in a FIFO buffer and the device identifier in another register. But you may also simply use a generic-purpose I/O line as DATA and another one as CLK. That will work whatever the speed of your CPU.

Much like ISA soundblaster cards would use only one of 0x220, 0x240, 0x260 or 0x280 port for their control register, an I2C-compatible sound chip would e.g. only react to chip ID 0x22, 0x24, 0x26 or 0x28. And much like you had jumpers on your soundblaster card to pick something else than 0x220 if you happened to have a tape reading device using that port as well (or too soundblaster, lucky weirdo :-D), your I2C chip will typically feature some configuration pin that you can wire to ground or VCC to pick one of the available IDs.

Il est où le wifi ?

Le portail Wifi qui nous connectait au monde de Bilou s'est effondré. Les forces de l'empire Télétravail ont fait intrusion, entendant stabiliser leur hyper-tunnel privé sécurisé contre les fluctuations de l'étoile 192.168.0.24. Résultat, tout le système stellaire a été basculé en WPA alors que l'astro-cruiser ne peut communiquer qu'en WEP.

J'avais envoyé sur place ma sonde ZD1201 qui m'avait déjà tiré d'affaire quelques fois, mais si la DS peut bien voir le nouveau réseau, par contre, je n'ai pas encore réussi à m'y connecter. Echec à la première tentative. Freeze de la DS à la seconde (dans runMe). Serait-ce lié au fait que je n'ai pas su définir de clé WEP pour le nouveau réseau ?

Je n'ai plus le concierge-Mario Kart, mais j'ai un menu de configuration wifi dans Phantom Hourglass ... qui ne fait guère mieux. Le pilote est maintenant maintenu par les gens du Noyau et son firmware est pré-distribué par la Fédération Ubuntu.

The WorkFromHome Empire has struck hard the WiFi portal that allowed me to communicate with Bilou and Bouli. I had to accept a new modem/router device so that their secured hyper-tunnel would get shielded against pulstar 192.168.0.24, but the result is that the whole stellar system now has to use WPA instead of WEP. And unfortunately, the DeepSpace cruiser of Bilou and Bouli only communicates over WEP.

I hopefully managed to recover my ZD1201 probe and dispatch it in the quadrant. It had proven effective to recover WiFi portals a couple of times already. The good news is that it is now part of Ubuntu Federation and their Kernel Teams' standard tools. It was quite trivial to confirm that the probe was accepted as an access point by the DeepSpace cruiser. Getting it in sync with that access point proved more complicated.

Wireshark restait muet. Ce n'est pas surprenant: si les paramètres de chiffrement sont incorrects, le stick wifi ne reconnaîtra pas les ondes comme étant un paquet pour lui et ne passera rien à la pile réseau Linux.

Mais ça c'était hier. Je viens de refaire un essai avec la tablette de ma fée d'abord, puis à nouveau avec Phantom Hourglass et je vois enfin des requêtes DHCP dans wireshark. Dont une avec une adresse MAC de chez Nintendo. Tout espoir n'est donc pas perdu.

Par contre, le logiciel que j'avais utilisé à l'époque pour le DHCP n'est plus distribué par Ubuntu qui lui a préféré UDHCPD, l'implémentation interne à BusyBox (dont il faudra que je vous reparle). Donc,

# The interface that udhcpd will use
interface enx00cafe00babe # default: eth0

devrait me permettre d'être serveur DHCP sur le stick wifi (à l'adresse MAC improbable 00:ca:fe:00:ba:be) tout en restant client sur les autres.

J'avais tenté d'utiliser une adresse statique hier, évidemment, mais sans succès. Au moindre test de connexion, le logiciel WFC sur la DS me lâchait juste un "paramètres incorrects". En réalité, si on désactive les requêtes DHCP sur la DS, il faut impérativement fournir *tous* les paramètres, y compris la passerelle à utiliser, le DNS, etc. j'ai probablement été un peu négligent là-dessus.

Running a similar test with my fairy's tablet proved it could be working, even without setting a WEP key (no clue how to define that with iwconfig properly, and not sure the ZD probe supports it). But if I try and use static IP address instead of configuring a DHCP server on the laptop attached to the probe, then I need to configure *all* the network parameter manually -- including Gateway and DNS -- else Phantom Hourglass' WFC manager would just shout "invalid parameters" and that's it.

So I finally got the MAC address of the Nintendo DS showing up in wireshark, proving that WEP handshaking worked. Now I'll have to find a way to mimmic the DHCP configuration I once used for udhcpd, the BusyBox-related tool Ubuntu Federation integrated to replace the legacy thing I knew. To be continued.

Affaire à suivre. Pourvu que nos héros tiennent bon.

Quand j'aurai pu vérifier que ça fonctionne, il me restera à créer une liste de règles iptables propres aux échanges avec les Nintendo DS (disons DSIN), y rediriger le traffic entrant venant d'une adresse MAC de NDS (/sbin/iptables -A INPUT -m mac --mac-source 00:0F:EA:91:04:08 -j DSIN) et jeter tout le reste qui vient de l'interface supplémentaire-et-non-protégée. (/sbin/iptables -A INPUT -i enx00cafe00babe -j DROP)

Pas vraiment un Zelda ?

Bon, ça fait quelques semaines, maintenant que j'ai fini Breath of the Wild, et je dois bien dire que c'était un très bon jeu. Ça au moins, ça ne fait pas de doute. Par contre, est-ce vraiment un Zelda ? Les personnages sont là, c'est indéniables, mais la série Zelda, c'est un gameplay en plus d'un univers. La série a commencé avec un gameplay "sauce soja" avec des ennemis qui mettent l'accent sur la mobilité et des donjons à clés.

Occarina of Time a lancé un deuxième type de gameplay "au ketchup" avec des ennemis qui mettent l'accent sur la visée et des donjons tordus dans tous les sens. Mais que l'on soit dans l'un ou l'autre il y a un nombre significatif de mécaniques de jeu qui sont restées inchangées. Les petits coeurs dans les buissons ou les clés-du-boss. Les items qui servent à la fois d'arme et de moyen de transport, et qui doivent être acquis à la sueur de nos neurones dans les donjons.

Breath of the Wild donne un gros coup de pied dans tout ça. Tous les objets spéciaux sont concentrés dans le prélude (équivalent de la période "trois talismans" pour les habitués de LttP ou OoT). Des armes à durée limitée et un stock de plats cuisinés à partir d'objets ramassés pendant la quête qu'on peut manger même au milieu d'un combat de boss. J'ai commencé par penser qu'on était sur une troisième sauce (disons "moutarde  l'ancienne"), mais à voir un peu la diversité de la licence à l'occasion du Zeldathon, en particulier les "Hyrule Warriors", je me dis que Breath of the Wild est peut-être plus proche d'un nouveau plat que d'une nouvelle sauce.

3-rooms todo board

The 'todo board' for School Zone worked quite well. Maybe I should make one for my "3 rooms" milestone, given how unlikely I am to do large amount of work for homebrew project these days...

(Well the milestone description for "3 rooms" is in itself a sort of todo-board; just focusing less on what is not going well right now)

And in case you see Bilou heads all over the place again, make sure you get a look back at that Bug Punch post...

Un montage graphique pour me rappeler de ce que j'ai à corriger, ça n'avait pas trop mal marché quand j'avais démarré la School Zone. Je me dis que ça pourrait marcher aussi pour mon challenge des "trois téléporteurs" ... Tentons, donc.