Hallo zusammen, ich möchte für einen STM32 erstmal vorübergehen für einen STM32f4-Discovery einen GUI programmieren. Da wir licence für Visual Studio 2015 Prof haben, möchten wir auch dabei bleiben. Um eine GUI zu gestalten empfiehlt es sich dazu der Qt plugin zu installieren. Für mich ist gut, da ich einige Projekte mit Visual Studio c++ und Qt entwickelt habe. Nun die Frage ist: Wie kann ich einen Verbindung zwischen das Board (STM32) und Visual Studio(C++) erstellen. Wie soll ich den vorgehen? Hat jemenden so was gemacht? Brauche ich Extra einen Library "mindesten für die USB Kommunikation"? Danke in voraus
Roman schrieb: > Nun die Frage ist: Wie kann ich einen Verbindung zwischen das Board > (STM32) und Visual Studio(C++) erstellen. USB bietet sich an, einfacher ist eine serielle Verbindung (USART) mit einem USB-Seriell-Wandler. FT232 ist der DeFacto-Standard dafür. Alternativ gehen natürlich SPI und I2C auch, wenngleich die dafür benötigten Wandler exclusiver sein dürften. Roman schrieb: > Wie soll ich den vorgehen? Einen Unternehmen beauftragen, der sich damit auskennt... Roman schrieb: > Hat jemenden so was gemacht? Viele hundert Leute, würde ich so mal spontan behaupten. Nur bei uns in der Firma sind es fast ein Dutzend. Roman schrieb: > Brauche ich Extra einen Library "mindesten für die USB Kommunikation"? Schadet nicht. Auch nicht, mit der grundsätzlichen Funktionsweise von USB zu beschäftigen. Tipp: nimm USART, damit kommst du mit etwas Glück sogar bis zum Ziel...
Was ich gerne machen möchte, ist die die Steuerung einen STM32 mittels einen GUI. Dieses GUI wird in Visual Studio 2015 c++ und Qt5 Plugin implementiert. z.B: Der STM32-Board wird an dem PC mit USB verbunden und mittels einen GUI kann ich einschalten ausschalten und .....
Roman schrieb: > Der STM32-Board wird an dem PC mit USB verbunden und mittels einen GUI > kann ich einschalten ausschalten und ..... Für den µC ist es eigentlich herzlich egal, was da auf welchem PC unter welchem OS läuft. Ob mit GUI oder ohne. Das Einzige, was nicht egal ist, das ist ein sauber ausgedachtes und ebenso sauber implementiertes Protokoll auf der Verbindungsstrippe zwischen dem µC und dem PC. W.S.
@W.S Mir is schon klar, dass es einen Protokoll für die Kommunikation (PC-->µC) geben muss.Diese protokoll muss von der beiden Kommunkationsteilnehmer verständlich sprich eine saubere Implementieren bei der µC bzw. bei der PC(hier in dem Fall C++(Visual Studio)). Für die Kommunikation zwischen PC und µC brauche ich bestimmte extra Bibliotheken für die USB. Hast du bitte sowas in der Art schon gemacht? Danke
Roman schrieb: > Für die Kommunikation zwischen PC und µC brauche ich bestimmte extra > Bibliotheken für die USB. > > Hast du bitte sowas in der Art schon gemacht? => Louis schrieb: > Tipp: nimm USART, damit kommst du mit etwas Glück sogar bis zum Ziel... Bei einer UART Kommunikation brauchst du keine Bibliotheken auf dem PC (ist schon seit Jahrzehnten ein Standard). Du kannst auf beiden Seiten mit Kommados arbeiten. Protokolle gibt es etwa so viele wie umgesetzte Projekte. Kannst ja bei Modbus reinsehen und das als Anhaltspunkt nehmen. Pseudo mässig könnte das so aussehen (PC ist Master): Kommando Schreiben | Was/Wo | Wieviel | Daten | Check Summe Antwort Schreiben OK | Check Summe Kommando Lesen | Was/Wo | Wieviel | Check Summe Antwort Lesen | Wieviel | Daten | Check Summe Kommando Lesen OK | Check Summe Antwort Lesen OK | Check Summe Auf beiden Seiten müssen halt entsprechende State-Machines umgesetzt werden. Das kann man natürlich beliebig vereinfache/erweitern. Die Frage ist wozu brauchst du das und in welchem Umfeld läuft es (muss es störsicher sein, was passiert bei fehlerhaften Daten...).
Es gibt schon ein fertiges Protokoll und auch eine fertige Software: Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle"
Louis schrieb: > USB bietet sich an, einfacher ist eine serielle Verbindung (USART) mit > einem USB-Seriell-Wandler. FT232 ist der DeFacto-Standard dafür. Oder du schaust dir mal Beispiele für einen Virtual COM Port an. https://stm32f4-discovery.net/2014/08/library-24-virtual-com-port-vcp-stm32f4xx/ Dann hast du die Einfachheit von UART/COM Port und benötigst keine weiteren Komponenten für dein Discovery Board. Ich glaube es gibt sogar ein Beispiel direkt von ST.
Roman schrieb: > Hast du bitte sowas in der Art schon gemacht? Ja. Mit Protokoll meine ich NICHT, wie das Betriebssystem deinen Chip bedient, sondern wie sich dein PC-Programm mit dem µC verständigt. Über welchen Kanal, ist dabei erstmal nebensächlich, aber ich würde allzeit ein gewöhnliches serielles Interface nehmen, entweder direkt oder als USB-VCP. Wie darauf das Protokoll aussieht, ist dein Gusto. Hier nur mal 2 Vorschläge: a) gewöhnliche Kommandos: Der µC empfängt Zeichen vom PC, echot sie zurück und sammelt sie in einer Kommandozeile. Wenn dann ein Zeilenende kommt (CRLF), wertet er die Kommandozeile aus und macht, was dort drinsteht. Beispiel: D 100 1FF soll bedeuten Zeige Speicherbereich 100h bis 1FFh an. b) UPN-Elementartext: der µC empfängt vom PC Zeichen, echot sie NICHT und wertet sie sofort aus. Ziffern ergeben Zahlen (alles NUR dezimal) und Buchstaben ergeben Kommandos. Bei allem anderen wird nach deinem Gusto verfahren Der µC hat einen Akku, wo Zahlen auflaufen, sobald eine neue Ziffer hereinkommt. Sobald ein Buchstabe hereinkommt, wird das zugehörige Kommando ausgeführt. Falls dieses einen Parameter braucht, hat er diesen in Form der aufgelaufenen Zahl. Der Parameter kommt also vor dem Kommando. Beispiel: 256A1023ED bedeutet Setze Anfang auf 256, Setze Ende auf 1023, Zeige Speicher an von A bis B. Der Rückkanal, also vom µC zum PC ist damit frei verfügbar. Variante a) ist besser verständlich für Menschen, Variante b) braucht weniger Traffic und arbeitet nur mit atomaren Kommandos, ist also für Maschine zu Maschine eher besser geeignet. Natürlich kann man sich noch unendlich viele andere Protokolle ausdenken, aber wenigstens einigermaßen durchdacht sollten sie sein. Dazu gehört auch, daß sowas erweiterbar ist, ohne inkompatibel zum Bisherigen zu sein. Ich hatte da vor Jahren das klassische Gegenbeispiel beim NWT vom Funkamateur: Der Autor des zugehöigen PC-Programmes und der Firmware für den PIC (A.Lindenau) hatte zur Kommunikation sich feste Blöcke von Zeichen ausgedacht - für jedes Kommando einen Block, aber bei jedem Kommando von unterschiedlicher Länge und unterschiedlicher Belegung der einzelnen Bytes. Ein klassischer Schuß ins eigene Knie. Mach du sowas lieber NIE. W.S.
Hi W.S, Ich bin auch an der gleichen Problem was der Roman hat. ehrlich gesagt kann ich dich nicht folgen. Es wäre super nett, wenn du anhand einen funktionierende Beispiel erklärt. Danke
Bei STM32F1 geht das so: http://stefanfrings.de/stm32/index.html#usb Bei STM32F4 ist es sicher sehr ähnlich.
Andreas schrieb: > ehrlich gesagt kann ich dich nicht folgen. > Es wäre super nett, wenn du anhand einen funktionierende Beispiel > erklärt. Das was W.S. meint ist, das du die Kommunikation am einfachsten über eine serielle Schnittstelle abwickelst. Ob das nun ein einfacher UART oder USB-VCP ist, ist erstmal egal. Zwischen dem PC und dem Mikrocontroller hast du dann ein Protokoll, was beide Programme "verstehen". Der PC sendet zum uC eine bestimmte Zeichenfolge von ganz normalem Text und der uC reagiert darauf in einer bestimmten Art und Weise. Andersherum reagiert der PC (egal ob mit oder ohne GUI) auf eine bestimmte Art und Weise auf eine Zeichenfolge des uC. Sowohl PC-Programm als auch die Firmware des uC betreiben einfache Textverarbeitung, d.h. sie extrahieren aus dem empfangenen Text die Information die der Sender übermittelt hat bzw. verpacken die Information die sie übermitteln wollen als einfachen Text. Ein Beispiel für ein solches Protokoll ist G-Code, wie er z.B. bei CNC-Fräsen oder 3D-Druckern eingesetzt wird. Bei den meisten 3D-Drucker-Firmwares kann man z.B. mit
1 | M104 S190 |
dem Drucker sagen, das er die Temperatur des Extruders auf 190°C setzen soll. Bei einer CNC-Fräse wiederum kann man zumeist mit
1 | M03 S1500 |
dafür sorgen, dass die Frässpindel im Uhrzeigersinn mit 1500 U/min dreht oder diese mit
1 | M05 |
anhalten. Will man auf der anderen Seite die Temperatur des Extruders eines Druckers wissen, dann schickt man an den Drucker ein
1 | M105 |
worauf dieser mit so etwas wie
1 | ok T:182 B:42 |
antwortet, was z.B. bedeutet, dass die Extrudertemperatur 182°C beträgt und die Temperatur des Druckbetts 42°C. Ein PC-Programm, welches die Extrudertemperatur über der Zeit als Graph darstellen soll schickt dann kontinuierlich (in gewünschten Zeitabständen) ein "M105" über die serielle Schnittstelle an den Drucker, extrahiert die Information, also die Extrudertemperatur, aus dem Antworttext den der Drucker zurückschickt und zeigt die Daten auf irgendeine Weise als Diagramm auf dem Bildschirm an.
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.