Et si votre prochain projet matériel reposait sur une puce dont les créateurs n’ont même pas pris la peine de rédiger un manuel ?
C’est l’histoire du CH341 sous Python. Ce dongle USB bon marché – pince ZIF incluse – promet I2C, SPI et GPIO en mode EPP/MEM. Mais bonne chance pour dénicher plus qu’une datasheet famélique. J’ai exploré le terrier du reverse-engineering à votre place.
Le CH341 n’a rien de neuf. Il squatte les cartes de programmation depuis des années. Impressionnant au premier coup d’œil. Le faible nombre de composants rassure. Puis vous traquez la doc. Datasheet ? Au minimum syndical. Guide de programmation ? Nada. Registres ? Soupirons.
Drivers pour tous les OS, d’accord. Mais du code ? Là, la communauté fait des étincelles. Coup de chapeau au repo GitHub https://github.com/danguer/pych341 – de l’or en barre si vous zappez le cirque.
Pourquoi le CH341 joue-t-il à cache-cache à trois visages ?
Les configs de broches basculent cette bête entre modes. UART : port série barbant. Branchez et priez. PRINT : faux port imprimante. Bâillement. EPP/MEM : le vrai Graal – maître I2C, driver SPI esclave, terrain de jeu GPIO. Sans oublier les hacks mémoire parallèle, pour les nostalgiques.
La datasheet esquisse les maps de broches. Vagues à l’extrême. Entrez pyusb. Vendor ID 0x1A86, product ID 0x5512. Flairez les endpoints. Bulk in, bulk out. Les écritures exigent des wrappers opcodes ; les lectures ? Données brutes en pagaille.
WCH balance un zip Linux : https://www.wch-ic.com/downloads/CH341PAR_LINUX_ZIP.html. Ça mène à https://github.com/WCHSoftGroup/ch341par_linux. Démo, lib, module kernel. La lib appelle le kernel avec des args. Fonctions à foison – certaines pour les cousines CH347, d’autres HS dès le départ. Mémoire parallèle ? Mort-né.
Pas de source pour la lib. Classique.
Le README renvoie vers https://github.com/WCHSoftGroup/ch34x_mphsi_master_linux. Plus propre. I2C via ch341_i2c_stream. Danse des paquets : opener CH341_CMD_I2C_STREAM, STA pour start, OUT/IN avec longueurs ORées, STO stop, END closer.
L’analyseur logique confirme : STA génère le start, STO l’arrêt. Adresse ? 7 bits décalés, bit R/W collé (0 écriture, 1 lecture). Pas de baby-sitting – vous êtes le maître du bus.
To write data to a device is straightforward: # send a 0xFF as message to address 0xC0 address = 0xC0 data = 0xFF cmd = ( I2CCmd.MODE_STREAM, I2CCmd.START, # start signal I2CCmd.DIR_OUT | 2, # sending just 1 byte of data plus 1 byte of address address << 1, # sending 7-bit address and 0 as R/W bit data, I2CCmd.STOP, # stop signal I2CCmd.END, )
Extrait du post original. Clair, vibes Arduino Wire. Pour lire ? Écrivez d’abord l’adresse (R/W=1), puis aspirez les octets. Piégeux, mais pyusb fait chanter.
Le hic : l’opacité de WCH pue les vibes embarquées des années 90. Vous vous souvenez des guerres de reverse-engineering sur FT232 ? Même époque. Le CH341 emboîte le pas : la communauté comble le vide, enfantant des libs comme pych341. Mon avis cash ? Ces docs faméliques annoncent un boom de l’écosystème Python. Hacking hardware pas cher pour makers fauchés. Prono audacieux : d’ici 2025, il alimentera la moitié des side-projects I2C Raspberry Pi, écrasant les FT plus coûteux.
Python peut-il vraiment dompter la bête CH341 ?
Réponse courte : oui. Mais attendez-vous à des verrues.
L’install pyusb est un jeu d’enfant. Saisissez l’appareil, claim l’interface, traquez les endpoints. Les écritures bundlisent les opcodes ; la puce les déballe pour les ops bus. SPI ? Cmds stream similaires – mode, div clock, puis salve de données. GPIO ? Bangs pins directs via MEM.
Les pièges pullulent. Mauvais endpoints tuent les sessions. Vitesses clock ? La datasheet murmure. Essais-erreurs à la scope. Cette “dev board” ? Or pour protos, mais les programmateurs stock exigent des tweaks jumpers.
La lib ? pych341 abstrait le bordel. Classe I2C mime smbus. SPI aussi. Masques bits GPIO. Testé Linux – Windows ? pyusb user-space esquive le drame kernel.
Mais WCH,
