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.
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
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.
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.
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:
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.
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
> 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
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
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
> 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
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.
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
Ε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.
> 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.
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.
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.
Ε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:
Thread beobachten
Seitenaufteilung abschalten