Hallo Leser, beim immerwährenden Basteln an kleinen oder großen Werkzeugmaschinen bin ich (beim Projekt Ofensteuerung) zu dem Schluss gekommen, dass die Ausgestaltung des Mensch-Maschine-Interfaces (auch Benutzerschnittstelle oder HMI = Human Machine Interface im Fachenglisch) die größte Arbeit macht. Das Steuern der Maschinenseite (hier: Keramik-Brennofen, Fräsmaschine, Innenloch-Kreissäge, Drahtsäge, Waschmaschine für Wafer, VR-Simulator für Hammereinschläge usw.) ist vergleichsweise einfach. Mein Mikrocontroller-Favorit ist derzeit ATmega32U4 oder, für mehr Rechenleistung, STM32F103 oder STM32F407. Dabei implementierte ich stets ein USB-Device mit WebUSB-Interface (= treiberloser Zugang für PCs UND Smartphones) sowie eine passende Webseite („Äpp“) auf dem Webserver der TU Chemnitz. Die Maschine benötigt eine hohe elektrische Leistung, daher ist das USB-Device in der Regel „self-powered“ und benötigt VBUS allenfalls zur Präsenzerkennung und zur Speisung des chip-internen Pullup-Widerstandes an D+. Die Äpp benutzt ausgiebig JavaScript und stellt Prozessparameter (bspw. Temperatur) als große, von Ferne ablesbare Zahlen sowie grafisch in einem Zeitdiagramm dar, ermöglicht alle Einstellungen und Programmierungen. Keine Webhostkommunikation (= läuft vom Cache) und keine Cookies. Maschinen-Einstellungen und Prozessabläufe werden im EEPROM oder Flash des Mikrocontrollers gespeichert, nicht im Local Storage der Äpp. Nur bei der Fräsmaschine kommt der G-Code von einer Datei hereingestreamt. Um das so nervige Problem von GRBL und der allfälligen Synchronisation kümmert sich USB von selbst: Der Verzicht auf altmodische Schnittstellen macht's möglich. In vielen Fällen benötigt man ohne diese HMI allenfalls einen Startknopf. Dann geht der Ofen, die Waschmaschine oder die Drahtsäge einfach das zuletzt abgearbeitete Programm noch einmal durch. Bei Maschinen, die einen feinfühligen Jog-Modus benötigen, hängt am Mikrocontroller noch ein Inkrementalgeber sowie ggf. weitere analoge, quasianaloge oder digitale Eingabegeräte, bspw. ein Fußpedal. So weit, so gut, das funktioniert alles prima seit Jahren. Ein Renner, der Schule machen sollte. Derzeit mit jeweils einem dazu abgestellten Windows-PC. Beim Betrieb mit Smartphone stellt sich — abgesehen von der Bildschirmgröße und der notwendigen Umgestaltung der einen oder anderen Äpp — das Problem, dass man jenes auch aufladen können muss. Die gängige Lösung für Kommunikation UND Laden ist die Verwendung eines PCs. Das beißt sich allerdings mit WebUSB und Device-Only-USB-Geräten. Und dafür OTG implementieren erscheint mir zu aufwändig, falls das überhaupt funktioniert. Die Rettung naht: USB-C! (Leider nicht für Uralt-Smartphones.) So wie ich herausgefunden habe, ist bei USB-C die Host-Device-Richtung von der Stromversorgungsrichtung entkoppelbar. Dazu muss das Smartphone als auch das USB-Device eine USB-C-Buchse haben und ein einigermaßen vollbeschaltetes USB-C-C-Kabel verwendet werden. Im Standardfall: USB-Device = Strom-Konsument muss CC1 und CC2 je mit einem Widerstand 5,1 kOhm nach GND beschaltet sein. Im Sonderfall: USB-Device = Strom-Lieferant muss CC1 mit einem lieferstromabhängigen Widerstand (im Bereich 10 kOhm) gegen VBUS beschaltet sein, um die Strom-Lieferfähigkeit mitsamt Stromstärke anzuzeigen. Mir genügen hierbei 5 V; Spannungsumschaltung ist nicht vorgesehen. CC2 ist entweder frei zu lassen oder — wenn vorhanden — mit Plus eines LiIon-Akkus direkt zu verbinden. Ist das so richtig? Muss das USB-Device als Strom-Lieferant einen Schalter implementieren, der VBUS speist? Und wenn ja, wann ist dieser einzuschalten? Müssen Spannungspegel an CC1 und CC2 bspw. per A/D-Wandler gemessen werden? Wie geht ein Smartphone vor, um das Laden zu aktivieren? Wäre das alles gelöst kann ein altes Smartphone an der Maschine verbleiben und seine Nutzungsperiode vor dem fälligen Recycling verlängern. Und es ist im Fehlerfall kinderleicht tauschbar, im Vergleich zu HMIs wie man sie von sonstigen Werkzeugmaschinen kennt. Interessanterweise gibt es von der USB-C-Buchse eine 12-polige Version zu kaufen, die alle notwendigen Kontakte dafür herausführt und mit Lötkolben lötbar ist: Einreihige, nach Bestückung sichtbare und damit revisionierbare SMD-Kontakte. Diese reicht für alles außer USB jenseits 480 MBit/s. Also für alle Bastelprojekte dieser Art. Jaja, 0,5 mm Pitch ist schon arg eng, da kann man vom ATmega32U4 auch die QFN-Version nehmen: Hat den gleichen Pitch – aber ist nicht revisionierbar: Keine Stummelbeinchen und das olle PowerPad. Jaja, viel Text. Bitte vor dem Kommentieren genau durchlesen.
:
Verschoben durch Moderator
Also dein Smartphone kann an einen PC und wird gleichzeitig geladen und darf über USB reden. Nur ist der PC der Host/Master. Wenn nun deine eigene Elektronik das Smartphone als Bedienfeld inkl. Dauerladung nutzen will muss es doch nichts anderes als der PC machen. Geht es dir darum, dass eine USB Host Implementation dir zu komplex ist ?
Michael B. schrieb: > Geht es dir darum, dass eine USB Host Implementation dir zu komplex ist Unwahrscheinlich, die bringt das Smartphone schon ab Werk mit. Henrik geht es, so wie ich seinen Text verstanden habe, nur darum, als Host zu arbeiten, aber von außen mit Spannung versorgt zu werden. Das ist mit einem "USB-Dock" lösbar. So etwas ist ein USB-Hub, meist angereichert mit zusätzlichen Dingen (Kartenleser, HDMI-Ausgang, Audio, Netzwerk), und --und das ist das entscheidende-- einem Stromversorgungsanschluss. Nicht jedes "USB-Dock" hat sowas, darauf muss man bei der Auswahl also achten. So ein Ding zwischen das Smartphone und die eigenen USB-Geräte gesetzt, ein (USB-) Netzteil dran angeschlossen, und der Drops sollte fein säuberlich ausgewickelt, gelutscht und genossen sein. Ein ziemlich willkürlich ausgesuchtes Beispiel: https://www.amazon.de/dp/B0BLNDNBG1 Das löst immerhin auch das Problem, das Henrik mit dem Verarbeiten der USB-C-Buchse beschreibt - das kann man sich dann sparen und weiterhin lötfreundlichere USB-A-Steckverbinder nutzen. Funktional ist dieses "Dock" natürlich leichter Overkill, aber wirklich teuer ist es auch nicht, und mit etwas Suche sollten sich auch andere, günstigere Varianten auftreiben lassen. Wenn man zum Selbstbau schreiten will, ist der Dreh- und Angelpunkt vermutlich ein USB-PD-fähiger USB-Hub. Eventuell aber ist auch ein komplett anderer Ansatz möglich, wenn ein µC verwendet wird, der selbst mit USB-PD umgehen kann. Ich hab' das allerdings (noch) nicht im Detail betrachtet, was damit tatsächlich alles möglich ist. Es gibt aber solche µCs inklusive Testplatinen für recht wenig Geld, und auch ein paar Projekte, die damit etwas anstellen: https://www.wch-ic.com/products/CH32X035.html https://github.com/WeActStudio/WeActStudio.CH32X035CoreBoard https://www.aliexpress.com/item/1005006909948695.html https://github.com/wagiminator/CH32X035-USB-PD-Tester https://github.com/wagiminator/CH32X035-USB-PD-Adapter (Ja, diese beiden Projekte machen natürlich was anderes, aber daraus lässt sich möglicherweise interessantes ableiten) Persönliche Anmerkung an Henrik: Ich verfolge Deine Basteleien schon seit etlichen Jahren und betrachte die als sehr erfreuliche Bereicherung. Weiter so!
Wenn da also doch immer ein PC dabei sein muss: Kann der dann nicht gleich die Steuerung übernehmen und das Handy wird hinfällig?
.● Des|ntegrator ●. schrieb: > Wenn da also doch immer ein PC dabei sein muss: > Kann der dann nicht gleich die Steuerung übernehmen > und das Handy wird hinfällig? Mit welcher Presse willst du den PC auf den Formfaktor eines Smartphones bringen so dass gleichzeitig das draufgelegte Display heile bleibt ?
Die neueren ESP32 sind auch USB Host, die älteren können das per SW.
Hardwareseitig ist das nicht so das Problem, aber der Ladevorgang muss vom Kernel auch unterstützt werden. Das läuft dann evtl. auf einen Custom Kernel hinaus, sprich jegliche Integrität geht verloren.
Henrik H. schrieb: > beim immerwährenden Basteln an kleinen oder großen Werkzeugmaschinen bin > ich (beim Projekt Ofensteuerung) zu dem Schluss gekommen, dass die > Ausgestaltung des Mensch-Maschine-Interfaces (auch Benutzerschnittstelle > oder HMI = Human Machine Interface im Fachenglisch) die größte Arbeit > macht. Gratulation, du hast eine mindestens 40 Jahre alte Erkenntnis wieder entdeckt. Als man noch von Benutzerschnittstelle oder User-Interface und nicht in Hipster-Sprech von User-Experience (UX) sprach. > Mein Mikrocontroller-Favorit ist derzeit ATmega32U4 oder, für mehr > Rechenleistung, STM32F103 oder STM32F407. Ok. Aber dann: > Dabei implementierte ich stets > ein USB-Device mit WebUSB-Interface (= treiberloser Zugang für PCs UND > Smartphones) ... > Derzeit mit jeweils einem dazu abgestellten > Windows-PC. Soll also heißen deine Lösung verlangt das du neben dem Mikrocontroller immer einen PC mit laufen hast. Eine Folge dessen dass du dich in eine Technologie (WebUSB) verliebt hast, die eher ein Nischenprodukt ist. Nun ja ... Man könnte auf die Idee kommen einfach einen Embedded PC zu nehmen um die Maschine zu steuern, statt zusätzlich Mikrocontroller mit rein zu werfen. > Die Rettung naht: USB-C! Sagen wir so, die "Rettung" für ein selbstgemachtes Problem. > Ist das so richtig? Also ich habe jetzt keine Lust mich durch die Feinheiten der USB-Spezifikationen zu arbeiten. Denn da musst du im Detail rein sehe. Grob überfliegen und aus dem Web was zusammen zu googlen wird nicht reichen. Da du an der UNI aber unendlich viel Zeit hast würde ich vorschlagen du machst folgendes: Schritt 1: Mit einem feinen Kamm durch die USB-Spezifikationen gehen Schritt 2: Eine "Theorie" formulieren und dokumentieren (Schaltplan, nicht wilde Prosa) wie das funktionieren soll Schritt 3: Hoffen dass beliebige Handy-Hersteller und die Hersteller von in Handys verwendeten Lade-ICs die USB-Spezifikationen ebenfalls genau durchgegangen sind und sich daran halten. Schritt 4: Probeaufbau im Labor und Evaluation der Theorie
Hannes J. schrieb: > Soll also heißen deine Lösung verlangt das du neben dem Mikrocontroller > immer einen PC mit laufen hast. Ich habe Henrik so verstanden, daß webusb auch mit Smartphones funktioniert, und sein Problem nur aus dem Betrieb des Smartphones mit angeschlossenem USB-Device und gleichzeitiger Stromversorgung besteht. Den Rest hat er vielleicht einfach etwas zu wortreich formuliert.
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.