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.
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
Kuck da: https://linux-club.de/wiki/opensuse/USB_Status_von_USB_pr%C3%BCfen Oft reicht aber schon "lsusb".
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.
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
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.
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.
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
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
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 ...
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.
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.
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.
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
Microchip Serial Analyzer kann I2C, SPI und RS-232. Da ein normaler 16F2550 (+ Targetlevelshiftern) drin steckt, sicher mit einiger Eigeninitiative noch einiges mehr.
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.
(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?
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."
(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)
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 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
Was spricht jetzt gegen die ELV-Variante mit HTerm unter Windows?
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.
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
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
> 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.
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
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.
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
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.
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
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?
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.
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
Angehängte Dateien:
-
Bild_2022-06-12_123545767.png
490 KB -
Bild_2022-06-12_123632985.png
500 KB
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
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.
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
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.
> 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?
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
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.
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.
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
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.
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.
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.
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.
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
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
Ε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.
AFAIK kennt nur die IoT Version von Windows I2C. Aber wer benutzt das schon?
J. S. schrieb: > Aber wer benutzt das schon? Windows ist eh nicht so Entwickler-Freundlich wie Linux. SCNR
ich mag es lieber Benutzerfreundlich. Und Linux läuft prima im Fenster. WSL jetzt auch mit USB um etwas on topic zu bleiben.
> 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! ;-)
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!.... <:-)
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.
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.
> > 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?
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
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.
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
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
Ε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.
Du kannst dir ja einen DRAM-Adapter bauen. Die haben auch i2c drauf.
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.
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.
Ε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.
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
Ε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.
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.
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.
Ε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.
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
Ε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.
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.
Ε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?
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.
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.
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.
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.
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.
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...
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
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.
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.
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?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.