Ich habe für ein Projekt einen FT260 vorgesehen, da ich fälschlicherweise dachte man könne den UART als V-COM und I2C als HID verwenden. Ich habe zwar den MCP2221 gefunden, welcher einen UART CDC haben soll, welcher als COM Port verwendet werden kann und einen I2C HID ... leider ohne die DTR und RTS Leitungen für den UART. Kennt jemand einen Chip (sollte ein einzelner Chip sein), welcher UART (COM Port) mit Flow Control sowie ein I2C HID interface erlaubt? Ich möchte einen ESP32 über ein einzelnes USB Kabel mit dem Computer verbinden und Tastatureingaben simulieren und aber den ESP per Arduino programmieren ohne selber RST und IO0 wackeln zu müssen. Das ganze soll aus einem Reset zustand funktionieren was bedeutet, dass es auch funktionieren soll wenn der ESP kein programm drauf hat oder sich aufgrund eines softwarefehlers festgehangen hat.
Wenn Du nur ein Kabel einsparen möchtest: Der ESP32 müsste über Bluetooth (LE?) auch eine Tastatur emulieren können (HID Profil).
.Gast schrieb: > ohne die DTR und RTS Leitungen für den UART. Es gibt dafpr doch extra freie Ports dafür am MCP2221.
merciMerci schrieb: > Es gibt dafpr doch extra freie Ports dafür am MCP2221. Es gibt dafür doch extra freie Ports am MCP2221.
.Gast schrieb: > Ich habe zwar den MCP2221 gefunden, welcher einen UART CDC haben soll, > welcher als COM Port verwendet werden kann und einen I2C HID ... leider > ohne die DTR und RTS Leitungen für den UART. Genau. > Kennt jemand einen Chip (sollte ein einzelner Chip sein), welcher UART > (COM Port) mit Flow Control sowie ein I2C HID interface erlaubt? FT2232D (Full Speed) oder FT2232H (High Speed). Der Chip hat eine MPSSE Einheit, die für JTAG, SPI, I2C und ähnliches benutzt werden kann. Die liegt auf dem ersten Port, der auch einen UART hat. Der zweite Port kann nur für einen UART verwendet werden. Beide UARTs haben vollständige Modelsignale (RTS/CTS, DTR/DSR/DCD, RI). Nachteile: Der Chip ist recht groß (TQFP48 beim FT2232D, TQFP64 beim FT2232H), und er braucht extra proprietäre Kerneltreiber. fchk
.Gast schrieb: > Ich habe für ein Projekt einen FT260 vorgesehen, da ich > fälschlicherweise dachte man könne den UART als V-COM und I2C als HID > verwenden. PS: Das HID beim MCP2221 ist ein Full Custom HID. Heißt also, das Device wird zwar über die HID.DLL gesteuert und braucht keine extra Gerätetreiber, aber es bildet keine der Standardklassen wie Tastatur oder Maus ab. Wenn Du so etwas erwartest, wirst Du entäuscht. Keine USB-I2C Bridge bildet eine Standardklasse ab. So etwas müsstest Du selber implementieren. fchk
Jim M. schrieb: > Wenn Du nur ein Kabel einsparen möchtest: Der ESP32 müsste über > Bluetooth (LE?) auch eine Tastatur emulieren können (HID Profil). Bluetooth ist leider bei den Computern, an welchen das ganze angebunden werden soll nicht vorhanden. merciMerci schrieb: > .Gast schrieb: >> ohne die DTR und RTS Leitungen für den UART. > > Es gibt dafpr doch extra freie Ports dafür am MCP2221. Ich sehe leider nicht, wie diese als DTR / RTS verwendet werden können, wenn das Programm die nicht als "GPIO" selber steuert. Ich würde gerne, dass die Reset Schaltung eines ESP32 über Arduino funnktioniert. Frank K. schrieb: > .Gast schrieb: > >> Ich habe zwar den MCP2221 gefunden, welcher einen UART CDC haben soll, >> welcher als COM Port verwendet werden kann und einen I2C HID ... leider >> ohne die DTR und RTS Leitungen für den UART. > > Genau. > >> Kennt jemand einen Chip (sollte ein einzelner Chip sein), welcher UART >> (COM Port) mit Flow Control sowie ein I2C HID interface erlaubt? > > FT2232D (Full Speed) oder FT2232H (High Speed). Der Chip hat eine MPSSE > Einheit, die für JTAG, SPI, I2C und ähnliches benutzt werden kann. Die > liegt auf dem ersten Port, der auch einen UART hat. Der zweite Port kann > nur für einen UART verwendet werden. Beide UARTs haben vollständige > Modelsignale (RTS/CTS, DTR/DSR/DCD, RI). > > Nachteile: Der Chip ist recht groß (TQFP48 beim FT2232D, TQFP64 beim > FT2232H), und er braucht extra proprietäre Kerneltreiber. > > fchk Leider ist der Chip etwas zu groß. Ich habe aktuell ein QFN28 und das ist wirklich das Maximum was ich noch unter bringen konnte. Die Platine ist leider schon sehr voll gestopft und das Gehäuse hat eine feste Größe. Frank K. schrieb: > .Gast schrieb: >> Ich habe für ein Projekt einen FT260 vorgesehen, da ich >> fälschlicherweise dachte man könne den UART als V-COM und I2C als HID >> verwenden. > > PS: Das HID beim MCP2221 ist ein Full Custom HID. Heißt also, das Device > wird zwar über die HID.DLL gesteuert und braucht keine extra > Gerätetreiber, aber es bildet keine der Standardklassen wie Tastatur > oder Maus ab. Wenn Du so etwas erwartest, wirst Du entäuscht. Keine > USB-I2C Bridge bildet eine Standardklasse ab. So etwas müsstest Du > selber implementieren. > > fchk Das ist eine interessante Information mit dem HID. Wichtig ist mir der UART ohne dass etwas extern konfiguriert werden muss. Das mit der Tastatur beim MCP2221 werde ich mir noch mal etwas genauer anschauen .... vllt. muss ich das ja auch ganz anders machen.
Ich glaube ich habe jetzt eine mögliche Idee. - Problem: Gehäusegröße / Computer haben kein Bluetooth. Es kann kein Bluetooth Stick an die Computer angeschlossen werden. Das Gehäuse kann ich nicht größer machen. Mehr Chips passen nicht in das Gehäuse. -> Ich könnte anstelle "das Gerät" an den Computer an zu schließen ein extra Gerät bauen, welches sich als Tastatur ausgibt und selber per Bluetooth mit dem "Gerät" verbunden ist um die gewünschten Tastaturdrücke dar zu stellen. Nun muss ich nur noch das RS232 Interface im Gehäuse haben was per 4Layer Adapterplatine machbar sein sollte.
Wie willst Du dem PC eine Tastatur vorspielen? Per USB? Dann kannst Du genauso gut einen BT-Stick einstecken. Per PS/2? Haben die Rechner überhaupt noch PS/2-Anschlüsse? Dein Gerät müsste dann ja parallel zu einer vorhandenen PS/2-Tastatur funktionieren. fchk
.Gast schrieb: > Wichtig ist mir der UART ohne dass etwas extern konfiguriert werden > muss. Dann ist der FTDI sowieso außen vor, denn der implementiert kein CDC - einzig deren proprietärer Treiber wird unterstützt. Ohne den kannst du mit dem Teil praktisch nichts anfangen. Und eine ordentliche Protokollbeschreibung gibt es auch nicht für die FTDI-Chips - einzig der Treiber im Linux-Kernel ist mir bekannt, der open-source ist. Vermutlich entstand der aus Reverse-Engeneering. Ich habe schon vor Jahren bei denen angefragt, wieso sie denn keinen Chip hinbekommen, der ganz gewöhnliches CDC unterstützt, offenbar haben die es nicht nötig... Die Microchip-Teile sind gut, haben wir auch im Einsatz - völlig problemlos!
Frank K. schrieb: > Wie willst Du dem PC eine Tastatur vorspielen? Per USB? Dann > kannst Du > genauso gut einen BT-Stick einstecken. Per PS/2? Haben die Rechner > überhaupt noch PS/2-Anschlüsse? Dein Gerät müsste dann ja parallel zu > einer vorhandenen PS/2-Tastatur funktionieren. > > fchk Eine USB Tastatur wird auch bei noch so hohen Sicherheitseinstellungen von Windows erkannt. Alle Bluetooth Sticks, die ich bisher hatte wollten spezielle Treiber / Software um richtig zu funktionieren. Eine USB Tastatur kann man sogar einstecken und Nutzen während aktuell kein Nutzer angemeldet ist. Michael schrieb: > .Gast schrieb: >> Wichtig ist mir der UART ohne dass etwas extern konfiguriert werden >> muss. > > Dann ist der FTDI sowieso außen vor, denn der implementiert kein CDC - > einzig deren proprietärer Treiber wird unterstützt. Ohne den kannst du > mit dem Teil praktisch nichts anfangen. Und eine ordentliche > Protokollbeschreibung gibt es auch nicht für die FTDI-Chips - einzig der > Treiber im Linux-Kernel ist mir bekannt, der open-source ist. Vermutlich > entstand der aus Reverse-Engeneering. > > Ich habe schon vor Jahren bei denen angefragt, wieso sie denn keinen > Chip hinbekommen, der ganz gewöhnliches CDC unterstützt, offenbar haben > die es nicht nötig... > > Die Microchip-Teile sind gut, haben wir auch im Einsatz - völlig > problemlos! Bei dem FTDI geht es mir darum, dass dieser von µController Seite nicht konfiguriert werden muss. Dieser darf gerne auf dem Computer zusätzliche Software / Treiber benötigen. Die Microchip teile haben (nach Preis sortiert und geschaut bis ich was gefunden habe) nicht die benötigten DTR / RTS bei entsprechend geringen Pinzahlen. -> QFN20. Auch wenn vorher ein etwas größerer Chip eingeplant worden war muss der neue etwas kleiner sein, um die Adapterplatine ordentlich unter zu bekommen.
Wie wäre es, wenn du dir einen geeigneten µC aussuchst und das USB device nach deinen Bedürfnissen selbst implementierst?
QQ schrieb: > Wie wäre es, wenn du dir einen geeigneten µC aussuchst und das USB > device nach deinen Bedürfnissen selbst implementierst? Liegt nicht in meinen Möglichkeiten. Ich habe mich zwar schon etwas an USB versucht, sehe dies aber nicht als Zielführend.
Michael schrieb: > Ich habe schon vor Jahren bei denen angefragt, wieso sie denn keinen > Chip hinbekommen, der ganz gewöhnliches CDC unterstützt, offenbar haben > die es nicht nötig... Das hat historische Gründe. CDC-ACM ist nicht bei Microsoft entstanden, und alle Implementationen von fremden Standards durch Microsoft, waren und sind anfangs grottig. Auch CDC-ACM ist ein solchen Beispiel, oder USB 2.0-Audio (nicht das 1.1'er USB Audio). Des weiteren bildet CDC-ACM natürlich nicht solche Sachen wie Bitbanging ab, oder die diversen MPSSE-Konfigurationen. fchk
.Gast schrieb: > QQ schrieb: >> Wie wäre es, wenn du dir einen geeigneten µC aussuchst und das USB >> device nach deinen Bedürfnissen selbst implementierst? > > Liegt nicht in meinen Möglichkeiten. > Ich habe mich zwar schon etwas an USB versucht, sehe dies aber nicht als > Zielführend. Schade. Bei Deinen Anforderungen wäre genau das die einzig mögliche Lösung gewesen. Wenn es etwas ist, womit Du Dein Geld verdienst (also kein Bastelobjekt, bei dem es egal ist), wirst Du entweder Abstriche machen müssen oder Geld in die Hand nehmen müssen, um jemandem einen entsprechenden Entwicklungsaufwand zu geben. fchk
fchk schrieb: > Das hat historische Gründe. CDC-ACM ist nicht bei Microsoft entstanden, > und alle Implementationen von fremden Standards durch Microsoft, waren > und sind anfangs grottig. Auch CDC-ACM ist ein solchen Beispiel, oder > USB 2.0-Audio (nicht das 1.1'er USB Audio). Jaein, keine der Classspecs ist bei MS entstanden, die waren aber auch in den entsp. Gremien vertreten. usbser.sys ist seit ewigen Zeiten auch bei Win dabei. Bis W10 haben sie es aber nicht geschafft das Ding als Classdriver zu implementieren. Gemacht haben die es vermutlich nur, weil es inzwischen ziemlich unmöglich ist custom inf Dateien zu verwenden. Usbaudio.sys hat anfangs auch nur mehr schlecht als Recht funktioniert. Ich stimme mit dir überein dass die Anwendung des TO förmlich nach einer usbmcu schreit. Sowas kann man sehr schnell bauen, das ist kein Hexenwerk. Wenn ich das brauchen würde, würde ich da vermutlich in einem CH552 implementieren,den gibt es in einem MSOP10 Gehäuse. Beides habe ich schon gemacht nur den Kombi noch nicht. Thomas
:
Bearbeitet durch User
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.