Hi Leute. Ich habe ein fertiges Projekt mit einem dsPIC33CH512MP505. Jetzt gab es eine Änderung in den Anforderungen, das ganze soll nun per USB an einen PC angeschlossen werden und sich dort als Touchscreen per HID anmelden. Der verbaute dsPIC33CH512MP505 hat natürlich kein USB-Interface, und nun frag ich mich wie ich das am besten anstelle. Von FTDI hab ich den FT260 gefunden, der anscheinend das kann was ich brauch: Eine bridge von USB HID auf UART/SPI/I2C, um die Touchkoordinaten zu füttern. Aber der ist nicht lieferbar. Gibts da noch andere ICs, die das können? Zumindest auf Anhieb hab ich da nix gefunden. Alternative wäre, den dspic33CH zum Teufel zu hauen und auf einen dsPIC33EP256MU806 zu wechseln, der hat ein USB-Interface integriert. Aber will man das? Bin mir nicht sicher was ich an der Stelle am sinnvollsten tun soll. Sinnvoll in Sachen Aufwand und Lieferbarkeit.
Stefan . schrieb: > Von FTDI hab ich den FT260 gefunden, der anscheinend das kann was ich > brauch: Eine bridge von USB HID auf UART/SPI/I2C, um die > Touchkoordinaten zu füttern. Aber der ist nicht lieferbar. Der wird Dir auch nichts nützen. Die Anforderung ist ja nicht einfach "USB" oder "HID", sondern eine ganz spezifische HID-KLasse. Das kann kein generischer Interface-Baustein, dafür brauchst Du zwingend einen Mikrocontroller mit eingebautem USB-Device. Es geht nicht anders. Entweder portierst Du Deinen Code auf eine andere dsPIC33-Familie wie dsPIC33EP-MU, wie du gesagt hast, oder Du nimmst einen weiteren PIC nur fürs USB - hier würde z.B. ein PIC16F1454 oder PIC16F1455 reichen. https://www.digikey.de/de/products/detail/microchip-technology/PIC16F1454T-I-SL/3879781 https://www.digikey.de/de/products/detail/microchip-technology/PIC16F1455-I-JQ/5033394 fchk
Hatte das Datenblatt nur kurz überflogen, dort schreiben sie was von anpassbaren descriptor. Aber wenn es so ist wie du sagst, geht das wohl nicht weit genug. Welche Variante würdest du wählen :) Würde ungern zwei ICs auf dem Board flashen wollen. Problem ist halt dass der andere dsPIC mit USB nicht lieferbar ist. Ich müsste dann ins STM32 Lager wechseln, und der Aufwand ist schon bisschen höher.
Gast
#7236113
Der Cypress FX2LP (CY7C68013A) kann das, dein dpPic kann den einfach über I2C mitprogrammieren. Ich habe gerne eingesetzt.
Stefan . schrieb: > Hatte das Datenblatt nur kurz überflogen, dort schreiben sie was von > anpassbaren descriptor. Aber wenn es so ist wie du sagst, geht das wohl > nicht weit genug. > > Welche Variante würdest du wählen :) > > Würde ungern zwei ICs auf dem Board flashen wollen. Problem ist halt > dass der andere dsPIC mit USB nicht lieferbar ist. Ich müsste dann ins > STM32 Lager wechseln, und der Aufwand ist schon bisschen höher. Der externe PIC16 birgt das geringste Entwicklungsrisiko und ist lieferbar. Dass Du dann zwei PICs flashen musst, ist dann die Kröte, die Du schlucken müssen wirst. STM32 sind erst recht nicht lieferbar - der Weg scheidet für Dich auch aus. TI TIVA TM4C123 sind immer noch relativ gut erhältlich. fchk
Ich dachte zB an den STM32G491KEU6. Aber das ist halt ein kompletter Ökosystemwechsel mit allen Vor und (mehr) Nachteilen. Der Kollege wäre sogar lieferbar, aber bis ich das alles auf den STM portiert habe inkl IDE, Compiler, Toolchain allgemein. Meh. Ich geb dir recht, der kleine PIC ist die angenehmere Kröte.
@udok danke für den Tip, der scheint echt overkill zu sein. Ich tendiere sehr zu der PIC16-Lösung. Was ich mich grad frage: Die fertige Schaltung mit dem dsPIC braucht unter Last gute 2A. Wenn irgendein Kasper aus irgendwelchen Gründen dort die Masse trennt und das USB-Kabel noch steckt, kanns passieren dass der Laststrom weiter über die USB-Masse fließt. Ohne Masse und 5V läuft der USB vmtl nicht, obwohl es ein differentielles Signal ist. Hab gesehen dass der über Pullups seine Geschwindigkeit mit dem Host aushandelt. Was macht man da denn praktisch gegen, um nicht die Lastströme plötzlich auf dem USB-Kabel zu finden?
Stefan . schrieb: > Ohne Masse und 5V läuft der USB vmtl nicht, obwohl es ein > differentielles Signal ist. Hab gesehen dass der über Pullups seine > Geschwindigkeit mit dem Host aushandelt. Genau. GND und VBus sind erforderlich. > Was macht man da denn praktisch gegen, um nicht die Lastströme plötzlich > auf dem USB-Kabel zu finden? Mach den PIC16 bus-powered und setze einen Isolator zwischen die beiden Prozessoren. Wenn die beiden Prozessoren über UART miteinander sprechen z.B. den da. https://www.digikey.de/de/products/detail/skyworks-solutions-inc/SI8622BB-B-ISR/7201599 Dann bist Du DAS Problem los. Man könnte auch auf der USB-Seite isolieren, aber das ist viel komplizierter. Die Schnittstelle zwischen dsPIC und PIC16 ist der ideale Ort dafür. fchk
Gast
#7236594
> kein generischer Interface-Baustein, dafür brauchst Du zwingend einen > Mikrocontroller mit eingebautem USB-Device. Es geht nicht anders. Nein, es gab auch mal externe USB Bausteine. (USBN9604) Die waren aber vor 20Jahren aktuell und sind jetzt vermutlich alle Geschichte. Also ist das einzig vernuenftig sicherlih einen groesseren moeglichst aehnlichen Controller zu nehmen der USB integeriert hat und den Produktmanagern in der Firma klar zu machen wieviel Aufwand das ist und wie "klug" ihre Entscheidung war. Olaf
Gast
#7236603
Stefan . schrieb: > Ohne Masse und 5V läuft der USB vmtl nicht, obwohl es ein > differentielles Signal ist. Hab gesehen dass der über Pullups seine > Geschwindigkeit mit dem Host aushandelt. > > Was macht man da denn praktisch gegen, um nicht die Lastströme plötzlich > auf dem USB-Kabel zu finden? Wenn du mit USB Full Speed (12-MBit) auskommst, dann gibt es dafür von TI fertige Isolatoren. Die gehen auch gut und trennen direkt den USB Bus. Oder du ignorierst das Problem. Wenn die Masse nicht mehr verbunden ist, dann sollte doch auch nicht mehr Strom fliessen, als USB liefern kann. Das ist jedenfalls mein Verständis von deinem Problem. Der FX2LP ist sehr flexibel, den gibt es auch im 56-QFN Gehäuse. WENN also dein Chip kein USB hat, dann ist der eine gute Lösung. Der FX2LP war auch einer der wenigen Chips, die immer problemlos erhältlich waren - von dem her ist er eine Überlegung wert. ABER wenn deine Datenraten < 1 Mbit sind, UND du mit RS232 auskommst, dann ist ein einfacher USB <-> RS232 Wandler Chip eine einfachere Lösung. Udo
Udo K. schrieb: > ABER wenn deine Datenraten < 1 Mbit sind, UND du mit RS232 auskommst, > dann ist ein einfacher USB <-> RS232 Wandler Chip eine einfachere > Lösung. Genau das kann er ja nicht verwenden, weil er ja Touchscreen spielen soll, also HID Digitizer oder Absolute Mouse. Dafür muss er die passenden HID-Reports schicken, und das kann keine generische USB-Brücke. fchk
Udo K. schrieb: > Wenn die Masse nicht mehr verbunden > ist, dann sollte doch auch nicht mehr Strom fliessen, als USB liefern > kann. > Das ist jedenfalls mein Verständis von deinem Problem. USB und 12V und Masse sind angeschlossen. Aus irgendeinem Grund wird die Masse unterbrochen, während das System läuft. Die Masse vom USB läuft aufs PC-Gehäuse und der Laststrom kann über das windige USB-Kabel fließen. Zumindest so lang, bis das gasförmig wird :) Ich scheu ein bisschen den Aufwand, die Register des FX2LP so lang mit Daten zu bewerfen bis ich den descriptor passend fürn Touch hab. Ich vermute, mit dem PIC16 bin ich schneller am Ziel, auch wenn ich dafür zwei µC flashen muss. Beim Isolator dachte ich an einen ISO1640, der ist immerhin als SOIC16 lieferbar.
Stefan . schrieb: > Beim Isolator dachte ich an einen ISO1640, der ist immerhin als SOIC16 > lieferbar. Du willst also beide PICs über I2C miteinander verbinden. Auch eine Möglichkeit, aber UART ist aus meiner Erfahrung einfacher - natürlich unter der Voraussetzung, dass Du am dsPIC noch einen UART frei hast. Und für UART ist der ISO1640 nicht gedacht. fchk
Meine Überlegung war, dass der I2C auf 400kHz schneller und zuverlässiger ist als ein UART ohne Takt. Noch besser wär evtl der SPI, den kann man ja bis über 1MHz betreiben. Mal sehen was es wird.
Stefan . schrieb: > Meine Überlegung war, dass der I2C auf 400kHz schneller und > zuverlässiger ist als ein UART ohne Takt. Noch besser wär evtl der SPI, > den kann man ja bis über 1MHz betreiben. Mal sehen was es wird. Die Geschwindigkeit ist nicht so kritisch. Der USB-Host wird dich defaultmäßig eh nur 100 mal pro Sekunde (maximal 1000 mal) nach neuen Werten fragen. fchk
Gast
#7237408
Stefan . schrieb: > Meine Überlegung war, dass der I2C auf 400kHz schneller und > zuverlässiger ist als ein UART ohne Takt. I2C geht SPEC-mäßig auch mit 1MBps, falls es etwas hilft.
@fchk Hast du son PIC16 mal per USB an einen Rechner gebracht? Das neue Microchip MCC ist ja ganz nett, aber anscheinend nicht für USB.
Stefan . schrieb: > @fchk > > Hast du son PIC16 mal per USB an einen Rechner gebracht? Das neue > Microchip MCC ist ja ganz nett, aber anscheinend nicht für USB. Der Microchip USB Stack ist in der MLA (Microchip Libraries for Applications) enthalten - extra Download. Alternativ: https://github.com/signal11/m-stack fchk
Danke, MLA kenn ich und spiel grad damit rum. Die Alternative kannte ich noch nicht.
Du brauchst möglicherweise die Legacy MLA für PIC16. fchk
Weitere Alternative: https://github.com/johnnydrazzi/USB-Stack fchk
Jener Moment in dem das freie github-Projekt eleganter und besser dokumentiert ist als der Stack vom Hersteller, der seine ICs verkaufen will... Merci!
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.