Moin, Ausgehend von diesem Thread: Beitrag "KVM-Switch ohne V" habbich mich jetzt mal ans Kicad gesetzt und ein kleines Schaltbild dieser, meiner Schnapsidee erstellt. Mitm STM32 hatte ich bisher nichts am Hut, seit 'ner guten Woche wurstel ich hier mit einem Nucleo F411 Board 'rum. Sieht aber erstmal noch garnicht schlecht aus. Jetzt koennte ich, um Spass zu haben, mir beim Zahnarzt eine Wurzelbehandlung goennen oder im Surface-Mount-Studio was entsprechendes. Ist mir aber nicht krass genug - daher haeng' ich mal mein Schaltbild zur allgemeinen Begutachtung und Benoergelung hier an, bevor ich mir einen Wolf layoute. Was mich am meisten interessieren wuerde: Faellt jemandem was auf, wo ich mir bzgl. des ISP des STM32 ins Knie geschossen hab'? Oder sonst irgendwelche wichtigen Pins vong der Geraet nicht/falsch angeschlossen? Sollte das mal als HW vor mir liegen, hab' ich vor, das mit dem ST-Link vom Nucleoboard in Betrieb zu nehmen. Ja, ich weiss: Ich mach' Schweinskram mit den USB-Leitungen. Die A und B Buchsen eines Ports werden niemals gleichzeitig bestueckt/benutzt werden. Ich moecht' nur am Anfang etwas flexibel sein. Mir sind die Tuecken von HiSpeedinterfaces bzgl. Leitungsfuehrung und Impedanzen, etc. bekannt. Der Schaltplan besteht komplett aus 7 Seiten, allerdings sind Seite 2-7 voellig identisch bis auf die Bauteilnummern. Daher hier nur 2 Seiten im pdf. Feuer frei :-) Gruss WK
Beitrag #7946693 wurde vom Autor gelöscht.
Bist du sicher, daß man den Reset Pin mit einem Kondensator belasten soll? Der Pin ist sowohl Eingang als auch Ausgang.
Moin, Nemopuk schrieb: > Bist du sicher, daß man den Reset Pin mit einem Kondensator > belasten > soll? Der Pin ist sowohl Eingang als auch Ausgang. Gute Frage. Ich bin mir nur so sicher, wie die Entwickler des Nucleoboards, von dem ich das so "geklaut" hab'. Haett' ich jetzt so ausm Bauch raus auch nicht so gemacht, aber nachdem ich gesehen hab' dass am SWD Interface wenigstens ein 22 Ohm Serienwiderstand den Entladestrom begrenzt, habbich mir gedacht: Wird wohl schon so richtig sein. https://www.st.com/resource/en/schematic_pack/mb1136-default-c03_schematic.pdf Als Ausgang werd' ich den eh nie benutzen. Das ist beim attiny13a auch schon eine ganz schlechte Idee. Gruss WK
Dergute W. schrieb: > wie die Entwickler des > Nucleoboards, von dem ich das so "geklaut" hab'. Dann wird es wohl OK sein. Ich habe eine App Note gefunden, wo auch 100nF genannt wurden. http://nic.vajn.icu/PDF/STMicro/ARM/STM32F4/STM32F4xx_Hardware_Dev.pdf
:
Bearbeitet durch User
Angehängte Dateien:
-
blink1.jpg
63 KB
Moin, Mal n kleiner Zwischenstatus, nachdem mir ein berittener Bote heute ein Packerl bestueckte PCBs aus dem Reich der Mitte zustellte. Meinen Originalschaltplan hab' ich auf die Haelfte der Ports (also von 6 auf 3) eingedampft. Die Bauteile haetten sonst nicht so recht schmerzfrei auf 100x100mm PCB einseitig gepasst. Damit gings dann ganz gut. Fuer einen KM-Switch mit 2 Eingaengen fuer Maus und Tastatur und 4 PC "Ausgaengen" brauchts dann 2 PCBs, die ich dann so sandwichartig zusammensetzen darf. Spannungen passen grob, soweit ich's gemessen hab. Was ich ja gerne als erstes bei der Inbetriebname von neuen Boards mache, ist, mit einem alten Analogmultimeter in einem kleineren Ohm-Messbereich mal den "Innenwiderstand" von Betriebsspannung nach Masse zu messen, ohne dass sonst irgendwas angeschlossen ist. Nur so, damit evtl. Kurzschluesse auffallen, bevor es zu sehr qualmt. Da konnte man dann schon schoen sehen, dass der Boostconverter von dem bisschen Messstrom in den Hiccup-Mode gegangen ist, und tapfer versucht hat, schonmal die 5V fuer die USB-Host-Ports zu erzeugen. Auf einen der µCs hab' ich schonmal ein LED-Blinkprogramm geflasht, das ging gut und blonk auf Anhieb, d.h. Taktversorgung und Bootpins scheinen auch grob zu passen. Haette erstmal schlimmer kommen koennen ;-) Zeit fuer ein kleines Paeuschen...Dem Werke bekommen weder Eyle noch Hast. Gruss WK
Harald K. schrieb: > Dergute W. schrieb: >> und blonk auf Anhieb > > Es blonk. Sehr schön ... In der Tat. Haette es nicht geblunken, waere es nicht sehr schoen gewesen. Gruss WK
Moin, So, nachdem das Dingens jetzt mangels Motivation fast 3 Monate im Eck vor sich hinoxidiert hat, hab'sch mal wieder ein bisschen dran weitergestuempert - und siehe da: USB-Device funktioniert nicht so recht, wie ich das erwartet haette. Eigenartigerweise geht der Code auf dem Nucleoboard mit meinem per Huckepacklochraster angeflanschten USB-B-Stecker immer. Auf dem KM-Switchboard dagegen nur, wenn entweder der 1.5K Pullup per Transistor zugeschaltet ist (was man ja eigentlich bei den STM32F4 nicht extra braucht), oder der USB-Host-Spannungswandler laeuft... Ursache: Da ist wohl ein Oopsie/fehlende Konfigurationsmoeglichkeit in der libopencm3, was dann zuschlaegt, wenn die USB-Versorgungsspannung VBUS nicht am PORT PA9 anliegt. Und zwar auch im USB-Devicebetrieb. Damit ich's in ein paar Monaten wiederfind': https://github.com/libopencm3/libopencm3-examples/issues/178 https://github.com/apache/nuttx/issues/8968 Gruss WK
Angehängte Dateien:
-
kmswitch1kbd.jpg
210 KB
Moin, So, das sieht doch garnicht mal so schlecht aus: Grad' konnte ich die ersten "Tastendruecke" (durch wildes rumfummeln mit einer Drahtbruecke zwischen dem langen und kurzen schwarzen Anschluss fuer die Tastaturmatrix) vom "nackigen USB-Keyboard" unten rechts im Bild via USB-Host Anschluss unten rechts an der gruenen Platine (dem KM-Switch) zum USB-Device Anschluss unten links (neben der gemalten schwarzen 1) an dem PC weitergeben. (Sie lauteten: aafjajq) Die LEDs am USB-Keyboard' steuer ich vom USB-Host aus auch schon an, nur die Info vom PC via USB-Deviceport leite ich momentan noch nicht weiter. Von der Software her bin nun USB-maessig komplett bei TinyUSB gelandet und damit hochzufrieden. Von der USB-Middleware von ST kann ich nur stark abraten (siehe Nachbarthread). Laeuft! <froi> ;-) Gruss WK
Ist das so ein Dingens was so tut, als wenn es die Maus und Tastatur wäre? Die scheitern immer kläglich, wenn ein Gerät angeschlossen wird, das zwar völlig innerhalb der USB-Spezifikation liegt, aber diese etwas umfangreicher nutzt, als es der Entwickler von der Nervkiste gedacht hat.
Guido K. schrieb: > Die scheitern immer kläglich Bei USB-KVM ist das nicht so schlimm, die können die Verbindung zu Maus/Tastatur beim Umschalten auch trennen. Richtig ärgerlich aber war das, als man noch PS/2-Mäuse verwendete - die nämlich waren nicht hotplugfähig und mussten daher vom Umschalter zwingend emuliert werden. Und da genügte schon eine Maus mit einem Scrollrad, um einen zur Verzweiflung zu treiben. Seltsamerweise waren Tastaturen hotplugfähig, und die nutzten immerhin das gleiche (oder ein sehr, sehr ähnliches) Protokoll. Aber bei eimem USB-KVM ist der Aufwand nicht nötig. Was man da nachbilden will, ist das EDID-EEPROM des angeschlossenen Monitors, damit die gerade nicht mit den Monitor verbundenen Rechner das nicht mitbekommen, denn manche Betriebssysteme (Windows) reagieren ausgesprochen ärgerlich, wenn man den Monitor abzieht und wieder dransteckt ...
Leider ist die Praxis, dass diese Umschalter versuchen möglichst intelligent zu sein. Wir kriegen das laufend ab, als Hersteller von Controllern für Tastaturen, Mäuse etc. Da wird die USB-Spezifikation frei interpretiert und mit ein paar Geräten getestet und alle anderen sollen sich dann genau so verhalten. Wir hatten da schon die irrsten Sachen, wie ein Switch der ignoriert hat, dass die LEDs einer Tastatur entweder über den SetReport gesetzt werden, oder ein extra Endpoint dafür existiert, über den dann direkt ein Report geschickt wird. An den Computer hat er die Descriptoren durchgereicht, dann aber nicht verstanden, was der Host wollte, als der ordnungsgemäß den Endpoint ansprechen wollte.
Moin, Guido K. schrieb: > Ist das so ein Dingens was so tut, als wenn es die Maus und Tastatur > wäre? Jepp. Das ist der Plan. > Die scheitern immer kläglich,... Kann ich mir gut vorstellen, wenn ich irgendwelche Spezial-Gamerz-Maeuse oder Hackerz-Tastaturen hab, mit Beleuchtung, Furz und Feuerzeug. Habbich aber nicht. Ich hab' eher den Billigshice vom Pollin, wo ich hoffe, dass der eine Chinese vom anderen 1:1 abkupfert. Harald K. schrieb: > Bei USB-KVM ist das nicht so schlimm, die können die Verbindung zu > Maus/Tastatur beim Umschalten auch trennen. Genau das ist das, was ich nicht will. Klar - koennt ich sonst natuerlich auch mit nem aufgepumpten CD4052 oder so bauen. Harald K. schrieb: > Was man da nachbilden will, ist das EDID-EEPROM des angeschlossenen > Monitors, Auch das will ich nicht. Mir reicht Maus und Tastaturumschalter. Guido K. schrieb: > Leider ist die Praxis, dass diese Umschalter versuchen möglichst > intelligent zu sein. Im Gegensatz zu den Herstellern von so Zeugs, die das machen, um die danach zu verkaufen, mache ich das hauptsaechlich aus reinem, gerontologischem Spass an der Freud'. Ich glaube, was hier viel oefter passiert, ist dass irgendwelche Kasper freitags mit Blitzideen hier auftauchen, auf der Suche nach einem Deppen, der ihnen ehrenamtlich ihren unausgegorenen Shice versucht, in ein verkaufbares Produkt zu verwandeln. Ist bei mir nicht so. Ich will nix verkaufen. Also muss auch nix mit zig unbekannten USB-Geraeten zusammenspielen. Beim TinyUSB ist so ein Beispiel dabei, fuer ein 5fach HID-Composite-Device, also Maus, Tastatur, Gamepad, etc. bla. - das habbich erstmal auf Maus und Tastatur zurueckgebaut, das reicht mir erstmal. Also fixe Descriptoren, fixe Reportlaengen, alles fix. Klar, hatte mir auch schon mal Gedanken gemacht, auf der Hostseite die Descriptoren der angeschlossenen Geraete "zu verstehen" und entsprechend durchzureichen. Aber heute nicht mehr und morgen nicht gleich. Gruss WK
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.