Forum: Mikrocontroller und Digitale Elektronik USB I2C Interface Hardware Software


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Zu schnell Fahrer (Gast)


Lesenswert?

Guten Abend,
ich suche nach einer Möglichkeit um I2C Chips vom PC aus zu testen.
Das einfachste einen PCF8574 I2C IO Port IC vom PC aus an zu steuern.
Weitere Anwendungen, AD Wandler oder PLL ICs.

Was ich bisher gefunden habe gibt es bei ELV:
https://de.elv.com/elv-usb-i2c-interface-komplettbausatz-inkl-gehaeuse-bearbeitet-und-bedruckt-usb-kabel-3-anschlusskabel-084123

Das wäre eine Möglichkeit, gibt es so was auch zum selbst bauen.
Also nicht wie bei ELV mit der fertigen Platine wo ein Programmierter 
AVR Controller drauf ist.

Eine Lösung mit AVR Controller ist sicher eine einfache Lösung.
Leider gibt es von ELV die Software so nicht einzeln.

Wer kennt andere vergleichbare Lösungen.
Dachte dabei an Arduino oder Bascom für AVR Controller.

von Chris R. (hownottobeseen)


Lesenswert?

Der MCP2221 könnte evtl. das sein, was du suchst. Ist allerdings kein 
Geschwindigkeitswunder.

Hab vor einer Weile mal eine Python-Lib dafür geschrieben: 
https://hobbyelektronik.org/w/index.php/MCP-USB-Bridge

von N. M. (mani)


Lesenswert?

Ein FTDI Adapter Kabel?
Oder ein Raspi?

von Der Klaus (Gast)


Lesenswert?


von Hmmm (Gast)


Lesenswert?

Zu schnell Fahrer schrieb:
> Das wäre eine Möglichkeit, gibt es so was auch zum selbst bauen.

Es gibt z.B. das hier: https://github.com/harbaum/I2C-Tiny-USB

Der Klaus schrieb:
> Kuck da:
> https://linux-club.de/wiki/opensuse/USB_Status_von_USB_pr%C3%BCfen
>
> Oft reicht aber schon "lsusb".

Dein Beitrag passt irgendwie nicht zum Thema.

von Frank K. (fchk)


Lesenswert?

Chris R. schrieb:
> Der MCP2221 könnte evtl. das sein, was du suchst. Ist allerdings kein
> Geschwindigkeitswunder.
>
> Hab vor einer Weile mal eine Python-Lib dafür geschrieben:
> https://hobbyelektronik.org/w/index.php/MCP-USB-Bridge

Inzwischen gibts den MCP2221A mit verbesserter Firmware, aber ja, den 
verwende ich auch gerne. Ist im Prinzip ein vorprogrammierter 
PIC16F1455.

fchk

von PittyJ (Gast)


Lesenswert?

Ich habe für so etwas einen Raspi.
Der I2C Bus liegt auf der 40 poligen Leiste. Da kann ganz einfach was 
angeschlossen werden.
Es gibt freie Tools wie i2cdetect, i2cset ...
Die Programmierung von eigenen Tools ist einfach und gut dokumentiert.

Der Raspi kostet nicht viel, und wird einfach Remote über ssh vom PC 
betrieben. Also nicht mal Tastatur und Monitor.

von Waldmeister Zwei (Gast)


Lesenswert?

Zu schnell Fahrer schrieb:
> Wer kennt andere vergleichbare Lösungen.
> Dachte dabei an Arduino oder Bascom für AVR Controller.

Da habe ich was gefunden, ist zwar mit RS232 aber man kann ja einen FTDI 
oder CP2102 an Stelle des MAX232 verwenden.

http://www.gameroom-austria.info/cms/index.php/menu-hobby/menu-elektronik1/mnu-elek-i2c-parser

Da der Sourcecode als Download zur Verfugung steht sollte es auch 
möglich sein einen anderen Controller zu verwenden.
Das ganze sollte z.B. mit einem Arduino Board mit ATMEGA168 oder 328 
funktionieren.
Daraus sollte es schon möglich sein etwas zu machen.

von Rainer M. (excogitator)


Lesenswert?

Mein Tipp wäre das UMFT4222EV-D Board. Kostet nicht die Welt und man 
kann damit direkt I2C- und SPI-Bausteine ansteuern. Funktioniert hier 
ganz gut.

Gruß
Rainer

von Max M. (prokrastinator)


Lesenswert?

Zu schnell Fahrer schrieb:
> Möglichkeit um I2C Chips vom PC aus zu testen

https://www.mikrocontroller.net/articles/Bus-Pirate
Hat den Vorteil das man mit jedem terminalprg arbeiten kann.
Ein sehr nützliches Tool das viel kann für wenig Geld.

Frank K. schrieb:
> Inzwischen gibts den MCP2221A mit verbesserter Firmware
MC bietet dafür auch die DLL und ein I2C Terminal an.
Sicher die preiswerteste Lösung.
https://www.microchip.com/en-us/product/mcp2221a#document-table

von Der Klaus (Gast)


Lesenswert?

Hmmm schrieb:
> Der Klaus schrieb:
>> Kuck da:
>> https://linux-club.de/wiki/opensuse/USB_Status_von_USB_pr%C3%BCfen
>>
>> Oft reicht aber schon "lsusb".
>
> Dein Beitrag passt irgendwie nicht zum Thema.

Du hast natürlich Recht; irgendwie war ich bei USB. Also alles ganz 
schnell vergessen ...

von bingo (Gast)


Lesenswert?


von asdf (Gast)


Lesenswert?

Unter Windows oder unter Linux?

Für Linux bietet sich das hier an: 
https://github.com/harbaum/I2C-Tiny-USB
Einbindung problemlos dank vorhandenem Kernel-Treiber.

von Guido K. (Firma: Code Mercenaries GmbH) (thebug)


Lesenswert?

Falls die Lösung auch etwas eleganter sein darf:
https://www.codemercs.com/de/dongles/iow28dg

von bingo (Gast)


Lesenswert?

asdf schrieb:
> Unter Windows oder unter Linux?

Es gibt für den USB4all einen MDC-Treiber von Microchip, er lässt sich 
aber auch per CDC betreiben, da geht dann jedes BS.

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

asdf schrieb:
> Unter Windows oder unter Linux?
>
> Für Linux bietet sich das hier an:
> https://github.com/harbaum/I2C-Tiny-USB
> Einbindung problemlos dank vorhandenem Kernel-Treiber.

Kann ich bestätigen.

Ich würde gerne eine Potierung auf den Arduino haben wollen, um noch 
universeller I2C nutzen zu können.
Wenn da jemand noch was gesehen hat, bitte in die Runde schreiben.

Beitrag #7088734 wurde von einem Moderator gelöscht.
von (prx) A. K. (prx)


Lesenswert?

Max M. schrieb:
> https://www.mikrocontroller.net/articles/Bus-Pirate
> Hat den Vorteil das man mit jedem terminalprg arbeiten kann.
> Ein sehr nützliches Tool das viel kann für wenig Geld.

Aber Vorsicht. So nützlich das Teil ist, es kann leider ebensowenig mit 
Clock Stretching umgehen wie der RasPi. Bei I2C Devices, die auf 
Mikrocontrollern beruhen, gerät das zum Problem.

: Bearbeitet durch User
von CartmanD (Gast)


Lesenswert?

Microchip Serial Analyzer kann I2C, SPI und RS-232.
Da ein normaler 16F2550 (+ Targetlevelshiftern) drin steckt,
sicher mit einiger Eigeninitiative noch einiges mehr.

von W.S. (Gast)


Lesenswert?

Zu schnell Fahrer schrieb:
> ich suche nach einer Möglichkeit um I2C Chips vom PC aus zu testen.
> Das einfachste einen PCF8574 I2C IO Port IC vom PC aus an zu steuern.

Ich sehe so etwas nicht als die einfachste Lösung.
Nimm stattdessen irgend einen µC, der per USB am PC einen COM-Port 
darstellen kann und packe dort die notwendigen Lowlevel-Treiber für I2C 
drauf, dazu noch passende Kommandos und den Rest macht dein 
selbstgeschriebenes Testprogramm auf dem PC. Passende µC hat es bislang 
zuhauf gegeben, ich erinnere hier mal an die ellenlangen 
USB-Diskussionen zu den diversen STM32, ebenso den gehabten Hype zu den 
"BluePill"-Boards und gewiß tut es auch ein 8 bittiger 8051-Clone von 
WCH. Also die Bauteile für so eine Anwendung hat fast jeder bereits in 
der Bastelkiste.

W.S.

von Zombie (Gast)


Lesenswert?

(prx) A. K. schrieb:
> So nützlich [der Bus-Pirate] ist, es kann leider ebensowenig mit
> Clock Stretching umgehen wie der RasPi.

Apropos: Können die FTDI Chips Clockstreching? Weiss das jemand?

von (prx) A. K. (prx)


Lesenswert?

Die FTx232H können es nicht. AN 411: "When clock stretching is required 
by the attached peripheral, it is strongly recommended to use the new 
I2C bridging devices from FTDI including the FT4222H and FT260 which 
have support for clock stretching functionality."

von Zombie (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Die FTx232H können es nicht. AN 411: "When clock stretching is required
> by the attached peripheral, it is strongly recommended to use the new
> I2C bridging devices from FTDI including the FT4222H and FT260 which
> have support for clock stretching functionality."

Danke!
Ich habe mich gerade etwas durch den MPSSE Code gewühlt (weil ich ein 
C++ Wrapper bauen möchte) und folgenden Kommentar gefunden:

> The I2C master should actually drive the SDA line only when the output is LOW.
> It should tristate the SDA line when the output should be high. This tristating
> the SDA line during output HIGH is supported only in FT232H chip

zu finden in der Datei "ftdi_mid.c" in der Funktion "FT_InitChannel" 
Zeile 426-428 
https://ftdichip.com/wp-content/uploads/2020/08/libMPSSE_Source.zip

Das bedeutet wohl, dass man die Wahl hat zwischen clock streching 
(FT4222H o. FT 260) und einem normgerechten SDA ausgang mit dem 
FT232H... beides geht nicht :/ (oder der Code wurde seitens FTDI nicht 
aktuell gehalten)

von Zombie (Gast)


Lesenswert?

Nachtrag: Der FT260 benötigt einen speziellen Treiber und unterstützt 
kein MPSSE (darum ist er im libMPSSE Code nicht aufgeführt). Laut 
Datenblatt ist sein Output open drain.

von P.S. (Gast)


Lesenswert?

Von Silicon Labs gibt es den CP2112, eine USB HID to SMBus/I2C Bridge. 
Der Chip hat auch noch ein paar GPIOs. Sowohl für I2C als auch für die 
GPIOs sind im Linux-Kernel Treiber vorhanden.

Bei Ali hatte ich vor einiger Zeit Boards (CP2112 Debug Board) mit 
diesem Chip  gekauft. Diese funktionieren ohne Probleme. Die folgenden 
udev-Regeln verwende ich:
1
# udev rules file for Silicon Labs CP2112 HID USB-to-SMBus Bridge
2
#
3
# groupadd -r -g 621 gpio
4
# groupadd -r -g 622 i2c
5
#
6
ACTION=="add", SUBSYSTEMS=="i2c-dev", DEVPATH=="*usb*10C4:EA90*", SYMLINK+="cp2112-i2c-%E{MINOR}", MODE="0660", GROUP="i2c"
7
ACTION=="add", SUBSYSTEMS=="gpio", DEVPATH=="*usb*10C4:EA90*", SYMLINK+="cp2112-gpio-%E{MINOR}", MODE="0660", GROUP="gpio"
8
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea90", RUN+="/sbin/modprobe -ba i2c-hid i2c-dev"

Die Boards hatten damals so zwischen 2 und 3 Euro gekostet. Offenbar 
sind die Chips jetzt knapp geworden, denn die Boards werden nur noch zu 
Wucherpreisen angeboten, z.B. hier: 
https://www.aliexpress.com/item/4000906840272.html?spm=a2g0o.productlist.0.0.667b19b6KZ7ZOE&algo_pvid=dfc4d025-cad1-4810-9149-c9cbcf4033d7&algo_exp_id=dfc4d025-cad1-4810-9149-c9cbcf4033d7-11&pdp_ext_f=%7B%22sku_id%22%3A%2210000010486928294%22%7D&pdp_npi=2%40dis%21EUR%21%2118.6%21%21%215.33%21%21%400b0a0ac216549491291761934e77f7%2110000010486928294%21sea

von Ludwig K. (hellas)


Lesenswert?

Was spricht jetzt gegen die ELV-Variante mit HTerm unter Windows?

von Manfred (Gast)


Lesenswert?

Ludwig K. schrieb:
> Was spricht jetzt gegen die ELV-Variante

Gegen ELV spricht generell, dass sie programmierte ICs einsetzen und 
deren Software nicht verfügbar machen. Dazu findet sich alle paar Monate 
etwas im Forum.

Speziell dieser I2C Adapter wird in Testumgebungen eingesetzt und ist 
damit stark Abschussgefährdet - da möchte man wissen, wie man ihn 
reparieren kann.

von Michael D. (nospam2000)


Lesenswert?

P.S. schrieb:
> Von Silicon Labs gibt es den CP2112,
> Die Boards hatten damals so zwischen 2 und 3 Euro gekostet.

Bei Amazon derzeit für 11,75,- inklusive Versand erhältlich 
https://www.amazon.de/gp/product/B09YXWCPJ9/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

 Michael

von Michael D. (nospam2000)


Lesenswert?

René D. schrieb:
>> https://github.com/harbaum/I2C-Tiny-USB
> Ich würde gerne eine Potierung auf den Arduino haben wollen, um noch
> universeller I2C nutzen zu können.

Schließe mich an. Ich habe auf die Schnelle nichts gefunden und würde es 
gerne auf einem Arduino Pro micro/Leonardo mit ATMega32U4 und sauberem 
Hardware USB laufen lassen.

Wenn niemand was findet würde ich das mal portieren.

  Michael

: Bearbeitet durch User
von J. S. (jojos)


Lesenswert?

STLink V3 geht auch, kann I2C/SPI/CAN und UART.

von Cartman (Gast)


Lesenswert?

> Nimm stattdessen irgend einen µC, der per USB am PC einen COM-Port
> darstellen kann und packe dort die notwendigen Lowlevel-Treiber für I2C
> drauf

Gibt es fertig als Maximite bzw. Duinomite.
Basiert auf einem PIC32-MIPS. Der Interpreter ist dabei ueber
eine USB-UART-Schnittstelle erreichbar und enthaelt bereits
die notwendigen Treiber und (BASIC-)Befehle um mit angeschlossener
I2C-Peripherie einen Smalltalk zu halten.
Das kann man wahlweise auch autark laufen lassen.
Das Ding ist ja in BASIC probrammierbar.

Es ist auch nicht auf I2C beschraenkt sondern unterstuetzt auch
noch SPI, RS-232 und u.U. auch CAN.

von Joachim S. (oyo)


Lesenswert?

asdf schrieb:
> Unter Windows oder unter Linux?
>
> Für Linux bietet sich das hier an:
> https://github.com/harbaum/I2C-Tiny-USB
> Einbindung problemlos dank vorhandenem Kernel-Treiber.

Ich habe vor ein paar Jahren ebenfalls eine Möglichkeit gesucht, am PC 
direkt mit I2C-Geräten zu kommunizieren, bin dann letztlich auch bei 
i2c-tiny-usb gelandet und kann nur bestätigen, dass das zumindest unter 
Linux wunderbar funktioniert, weil der passende Treiber sogar bereits im 
Linux-Kernel enthalten ist.

Als Hardware verwende ich das günstige sogenannte "Digispark"-Board - 
das bekam man vor ein paar Jahren noch für 90 Cent inkl. Porto bei 
AliExpress regelrecht hinterhergeschmissen. Mittlerweile bestimmt ein 
bisschen teurer, aber wahrscheinlich immer noch die günstigste fertige 
Lösung.
https://github.com/harbaum/I2C-Tiny-USB/tree/master/digispark

von W.S. (Gast)


Lesenswert?

Joachim S. schrieb:
> bin dann letztlich auch bei
> i2c-tiny-usb gelandet und kann nur bestätigen, dass das zumindest unter
> Linux wunderbar funktioniert, weil der passende Treiber sogar bereits im
> Linux-Kernel enthalten ist.

Wozu all diese Umstände? Wozu braucht man irgend einen speziellen 
I2C-Treiber in einem OS-Kernel? Bedenke mal, daß der TO folgendes 
schrieb:

Zu schnell Fahrer schrieb:
> ich suche nach einer Möglichkeit um I2C Chips vom PC aus zu testen.

Also braucht man bloß irgend einen Kanal, der aus dem PC herausführt und 
daran irgend einen µC, der dann die eigentlichen Signale für den I2C 
erzeugt. Da braucht es keine speziellen Treiber im OS - sondern nur eben 
die Treiber, die das Benutzen des USB ermöglichen. Man könnte von der 
Sache her auch eine klassische serielle Strippe benutzen, sofern der PC 
noch eine Schnittstelle dafür hat. Und so ziemlich jeder µC in der 
Bastelkiste, den man irgendwie an USB oder ne Serielle drankriegt, ist 
für sowas geeignet.

W.S.

von Michael D. (nospam2000)


Lesenswert?

W.S. schrieb:
> Joachim S. schrieb:
> Wozu all diese Umstände? Wozu braucht man irgend einen speziellen
> I2C-Treiber in einem OS-Kernel? Bedenke mal, daß der TO folgendes
> schrieb:

Vielleicht weil der TO nicht der einzige ist welcher gerne eine 
Problemlösung hätte und eine allgemeinere Lösung auch anderen hilft, 
z.B. mir selbst?

> Also braucht man bloß irgend einen Kanal, der aus dem PC herausführt und
> daran irgend einen µC, der dann die eigentlichen Signale für den I2C
> erzeugt. Da braucht es keine speziellen Treiber im OS

Klar, man kann alles proprietär machen. Zurück in das Zeitalter als jede 
Maus ihren eigenen Treiber benötigt hatte.

 Michael

von Joachim S. (oyo)


Lesenswert?

W.S. schrieb:
> Joachim S. schrieb:
>> bin dann letztlich auch bei
>> i2c-tiny-usb gelandet und kann nur bestätigen, dass das zumindest unter
>> Linux wunderbar funktioniert, weil der passende Treiber sogar bereits im
>> Linux-Kernel enthalten ist.
>
> Wozu all diese Umstände? Wozu braucht man irgend einen speziellen
> I2C-Treiber in einem OS-Kernel?

Vielleicht sitze ich gerade auf der Leitung, aber ich verstehe partout 
nicht, was daran "umständlich" sein soll.

Ich jedenfalls empfand diese Lösung ganz im Gegenteil als erstaunlich 
einfach und unkompliziert:
Man holt sich für 2-3 Euro so ein Digispark-Board und schliesst es per 
USB an den PC an, flasht mit einem Kommandozeilen-Befehl noch fix die 
i2c-tiny-usb-Firmware drauf und verbindet das Digispark-Board mit dem 
I2C-Bus, fertig. Schon kann das Standard-i2c-Interface von Linux nehmen, 
um mit beliebigen I2C-Geräten zu kommunizieren. Man kann z.B. mit dem 
Kommandozeilen-Tool "i2cdetect" erst einmal den I2C-Bus nach Geräten 
scannen und so ganz fix überprüfen, ob Verkabelung etc. ok ist und die 
I2C-Kommunikation grundsätzlich funktioniert.
Dann kann man in der Programmiersprache der Wahl ein auf das konkrete 
I2C-Device angepasstes Testprogramm schreiben - und das Programm läuft 
ohne jede Änderung auch z.B. auf einem Raspberry Pi, bei dem man eine 
USB-I2C-Bridge nicht benötigt, weil die I2C-Pins dort direkt 
herausgeführt sind.

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

Es gibt doch auch Fertige Lösungen CH341 zum beispiel?

Wieso so Kompliziert? Tool ist Downloadbar und er kann auch grad noch 
andere brauchbare Sachen wie, EEPROMS oder FLASH oder Paralellport oder 
Serial usw?

Nix Programmieren, einstecken Jumper setzen und fetich.
Beispiel: https://www.ebay.de/itm/384156284118

von J. S. (jojos)


Lesenswert?

Patrick L. schrieb:
> Nix Programmieren, einstecken Jumper setzen und fetich.
> Beispiel: https://www.ebay.de/itm/384156284118

und wo schließt man da die I2C Komponenten an?

von Stefan ⛄ F. (stefanus)


Lesenswert?

Joachim S. schrieb:
> Man holt sich für 2-3 Euro so ein Digispark-Board ...

Danke für den Tipp. Hat mich daran erinnert, dass ich mir so einen 
Adapter zulegen wollte. Mir war nur noch nicht klar, welcher unter Linux 
"einfach so" funktioniert.

von Frank K. (fchk)


Lesenswert?

Joachim S. schrieb:
>> Für Linux bietet sich das hier an:
>> https://github.com/harbaum/I2C-Tiny-USB
>> Einbindung problemlos dank vorhandenem Kernel-Treiber.
>
> Ich habe vor ein paar Jahren ebenfalls eine Möglichkeit gesucht, am PC
> direkt mit I2C-Geräten zu kommunizieren, bin dann letztlich auch bei
> i2c-tiny-usb gelandet und kann nur bestätigen, dass das zumindest unter
> Linux wunderbar funktioniert, weil der passende Treiber sogar bereits im
> Linux-Kernel enthalten ist.

Ich halte immer maximalen Abstand zu VUSB-Frickelimplementationen. Ein 
MCP2221A ist nicht teurer, ist inzwischen auch im Linux-Kernel drin, und 
hat wenigstens Hardware-Full-Speed-USB.

fchk

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)



Lesenswert?

J. S. schrieb:
> und wo schließt man da die I2C Komponenten an?

Man nimt wenn man will beispielsweise den:
https://www.ebay.de/itm/265689795534
(Bild 1) Da ist alles grad richtig angeschrieben

oder bei dem erst verlinkten (roter Pfeil Bild 2)

Es gibt vom Hersteller, aber auch bei Gitthub fertige Programme mit 
deren man I²C Bausteine ansteuern kann auch Librarys für Visual C,C, 
Basic, oder Profilab EXPERT> usw....
und der CH341A arbeitet sehr zuverlässig mit Treiber für LINUX und 
Windows.

Und du hast ganz neben bei auch noch einen Programmer.

73 55

: Bearbeitet durch User
von J. S. (jojos)


Lesenswert?

Patrick L. schrieb:
> Man nimt wenn man will beispielsweise den:
> https://www.ebay.de/itm/265689795534

ok, sehr praktisch, sah mir erst nach nur SPI aus.

von Alexander S. (alesi)


Lesenswert?

Zu schnell Fahrer schrieb:
> ich suche nach einer Möglichkeit um I2C Chips vom PC aus zu testen.

Das sollte doch prinzipiell mit jedem Atmega32u4 Breakout board gehen. 
Z.B. https://learn.adafruit.com/atmega32u4-breakout?view=all oder 
https://www.sparkfun.com/products/15795

von Alexander S. (alesi)


Lesenswert?

Frank K. schrieb:
> Inzwischen gibts den MCP2221A mit verbesserter Firmware,

Dafür gibt es z.B. das https://www.mikroe.com/usb-i2c-click board.

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

> https://github.com/harbaum/I2C-Tiny-USB
> Einbindung problemlos dank vorhandenem Kernel-Treiber.

Diese Teil hatte ich auch in Verwendung. Er läuft gut, Leider ist die 
USB Implementierung im Gerät nicht durchschaubar und auf ein anderen 
Baustein portierbar. Ich hatte es mal versucht auf ein Arduino board. Er 
meldet sich mit verschiedenen Vendor IDs an. Alles undurchsichtig.

Das Tool war aber gut. Ich kommte die I2Ctools nutzen und alle gängigen 
Sensoren, genauso wie in den Rasberry-Pi Projekten am Laptop nutzen. So 
musst nicht immer den Raspberry erst aufsetzen.



Frank K. schrieb:
....
> MCP2221A ist nicht teurer, ist inzwischen auch im Linux-Kernel drin, und
> hat wenigstens Hardware-Full-Speed-USB.
>

Kann man mit den Treibern auch die I2Ctools nutzen?

von Frank K. (fchk)


Lesenswert?

René D. schrieb:

>> MCP2221A ist nicht teurer, ist inzwischen auch im Linux-Kernel drin, und
>> hat wenigstens Hardware-Full-Speed-USB.
>>
>
> Kann man mit den Treibern auch die I2Ctools nutzen?

Ja klar, meldet sich als /dev/i2c-... an.

fchk

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

Frank K. schrieb:
> René D. schrieb:
>
>>> MCP2221A ist nicht teurer, ist inzwischen auch im Linux-Kernel drin, und
>>> hat wenigstens Hardware-Full-Speed-USB.
>>>
>>
>> Kann man mit den Treibern auch die I2Ctools nutzen?
>
> Ja klar, meldet sich als /dev/i2c-... an.
>
> fchk

Das ist richtig gut.
So klar war mir das nicht.

Die FTDI I2C Lösungen können das nicht.

von W.S. (Gast)


Lesenswert?

Michael D. schrieb:
> Klar, man kann alles proprietär machen. Zurück in das Zeitalter als jede
> Maus ihren eigenen Treiber benötigt hatte.

Was der TO für Tests an welchen Chips vor hat, ist etwas proprietäres.

Und von Linux hat er garnix geschrieben.

Es ist also die sinnvollste Lösung, irgend ein Standardinterface zu 
benutzen was man bei allen üblichen OS benutzen kann, damit einen 
kleinen µC vom PC aus zu erreichen und dort den Lowlevel-Teil der ganzen 
Testeinrichtung zu machen.

Dein ganzer Einwand ist also eigentlich gegenstandslos.

W.S.

von Michael D. (nospam2000)


Lesenswert?

W.S. schrieb:
> irgend ein Standardinterface zu
> benutzen was man bei allen üblichen OS benutzen kann

Unter einen Standardinterface verstehe ich eines, welches von vielen 
unterschiedlichen Geräten unterstützt wird oder wie im Falle von 
i2c-tiny-usb so weit verbreitet ist, dass es sogar vom Kernel 
unterstützt wird.
Für nicht Linux Betriebssysteme gibt es wenigstens ein Python Language 
Binding.

Der TO hat überhaupt kein Betriebssystem genannt und auch keine 
Programmiersprache in welcher er ein i2c API verwenden will. Das wird 
aber sein Hauptproblem werden.

Spätestes wenn man eine Applikation gegen ein herstellerspezifisches API 
geschrieben hat und die Hardware den Geist aufgibt und kein Ersatz mehr 
verfügbar ist, kommt Freude auf alles auf ein anderes API umzuschreiben.

  Michael

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Michael D. schrieb:
> Unter einen Standardinterface verstehe ich eines, welches von vielen
> unterschiedlichen Geräten unterstützt wird...

Also was du unter einem Standardinterface verstehst, ist 99% aller 
PC-Benutzer herzlich egal. Die gucken auf der Rückseite ihres PC nach, 
was da für Löcher sind, wo man einen Stecker nebst Kabel hineinstecken 
kann. Genau das sind die Standardinterfaces, die man am PC benutzen 
kann. Heutzutage sind da vornehmlich USB-Anschlüsse zu finden, früher 
gab's noch das Parallele, was zumeist für den Drucker war und die 
Seriellen, die man damals eben benutzen konnte.

Eine Buchse für einen I2C gab's da noch nie. Allenfalls irgend eine 
Einsteck-LP, wo sowas drauf war und wo es Treiber dazu vom jeweiligen 
Hersteller gab. Dem Betriebssystem war das herzlich egal, solange der 
Treiber sich konform zum System verhielt.

W.S.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Aber Linux und Windows haben beide eine API zum Ansprechen von I²C 
Bussen. Insofern möchte ich einen I²C Adapter verwenden der diese API 
unterstützt. Ansonsten muss ich mein Programm mit einer proprietären API 
verheiraten und bin dadurch mindestens an den Hersteller des Adapters 
gebunden, wenn nicht an den konkreten Adapter selbst.

Wer früher Multimedia unter DOS Entwickelte weiß wie ätzend das ist.

von W.S. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Aber Linux und Windows haben beide eine API zum Ansprechen von I²C
> Bussen. Insofern möchte ich einen I²C Adapter verwenden der diese API
> unterstützt.

Also, erstmal eines: du programmierst am PC Anwendungen und nicht das OS 
selber. Von da her sind solche Dinge wie die Info von der Grafikkarte 
oder andere interne Management-Dinge nicht dein Thema. Es gibt an einem 
normalen PC kein I2C-Interface, das vom User benutzbar ist und das 
dranstöpseln eines externen Gerätes ermöglicht. Das sollte erstmal klar 
sein.

Alsdann: Das, was von Windows vorgehalten wird, sind Typdeklarationen 
und die sind für Leute, die Peripherie-Karten entwickeln und dafür einen 
Treiber schreiben wollen. Auch das hat mit Anwendungsprogrammierung nix 
zu tun.

So: Da will der TO also irgendeinen Testplatz machen, wo er I2C-Chips 
testen will. Er will dazu ganz gewiß keine Treiber für sein aktuelles OS 
schreiben und eine Peripheriekarte für den PC entwickeln.

Deine Einlassung ist also wenig hilfreich. Deshalb mal ne Frage an dich: 
Wenn z.B. ich dir eine Handvoll Chips (z.B. EEProms mit I2C-Interface 
usw.) auf den Tisch schütten würde und dir dazu sagen würde "testense 
die mal" - wie würdest du das angehen?

W.S.

von Stefan ⛄ F. (stefanus)


Lesenswert?

W.S. schrieb:
> Also, erstmal eines: du programmierst am PC Anwendungen und nicht das OS
> selber. Von da her sind solche Dinge wie die Info von der Grafikkarte
> oder andere interne Management-Dinge nicht dein Thema.

Doch, denn unter DOS musste man die Hardware (also den/die Chips 
zwischen CPU und I²C Bus) direkt auf Registerebene ansprechen. Und jeder 
Chip hatte andere Register.

Durch die I²C API vom Linux oder Windows Kernel muss man sich damit 
nicht herum schlagen. Man hat eine definierte API über austauschbare 
Hardware. Die ggf. nötigen Treiber liefert der Hersteller des I²C 
Adapters.

Früher hätte ich I²C Peripherie an den parallel Port geklemmt und per 
Bit-Banging programmiert, aber das geht ja kaum noch.

: Bearbeitet durch User
von Εrnst B. (ernst)


Lesenswert?

W.S. schrieb:
> Deshalb mal ne Frage an dich:
> Wenn z.B. ich dir eine Handvoll Chips (z.B. EEProms mit I2C-Interface
> usw.) auf den Tisch schütten würde und dir dazu sagen würde "testense
> die mal" - wie würdest du das angehen?

Frage ging zwar nicht an mich, aber: An einen I2C-Bus anklemmen, 
i2cdetect, ggfs. Treiber laden, Funktionen ansteuern&ausprobieren. 
Nächsten Chip dran, repeat.
1
# One Wire Bus:
2
echo ds2482 0x18 > /sys/bus/i2c/devices/i2c-0/new_device
3
# DS18B20 werden erkannt und sind auslesbar unter  /sys/bus/w1/devices/...
4
5
# IO-Expander:
6
echo pcf8574 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
7
echo 56 > /sys/class/gpio/export
8
echo 57 > /sys/class/gpio/export
9
echo 60 > /sys/class/gpio/export
10
echo 1 > /sys/devices/platform/i2c-gpio.0/i2c-0/0-0020/gpio/gpio56/active_low
11
echo 'out' > /sys/devices/platform/i2c-gpio.0/i2c-0/0-0020/gpio/gpio56/direction
12
echo 0 > /sys/devices/platform/i2c-gpio.0/i2c-0/0-0020/gpio/gpio56/value

: Bearbeitet durch User
von Frank K. (fchk)


Lesenswert?

Stefan ⛄ F. schrieb:
> Aber Linux und Windows haben beide eine API zum Ansprechen von I²C
> Bussen.

Die Linux-API kenne ich, die von Windows nicht. Da hätte ich gerne einen 
Pointer auf die Primärquelle.

fchk

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

Εrnst B. schrieb:
> Frage ging zwar nicht an mich, aber ...

Danke. Genau das geht eben nur, wenn man Hardware verwendet, die vom OS 
unterstützt wird bzw. wofür es Treiber gibt die das dafür vorgesehene 
API unterstützen.

Ich bin jetzt kein Windows Spezialist, aber doch ziemlich sicher, dass 
es so ähnlich auch mit der Powershell machbar ist. Wer bis jetzt immer 
so, wenn man mal die richtigen Leute fragt.

: Bearbeitet durch User
von J. S. (jojos)


Lesenswert?

AFAIK kennt nur die IoT Version von Windows I2C. Aber wer benutzt das 
schon?

von Stefan ⛄ F. (stefanus)


Lesenswert?

J. S. schrieb:
> Aber wer benutzt das schon?

Windows ist eh nicht so Entwickler-Freundlich wie Linux.

SCNR

von J. S. (jojos)


Lesenswert?

ich mag es lieber Benutzerfreundlich. Und Linux läuft prima im Fenster.
WSL jetzt auch mit USB um etwas on topic zu bleiben.

von das Neutrum vom Bitrot (Gast)


Lesenswert?

> Ich würde gerne eine Potierung auf den Arduino haben wollen, um noch
> universeller I2C nutzen zu können.
> Wenn da jemand noch was gesehen hat, bitte in die Runde schreiben.

Liebe Arduino-Lüfterjungs (Fan Boys),
Liebe Arduino-Verweigerer,

warum wird die alte "Firmata"-FW bereits vergessen?


Diese war doch unter diversem Anderem ein "Zeugungsgrund" von Arduino & 
co.
Das ist ein definiertes (ich vermeide "standard") Protokoll um vom Host 
(PC aber auch anderes) via Serielle Schnittstelle (gerne auch durch USB 
getunnelt) die I/Os eines Arduinos zu erreichen. Entsprechend gibt es 
libs/APIs zu zahlreichen Programmiersprachen um bequem per Hochsprache 
buchstäblich zu schalten und walten.

Der HW-Vorteil eines Arduinos als "Frontends" ggü eines I2C-Busses 
direkt am Host-Motherboards: etwas mehr Distanz zu Fremdspannung. Ein 
gekillter Arduino ist einfachet und billiger ersetzt als des Hosts 
Motherboard.

---

Und dann gibts noch bitlash.net von Bill Roy und weitere ähnliche 
Projekte.

---

Unsere "altvorderen" haben auch schon richtig gedacht und Arbeit 
geleistet, man muss nicht jedes Rad mehrmals neu erfinden!
;-)

von das Neutrum aus Bitrot (Gast)


Lesenswert?

Manfred schrieb:
> Ludwig K. schrieb:
>> Was spricht jetzt gegen die ELV-Variante
>
> Gegen ELV spricht generell, dass sie programmierte ICs einsetzen und
> deren Software nicht verfügbar machen. Dazu findet sich alle paar Monate
> etwas im Forum.
>
> Speziell dieser I2C Adapter wird in Testumgebungen eingesetzt und ist
> damit stark Abschussgefährdet - da möchte man wissen, wie man ihn
> reparieren kann.

Tja... wer sich auf Windows einlässt kann auch ELV nehmen. Genau aus 
o.g. Grund.

Ansonsten, das wird aber "unglaublich aufwändig", müsste doch erst das 
sich niemals durchsetzende OpenSource erfunden werd...
Moment mal!....
<:-)

von W.S. (Gast)


Lesenswert?

das Neutrum aus Bitrot schrieb:
> Tja...
> Ansonsten, das wird aber "unglaublich aufwändig",...

Mal zum Thema zurück. Was findet ihr da eigentlich so unsäglich 
schwierig? Ich hab ja schon viel weiter oben genau das vorgeschlagen, 
mit dem man ohne besonderen Aufwand zu Potte kommt: Man nehme irgend 
einen µC, den man per USB als VCP an den PC drankriegt, lasse diesen µC 
das niedere I2S-Zeugs machen (also Startcond, Stopcond, Daten 
übertragen...) und den Rest der Tests macht ein kleines 
selbstgeschriebenes Programm auf dem PC. Und für sowas ist es völlig 
egal, ob und wie irgend ein OS irgendwelche I2C-Steckkarten usw. kennt 
und unterstützt.

Notfalls (oder wenn man zu sowas außerstande ist) eben ein fertiges 
Terminalprogramm und passende Kommandos zum µC hin.

Stellt euch nicht an wie die ersten Menschen.

W.S.

von W.S. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Doch, denn unter DOS musste man die Hardware (also den/die Chips
> zwischen CPU und I²C Bus) direkt auf Registerebene ansprechen.

OMG! Das ist so etwa seine 30 Jahre her oder noch länger. Und wenn da 
bereits ein I2C-Chip auf dem MB verbaut wäre, hättest du damit noch 
lange nicht die Handvoll Chips auf deinem Schreibtisch getestet. BTW: 
Auf den Motherboards der XT gab es zwar ne Menge TTL, aber keinen 
I2C-Treiberchip. Erzähle du mir da nicht allzu blauen Dunst.

Εrnst B. schrieb:
> Frage ging zwar nicht an mich, aber: An einen I2C-Bus anklemmen,

Und zwar an WELCHEN bittesehr? Mir ist noch kein PC untergekommen, der 
an seiner Rückseite ne Buchse für einen I2C gehabt hat. Dein Beitrag 
erinnert mich an die akademische Frage, wie man einen Löwen in der Wüste 
fängt. Hatten wir hier neulich, die Frage.

W.S.

von das Neutrum aus Bitrot (Gast)


Lesenswert?

>
> Stellt euch nicht an wie die ersten Menschen.
>
> W.S.

Aber eben auch nicht wie W.S.
Wozu etwas NOCHmals selber schreiben, was bereits (so gut wie) 
schlüsselfertig seit vielen Jahren bereit liegt?

> Und zwar an WELCHEN bittesehr? Mir ist noch kein
> PC untergekommen, der an seiner Rückseite ne Buchse
> für einen I2C gehabt hat.
Meine Errinnerungen knirschen ein wenig... zu späteren VGA-Zeiten 
liessen sich Grenzwerte/Eigenschaften der Bildröhrenmonitore durch die 
Grafikkarte einlesen. Was war das für eine Schnittstelle auf Pin 12 + 
15, als DDC verschleiert?

Bittesehr: Buchse auf PC-Rückseite mit I2C, ja?

Musst wohl Millenial sein, dass du sowas nicht miterlebt hast und 
recherchieren (so richtig altmodisch, mit Grips und Anstrengung) kannste 
auch nicht VOR dem ins-Forum-tröten.
Aber Tröten ja, und in falschen/unfreundlicher Tonlage ist gut - gelle?

von Frank K. (fchk)


Lesenswert?

W.S. schrieb:

> mit dem man ohne besonderen Aufwand zu Potte kommt: Man nehme irgend
> einen µC, den man per USB als VCP an den PC drankriegt, lasse diesen µC
> das niedere I2S-Zeugs machen (also Startcond, Stopcond, Daten
> übertragen...) und den Rest der Tests macht ein kleines
> selbstgeschriebenes Programm auf dem PC. Und für sowas ist es völlig
> egal, ob und wie irgend ein OS irgendwelche I2C-Steckkarten usw. kennt
> und unterstützt.

Das hat Microchip bereits auf einem PIC16F1455 gemacht und verkauft es 
als MCP2221A. Muss man also nicht mehr selber machen. Ist halt HID statt 
VCP für I2C und GPIO.

fchk

von Stefan ⛄ F. (stefanus)


Lesenswert?

W.S. schrieb:
> Stellt euch nicht an wie die ersten Menschen.

Sorry, aber zu dieser Strategie gehört, bestehende Standards (in diesem 
Fall API) zu Unterstützen anstatt sein eigenes Ding zu drehen. Das 
hatten wir zu DOS Zeiten lange genug.

W.S. schrieb:
> Mir ist noch kein PC untergekommen, der
> an seiner Rückseite ne Buchse für einen I2C gehabt hat.

Irrtum, den Raspberry Pi 400 kennst du doch, oder?
https://www.berrybase.de/raspberry-pi-400-de

Außerdem haben viele industrielle und standard PC Mainboards einen I²C 
Anschluss auf dem Mainboard. Damals waren auch einige Video-Grabber und 
Soundkarten damit ausgestattet, allerdings nur intern, nicht am 
Slotblech.

Die VGA Buchse wurde schon genannt, sie enthält einen I²C Bus.

: Bearbeitet durch User
von Εrnst B. (ernst)


Lesenswert?

W.S. schrieb:
> Εrnst B. schrieb:
>> Frage ging zwar nicht an mich, aber: An einen I2C-Bus anklemmen,
>
> Und zwar an WELCHEN bittesehr? Mir ist noch kein PC untergekommen, der
> an seiner Rückseite ne Buchse für einen I2C gehabt hat.

Das ist völlig egal, solange der Linux-Kernel den unterstützt. Z.B. 
könnte ich Drähte an einen Parallel/Druckerport dranfriemeln, "modprobe 
i2c-parport".
Manche Mainboards haben auch einen I2C/SMBus Pinheader.
Oder ich nehm eine der oben genannten USB->I2C Lösungen.
Oder ich frickel mir was an die VGA-Buchse.
Oder, oder, oder.

Das schöne ist ja: dem (z.B) eeprom-Treiber ist es egal, wie oder wo der 
I²C-Bus herkommt. Der funktioniert einfach damit.

Und wenn ich Software schreibe, die dann auf das I²C-eeprom-Device 
zugreift, hat die dafür immer dieselbe Schnittstelle. Egal ob die später 
auf einem OpenWRT-Router läuft, auf einem Raspi, oder dem PC.

: Bearbeitet durch User
von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

Ich habe da noch eine Frage zum  MCP2221A.

Kann man den sowohl als Master und als Slave nutzen oder nur als Master?

Dann noch die Superfrage:
Kann man damit auch Sniffen? Ich meine eine Monitorfunktion auf dem I2C 
Bus.

Hat die Funktionen vom Beagle von www.totalphase.com

von W.S. (Gast)


Lesenswert?

Εrnst B. schrieb:
> Das ist völlig egal, solange der Linux-Kernel den unterstützt.

Das ist überhaupt nicht egal, ganz gleich, ob da nun ein Linux-Kernel da 
was unterstützt oder nicht. Es kommt auf die Buchse auf der 
Rechnerrückseite drauf an, ob die überhaupt existiert. Das ist das, 
worauf es wirklich drauf ankommt.

Du willst doch wohl nicht ernsthaft vorschlagen, daß man irgendwo auf 
dem Mainboard seine Drähte an die Pins eines IC dranlötet.

W.S.

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Du kannst dir ja einen DRAM-Adapter bauen. Die haben auch i2c drauf.

von W.S. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Irrtum, den Raspberry Pi 400 kennst du doch, oder?

Ist der etwa ein PC? Nein, der ist eher eine Baugruppe. Ich habe hier 
einen Thinkpad und der hat keinerlei I2C-Buchsen, dafür aber ausreichend 
USB-Buchsen. Und das ist ein universelles Interface, was es heutzutage 
an eigentlich allen PC's gibt.

Suche du also lieber mal nicht weiter nach irgendwelchen exotischen 
Dingen, bloß um ein Argument zu finden.

W.S.

von Εrnst B. (ernst)


Lesenswert?

W.S. schrieb:
> Das ist überhaupt nicht egal,

Doch. ist es.

Der I²C-Bus-Treiber muss nicht wissen, welche Chips am Bus hängen, und 
die Device/IC-Treiber müssen nicht wissen, wo und wie der Bus herkommt.
Ganz klare Aufgabenteilung.

Und warum bist du vorher vehement gegen USB->I²C Adapterchips, und sagst 
jetzt dass dein Thinkpad nur USB hat, und du deswegen so Einen verwenden 
willst?
Für USB hatten wir ja schon einige Lösungen. Es geht eben auch ohne. 
Aber nur weil es eine Lösung ohne USB gibt, bedeutet das nicht, dass USB 
"verboten" wäre. Benutz' doch dann einfach USB. Hast du am wenigsten 
Probleme, und auf Software-Seite ist es egal, ob dein I²C-Bus aus dem 
USB-Dongle kommt oder per Bitbanging von der CPU auf GPIOs rausgetaktet 
wird.

von J. S. (jojos)


Lesenswert?

Εrnst B. schrieb:
> Und warum bist du vorher vehement gegen USB->I²C Adapterchips,

weil nur seine Lösung wieder die Beste ist. Nur hat er sich schon lange 
mit USB beschäfftig und USB auf dem µC zu implementieren ist deshalb ja 
sooo trivial.
Das andere das vielleicht nicht so sehen und sich gerade mal in I2C 
einarbeiten und dabei nicht auch noch mal eben USB implementieren 
wollen, das sieht Mr. Scheuklappen nicht.

Immerhin ist der SMBus auf Mainboards weit verbreitet und an Pin Headern 
verfügbar, damit könnte man den durchaus gut nutzen. Nur mit der Gefahr 
das man beim Basteln etwas zerschießt, da würde ich auch lieber einen 
billigen Umsetzer benutzen.

von Frank K. (fchk)


Lesenswert?

René D. schrieb:
> Ich habe da noch eine Frage zum  MCP2221A.
>
> Kann man den sowohl als Master und als Slave nutzen oder nur als Master?

nur als Master.

> Dann noch die Superfrage:
> Kann man damit auch Sniffen? Ich meine eine Monitorfunktion auf dem I2C
> Bus.

nein.

fchk

von W.S. (Gast)


Lesenswert?

Εrnst B. schrieb:
> Der I²C-Bus-Treiber muss nicht wissen, welche Chips am Bus hängen, und
> die Device/IC-Treiber müssen nicht wissen, wo und wie der Bus herkommt.
> Ganz klare Aufgabenteilung.

Du theoretisierst. Wenn ich dir ein Notebook und 2 Drähte in die Hand 
drücken würde und dazu sagen würde "du mußt nicht wissen, welche Chips 
am Bus hängen... Mach deshalb mal einen Testaufbau zum Testen von Chips 
am I2C aus dem Notebook und den 2 Drähten" dann würdest du vermutlich 
ziemlich bedröppelt ausschauen, weil damit keiner zu Potte kommen kann.

> Und warum bist du vorher vehement gegen USB->I²C Adapterchips, und sagst
> jetzt dass dein Thinkpad nur USB hat, und du deswegen so Einen verwenden
> willst?

Weil es nicht das Thema dieses Threads ist, sich irgendwelche I2C-Chips 
auszugucken und dann beschaffen zu wollen (nebst Treibern dafür), 
sondern einen Testaufbau zu machen. Sollte doch verständlich sein.

W.S.

von Εrnst B. (ernst)


Lesenswert?

W.S. schrieb:
> weil damit keiner zu Potte kommen kann.

Ach. Und deine Lösung mit: "Es muss über USB gehen, darf aber kein USB 
verwenden" ist besser?
Projizierst du den I2C-Bus mit Gedankenkraft an die Chips?

W.S. schrieb:
> sondern einen Testaufbau zu machen. Sollte doch verständlich sein.

Nur du verstehst das nicht. Es geht um das Testen von Chips mit 
I²C-Interface, nicht um das Testen von I2C-Bussimplementierungen.

Zu schnell Fahrer schrieb:
> I2C Chips vom PC aus zu testen.
> Das einfachste einen PCF8574 I2C IO Port IC vom PC aus an zu steuern.
> Weitere Anwendungen, AD Wandler oder PLL ICs

Deshalb nimmt man für den Bus am besten was Fertiges, was sicher 
funktioniert und gute Treiberunterstützung bietet.
Damit kann ich mich exakt auf die Aufgabe konzentrieren, und muss nicht 
haufenweise zusätzliche Phantom-Fehlerquellen im Auge behalten.

von M.M.M (Gast)


Lesenswert?

J. S. schrieb:
> AFAIK kennt nur die IoT Version von Windows I2C. Aber wer benutzt das
> schon?

Auf einem Mainboard kann im Zweifelsfall was an an i2c hängen 
(Lüftersteuerung, Sensoren..), mit dem Win bestimmt auch gerne umgehen 
möchte. Von daher würde ich mal annehmen, daß es auch unterstützt wird.

von W.S. (Gast)


Lesenswert?

Εrnst B. schrieb:
> Ach. Und deine Lösung mit: "Es muss über USB gehen, darf aber kein USB
> verwenden" ist besser?

Hast du eine bessere Idee? Eine in der Realität bessere?
Nein, hast du nicht.

Auch das Anzapfen von irgendwelchen PC-internen Bussen ist überhaupt 
keine Lösung, denn sowas ist ja nicht für einen Anwender gemacht, 
sondern dient zu PC-internen Zwecken und da gibt es zumeist keine 
Buchsen, wo man irgend einen Stecker draufstecken kann und es gibt 
bereits Baugruppen, die am Bus hängen, Adressen belegen und 
möglicherweise ernste Störungen ergeben, wenn man dort zu Testzwecken 
dran herumfummelt. Ganz zu schweigen von Betriebssystemteilen, die es 
nicht vorgesehen haben, daß man ihnen in die Quere kommt. Und deshalb 
sollte man alle eventuell für interne Zwecke vorgesehenen Dinge in einem 
PC in Ruhe lassen und nur die nach außen für allgemeine Verwendung 
bestimmte Dinge in Erwägung ziehen.

Der USB ist heutzutage so ziemlich das einzige Interface, was ohne 
Probleme wie Aufschrauben, Anlöten usw. aus einem PC herausführt. OK, 
falls vorhanden kann man auch einen echten COM-Port benutzen, aber sowas 
ist heutzutage selten geworden.

Damit hast du das Szenario, in dem man sich am PC bewegen kann, ohne 
anzuecken. Was bleibt, ist dann nur noch der Übergang vom USB zum 
eigentlichen I2C-Testanschluß. Und den kann man mit sehr vielen µC 
erledigen, von denen recht wahrscheinlich einer bereits in der 
Bastelkiste liegt. Das passende Testprogramm muß man sich ohnehin 
vermutlich selber schreiben, da kommt es drauf an, was da alles zu 
testen ist. Die Suche nach einem Spezial-IC ist also nicht notwendig.

Alles andere ist aus meiner Sicht nur Träumerei.

W.S.

von Εrnst B. (ernst)


Lesenswert?

W.S. schrieb:
> Hast du eine bessere Idee? Eine in der Realität bessere?

Ja. Eine Stabilen I²C-Bus zum Testen zu verwenden, der einen sauber 
funktionierenden Treiber hat.

W.S. schrieb:
> Auch das Anzapfen von irgendwelchen PC-internen Bussen ist überhaupt
> keine Lösung,

Die krankhafte Fixierung auf diese Möglichkeit hast nur du.

Ich würde da einfach einen µC mit USB und I²C dranhängen.
Aber mit Firmware, die dem PC ermöglicht, den I²C-Bus als solchen zu 
erkennen.
Meinetwegen auch einen Maskenprogrammierten PIC / MCP2221A, wenn einem 
der Tiny85 mit vusb nicht gefällt.

> Der USB ist heutzutage so ziemlich das einzige Interface, was ohne
> Probleme wie Aufschrauben, Anlöten usw. aus einem PC herausführt.

Ja. Deshalb gut für solche Testaufbauten. Warum sträubst du dich so 
dagegen?

> Und den kann man mit sehr vielen µC
> erledigen, von denen recht wahrscheinlich einer bereits in der
> Bastelkiste liegt.

Ah. Jetzt auf einmal doch USB?

> Das passende Testprogramm muß man sich ohnehin
> vermutlich selber schreiben,

Nö. sh. oben.

> da kommt es drauf an, was da alles zu
> testen ist.

Mit vernünftiger Firmware am µC: Geht alles, notfalls sogar mit 
Bordmitteln an der Shell. Ohne dass man für jedes neue Test-IC den µC 
neu flashen muss.

> Die Suche nach einem Spezial-IC ist also nicht notwendig.

Spart aber Arbeit. Und ein "Attiny85" oder STM32F103 ist nun auch nicht 
soo speziell.

> Alles andere ist aus meiner Sicht nur Träumerei.

Du wirst irgendwann auch noch feststellen, dass es sich rächt an seinem 
Werkzeug zu sparen.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Εrnst B. schrieb:
> Ja. Eine Stabilen I²C-Bus zum Testen zu verwenden, der einen sauber
> funktionierenden Treiber hat.

Jaja,
Frage: Wie kann ich mein Problem lösen?
Antwort: Man nehme eine fertige Lösung.
Komische Logik deinerseits, leider hast du die immer bloß wiederholt. 
Und inzwischen hast du dich so oft um die eigene Achse gedreht, daß du 
nicht mehr auseinander halten kannst, wer hier was geschrieben hat.

Um dich mal wieder auszurichten, zitiere ich mich mal selbst:
W.S. schrieb:
> Nimm stattdessen irgend einen µC, der per USB am PC einen COM-Port
> darstellen kann und packe dort die notwendigen Lowlevel-Treiber für I2C
> drauf, dazu noch passende Kommandos und den Rest macht dein
> selbstgeschriebenes Testprogramm auf dem PC.

Reicht das jetzt?
Das eigentümliche Mißverständnis kam damit auf:

Joachim S. schrieb:
> Ich habe vor ein paar Jahren ebenfalls eine Möglichkeit gesucht, am PC
> direkt mit I2C-Geräten zu kommunizieren, bin dann letztlich auch bei
> i2c-tiny-usb gelandet und kann nur bestätigen, dass das zumindest unter
> Linux wunderbar funktioniert

Das Ziel der Übung besteht nicht darin, vom PC aus direkt mit 
I2C-Geräten zu kommunizieren, sondern etwas zu haben, womit man 
irgendwelche Chips mit I2C-Inteface testen kann. Man könnte das auch mit 
einem Testaufbau ohne jeglichen PC machen, bloß mit einem PC geht vieles 
leichter. Aber dafür braucht der PC selbst kein I2C-Interface zu haben, 
sondern nur eines zum Kommunizieren mit dem Rest des Testaufbaues. Und 
von den Innereien des PC lassen wir lieber die Finger.

Wird dir jetzt das Anliegen klarer?

W.S.

von Stefan ⛄ F. (stefanus)


Lesenswert?

W.S. schrieb:
> Es kommt auf die Buchse auf der
> Rechnerrückseite drauf an, ob die überhaupt existiert. Das ist das,
> worauf es wirklich drauf ankommt.

Wer keine I²C Buchse hat, der hat USB. Wurde bereits mehrfach gesagt.

>> Irrtum, den Raspberry Pi 400 kennst du doch, oder?
> Ist der etwa ein PC?

Informiere dich doch erstmal, bevor du dir ins eigene Knie schießt. Das 
ist ja echt peinlich! Der Raspberry Pi 400 wird mit Tastatur, Maus und 
Dekstop Linux ausgeliefert. Auch Windows läuft darauf, wenn man will.

> Suche du also lieber mal nicht weiter nach irgendwelchen
> exotischen Dingen, bloß um ein Argument zu finden.

Was ist denn bitte daran Exotisch, einen handelsüblichen oder selbst 
gebauten USB-I2C Adapter zu benutzen, der sogar vom Betriebssystem 
ausdrücklich unterstützt wird?

Exotisch ist das Ding von ELV, das ausschließlich mit der 
Software/Libraries von ELV benutzt werden kann. Wie schnell deren 
Software unbrauchbar wird, da nicht mehr aktualisiert, haben vermutlich 
schon viele Leute hier erlebt..

Ich habe das Gefühl, dass du dir quasi die Ohren zu hältst und 
"lalalalalala" rufst.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

Εrnst B. schrieb:
> Und warum bist du vorher vehement gegen USB->I²C Adapterchips, und sagst
> jetzt dass dein Thinkpad nur USB hat, und du deswegen so Einen verwenden
> willst?

Weil: lalalalalalalalala, oder

J. S. schrieb:
> weil nur seine Lösung wieder die Beste ist.

Mir fällt dazu auch nichts nettes mehr ein. Wie kann man nur so verbohrt 
sein?

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

W.S. schrieb:
> Was bleibt, ist dann nur noch der Übergang vom USB zum
> eigentlichen I2C-Testanschluß. Und den kann man mit sehr vielen µC
> erledigen, von denen recht wahrscheinlich einer bereits in der
> Bastelkiste liegt.

Ja, in meinem Fall ist das ein Digispark (ATtiny85).

> Das passende Testprogramm muß man sich ohnehin
> vermutlich selber schreiben

Eben nicht. Es wurde doch oben schon gezeigt, dass generische 
Testprogramme in Linux enthalten sind!

Und wenn ich mir ein Programm schrieben muss, dann 100x lieber aus Basis 
einer Standard API, denn dann kann ich später auch einen anderen Adapter 
benutzen, falls der Digispark mal nicht mehr funktioniert.

> da kommt es drauf an, was da alles zu testen ist.

Sicher. Für viele Fälle ist schon Software da, die benutze ich 
logischerweise gerne, wenn ich kann.

> Die Suche nach einem Spezial-IC ist also nicht notwendig.

Hat ja auch niemand gesagt. Es wurden ganz normale handelsüblich IC's 
empfohlen. Deiner Methode ist ein Spezialfall, da er eine eigene 
Firmware hat die nicht die Standard API unterstützt und daher auch nicht 
mit den Standard Programmen genutzt werden kann.

von W.S. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Und wenn ich mir ein Programm schrieben muss, dann 100x lieber aus Basis
> einer Standard API, denn dann kann ich später auch einen anderen Adapter
> benutzen, falls der Digispark mal nicht mehr funktioniert.

Du würdest (jaja, immer der gehäufte Konjunktiv hier) also für das OS 
deiner Wahl einen Treiber für deinen ATtiny schreiben, bloß um die 
Interface-Vorgaben des OS zu erfüllen und dies bloß um dann dein 
eigentliches Testprogramm unter Benutzung ebendieses Interfaces 
schreiben zu können. Ach ja, obendrein ist auch noch die Firmware für 
deinem ATtiny nötig und das Einbinden deines selbstgeschriebenen 
Treibers in dein OS. Mahlzeit!

Tja und zu der Zeit, wo ihr hier erhitzt über Treiber-IC für den I2C und 
über irgendwelche Routinen im Linux-Kernel diskutiert habt, hatte ich 
vorgeschlagen, einfach einen µC zu nehmen, sofern man den an den PC 
angeschlossen kriegt und fertig ist die Laube. Und jetzt kommst du, und 
tust so, als ob du derjenige wärest mit deinem ATtiny.

Ich vermute mal, daß es der Schaum vor dem Mund ist, der zu sowas führt. 
Also beruhige dich mal.

Ich sehe schon, daß es dir weitaus wichtiger ist, ein Standard-API zu 
benutzen, sobald du eines erspäht hast, als dir Gedanken über den 
eigentlichen Themeninhalt zu machen. Naja, das sind deine Prioritäten.

W.S.

von Stefan ⛄ F. (stefanus)


Lesenswert?

W.S. schrieb:
> Du würdest (jaja, immer der gehäufte Konjunktiv hier) also für das OS
> deiner Wahl einen Treiber für deinen ATtiny schreiben

Der Treiber für den Digispark (I2C-Tiny-USB) ist doch schon da!

> Ach ja, obendrein ist auch noch die Firmware für deinem ATtiny nötig

Die ist auch schon fix und fertig!

Deswegen will ich den ja nehmen. Habe ich nicht oft genug geschrieben, 
dass ich so weit wie möglich bestehende Software verwenden möchte?

Du bist derjenige, der hier das Rad neu erfinden will.

: Bearbeitet durch User
von DerDetlef (Gast)


Lesenswert?

Ist doch kein Wunder, dass er das will, wo er doch am liebsten seine 
räudige "Lernbetty" und seine sehr grindigen Vorstellungen über "C" an 
den Mann bringen möchte.

von Stefan ⛄ F. (stefanus)


Lesenswert?

W.S. schrieb:
> Tja und zu der Zeit, wo ihr hier erhitzt über Treiber-IC für den I2C und
> über irgendwelche Routinen im Linux-Kernel diskutiert habt, hatte ich
> vorgeschlagen, einfach einen µC zu nehmen, sofern man den an den PC
> angeschlossen kriegt und fertig ist die Laube. Und jetzt kommst du, und
> tust so, als ob du derjenige wärest mit deinem ATtiny.

Jetzt verdrehst du aber die Tatsachen. Hier war alles gut, bis jemand 
den I2C-Tiny-USB vorschlug. Von da an hast du die Diskussion versaut, 
indem du wiederholt dagegen argumentiert hast. Dabei hast du dir selbst 
mehrfach widersprochen, anderer Leute Aussagen verdreht und Fakten 
ignoriert.

So macht die Diskussion keinen Sinn. Ich werd dir in diesem Thread 
nicht mehr antworten.

von J. S. (jojos)


Lesenswert?

Diskussion? Das sind nur Monologe.

von Ludwig K. (hellas)


Lesenswert?

Stefan ⛄ F. schrieb:
> Exotisch ist das Ding von ELV, das ausschließlich mit der
> Software/Libraries von ELV benutzt werden kann. Wie schnell deren
> Software unbrauchbar wird, da nicht mehr aktualisiert, haben vermutlich
> schon viele Leute hier erlebt..

Das ist gelinde gesagt Käse.
Wo ihr hier noch sinnlos rum diskutiert, bin ich mit dem ollen ELV Ding 
schon längst fertig. Was an dem Teil so schlecht sein soll, keine 
Ahnung. Das Ding funktioniert einfach. Und wer mit Hterm unter Windoof 
klar kommt, kann auch seine Chips ruckzuck prüfen.

Das mit dem Raspi400 ist eine Überlegung wert. Da eh vorhanden, kann er 
auch genutzt werden...

von Jobst M. (jobstens-de)


Angehängte Dateien:

Lesenswert?

Ich kann hier noch ein kleines Projekt anbieten. Läuft am Amiga wie am 
Palm - und an allem, was eine RS232-Schnittstelle (bzw. UART) hat und 
diese mit einem Terminal ansprechen kann.

Für ATmega328 mit 18,432MHz und 19200Bd in asm geschrieben, lässt sich 
natürlich ändern.

Kann den Bus scannen, n Bytes schreiben, n Bytes als HEX und ASCII 
lesen.
Eine kurze Hilfe wird mit H ausgegeben.

Vielleicht kann es ja jemand gebrauchen...


Gruß
Jobst

von Stefan ⛄ F. (stefanus)


Lesenswert?

Ludwig K. schrieb:
> Das ist gelinde gesagt Käse.

Ich kenne den I²C Adapter von ELV nicht. Habe mit Software von anderen 
Produkten jedoch schlechte Erfahrungen gemacht. Wenn das Ding quasi ohne 
ELV Software nutzbar ist, dann will ich nicht meckern. Gute dass du das 
klar gestellt hast.

von W.S. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Jetzt verdrehst du aber die Tatsachen. Hier war alles gut, bis jemand
> den I2C-Tiny-USB vorschlug. Von da an hast du die Diskussion versaut,
> indem du wiederholt dagegen argumentiert hast.

Lüge nicht so dreist. Die in diesem Thread vorhandenen Beiträge zeigen 
etwas ganz anderes. Ich schrieb am  06.06.2022 14:25

W.S. schrieb:
> Zu schnell Fahrer schrieb:
>> ich suche nach einer Möglichkeit um I2C Chips vom PC aus zu testen.
>> Das einfachste einen PCF8574 I2C IO Port IC vom PC aus an zu steuern.
>
> Ich sehe so etwas nicht als die einfachste Lösung.
> Nimm stattdessen irgend einen µC, der per USB am PC einen COM-Port
> darstellen kann und packe dort die notwendigen Lowlevel-Treiber für I2C
> drauf, dazu noch passende Kommandos und den Rest macht dein
> selbstgeschriebenes Testprogramm auf dem PC. Passende µC hat es bislang
> zuhauf gegeben,...

Und erst danach kamest DU mit dem API, und zwar am 13.06.2022 17:23:

Stefan ⛄ F. schrieb:
> Aber Linux und Windows haben beide eine API zum Ansprechen von I²C
> Bussen. Insofern möchte ich einen I²C Adapter verwenden der diese API
> unterstützt. Ansonsten muss ich mein Programm mit einer proprietären API
> verheiraten und bin dadurch mindestens an den Hersteller des Adapters
> gebunden, wenn nicht an den konkreten Adapter selbst.

Und den ATtiny hat Ernst erstmalig erwähnt, und zwar am 14.06.2022 
16:21:

Εrnst B. schrieb:
> Und ein "Attiny85" oder STM32F103 ist nun auch nicht soo speziell.

Eigentlich herrscht hier durchaus die Ansicht, daß es das Einfachste 
ist, den Testaufbau mit irgendeinem geeigneten µC zu erledigen und daß 
es dazu bloß notwendig ist, selbigen irgendwie an den PC anzuschließen.

Du bist der Einzige, der wiederholt auf irgendwelchen 
Standard-Interfaces im OS heumgehackt hat - und zwar vehement. Das war 
und ist am eigentlichen Thema vorbei. Und das hatte ich dir mehrfach 
bereits dargelegt und das auch begründet. Und jetzt bist du die 
beleidigte Leberwurst und sagst "bäh, mit dir spiele ich nicht mehr". 
OK, akzeptiert, aber halte dich dran.

W.S.

von Εrnst B. (ernst)


Lesenswert?

W.S. schrieb:
> Und den ATtiny hat Ernst erstmalig erwähnt, und zwar am 14.06.2022
> 16:21:

Stimmt nicht, 10.01.2022 00:58:

Hmmm schrieb:
> Es gibt z.B. das hier: https://github.com/harbaum/I2C-Tiny-USB

--> Das läuft neben den Tinies 45,85 auch auf mega8, mega88 und 
Varianten.
Ports auf STM32 (Bluepill&co) existieren ebenfalls.

W.S. schrieb:
> Und erst danach kamest DU mit dem API, und zwar am 13.06.2022 17:23:

Stimmt auch nicht, 10.01.2022 06:52:

PittyJ schrieb:
> Es gibt freie Tools wie i2cdetect, i2cset ..

Also, konkret:
Was misfällt dir so an den Lösungen, die Standard-Hardware (µC aus der 
Bastelkiste, Aliexpress-Platinchen, RasPi, ...) mit Standard-Software 
koppeln?
NIH-Syndrom?
Zu einfach?

von Stefan ⛄ F. (stefanus)


Lesenswert?

Nach Joachim S. Vorschlag habe ich mir ein set Digispark bestellt, die 
I2C-Tiny-USB Firmware drauf geladen und mit den Standard i2c-tools 
ausprobiert. Hat prima geklappt, einfacher hätte es gar nicht laufen 
können.

Danke Joachim

Ich habe mir dazu ein paar Notizen gemacht. Siehe unten.

@W.S. da kannst du mal sehen, wie viele I²C Busse mein Laptop bereits 
hat, die alle das gleiche Standard API unterstützen.

--------------------------------------
Firmware for Digispark Boards to be used as an I²C adapter under Linux.
The following commands must be executed as root.

Upload firmware:
1
micronucleus --run --dump-progress --type intel-hex main.hex

Install I2C Tools and load the kernel driver:
1
apt install i2c-tools
2
modprobe i2c-dev

Scan for I2C busses:
1
root@stefanspc:~# i2cdetect -l
2
i2c-0  smbus       SMBus I801 adapter at 5040        SMBus adapter
3
i2c-1  i2c         nvkm-0000:01:00.0-bus-0000        I2C adapter
4
i2c-2  i2c         nvkm-0000:01:00.0-bus-0001        I2C adapter
5
i2c-3  i2c         nvkm-0000:01:00.0-bus-0002        I2C adapter
6
i2c-4  i2c         nvkm-0000:01:00.0-bus-0005        I2C adapter
7
i2c-5  i2c         nvkm-0000:01:00.0-bus-0006        I2C adapter
8
i2c-6  i2c         nvkm-0000:01:00.0-bus-0007        I2C adapter
9
i2c-7  i2c         nvkm-0000:01:00.0-bus-0008        I2C adapter
10
i2c-8  i2c         nvkm-0000:01:00.0-bus-0009        I2C adapter
11
i2c-9  i2c         nvkm-0000:01:00.0-aux-000a        I2C adapter
12
i2c-10  i2c         nvkm-0000:01:00.0-aux-000b        I2C adapter
13
i2c-11  i2c         nvkm-0000:01:00.0-aux-000c        I2C adapter
14
i2c-12  i2c         nvkm-0000:01:00.0-aux-000d        I2C adapter
15
i2c-13  i2c         i915 gmbus dpc                    I2C adapter
16
i2c-14  i2c         i915 gmbus dpb                    I2C adapter
17
i2c-15  i2c         i915 gmbus dpd                    I2C adapter
18
i2c-16  i2c         AUX A/DDI A/PHY A                 I2C adapter
19
i2c-17  i2c         i2c-tiny-usb at bus 001 device 109  I2C adapter

Check capabilities of the I²C adapter:
1
root@stefanspc:~# i2cdetect -F 17
2
Functionalities implemented by /dev/i2c-17:
3
I2C                              yes
4
SMBus Quick Command              yes
5
SMBus Send Byte                  yes
6
SMBus Receive Byte               yes
7
SMBus Write Byte                 yes
8
SMBus Read Byte                  yes
9
SMBus Write Word                 yes
10
SMBus Read Word                  yes
11
SMBus Process Call               yes
12
SMBus Block Write                yes
13
SMBus Block Read                 no
14
SMBus Block Process Call         no
15
SMBus PEC                        no
16
I2C Block Write                  yes
17
I2C Block Read                   yes

Scan the I2C bus:
1
root@stefanspc:~# i2cdetect 17
2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
3
I will probe file /dev/i2c-17.
4
I will probe address range 0x08-0x77.
5
Continue? [Y/n] Y
6
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
7
00:                         -- -- -- -- -- -- -- -- 
8
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
9
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
10
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
11
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
12
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
13
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
14
70: -- -- -- -- -- -- -- --

Send data:
1
i2cset 17 0x20 0x12 1
This example sends the value 1 to address 0x12 on slave 0x20 at bus 17.

Receive data:
1
i2cget 17 0x20 0x12 i 5
This example receives 5 bytes from address 0x12 on slave 0x20 at bus 17.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.