FTDI zum Bitklimpern von GPIO und I2C

[yeti]

----------8<-----{20161003-1749-GMT}----->8----------

Ich hab da was beim Aufräumen auf der Platte wieder gefunden:
tbb (Tiny Bit Bang) heißt das Ding, das mit dem FTDI nicht nur GPIOs allgemein sondern auch I2C bitrüttelt... \o/
Es gammelt schon lange auf der Platte herum und harrt noch immer geduldig der mal geplant gewesenen Testläufe. :-\
Nu ist's wenigstes hier fixiert... auch wenn es ich es vielleicht bald wieder in meiner Stehrümpelchen-Ecke auf der Platte vergesse... ;-)

----------8<-----{20161003-2112-GMT}----->8----------

Hit Shappens!

...ich krieg's unter Debian-8.6/AMD64 nicht gebacken. Ich denke, die kompiliert beiliegende FTDI-Library ("libftd2xx.a") erwartet 'ne ältere Libc... :-/
...außerdem lag auch nur eine bei, also vermutlich immer für die falsche Prozessorbitbreite... oder wie das auch immer heißt.

http://www.ftdichip.com/Drivers/D2XX.htm und http://www.ftdichip.com/Drivers/D2XX/Li ... -linux.txt halfen mir leider auch nicht weiter; mit der von dort genuckelten Lib grinste mich frech der selbe Fehler an.

FvvF! (Fallich völsche verpeilte Fehlinterpretation!)

Es lag dann doch an dem Fehlen von "-lpthread" im "Makefile".
Wie kommt denn sowas?

...und nebenbei codete er die VERSION als Float in seine C-Fragmente, was natürlich knallte als ich meine Verfummelungen durch "VERSION=\"0.06-himalaya-1\"" quasi unterschreiben wollte...

Alles beherrschbar...

Code: Alles auswählen

$ ./tbbi2c
Hardware Connection:
        I2C_SCL: Connect RI of ft232r, D7 of ft245r
        I2C_SDA: Connect DCD of ft232r, D6 of ft245r
        (Pull-up resisters required externally)

Usage:  tbbi2c -s i2c_slave_addr [-t access_type] [address] [write_data]

        access_type:
                01: 0 byte address - 1 byte data (default)
                02: 0 byte address - 2 byte data
                11: 1 byte address - 1 byte data
                12: 1 byte address - 2 byte data
                21: 2 byte address - 1 byte data
                22: 2 byte address - 2 byte data

Example1: read LM75(0b1001000) temperature
        tbbi2c -s 0x48
Example2: read a byte from 24LC64(0b1010000) on the address 0x0030
        tbbi2c -s 0x50 -t 21 0x0030
Example3: write a byte 0xf5 to 24LC64(0b1010000) on the address 0x0030
        tbbi2c -s 0x50 -t 21 0x0030 0xf5
        (tbbi2c -s50 -t21 30 f5 for short)

Das schaut ja fast schon vertrauenserweckend aus... aber ich hab mein Am-Rechner-Pensum für die letzten 48h schon kraß überzogen und der Test mit echter Hardware muß noch warten... die Augen brauchen auch mal Pause...

----------8<-----{20161004-1103-GMT}----->8----------

"tbb" ist zum Klimpern des FTDIngens als GPIO... ich hab einen Solchen angedrahtet, nur am Saft sozusagen, die folgende Ausgabe scheint plausibel für "alle Eingänge offen":

Code: Alles auswählen

$ sudo ./tbb -r
0xFF

"DCD" geGNDet:

Code: Alles auswählen

$ sudo ./tbb -r
0xBF

"RI" geGNDet:

Code: Alles auswählen

$ sudo ./tbb -r
0x7F

<Dr.Frankenstein-Stimme> ES LEEEEEEEEEBT!!! </Dr.Frankenstein-Stimme>

Jetzt mal I2C antesten... ich hoffe, der DS1307 mag auch ohne Quarz antworten...

...näää... der mocht mich nich... weder mit, noch ohne Quarz... muß ich wohl mal unter 'ner Lupe beäugen, ob man mir nicht evtl aus Versehn 'n 1302 geliefert hat...

...aber ein EEPROM ausm Hive gezogen:

Code: Alles auswählen

$ sudo ./tbbi2c -s 0x50 -t21 0x0000
0x00
$ sudo ./tbbi2c -s 0x50 -t21 0x0100
0x29

...das schaut doch nach was aus... \o/

Code: Alles auswählen

$ sudo time ./tbbi2cprog -s 0x50 -t 2 -d 0x100
          0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00000000 00 b4 c4 04 6f 7f 10 00 d4 33 08 7a 6b 02 14 7a 
00000010 ec 0e 5a 05 5b 02 08 00 53 05 04 00 dd 05 00 00 
00000020 0a 06 00 00 29 06 00 00 48 06 00 00 67 06 04 00 
00000030 75 06 08 00 9f 06 08 00 b6 06 00 00 d0 06 00 00 
00000040 f0 06 04 00 62 07 00 00 69 07 00 00 70 07 04 00 
00000050 82 07 28 00 b4 07 00 00 bc 07 00 00 c2 07 00 00 
00000060 c7 07 04 00 1c 08 04 00 26 08 04 00 3d 08 08 00 
00000070 5b 08 04 00 6e 08 04 00 78 08 00 00 80 08 00 00 
00000080 88 08 00 00 97 08 00 00 a6 08 04 00 b0 08 08 00 
00000090 a3 09 00 00 ab 09 00 00 b3 09 00 00 bb 09 00 00 
000000a0 c5 09 00 00 cf 09 04 00 e3 09 04 00 f7 09 04 00 
000000b0 0b 0a 04 00 25 0a 04 00 3f 0a 04 00 53 0a 04 00 
000000c0 69 0a 04 00 85 0a 04 00 a2 0a 04 00 ae 0a 04 00 
000000d0 b9 0a 04 00 c4 0a 04 00 cd 0a 0c 00 6d 0b 08 00 
000000e0 88 0b 04 00 92 0b 04 00 9c 0b 00 00 a4 0b 08 00 
000000f0 ba 0b 00 00 c5 0b 04 00 f4 0b 04 00 17 0c 00 00 
00000100 
1.04user 1.61system 0:12.54elapsed 21%CPU (0avgtext+0avgdata 1868maxresident)k
0inputs+0outputs (0major+145minor)pagefaults 0swaps

...schnell geht anders... und die Bitklimperei ist auch bösiglich CPU-lastig: 21% von 64bittigen 2.4GHz-chen sind schon kraß für diese Aufgabe... aber für unter 2€ ein für's Brotbrett taugliches USB<->I2C-Helferlein zur Hand haben, mag irgendwann durchaus mal den Tag retten!

Das Kleingedruckte:
Ich hab in Sachen USB<->I2C noch was auf ATtiny45-Basis in der Warteschlange... die ATtinys sind schon geblitzdingst, PCBs liegen auch bereit, aber ich warte noch auf die letzte Zutat: Auf einen Anfall von Lötlaune.

Edit @ 20170407-0646-GMT — Lötlaune war da... siehe i2c-tiny-usb

----------8<-----{Thematische Nachbarn}----->8----------

i2c-tiny-usb

----------8<-----{Happy End?}----->8----------

[yeti]

Mir kommen mittlerweile Zweifel auf, ob diese Lahmischkeit vielleicht daran lag, daß ich zu diesen Tests einen XIna-FT232-Clone erwischt haben könnte.

Anläßlich i2c-tiny-usb, das es nun in mehreren Hardware-Varianten gibt, oft verfügbaren I2C-Leitungen am Monitor-Ausgang, diversen I2C-Pins an den GPIOs der SBCs, FTDIs mit I2C, CH341 und Verwandschaft, ... hat es aber vielleicht wenig Sinn, das nochmal auszugraben.

[PIC18F2550]

Schau doch mal hier.

http://www.sprut.de/electronic/pic/proj ... sb4all.htm

Geht auch unter Win10.

[yeti]

Das schaut potetnt aus, aber dem fehlt vermutlich die Unterstützung in Linux, um das als I2C-Gerät mit den dafür vorgesehenen Funktionen anzusprechen.

Mißbrauch der I2C Signale in VGA, HDMI, ... wird eh schon unterstützt und zu usb-tiny-i2c gibt es auch 'nen "Treiber" in Linux. In den BSDs hab ich diesbezüglich noch gar nicht gewühlt. Die Tage sind einfach immer zu kurz, egal ob Sommer oder Winter... *seufz!*

[PIC18F2550]

Klaar geht auch unter Linux.

[yeti]

Damit?

Code: Alles auswählen

$ i2cdetect -l
i2c-3   unknown         i915 gmbus panel                        N/A
i2c-1   unknown         i915 gmbus ssc                          N/A
i2c-8   unknown         AUX C/port C                            N/A
i2c-6   unknown         i915 gmbus dpd                          N/A
i2c-4   unknown         i915 gmbus dpc                          N/A
i2c-2   unknown         i915 gmbus vga                          N/A
i2c-0   unknown         SMBus I801 adapter at 1880              N/A
i2c-9   unknown         AUX D/port D                            N/A
i2c-7   unknown         AUX B/port B                            N/A
i2c-5   unknown         i915 gmbus dpb                          N/A
$ doas i2cdetect 3
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- 28 -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
$ █

Ich hab jetzt kein usb-tiny-i2c angeplöppt, aber das würde auch mit diesen Tools bespatzt.

[PIC18F2550]

Ich dachte FTDI an USB und von dort auf I2C.

Das sieht aber mehr nach internen PC Bus aus.

[yeti]

Der FT232R kann für sowas benutzt werden aber braucht dann nonstandard Tools zum Ansprechen des I2C-Busses. Benutzt man stattdessen USB-Tiny-I2C, kann man die Programme benutzen, die auch für die anderen I2C-Busse zuständig sind. Das halte ich für erstrebenswerter.

—▷ viewtopic.php?f=27&t=1342