Hallo zusammen ! Ich bin gerade bei der Entwicklung einer Remote Control Einheit für ein Mainframe mit diversen Relaiskarten (Pro Audio). Die Steuerung soll mittels STM32 / C-Programmierung erfolgen. Auf der Softwareseite bin ich da schon ganz gut unterwegs. Nun möchte ich aber gerne die Anbindung der Remote an den Mainframe mit einem "einfachen" Ethernetkabel realisieren. Aufbau wäre: ******** Remoteunit mit STM32MCU (vermutlich F407VG) mit 54 beleuchteten LED-Tastern. Die Taster werden entweder über PISO-Shift Register über SPI abgefragt oder per Matrix. Die LEDs in den Tastern werden über SIPO Shift Register angesteuert. -> Ethernetkabel -> -> Mainframe mit weiterer STM32 MCU, die über (SIPO) Power-Shift-Register Relais schaltet, deren "Zustände" denen der LEDs an der Remote entsprechen. Könnte natürlich ggfs. auch ein einfacher AVR sein, allerdings habe ich mich jetzt in STM32 schon ganz gut eingearbeitet... ******** Die Grundaufgabenstellung ist also, aus den Schaltzuständen (Stand jetzt über struct Bitfields programmiert) einfache Null/Eins - Bits vom einen STM32 zum anderen zu bringen. Nun habe ich bisher leider noch Null Erfahrung und nur ein bisschen angelesenes Internetwissen zu der ganzen Ethernet-Geschichte. Soweit ich verstanden habe, bräuchte ich aber rein hardwareseitig eine Art PHY mit ein paar "Peripherieteilen" wie Übertrager und Ferrite etc. auf beiden Seiten. Gibt es da zum Experimentieren ein empfehlenswertes All-In-One Controllerboard, das aus den SPI Bit-Ketten auf der einen Seite ein Ethernet-Datenpaket schnürt und auf der anderen Seite das Ganze rückwärts ? Und wie aufwendig ist das Ganze auf der Programmierseite ? Mir ist bewusst, dass gerade der STM32F407 ja schon Ethernet an Bord hat....aber es wäre zum Ausprobieren wie schon angedeutet praktisch, wenn ich nicht die Schnittstelle aus Einzelteilen aufbauen müsste, sondern einfach eine Art integrierten SPI/Ethernet-Konverter hätte... Wäre das hier z.B. was ? https://www.amazon.de/USR-ES1-W5500-Ethernet-Converter-Modul/dp/B07J9PQ34B oder das hier: https://www.reichelt.de/pmod-nic100-netzwerk-schnittstellen-controller-digil-410-208-p243338.html?&nbc=1 Grundsätzlich wäre für den Transfer auch eine Lösung mit RS232/RS485 o.ä. denkbar - sind ja nur einfachste Schaltvorgänge....allerdings würde die Ethernet-Variante die Flexibilität mit sich bringen, ggfs. statt der Hardware-Remote mittelfristig auch andere Steuerungsvarianten (z.B. per Tablet GUI über LAN oder andere Steuersoftware auf Mac oder PC) zu ermöglichen.... Freue mich über Hilfe und Anregungen ! LG
:
Bearbeitet durch User
Uli A. schrieb: > Ich bin gerade bei der Entwicklung einer Remote Control Einheit für ein > Mainframe mit diversen Relaiskarten Etwas customising sollte bei den für Mainframe üblichen Preisen von dem Hersteller doch wohl drin sein. Dam uss man nicht selbst waas dran Rumfrikeln. https://en.wikipedia.org/wiki/Mainframe_computer Versuch vielleicht mal mit ein paar weniger Sätzen und den Richtigen Begriffen zu erzählen was du nun überhaupt machen willst...
Angehängte Dateien:
-
W5500_-_Aufbau.jpg
280 KB
Uli A. schrieb: > Freue mich über Hilfe und Anregungen ! Bin mal schnell drauf eingestiegen da ich gerade selbst mit dem W5500 Modul spiele. Es hat den Charme dass man nur wenig Software braucht um über Ethernet/TCP zu kommunizieren. Es ist nicht ultraschnell da die Daten über SPI geschaufelt werden. Dafür kann man einen fast beliebigen Controller seiner Wahl einsetzen, nur SPI muss er können. Die STM32F4xx haben meist schon den Ethernet-Controller eingebaut, aber einen externen PHY muss man immer noch selbst dazubauen. Dazu kommt noch ein LWIP Stack den man auch erst mal einigermassen verstehen muss. So richtig geschenkt bekommt man in beden Fällen nichts. Zum NIC100 weiss ich nichts zu sagen. Vielleicht (noch?) nicht sehr bekannt und verbreitet.
Fuer ein bisschen Bitgeklapper einen ARM M4. Ich bin bei ST bislang regelmaessig mit dem STM32F107 schon gut zurechtgekommen.
AlterSack schrieb: > Ich bin bei ST bislang regelmaessig mit dem STM32F107 schon > gut zurechtgekommen. Klar, ein AVR reicht für's Bitklappern wohl auch.
Wär das evtl. was um dem STM32 Ethernet beizubiegen? https://www.ebay.de/itm/1PCS-LAN8720-Ethernet-Module-Network-Transceiver-Embedded-Web-Server-RMII-PHY/163847001207?hash=item26260ad477:g:oX8AAOSwM0Rdb23Z
Irgend W. schrieb: > Uli A. schrieb: >> Ich bin gerade bei der Entwicklung einer Remote Control Einheit für ein >> Mainframe mit diversen Relaiskarten > > Etwas customising sollte bei den für Mainframe üblichen Preisen von dem > Hersteller doch wohl drin sein. Dam uss man nicht selbst waas dran > Rumfrikeln. > > https://en.wikipedia.org/wiki/Mainframe_computer > > Versuch vielleicht mal mit ein paar weniger Sätzen und den Richtigen > Begriffen zu erzählen was du nun überhaupt machen willst... Ok. Das war anscheinend nicht ganz eindeutig, wenn man Mainframe auch wie die Teile in Deinem Link deuten kann - worauf ich als "nicht hauptberuflicher" Computer nicht gekommen wäre....zur Erklärung: Der "Mainframe" ist nicht von einem Hersteller sondern auch von mir gebaut und ist kein riesiger Computerschrank sondern ein 6HE- Baugruppenträger im 19 Zoll Format. Ich dachte davon abgesehen eigentlich, mich recht klar ausgedrückt zu haben...
Harry L. schrieb: > Wär das evtl. was um dem STM32 Ethernet beizubiegen? > > https://www.ebay.de/itm/1PCS-LAN8720-Ethernet-Module-Network-Transceiver-Embedded-Web-Server-RMII-PHY/163847001207?hash=item26260ad477:g:oX8AAOSwM0Rdb23Z Wenn ich das recht verstehe, wäre das das Richtige für eine Lösung zur Nutzung der Onboard Ethernet Peripherie des STMF407 oder ? Mein Eindruck ist allerdings, dass die W5500-Variante in meinem Fall praktischer zu sein scheint - immerhin habe ich ja die zu versendenden Daten quasi schon "im SPI Format" vorliegen, weil damit ja auch die Ausgabeschieberegister in der Remote für die LEDs gefüttert werden...
Net Worker schrieb: > > Bin mal schnell drauf eingestiegen da ich gerade selbst mit dem > W5500 Modul spiele. Es hat den Charme dass man nur wenig Software > braucht um über Ethernet/TCP zu kommunizieren. Es ist nicht > ultraschnell da die Daten über SPI geschaufelt werden. Dafür kann > man einen fast beliebigen Controller seiner Wahl einsetzen, nur > SPI muss er können. Das wäre ja natürlich hier der Fall... Hast Du denn das W5500 Modul auch an beiden Enden verwendet, so wie ich das ggfs. vorhabe ? Also mit µC + W5500 an beiden Enden der Ethernetstrecke ? Und wenn ja, wie kann ich mir das bezüglich des eigentlichen Datentransfers vorstellen ? Kommt da dann einfach beim SPI am anderen Ende "verlustfrei" das raus, was man beim "Sender" reinschickt ? Ohne sonstige Konfiguration ? Oder muss ich da noch in den SPI Datenstrom noch was mit reinschreiben ? Oder den Controller des W5500-Boards noch irgendwie programmieren / konfigurieren ? Wo könnte ich darüber gute Infos finden ? (außer hier natürlich ! ;-))
Uli A. schrieb: > - worauf ich als "nicht > hauptberuflicher" Computer nicht gekommen wäre....zur Erklärung: Ich meinte natürlich: als "nicht hauptberuflicher" Computer-Interessierter... ;-)
Uli A. schrieb: > allerdings würde > die Ethernet-Variante die Flexibilität mit sich bringen, ggfs. statt der > Hardware-Remote mittelfristig auch andere Steuerungsvarianten (z.B. per > Tablet GUI über LAN oder andere Steuersoftware auf Mac oder PC) zu > ermöglichen Du solltest hier ansetzen und die Äpfel von den Himbeeren trennen. Für eine Fernanbindung brauchst du kein Ethernet. Unsere Urgroßvorfahren haben Kraftwerke per Modem supported. ;-) Du meinst sicherlich Netzwerkkommunikation. Da geht es um IP und Co. Du musst in deinem System einen Server vorsehen. Der Server kümmert sich um die Konvertierung und kann auch auf verschiedene Hardware umsetzten, z. B. auch CAN, RS485, ..., oder parallele Backplane. ;-)
MaWin schrieb: > Für eine Fernanbindung brauchst du kein Ethernet. Unsere Urgroßvorfahren > haben Kraftwerke per Modem supported. ;-) > > Du meinst sicherlich Netzwerkkommunikation. Da geht es um IP und Co. Du > musst in deinem System einen Server vorsehen. Der Server kümmert sich um > die Konvertierung und kann auch auf verschiedene Hardware umsetzten, z. > B. auch CAN, RS485, ..., oder parallele Backplane. ;-) Danke für den Beitrag. Genau die Unterscheidung dieser beiden Fälle a) schlichte Übertragung der Steuerdaten über welches serielle Schnittstellen-/Protokollformat auch immer = autarkes System bestehend aus Remote und zu steuerndem Gerät (->Kraftwerk per Modem) b) Erweiterung auf andere, die in a) genannte, autarke Remote ersetzende Systeme zur Steuerung der Schaltzustände = per Netzwerk hatte ich doch schon in den Raum geworfen.... Deine begriffliche Abgrenzung bzgl. Netzwerk und Ethernet verstehe ich noch nicht so ganz...Ethernet ist doch ne Teilmenge von Netzwerkkommunikation, oder ? Davon abgesehen....brauche ich tatsächlich für solche simplen Übertragungen schon einen Server ??? Also, wenn ich dieselben Pakete an den Mainframe schicken möchte, die der dortige W5500 in SPI umwandeln soll (wenn das dann so sein sollte, was hier noch nicht zweifelsfrei beantwortet wurde), dies aber von einem Computer oder einem Tablet am (Ethernet-)Netzwerk tue statt von der Remote....dann kann ich das nicht einfach machen, indem ich diese Pakete eben von dort aus losschicke ? Sorry für die Laienfragen...
:
Bearbeitet durch User
Uli A. schrieb: > Kommt da dann einfach beim SPI am anderen > Ende "verlustfrei" das raus, was man beim "Sender" reinschickt ? Ohne > sonstige Konfiguration ? > > Oder muss ich da noch in den SPI Datenstrom noch was mit reinschreiben ? > Oder den Controller des W5500-Boards noch irgendwie programmieren / > konfigurieren ? Eher das Letztere. Um die Konfiguration eines solch universellen und vergleichsweise komfortablen Chips kommt man dann doch nicht herum. Grob gesprochen setzt man alle Netzwerk-Parameter, baut einen Socket auf, setzt damit das gewünschte Protokoll (TCP, UDP und andere) und öffnet eine Verbindung als Client oder Server. Daneben kann man sich per Software-Erweiterung noch eine IP- Adresse automatisch von einem anzugebenden Server beziehen (DHCP). Steht die Verbindung, kann man über "send" und "receive" (das sind standard Socket Funktionen aus der Library) nackte Datenpakete zuverlässig senden und emfangen. Insgesamt eine Implementierung die bis jetzt für meine Begriffe die am wenigsten Aufwand für ein Netzwerk bedeuted. Selbst in einem AVR Mega328p mit 32K Flash und 2K (!) RAM kann man noch eine Netzwerk-Gerätesteuerung implementieren. Was man ohne Zusatz- Aufwand geschenkt bekommt ist ARP im Hintergrund und auto- matisches Antworten auf Ping Anforderungen, damit ist auch die direkte Kommunikation zwischen zwei W5500 Modulen ohne Netzwerk-Server möglich. Der Charme des W5500 ist also dass das vollständige Ethernet- Protokoll und allermeiste IP-Protokoll im Chip abläuft und damit dem Controller den Aufwand (der üblicherweise im Hinter- gund läuft) abnimmt.
Uli A. schrieb: > Mainframe mit weiterer STM32 MCU Was soll das denn bedeuten? Unter Mainframe verstehe ich Server mit der Leistung von 100 PC's. Ich habe massive Problem, aus deinen wirren Texten zu extrahieren, was du eigentlich machen willst. Solange du keine Ahnung hast, wie Ethernet und das IP Protokoll funktionieren würde ich an deiner Stelle die Finger davon lassen. Das ist nämlich alles andere als simpel - insbesondere wenn du nicht den simplen Weg über einen Ethernet-zu-UART Adapter gehst. Muss es unbedingt mit Kabel sein? Es gibt extrem preisgünstige WLAN-zu-UART Adapter, zum Beispiel das ESP-01 Modul.
Uli A. schrieb: > Mein Eindruck ist allerdings, dass die W5500-Variante in meinem Fall > praktischer zu sein scheint - immerhin habe ich ja die zu versendenden > Daten quasi schon "im SPI Format" vorliegen Der W5500 kann nicht einfach beliebige SPI Datenströme über Ethernet weiter leiten. Seine Schnittstelle zum steuernden Mikrocontroller ist SPI, aber da laufen Befehle und Daten in einem ganz bestimmten Format herüber, dass der Wiznet Chip festlegt. Das Gleiche hast du prinzipiell auch beim ESP-01 Modul, nur dass dieses halt WLAN und UART nutzt.
Uli A. schrieb: > Davon abgesehen....brauche ich tatsächlich für solche simplen > Übertragungen schon einen Server ??? In der Regel schon. Denke an diverse Internet-Dienste die du nutzt. Auf deinem PC/Smartphone benutzt du überlicherweise eine Client Anwendung, die sich mit einem Server verbindet. Der Server bedient die Anfragen des Clients. Der Server muss daher immer ansprechbar sein. Wenn ein Client etwas zu einem Server sendet, und dieser gerade abwesend ist, dann läuft die Anfrage ins leere. In diesem Zusammenhang könnte für dich ein MQTT Broker interessant sein. Das ist ein zentraler Speicher (Server) für Nachrichten, die deine Mikrocontroller dort ablegen und andere von dort abholen. Wie ein Postfach. In diesem Fall sind alle beteiligten Mikrocontroller Clients und müssen eben nicht permanent ansprechbar sein. Der Broker würde dann auf einem Linux/Windows Rechner (vielleicht ein Raspberry Pi) laufen.
Ich habe vor ein paar Jahren mal mit dem W5500 in Kombination mit einem Arduino herumgespielt. Einfache UDP Pakete konnte man wunderbar verschicken. So für lokale Datentransfers zwischen 2 Rechnern reicht das. Aber sobald der in ein richtiges Netz kommt, dann fehlt die Hälfte der Protokolle, die man z.B. bei einem Linux mit geliefert bekommt. Man darf sich selbst um Namesauflösung kümmern, DNS ist wohl nicht mit dabei. DHCP lief auch irgendwie nicht. Sprich solange man vereinzelte Pakete mit fester IP verschickt reicht das. Um das in ein Firmennetzwerk zu hängen, da fehlen ein paar Protokolle, um die man sich dann selber kümmern muss.
hier gab es vor kurzem eine ähnliche Aufgabe, da habe ich ein Stück Code mit mbed-os gepostet: Beitrag "Re: 32 GPIO Sender und Empfänger via Bus/Ethernet" Da ging es um die Übertragung von IO Signalen, im Prinzip das gleiche. Das SPI gibt es natürlich auch als API und Komponenten für die Portextender findet man auch. Ist C++, läuft aber auch auf einem F407. Einen W5500 würde ich mir nicht antun, weil der EMAC im F407 wunderbar funktioniert. Und man kann mit dem Debugger bis in die untersten Schichten von lwIP und Treiber. Es gibt eine ganze Menge verschiedener Boards mit dem F407, für die einfachen (<10€) vom Ali braucht man noch einen Phy und 11 Strippen zum anschliessen. Von Waveshare kosten originale ca. 10€, die Clones (ja, die Chinesen kopieren sich auch gerne selber) kosten weniger als die Hälfte. Dann gibt es weitere Boards mit dem F407 incl. Ethernet Phy und RJ45 Buchse, findet man ab ca. 20€. Und bei Olimex gibt es ebenfalls ein passendes Board E407 incl. Ethernet für ca. 30€. Das Code Beispiel arbeitet mit UDP, da kann man auch einen Empfänger bauen der von mehreren Sendern gesteuert werden kann. Das von Stefan genannte MQTT mag ich auch, dafür gibt es viele Clients, z.B. auch für das Smartphone. Oder Automatisierungssoftware die dann per GUI oder Timer Aktionen ausführen kann. Einen MQTT Client kann man mit dem F407 und Mbed auch realisieren, dafür hätte ich auch eine Komponente.
Ich halte auch den W5500 für diesen Anwendungsfall und die vorhandene Erfahrung für den besten Weg. Wie man beim Netzwerk-Protokoll auf MQTT kommt in Verbindung mit "pro Audio" erschließt sich mir nicht. Hier ist ehr OSC angesagt. https://de.wikipedia.org/wiki/Open_Sound_Control Vor allem, weil es im Pro Audio Umfeld von vielen Geräten unterstützt wird und es auch für Tablets und co. genügend Lösungen gibt. https://hexler.net/touchosc Im Musikerumfeld und zum Schalten von ein paar Relais kämen auch noch Midi oder DMX in Frage. Für DMX gibt's auch fertige drahtlose "Kabel": https://www.thomann.de/de/eurolite_quickdmx_wireless_receiver.htm?sid=0f74ac1d9f3beb61b0a693fa883969ec Ebenso gibt es fertige Relaisbaugruppen für DMX. Midi oder DMX sind auch simpel und billig mit dem kleinsten µC möglich. DMX erledigt ein STM32 per DMA im Halbschlaf.
Uli A. schrieb: > Gibt es da zum Experimentieren ein empfehlenswertes All-In-One > Controllerboard, das aus den SPI Bit-Ketten auf der einen Seite ein > Ethernet-Datenpaket schnürt und auf der anderen Seite das Ganze > rückwärts ? Und wie aufwendig ist das Ganze auf der Programmierseite ? > Mir ist bewusst, dass gerade der STM32F407 ja schon Ethernet an Bord > hat....aber es wäre zum Ausprobieren wie schon angedeutet praktisch, > wenn ich nicht die Schnittstelle aus Einzelteilen aufbauen müsste, > sondern einfach eine Art integrierten SPI/Ethernet-Konverter hätte... Mach es nicht. 1. Die SPI-Ethernet-Controller sind eigentlich nur Notlösungen für die Fälle, wo der Prozessor nichts eingebaut hat. Du fügst dem ganzen eher noch Komplexität hinzu. Der bessere Weg wäre ein Devboard, was Ethernet gleich schon mit drauf hat. 2. Du kannst nicht einfach Bitfolgen per SPI reintakten und hoffen, dass die auf der anderen Seite wieder rausfallen. Du brauchst einen speziellen Treiber, der Speicher und Register über den Flaschenhals SPI gezielt befüllt. Das ist genauso komplex wie die Programmierung des internen Controllers. 3. Du brauchst eh den ganzen Netzwerkstack mit IP, TCP, UDP, DNS usw. Das willst Du nicht selberschreiben, und deswegen setzt Du auf ein Framework auf. Diese Frameworks benutzen aber den internen Controller, irgendetwas anderes müsstest Du seinen reinbasteln. Viel Spaß damit. Es gibt leichtgewichtigere Alternativen: z.B. CAN oder RS422/RS485. RS422/RS485 gibts z.B. auch mit 10MBit/s und mehr, wenn man die passenden Controller verwendet. Und für den Anfang gibts auch Umsetzer LAN-RS232/422/485. Sowas z.B.: https://www.wiznet.io/product-item/wiz105sr/ Da brauchst Du Dich auf Controllerseite um nichts mehr zu kümmern. Ansonsten ist das hier ganz nett: https://www.ti.com/tool/EK-TM4C1294XL Der Chip hat Ethernet MAC UND PHY direkt eingebaut, d.h. Du kannst direkt die LAN-Buchse anklemmen. Und Du bekommst von TI eine komplette Treiberbibliothek und ein RTOS mit TCP/IP-Stack kostenlos dazu. fchk
Ich bin zwar auch ein grosser STM32-Fan, aber in diesem Fall würde ich doch den ESP32 vorschlagen, da das "Gesamtpaket" durchaus ein paar Vorzüge hat. 1. Für 6-7€ plus Versand bekommst Du ein fertiges Board vom Chinamann (https://de.aliexpress.com/item/1005002023028892.html) 2. Der ESP32 kann sowohl Ethernet als auch WLAN 3. Das ESP-IDF ist mittlerweile ziemlich ordentlich und die Programmierung damit ist gar nicht schwer 4. Sämtliche benötigten Protokolle sind mit an Bord (TCP/IP über lwIP), auch sowas wie MQTT, aber ebenso ist ein Websocket-Server oder HTTP()S-Server blitzschnell mit wenig Aufwand programmiert, ohne dass man sich in die Protokoll-Details tief einarbeiten muss 5. Der ESP32 kann natürlich auch SPI und I2C, also falls die Tasten keine eigenen Schieberegister haben, lassen sich natürlich mehrere MCP23017 leicht anschließen. Ich wage mal zu behaupten, dass Du mit dem ESP32-Board ziemlich schnell zumindest die grundlegende Funktionalität am Start hast. Mit dem STM32 wirst Du erheblich länger brauchen.
Hui. Ok. Ich versuche mal, das alles zu sortieren - vielen Dank für Eure Beiträge und Anregungen...! Ganz grob zusammengefasst, heißt das für mich: a) Frag 4 Ärzte und höre 7 Meinungen ;-) b) Wie ja durchaus von mir vorher angenommen, reichen meine Kenntnisse zum Thema Netzwerktechnik da noch nicht annähernd aus ;-( Das war ja auch der Grund für meine Frage nach einer quasi Plug&Play Lösung für die Konvertierung, die eben nicht so viel Netzwerkkenntnisse erfordert....die scheint es so aber wohl nicht zu geben, was zu wissen ja auch schon ein Gewinn ist. Ebenso wie der Hinweis, dass die vermeintliche Erleichterung dann doch wieder andere Komplikationen mit sich bringt... Allerdings scheint der WIZ105 interessant zu sein... Da muss ich also wohl erstmal einiges an Hausaufgaben machen bzw. doch eher den "lokalen" Weg (Modem zu Kraftwerk) über die gängigen seriellen Schnittstellen beschreiten. In der Zwischenzeit: Hat jemand vielleicht einen Tip zu einem guten Standardwerk oder zu Internetresscourcen, wenn ich mich grundlegend in die Netzwerktechnik einarbeiten will ? Vor allem auch auf der Hardwareseite ? Die meisten Bücher die ich bisher gesehen habe sind scheinbar eher für IT-Interessierte in Richtung "Wie richte ich ein Netzwerk ein" geschrieben....
Angehängte Dateien:
-
DSC04935.JPG
230 KB
Uli A. schrieb: > Da muss ich also wohl erstmal einiges an Hausaufgaben machen bzw. doch > eher den "lokalen" Weg (Modem zu Kraftwerk) über die gängigen seriellen > Schnittstellen beschreiten. Das ist ein guter Weg. Fang erstmal mit RS232 oder RS485 an und nimm vielleicht MODBUS-RTU als Protokoll. Dann kannst Du damit https://www.amazon.de/Waveshare-Industrial-Converter-Customized-Resolution/dp/B07S3HRYRR/ref=psdc_1626220031_t1_B00LJEQLR2 Dein Gerät ans Netzwerk anschließen, und auf der anderen Seite fällt MODBUS-TCP raus, oder nacktes TCP, je nach Einstellungen und dem, was auf der anderen Seite ist. > In der Zwischenzeit: Hat jemand vielleicht einen Tip zu einem guten > Standardwerk oder zu Internetresscourcen, wenn ich mich grundlegend in > die Netzwerktechnik einarbeiten will ? Vor allem auch auf der > Hardwareseite ? Auf der Hardwareseite ist es einfach: Nimm einen Controller mit eingebautem MAC, der MII oder RMII hat, klemme einen PHY an (der hat auch MII oder RMII), und der Rest steht in den Datenblättern der beteiligten Controllern. Wenn Du mit minimaler Hardware anfangen willst, nimmst Du diesen Mikrocontroller: https://www.microchip.com/wwwproducts/en/PIC18F67J60 Das ist dann eine Einchip-Lösung, d.h. da ist alles drin. Du brauchst dann noch einen 25 MHz Quarz, ein paar Kondensatoren und Widerstände, und den LAN-Port mit eingebautem Übertrager. Weniger und billiger geht nicht, und lötbar ist das auch noch. Die Software gibts bei Microchip kostenlos. Siehe Anhang, das kannst Du so abpinseln, das funktioniert. Wenn Du mehr Ports und Pins brauchst, gibts das ganze als PIC18F97J60 auch mit 100 Pins. fchk
Uli A. schrieb: > Deine begriffliche Abgrenzung bzgl. Netzwerk und Ethernet verstehe ich > noch nicht so ganz...Ethernet ist doch ne Teilmenge von > Netzwerkkommunikation, oder ? Ein Netzwerk kann Ethernet zur Datenübertragung nutzen, aber auch eine andere Art (z. B. W-LAN). Ein paar Bildchen zur Verdeutlichung: http://www.tcp-ip-info.de/glossar/tcp-ip-modell-vs-osi-modell.gif http://www.hbernstaedt.de/OSI.jpg http://www.hbernstaedt.de/osihis.jpg
Frank K. schrieb: > Auf der Hardwareseite ist es einfach: Nimm einen Controller mit > eingebautem MAC, der MII oder RMII hat, klemme einen PHY an (der hat > auch MII oder RMII), und der Rest steht in den Datenblättern der > beteiligten Controllern. Da bin ich ja mit dem STM32F407 schon genau richtig - der kann ja MII und RMII.... Welchen PHY würdest Du denn dafür nehmen ? Gibt es da was in einem lötbaren Format ? Wie wäre es mit dem hier: https://www.reichelt.de/10base-t-ethernet-kontroller-spi-eee-802-3-dip-28-enc-28j60-i-sp-p89340.html?&nbc=1 (darauf kam ich ebenfalls wieder im Sinne des Gedankens, mir wenn möglich den Aufbau von vielen "Kleinstkomponenten" in der Testphase zu sparen) ? Danke für die Tips mit TI und PIC....bin allerdings gerade so schön frisch eingearbeitet in die STM32-Welt und kann das alles soweit ganz gut bedienen und programmieren, zumindest was die einfache Registerprogrammierung angeht....also Configs schreiben und direkte Ansteuerung der GPIO, SPI und I2C Register...und das läuft alles prima mit dem Coden in der CubeIDE und das Debugging und die Ausführung auf dem STM funktioniert auch...daher würde ich nur bei absoluter Notwendigkeit direkt wieder einen Systemwechsel machen wollen...;-) Natürlich ist die Auswahl des F407 dem aktuellen Verwenden des Discovery Boards geschuldet, und dementsprechend ist der natürlich vor allem auf der "Empfängerseite" meines Projektes ziemlich Überdimensioniert....aber es geht eben für mich im Moment immer noch darum, sehr viele neue Sachen zu verstehen und anwenden zu lernen....das Ganze dann etwas passender dimensionieren kann ich ja später immer noch...
Uli A. schrieb: > Wie wäre es mit dem hier: > > https://www.reichelt.de/10base-t-ethernet-kontroller-spi-eee-802-3-dip-28-enc-28j60-i-sp-p89340.html?&nbc=1 Nein, das ist ein Ethernet Controller, für deine Betrachtungen in diesem deinen Beitrag brauchst du einen PHY, also etwa einen DP83848 oder einen LAN8720. So etwas ist auch auf den Nucleo Boards verbaut.
Net Worker schrieb: > brauchst du einen PHY, also etwa einen > DP83848 oder einen LAN8720. So etwas ist auch auf den Nucleo > Boards verbaut. Also dann sowas ? https://www.amazon.de/Waveshare-Performance-LAN8720-Board-Transceiver/dp/B00N4JW3YK bzw. https://www.amazon.de/Waveshare-DP83848-Ethernet-Board-Transceiver/dp/B00KM6VNBC
:
Bearbeitet durch User
Ja, passt, schrieb ich auch schon. Nur das Disco hat einige Ports belegt, da muss man gucken ob die RMII noch frei ist. Kann man einfach mit dem STM32Cube kontrollieren.
Net Worker schrieb: > Uli A. schrieb: >> Also dann sowas ? > > Schrub ich doch! Wollte nur sicher gehen, dass Du sowas als Board meintest und nicht nur den Chip an sich...;-) Johannes S. schrieb: > Ja, passt, schrieb ich auch schon. Nur das Disco hat einige Ports > belegt, da muss man gucken ob die RMII noch frei ist. Kann man einfach > mit dem STM32Cube kontrollieren. Ja, aber das krieg ich hin....immerhin....;o)))
Uli A. schrieb: > Wollte nur sicher gehen, dass Du sowas als Board meintest und nicht nur > den Chip an sich...;-) Wo ist der prinzipielle Unterschied zwischen nackten Chip und einem Board/Modul? Ich sehe keinen, soviel Abstraktion muss man von dir erwarten können.
Net Worker schrieb: > Wo ist der prinzipielle Unterschied zwischen nackten Chip und > einem Board/Modul? Ich sehe keinen, soviel Abstraktion muss > man von dir erwarten können. Auf diesen Boards ist für den RMII-Betrieb ein 50MHz-Quarz vorhanden. Das ist auch ganz gut so, da hat man beide Entscheidungen (RMII-Interface und Taktversorgung über separaten Oszillator und nicht vom F407) schon getroffen. Ansonsten: Der DP83848 bietet MII (der LAN8720 kann nur RMII), aber nicht auf diesen Boards. Bei mir laufen ein paar Server mit LAN8720 und dem DP83848(im MII Mode). Die Antwortzeit vom DP ist spürbar schneller, aber bei ein paar popligen Webseiten oder nur Daten spielt das kaum eine Rolle.
Uli A. schrieb: > Welchen PHY würdest Du denn dafür nehmen ? Gibt es da was in einem > lötbaren Format ? Ich würde mich da an den Empfehlungen von ST orientieren, denn du willst ja auch, dass deren Software dazu passt. Die haben bestimme eine Application Note dazu geschrieben.
Frank K. schrieb: > Das ist ein guter Weg. Fang erstmal mit RS232 oder RS485 an und nimm > vielleicht MODBUS-RTU als Protokoll. Dann kannst Du damit Bitte erst mal den Ausgagngspost lesen. Das Umfeld ist Pro Audio und damit ist MODBUS-RTU wohl nicht die beste Wahl.
Stefan ⛄ F. schrieb: > Ich würde mich da an den Empfehlungen von ST orientieren, ST verwendet den LAN8720 (ist auch auf den Waveshare drauf), neuere Boards den moderneren LAN8742A. Für die Basisfunktionalität sind die Register gleich, aber die PHY haben auch eine Adresse die per Hardware gesetzt ist. Wenn die nicht passt, dann sucht man da erstmal weil nix geht. Im Cube kann man den Phy auswählen und der Code wird passend generiert. In Mbed kann man die Bits und Bitmasken anpassen und so auch mit DP oder LAN87xx Phy arbeiten. Die nackten Chips sind nicht Breadboard tauglich, die Module habe ich mit 10 cm Dupontkabeln angeschlossen und das hat in mehreren Fällen funktioniert. Nur nicht die Kabel mit billigen Eisenkontakten nehmen, da kriegt man die Krise wenn die nach 3 Tagen von alleine wackelig werden.
temp schrieb: > Bitte erst mal den Ausgagngspost lesen. Das Umfeld ist Pro Audio und > damit ist MODBUS-RTU wohl nicht die beste Wahl. Könntest Du das für mich Anfänger erklären ?
Uli A. schrieb: > temp schrieb: >> Bitte erst mal den Ausgagngspost lesen. Das Umfeld ist Pro Audio und >> damit ist MODBUS-RTU wohl nicht die beste Wahl. > > Könntest Du das für mich Anfänger erklären ? Er meinte damit, dass MODBUS aus dem industriellen Umfeld kommt und im Audio-Umfeld weitgehend unbekannt ist. Wenn Du hingegen eh alles selberbauen willst, finde ich das nicht so wichtig. Es gibt da eine Lösung, die recht einfach umzusetzen ist, das Protokoll ist hinreichend einfach, und Umsetzer MODUBUS RS485-TCP gibts auch fertig zu kaufen. In Musikbereich ist DMX üblich, aber direkt DMX über IP ist meine ich nicht standardisiert. Es gibt mehrere Derivate, die etwas DMX-ähnliches über UDP oder IP machen. Außerdem kenne ich jetzt kein Gerät, was DMX über RS485 in DMX (oder ähnliches) über IP umsetzt, während das bei Modbus recht weit verbreitet ist. Musik ist aber nicht mein Ding, und daher kenne ich mich in dem Bereich auch recht wenig aus. Was es auch gibt, sind Lösungen, die auf dem Rechner eigene COM-Port Treiber installieren, die den IP-seriell-Umsetzer steuern. Dann merkt die eigene Software nicht, dass das entfernte Gerät übers Netzwerk angesteuert wird. Da Du aber mittelfristig eh direkt IP verwenden willst, halte ich das speziell für Dich nicht für eine geeignete Strategie. fchk
Frank K. schrieb: > Und für den Anfang gibts auch Umsetzer LAN-RS232/422/485. Sowas z.B.: > https://www.wiznet.io/product-item/wiz105sr/ > Da brauchst Du Dich auf Controllerseite um nichts mehr zu kümmern. Wie meintest Du das? Die Ethernet-Seite des WIZ105SR mit dem STM32 verbinden? Wäre es in dem Fall nicht einfacher, im STM32 UART und dann einen Pegelwandler auf RS232 zu benutzen? Falls die Verbindung andersherum gemeint war? Hat man dann nicht dieselben Nachteile wie von Dir für den W5500 beschrieben?
Frank K. schrieb: >>> damit ist MODBUS-RTU wohl nicht die beste Wahl. >> >> Könntest Du das für mich Anfänger erklären ? > > Er meinte damit, dass MODBUS aus dem industriellen Umfeld kommt und im > Audio-Umfeld weitgehend unbekannt ist. Wenn das so gemeint war, empfinde ich das auch nicht als wichtiges Kriterium. Für mich ist insgesamt wichtig, eine funktionierende Lösung mit halbwegs überschaubarem Lern- und Entwicklungsaufwand zu finden. Da ich das Ganze zunächst nur als erweitertes Hobbyprojekt betreibe, kann und will ich kein IT- und Informatikstudium zwischenschalten, um alle Pros und Cons der verschiednen technischen und Protokoll-Varianten bewerten zu können. Und davon abgesehen, dass es sicher nicht nur die eine, richtige Lösung gibt - offensichtlich gibt es ja da auch unter den erfahrenen Anwendern einigen Diskurs....;o) Was ich mir mit dem Thread erhofft habe, ist dementsprechend ein Ausschluss von SICHER NICHT sinnvollen Ansätzen und Anregungen für eine mögliche Richtung...und das eben auf Hardware- wie auf Code-Seite... So ganz uninteressant ist DMX da auch nicht - allerdings eben auch wieder eher als Lösung für die lokalere Idee (ohne spätere Erweiterung auf Netzwerk-Remote-Bedienung verschiedenster Art und Übertragungswege).
Uli A. schrieb: > Gibt es da zum Experimentieren ein empfehlenswertes All-In-One > Controllerboard, das aus den SPI Bit-Ketten auf der einen Seite ein > Ethernet-Datenpaket schnürt und auf der anderen Seite das Ganze > rückwärts ? Und wie aufwendig ist das Ganze auf der Programmierseite ? Grundsaetzlich ist Netzwerk-Kram etwas aufwendiger als das. Mit dem Wiznet-W5500-Geraffel kann man schon was zum Rattern kriegen, aber kaum skalierbar (und per SPI wegen der Performance nicht wirklich zu empfehlen). Die Anbindung per Bus-Interface ist etwas flotter. Aber merke: es gehen maximal 4 TCP Verbindungen (sollte ich mich jetzt nicht irren). Fertige Setups was die Hardware und Kommunikationslayer (Ethernet) angeht, solltest du bei der Suche nach Stichworten 'ROS' oder 'NuttX' einige finden. Darauf setzt du dann die Kommunikationslib deiner Wahl. Fuer alles, was Linux-Socket-kompatibel ist (LWIP, NuttX Stack, ...) kannst du einiges wiederverwerten. Vielleicht hilft Dir da auch netpp (https://gitlab.com/hackfin/netpp). Damit reduziert sich die Fernkontrolle auf Register-Treiber-Schreiben und Ansteuerung per Python o.ae., allerdings musst du etwas Schmalz in die Abstraktion der Geraetebeschreibung investieren (per grafischen XML-Third-Party-Tool).
Uli A. schrieb: > So ganz uninteressant ist DMX da auch nicht - allerdings eben auch > wieder eher als Lösung für die lokalere Idee (ohne spätere Erweiterung > auf Netzwerk-Remote-Bedienung verschiedenster Art und Übertragungswege). Da liegst du falsch. Der gängige Weg ist heute Artnet. Von der Netzwerkschicht (UDP) auf DMX wird es meistens erst relativ local gemacht mit solchen Teilen: https://www.dmx4all.de/produkte/dmx-stage-profi-1-1-rdm/ Github ist mit solchen Artet Nodes aber auch voll. Zu Artnet findest du über 600 Repositories. Der andere Weg ist OSC und das läuft auch über UDP Pakete. Darüber wird auch Midi abgewickelt. Die gängige Software im Pro Audio Umfeld wie Logic oder Cubase unterstützen dieses Protokoll. Viele andere auch. Lichtsteuersoftware spricht häufig Artnet, Midi und DMX. MQTT und Modbus wurde in diesem Umfeld noch nicht gesehen. Eventuell sollte der Threadstarter mal sagen was er unter Pro Audio in diesem Zusammenhang versteht.
Martin S. schrieb: > Grundsaetzlich ist Netzwerk-Kram etwas aufwendiger als das. Mit dem > Wiznet-W5500-Geraffel kann man schon was zum Rattern kriegen, aber kaum > skalierbar (und per SPI wegen der Performance nicht wirklich zu > empfehlen). Die im Gegensatz zu gebräuchlichen Netzwerkübertragungsraten eher geringe SPI Performance ist in meinem Fall vermutlich eher nicht das Problem, zumindest soweit ich das einschätzen kann...immerhin ist das eigentliche Datenpaket extrem winzig - ein paar Schaltbits halt....und das wird sich auch in einer "skalierten Variante" nicht ändern... > Die Anbindung per Bus-Interface ist etwas flotter. Aber > merke: es gehen maximal 4 TCP Verbindungen (sollte ich mich jetzt nicht > irren). Auch das sollte bei mir auch längerfristig ausreichen, wenn ich die Zahl der TCP Verbindungen von maximal 4 mit der maximalen Zahl der "gleichzeitig Zugriffsbeteiligten" auf das Gerät richtig verstehe... > Fertige Setups was die Hardware und Kommunikationslayer (Ethernet) > angeht, solltest du bei der Suche nach Stichworten 'ROS' oder 'NuttX' > einige finden. > > Darauf setzt du dann die Kommunikationslib deiner Wahl. Fuer alles, was > Linux-Socket-kompatibel ist (LWIP, NuttX Stack, ...) kannst du einiges > wiederverwerten. Vielleicht hilft Dir da auch netpp > (https://gitlab.com/hackfin/netpp). > Damit reduziert sich die > Fernkontrolle auf Register-Treiber-Schreiben und Ansteuerung per Python > o.ae., allerdings musst du etwas Schmalz in die Abstraktion der > Geraetebeschreibung investieren (per grafischen XML-Third-Party-Tool). Danke für die Hinweise - sind für mich für den Moment noch einige spanische Dörfer dabei, aber das werde ich mal mit der Zeit durcharbeiten ;-)
temp schrieb: > Eventuell sollte der Threadstarter mal sagen was er unter Pro Audio in > diesem Zusammenhang versteht. Ich bin der Threadstarter....;-) Nochmal zur Klärung: Pro Audio ist die eigentliche Anwendung des Geräts, für das die Steuerung implementiert werden soll - genauer gesagt eine Art Schaltmatrix für analoge Geräte im Bereich Audio Mastering / Mixing. Der Mainframe (ja, man kann den Begriff auch im Sinne von "Hauptgerät" verwenden und nicht nur mit der spezifischen Bedeutung "Megazentralrechnerkomplex", wie immerhin die Wortbedeutung an sich auch nahelegt) enthält hier ein modulares Relaiskartensystem, das die einzelnen Geräte in den analogen Signalweg schaltet. Die Remote soll natürlich diese Schaltvorgänge entsprechend ansteuern bzw. abspeicherbar verwalten. Aktuell gibt es das Gerät auch schon (habe es für mein eigenes Studio entwickelt und gebaut), alerdings in einer noch nicht "digitalisierten", einfachen Version, in der die Schaltzustände schlicht über rastende Schalter hergestellt werden... Von der Anwenderseite sind mir natürlich sowohl DMX als auch OSC bekannt. WLAN fällt für mich übrigens weg (da sind Studioleute - besonders im Masteringbereich - eher keine Fans von). Die gesuchte Struktur ist also wie schon im Anfangspost beschrieben das eigentlich schaltende Gerät, das dann im einfachsten Fall durch die besagte Hardware Remote Unit bedient wird, im erweiterten Fall aber auch (entweder statt oder sogar parallel zur Remote) durch einen Rechner im Ethernet LAN....anwendungsseitig dann z.B. durch DAWs bzw. entsprechende Plugins. Natürlich hätte da die Verwendung eines OSC-kompatiblen Protokolls seinen Reiz - eben durch die große Verbreitung im gesamten Audio-Kosmos... Danke auch noch für den Aspekt Artnet (kannte ich noch nicht !)
:
Bearbeitet durch User
Jörg schrieb: > Frank K. schrieb: >> Und für den Anfang gibts auch Umsetzer LAN-RS232/422/485. Sowas z.B.: >> https://www.wiznet.io/product-item/wiz105sr/ >> Da brauchst Du Dich auf Controllerseite um nichts mehr zu kümmern. > > Wie meintest Du das? Die Ethernet-Seite des WIZ105SR mit dem STM32 > verbinden? Wäre es in dem Fall nicht einfacher, im STM32 UART und dann > einen Pegelwandler auf RS232 zu benutzen? > > Falls die Verbindung andersherum gemeint war? Hat man dann nicht > dieselben Nachteile wie von Dir für den W5500 beschrieben? Es ist andersrum gemeint. Und dann kommt das, was Du auf der einen Seite seriell reinschiebst, auf der anderen Seite 1:1 als TCP-Datenstrom auf einem festen TCP-Port raus. Das serielle Gerät weiß davon nichts. Wenn es nur darum geht, einen Datenstrom zu übertragen, ist das das einfachste. Solche Geräte gibts entweder zum Einbauen oder als externe Einheit, die dann bis zu 16 serielle Ports (RS232 oder RS422/485) haben kann. fchk
Nochmal ne grundsätzliche Verständnisfrage, um das Ganze trotz aller weißen Wissens-Flecken bei mir ein bisschen zu konkretisieren: Wenn ich nun also die Grundhardware für den Moment mit STM32 (mit Ethernet- bzw. MII oder RMII-Fähigkeit an Bord) + PHY in Form von z.B. DP83848 oder LAN8720 für beide Geräte (Remote und Hauptgerät) annehmen würde, dann könnte ich doch im Nachhinein immer noch komplett frei entscheiden, welches Level von Skalierbarkeit ich erreichen möchte, oder ? Also damit müsste ich doch immer noch entscheiden können a) ob ich z.B. UDP oder TCP zur Übertragung nutzen möchte (oder was ganz anderes) b) ob ich eine eher lokale reine Master-Slave-Lösung realisiere oder ob ich Remote und Hauptgerät ggfs. über einen Switch ans "Haus"-LAN anschließe und über einen dort ebenfalls angeschlossenen Rechner oder ein Tablet steuere...? Das wären dann doch eigentlich "nur noch" programmiertechnische Fragen, oder ? Ich habe ja keine Angst, mich in Dinge einzuarbeiten, ich versuche nur, nun mal einen bestimmten Hardwareweg für Tests und Entwicklung festzuzurren, dessen Möglichkeiten ich nicht unbedingt voll ausschöpfen muss, mit dem ich dann aber vor allem nicht in Sackgassen renne, die wieder einen kompletten "Systemwechsel" erfordern und viel unnötige Zeit auffressen...
Du kannst im Prinzip alles damit machen, deshalb hat sich diese IP Übertragung in diesem Internet so durchgesetzt.
Frank K. schrieb: > Es ist andersrum gemeint. Und dann kommt das, was Du auf der einen Seite > seriell reinschiebst, auf der anderen Seite 1:1 als TCP-Datenstrom auf > einem festen TCP-Port raus. Das serielle Gerät weiß davon nichts. Wenn > es nur darum geht, einen Datenstrom zu übertragen, ist das das > einfachste. > > Solche Geräte gibts entweder zum Einbauen oder als externe Einheit, die > dann bis zu 16 serielle Ports (RS232 oder RS422/485) haben kann. > > fchk Das würde ja für mich bedeuten: 1) Beschränkung auf die nun schon oft erklärte "lokale Master-Slave-Lösung" und 2) genau das zu sein, was ich für diese lokale Lösung von Anfang an hier erfragen wollte -> einen reinen Datentransceiver von seriell auf Netzwerkhardware und zurück (nur, dass ich dabei SPI und nicht UART im Sinn hatte) Oder ?
Uli A. schrieb: > Nochmal zur Klärung: > > Pro Audio ist die eigentliche Anwendung des Geräts, für das die > Steuerung implementiert werden soll - genauer gesagt eine Art > Schaltmatrix für analoge Geräte im Bereich Audio Mastering / Mixing. > Also geht es hier nur um ein bischen Schaltergeplänkel. Dann wäre meine Klare Antwort: Nimm Midi. Das kannst du immer noch physikalisch über OSC transportieren wenn du willst, aber einfacher als über Midi geht es kaum. Und das Protokoll kann jedes Gerät und jede Software die mit Audio Production zu tun hat.
Meine einfache Lösung: Raspberry Pi und Node-Red
Manfred Scheer schrieb: > Meine einfache Lösung: Raspberry Pi und Node-Red Wenn da nur nicht dieses JavaScript wäre :)
Uli A. schrieb: >> Solche Geräte gibts entweder zum Einbauen oder als externe Einheit, die >> dann bis zu 16 serielle Ports (RS232 oder RS422/485) haben kann. >> >> fchk > > Das würde ja für mich bedeuten: > > 1) Beschränkung auf die nun schon oft erklärte "lokale > Master-Slave-Lösung" und > 2) genau das zu sein, was ich für diese lokale Lösung von Anfang an hier > erfragen wollte -> einen reinen Datentransceiver von seriell auf > Netzwerkhardware und zurück (nur, dass ich dabei SPI und nicht UART im > Sinn hatte) > > Oder ? Im Prinzip ja. Der Haken dabei ist, dass bei einer 1:1 Umsetzung das Netzwerkprotokoll dann nichts standardmäßiges wäre, was Du mit fertigen Applikationen ansprechen kannst. Wenn DU damit leben kannst: hervorragend. Wenn nicht, dann brauchst Du spezialisierte DMX-Artnet oder DMX-OSC-Umsetzer oder Midi-Artnet oder wasauchimmer, die dann keine 1:1 Durchreiche machen, sondern ein bestimmtes serielles Protokoll auf ein bestimmtes Netzwerkprotokoll vornehmen. Das wird dann aber wieder aufwändiger, zum einen vom Geld her und zum anderen, weil du dann das serielle Protokoll korrekt implementieren musst, anstelle Dir selber irgendetwas maximal einfaches auszudenken. fchk
Manfred Scheer schrieb: > Meine einfache Lösung: Raspberry Pi und Node-Red Hm....das klingt ja interessant.....aber kann ich das auch auf einem STM32 implementieren ? Da ich ja am Ende einen Prototypen und langfristig ggfs. eine verkaufbare Kleinserie herausbekommen möchte, bringt es mir ja wenig, wenn ich dann da einen RasPi einbauen soll....das Ganze soll insgesamt hardwareseitig möglichst schlank bleiben und eben als eigenes Board aufbaubar... Das muss nicht unbedingt heißen, dass es am Ende selbst lötbar bleiben muss - für eine kleine Serie würde sich auch schon eine Auftragsfertigung lohnen - aber es geht eben nicht um "Bau da jetzt an Dein Discoboard noch ein ganzes Konglomerat an anderen Boards dran" (das wäre bei den obengenannten Lösungen der kleinen PHY-Boards noch im Rahmen, da man die ja auch am Ende selbst in den Einzelteilen nachbauen kann). Auch die Bestandteile des Discoboards werde ich am Ende "maximal entschlackt auf das Nötigste" für das eigene Controllerboard übernehmen...
Uli A. schrieb: > Da ich ja am Ende einen Prototypen und langfristig ggfs. eine > verkaufbare Kleinserie herausbekommen möchte, bringt es mir ja wenig, > wenn ich dann da einen RasPi einbauen soll....das Ganze soll insgesamt > hardwareseitig möglichst schlank bleiben und eben als eigenes Board > aufbaubar... Auch dafür gibts was: https://www.raspberrypi.org/products/compute-module-4/?variant=raspberry-pi-cm4001000 Dieser Pi4 ist extra dafür gemacht, als Modul auf ein kundenspezifisches Basisboard zu wandern und in ein Gesamtsystem integriert zu werden. So ein Vorgehen ist in der Industrie bei kleinen Stückzahlen nichts ungewöhnliches. Von NVidia gibts z.B das hier - da ist dann ein 64 Bit ARM Hexacore plus eine fette GPU drauf, zur Verwendung in eigenen Produkten: https://www.nvidia.com/de-de/autonomous-machines/embedded-systems/jetson-xavier-nx/ Sollte das Dein Weg sein - hier ist er. fchk
Manfred Scheer schrieb: > Meine einfache Lösung: Raspberry Pi und Node-Red Wer das als einfache Lösung empfindet, hat den Schuss nicht gehört. Einfach höchsten in der Form: geht auch gerade noch für Dummies. Ich frage mich wirklich ob die Welt heute schon so blöd ist für das Wackeln von ein paar Relais aber Millionen Zeilen Quellcode in der Summe zu benötigen. Und mit nodejs nur 1 Byte über eine serielle Schnittstelle zu schieben werden zusätzlich zu dem Haufen den man eh schon hat 612 Dateien in 142 Verzeichnissen ins Projekt gespült. Und mit jeder weiteren kleinen Abhängigkeit kommen die nächsten paar hundert. In meinen Augen ist das alles nur noch krank.
temp schrieb: > für das > Wackeln von ein paar Relais aber Millionen Zeilen Quellcode in der Summe > zu benötigen. Das verstehe ich als Einwand und finde es auch dem Grundsatz nach wenig sinnig. Auf der anderen Seite ist die Frage, ob das für die von Dir ein wenig abfällig als "Dummies" bezeichneten Anfänger oder vielleicht auch schlicht Menschen mit anderen Schwerpunkten als ganz tief in die Materie einzutauchen nicht doch sinnvoll sein kann, sich über solche Vehikel eine Zugangsmöglichkeit zum Entwickeln zu schaffen. Natürlich bringen diese Plattformen eine Menge an "unnötigem Code-Ballast" mit sich....aber ist das bei den heutigen Prozessoren mit Ihrer immensen Power und Speicherkapazität denn ein realistisches Problem (gerade für einfachere Anwendungen)? Das mag für Puristen regelrecht anstößig sein. Dem kreativen Anwender bietet es aber ggfs. tolle Optionen, ohne abgeschlossenes Studium auch Projekte zu realisieren.... Wenn in Zukunft die Leistung der Prozessoren ausreicht, um eine - vielleicht KI-basierte - Umgebung zu schaffen, der man nur noch diktiert, was denn so im Programm passieren soll, und die das dann in Massen von Code implementiert, bin ich der erste der das nutzt......egal, ob das programmierethisch einen Verfall bedeutet....;o) Aber mal was ganz anderes: Was wäre denn Deine Lösung für mein Problem ?
Frank K. schrieb: > Auch dafür gibts was: > https://www.raspberrypi.org/products/compute-module-4/?variant=raspberry-pi-cm4001000 > > Dieser Pi4 ist extra dafür gemacht, als Modul auf ein kundenspezifisches > Basisboard zu wandern und in ein Gesamtsystem integriert zu werden. So > ein Vorgehen ist in der Industrie bei kleinen Stückzahlen nichts > ungewöhnliches. Von NVidia gibts z.B das hier - da ist dann ein 64 Bit > ARM Hexacore plus eine fette GPU drauf, zur Verwendung in eigenen > Produkten: > > https://www.nvidia.com/de-de/autonomous-machines/embedded-systems/jetson-xavier-nx/ > > Sollte das Dein Weg sein - hier ist er. > > fchk Wow. Du hast echt für alles eine Antwort....;-) Super interessant, diese Variante. Und cool zu wissen, dass es das gibt ! Allerdings möchte ich nach Möglichkeit in der Nähe zu Audioleitungen auf Hi-Speed Prozessoren verzichten - und das ist dann schon auch irgendwie Kanonen auf Spatzen für die paar übertragenen Bits... Aber nochmal eine grundsätzliche Frage zu einem möglichen Aufbau für mein Projekt, die für mich noch nicht abschließend beantwortet wurde: Brauche ich wirklich einen Server, wie weiter oben gesagt wurde, sobald ich irgendein Gerät per Ethernet-Schnittstelle ins Netz hängen möchte....? Also muss in JEDEM GERÄT ein Serverblock sein ? Das wäre mir neu..... Also nochmal die Frage nach der MINIMALanforderung einer MCU-basierten Hardware für die Anbindung ans ('Äther')Netz per STM32....gerne auch per Skizze ! ;o) Danke allen auch nochmal für die Beiträge !
für so eine Anwendung reicht einfaches UDP, siehe meine verlinktes Beispiel weiter oben. Man macht ein bind() auf einen Empfängerport, und damit kann jeder an das Gerät senden. Der Empfänger weiss auch von wem das Packet kam und kann mit Statusinfos antworten. Ein UDP Testsender in JS mit Nodejs sind ein paar Zeilen ohne zig libs, das ist in der Doku schon als Beispiel drin.
Uli A. schrieb: > Brauche ich wirklich einen Server, wie weiter oben gesagt wurde, sobald > ich irgendein Gerät per Ethernet-Schnittstelle ins Netz hängen > möchte....? Also muss in JEDEM GERÄT ein Serverblock sein ? Das wäre mir > neu..... In (Inter-)net sind nur Server für andere erreichbar. Genau das sagt das Wort "Server" aus. Server stellen einen Service bereit. Die anderen nennt man Clients. Clients sind nicht für andere erreichbar. Vielleicht stellst du dir unter Server ein großes komplexes Ding vor, aber das muss nicht sein. Server sind oft sogar einfacher zu programmieren, als die zugehörigen Clients.
Uli A. schrieb: > Brauche ich wirklich einen Server, wie weiter oben gesagt wurde, sobald > ich irgendein Gerät per Ethernet-Schnittstelle ins Netz hängen > möchte....? Also muss in JEDEM GERÄT ein Serverblock sein ? Das wäre mir > neu..... Was meinst Du mit Server genau? Wenn es um Netzwerkverbindungen geht, muss es immer eine Seite geben, die einen Verbindungswunsch äußert, und eine Seite, die empfangsbereit ist und die Verbindung annimmt. Das erste nennt man üblicherweise Client, das zweite Server. fchk
Uli A. schrieb: > Aber mal was ganz anderes: Was wäre denn Deine Lösung für mein Problem ? Hab ich geschrieben. Midi.
temp schrieb: > Uli A. schrieb: >> Aber mal was ganz anderes: Was wäre denn Deine Lösung für mein Problem ? > > Hab ich geschrieben. Midi. Kannst Du das denn auch etwas konkreter ausgestalten ? Ich weiß, Du bist ein Fan von Effizienz, aber ich bräuchte ggfs. ein paar "unnötige Sätze" mehr..... Ist nicht böse gemeint....! ;o) Das wäre dann doch im Grunde MIDI über USB, oder ? Das hilft mir zwar beim Anbinden z.B. der Remote oder des Hauptgerätes an einen Rechner, aber wie dann da die Idee einer variablen Verkoppelung ENTWEDER nur (lokal) zwischen Remote und Gerät ODER zwischen Hauptgerät und Rechner ODER sogar beides zusammen (z.B. Bedienung per Remote aber Speicherung der Daten im Rechner und bei Audio Playback auch wiederum Ansteuerung des Geräts und Update der Zustände auf der Remote) realisiert werden sollen, ist mir noch unklar...
Stefan ⛄ F. schrieb: > Vielleicht stellst du dir unter Server ein großes komplexes Ding vor, > aber das muss nicht sein. Server sind oft sogar einfacher zu > programmieren, als die zugehörigen Clients. Ja, das habe ich mir in der Tat so vorgestellt...sorry in die Runde für meine Unwissenheit....;-/ Frank K. schrieb: > Wenn es um Netzwerkverbindungen geht, muss es immer eine Seite geben, > die einen Verbindungswunsch äußert, und eine Seite, die empfangsbereit > ist und die Verbindung annimmt. Das erste nennt man üblicherweise > Client, das zweite Server. Aber das heißt dann, dass jeder PC/Mac grundsätzlich in einem Netzwerkverbund schon auch als Server fungiert, oder ? Bedeutet denn "Verbindungswunsch" auch automatisch was für die Richtung der Datenübertragung ? Also in meinem Projekt mit den drei Varianten a) Lokale Konfiguration nur mit zwei Geräten (Remote und Hauptgerät) b) PC als Ersatz für die Remote c) Hauptgerät wird sowohl von der Hardware-Remote als auch von einer wie auch immer gearteten virtuellen Remote auf dem Rechner gesteuert und informiert auch die Hardware Remote über Änderungen der Schaltzustände -> wie würde ich denn das am besten aufbauen, was die Einordnung in Server und Clients betrifft ?
Wäre eigentlich nicht auch USB-OTG eine Möglichkeit ? Bietet der F407 ja auch ....
Uli A. schrieb: > Kannst Du das denn auch etwas konkreter ausgestalten ? Du hast ja erst mal nur danach gefragt welcher Übertragungsstandard verwendet werden soll. Und da ist im Musikbereich die einfachste und universellste Schnittstelle nun mal Midi. Da geht es auch nicht um die Hardwareschnittstelle als solche (bei original Midi ist das uart über Stromschleife) sondern um die Softwareschicht. Also sowas wie: 0x91 0x95 0x127 (Note On) für Relais ein und 0x81 0x95 0x00 (Note Off) für Relais aus Wenn du im Sequenzer einfach eine Midi-Stpur für deine Relais anlegst, kannst du sie dann direkt von der Position im Song ansteuern. Ich denke in den letzten 40 Jahren wurde genügend Hardware produziert um alle erdenklichen Midi-Routings für ein paar wenige Euros zu realisieren. (Midi Merger u.s.w.) Wenn die Midi-Verkabelung nicht reicht kann als Brücke OSC (Udp) benutzt werden oder was selbst gestricktes mit einem Controller oder oder. Ausschlaggebend ist aber der einheitliche Transportstream den jedes musikalische Gerät versteht. Wenn du selbst basteln willst reicht ein STM32 Billigboard. Hier mal ein Softwarebeispiel: Beitrag "STM32 USB-MIDI"
Uli A. schrieb: > Frank K. schrieb: >> Wenn es um Netzwerkverbindungen geht, muss es immer eine Seite geben, >> die einen Verbindungswunsch äußert, und eine Seite, die empfangsbereit >> ist und die Verbindung annimmt. Das erste nennt man üblicherweise >> Client, das zweite Server. > > Aber das heißt dann, dass jeder PC/Mac grundsätzlich in einem > Netzwerkverbund schon auch als Server fungiert, oder ? Ja, beispielsweise Dateifreigabe: Jemand gibt auf seinem Rechner ein Verzeichnis frei, damit andere darauf zugreifen können. > > Bedeutet denn "Verbindungswunsch" auch automatisch was für die Richtung > der Datenübertragung ? Nein, das ist unabhängig. Bei der Dateifreigabe kannst Du vom freigegebenen Verzeichnis Dateien lesen und schreiben (solange der Freigeber Dir das erlaubt hat). > Also in meinem Projekt mit den drei Varianten > > a) Lokale Konfiguration nur mit zwei Geräten (Remote und Hauptgerät) > > b) PC als Ersatz für die Remote > > c) Hauptgerät wird sowohl von der Hardware-Remote als auch von einer wie > auch immer gearteten virtuellen Remote auf dem Rechner gesteuert und > informiert auch die Hardware Remote über Änderungen der Schaltzustände > > -> wie würde ich denn das am besten aufbauen, was die Einordnung in > Server und Clients betrifft ? Das Hauptgerät wäre der Server, der n verschiedene Clientverbindungen gleichzeitig handhaben müsste und sowohl Schaltbefehle als auch Zustandsabfragen entgegen nehmen würde. Beachte, dass die seriell-Ethernet-Wandler das nicht können. Die reichen nur jeweils EINE serielle Verbindung 1:1 an EINE Netzwerkverbindung durch. Da musst Du direkt den IP-Stack des STM32 nehmen und Clients und Server selber zu Fuß programmieren. Aber dafür brauchst Du noch VIEL mehr Know-How als Du jetzt hast. Versuche das erstmal auf einem PC oder Mac, denn da kannst Du besser debuggen. Wenn das da klappt, dann kannst Du über Mikrocontroller anfangen nachzudenken. fchk
temp schrieb: > Wenn du selbst basteln willst reicht ein STM32 Billigboard. Hier mal ein > Softwarebeispiel: > Beitrag "STM32 USB-MIDI" Danke für die Hinweise und das Beispiel - schaue ich mir an !
Danke Frank für die Erklärungen und Deine Einschätzung des für mich (ggfs. noch nicht) Machbaren ! So langsam kommt Licht ins Dunkel...;-) Frank K. schrieb: > Beachte, dass die seriell-Ethernet-Wandler das nicht können. Die reichen > nur jeweils EINE serielle Verbindung 1:1 an EINE Netzwerkverbindung > durch. Das heißt dann ja auch, dass diese Variante für die erweiterte (3-Geräte-) Konfiguratione ohnehin ausfällt - und für die lokale Lösung brauche ich ja wiederum kein Brimborium mit Netzwerk zu veranstalten - da tut's ja eh jede einfache serielle Schnittstelle... Wenn ich mich da aber doch einarbeiten will, ist also IP Stack Programmierung das Stichwort, richtig ? Wie gesagt ist es nicht leicht, da einen roten Faden zu finden, wie ich das lerntechnisch am besten angehe...
lerntechnisch fängt man mit den Grundlagen an, z.B. http://www.netzmafia.de/skripten/index.html Mindestens die ersten drei Skripte unter 'Datenkommunikation, Netze'. Es gibt tausend tolle Möglichkeiten, bringen aber alle nix wenn man nicht anfängt.
Uli A. schrieb: > Remoteunit mit STM32MCU (vermutlich F407VG) mit 54 beleuchteten > LED-Tastern. Ich gehe mal nicht darauf ein wie du 54 Tasten abfragst bzw. die LEDs ansteuerst. Wenn du hier Midi als Softwareschicht verwendest, bedeutet das jede der 54 Tasten sendet einen Note On/Note Off Befehl bei Tastendruck. Je nach Wunsch beim Drücken NoteOn beim Loslassen NoteOff oder (als Schalter) einmal drücken NoteOn nochmal drücken NoteOff. Die Leds werden auch direkt über NoteOn/NoteOff Befehle ein- bzw. ausgeschaltet. Über einen Standard Midi LocalOn/LocalOff Befehl kannst du steuern ob die Tasten die Led's direkt steuern oder ob das z.B. der Sequenzer macht. Mit anderen Worten, du hast jetzt einen ganz normalen Midi-Controller wie es ihn früher mal zu kaufen gab. Ich sage deshalb früher, weil die heutigen Controller meistens nur noch USB können intern aber auch Midi sprechen. Das Teil verhält sich mehr oder weniger wie ein Keyboard. Im Sequenzer kannst du deine Tastendrücke/Schalterstellungen aufnehmen und bei Bedarf wieder abspielen. Das wäre damit ein völlig eigenständiges Gerät mit Midi-Ein/Ausgang. Und ja, im ersten Schritt würde ich da auch bei physikalisch Midi bleiben. Mehr geht immer, aber das Protokoll bleibt gleich. Das zweite Gerät ist die Relaisbaugruppe. Die braucht theoretisch nur Midi-In und reagiert nur auf die Befehle aus dem Sequenzer oder deinem Controller. Ein zusätzlicher Midi-Merger würde es ermöglichen, das ganze von beliebig vielen Controllern/Sequenzern anzusteuern. Dafür musst du auch nicht alles neu erfinden, solche Aufgaben sind Standard. Heutige µCs haben aber sowieso auch mehrere UARTs so dass der diese simple Aufgabe mit übernehmen kann. Die Midi-Verkabelung würde ich über CAT5-Kabel machen, damit ist der Weg für zwischengeschaltete Midi/Osc-Wandler und Transport über Ethernet frei. Durch so ein modulares Konzept mit Standardschnittstellen kannst du das in jedem Studio dieser Welt einsetzen. Deinen LED/Tasten Controller kannst du dann auch prima verkaufen. So was mit direkt Midi oder OSC gibt es aktuell nur wenig zu kaufen. Hier im Forum haben schon Leute angefragt wie sie in eigene Projekte solche Controller einbinden können. Das läuft dann in der Regel auf einen Raspi oder ähnliches hinaus. Nicht zu vergessen die leichte Testbarkeit. Mit jedem billigen Master- oder Spielzeugkeybord kannst du deine Baugruppen testen. Solltest du in der Folge mehr Intelligenz brauchen, dann würde ich das in eine weitere Baugruppe verlagern. Meinetwegen STM32 mit mehreren Midi-In/Out. Oder sowas wie Midibox wenn du dich richtig ausferkeln willst. http://www.ucapps.de/ Aber egal was du machst, mit so einem Weg bleibst du bei den Standards. Das wird ein selbstgestricktes Modbus/Ethernet/MQTT Protokoll niemals hergeben.
Johannes S. schrieb: > lerntechnisch fängt man mit den Grundlagen an, z.B. > http://www.netzmafia.de/skripten/index.html > Mindestens die ersten drei Skripte unter 'Datenkommunikation, Netze'. > Es gibt tausend tolle Möglichkeiten, bringen aber alle nix wenn man > nicht anfängt. Danke für den Link zu netzmafia !
Danke "temp" für die ausführliche Erklärung ! Das klingt recht sinnvoll... temp schrieb: > Die Midi-Verkabelung würde ich über CAT5-Kabel machen, damit ist der Weg > für zwischengeschaltete Midi/Osc-Wandler und Transport über Ethernet > frei. Kannst Du mir das nochmal genauer erklären ? Also das mit der Verkabelung an sich verstehe ich natürlich, aber was sind das für zwischengeschaltete Wandler ? Hardware- oder softwareseitige ? Und was meinst Du genau mit "Transport über Ethernet" ?
temp schrieb: > Wenn du hier Midi als Softwareschicht verwendest Kannst Du (oder sonst wer) mir sagen, wo ich Ressourcen zu dem Thema finde, also Programmierung von MIDI in C ? Also etwas eingängiger als die MIDI-Spezifikation durchzulesen ? ;-) Ich habe das Buch "Musik mit dem Arduino und MIDI" von Wronka/Naumann, das geht schon sehr in die Richtung und enthält für den Ansatz schon viel Wissenswertes. Allerdings eben für Arduino mit den entsprechenden Libraries für die Arduino IDE...weißt Du zufällig, wo ich ggfs. entsprechende MIDI-Command-Libraries für STM32 finde ? Wenn ich das richtig verstehe, würde ich ja dann hardwareseitig die MIDI-Ports an als UART konfigurierte GPIOs des STM32 anschließen, oder ?
Uli A. schrieb: > Aber das heißt dann, dass jeder PC/Mac grundsätzlich in einem > Netzwerkverbund schon auch als Server fungiert, oder ? Nur die, die irgendwelche Dienste anbieten. Was normalerweise* nicht der Fall ist. Aber wenn du z.B. Skype startest, dann kann man dich anrufen. Dann bietest du einen Skype-Anruf-Service an. *) Ich vermute mal, dass jeder Windows Rechner irgendwelche verborgenen Server-Dienste laufen hat, von denen ich nichts weiß. Bei Windows 8 ist mir z.B. mal aufgefallen, dass Windows immer einen leeren Webserver mit laufen hatte. Das soll aber eigentlich nicht sein. > Bedeutet denn "Verbindungswunsch" auch automatisch > was für die Richtung der Datenübertragung ? Fast alle Services kommunizieren bidirektional. Der Client sende eine Anforderung an den Server (z.B. eine URL) und der Server beantwortet diese Anforderung (z.B. eine Webseite). > wie würde ich denn das am besten aufbauen, was die Einordnung > in Server und Clients betrifft? Hatte ich schon geschrieben: Der Server bietet einen Dienst an, den der Client aufruft. Der Server ist derjenige, der ständig auf Anfragen lauscht und bereit sein muss, schnell zu antworten. Der Client ist derjenige, der vom Server etwas anfordert. Wenn ein Temperatursensor einen Messwert an eine Datenbank sendet, dann ist die Datenbank der Server und der Sensor ist der Client. Denn der Sensor initiiert den Verbindungsaufbau (Timer-gesteuert) und befiehlt der Datenbank "bitte speichere dies und das ab".
Ich gebe dir noch ein Beispiel: Drucker mit WLAN. Wenn du ein Dokument druckst, dann ist der Drucker der Server und dein PC ist der Client. Weil Drucker derjenige ist, der den Druck-Service bereit stellt und auf Anfragen des PC wartet.
Uli A. schrieb: > Wäre eigentlich nicht auch USB-OTG eine Möglichkeit ? > Bietet der F407 ja auch .... Ja aber nicht für dich, da noch sehr viel komplexer, als Ethernet. Ich halte mich davon fern.
Uli A. schrieb: > Frank K. schrieb: >> Beachte, dass die seriell-Ethernet-Wandler das nicht können. Die reichen >> nur jeweils EINE serielle Verbindung 1:1 an EINE Netzwerkverbindung >> durch. > > Das heißt dann ja auch, dass diese Variante für die erweiterte > (3-Geräte-) Konfiguratione ohnehin ausfällt - und für die lokale Lösung > brauche ich ja wiederum kein Brimborium mit Netzwerk zu veranstalten - > da tut's ja eh jede einfache serielle Schnittstelle... Ausweg: https://www.wiznet.io/product-item/wiz120sr/ Der hat zwei serielle Schnittstellen und unterstützt damit zwei Verbindungen. Das wäre der Trick. Dein STM32 müsste dann gleichzeitig beide seriellen Ports bedienen. > Wenn ich mich da aber doch einarbeiten will, ist also IP Stack > Programmierung das Stichwort, richtig ? Ja. Stichwort Berkeley Sockets. > Wie gesagt ist es nicht leicht, da einen roten Faden zu finden, wie ich > das lerntechnisch am besten angehe... fchk
Uli A. schrieb: > weißt Du zufällig, wo ich ggfs. entsprechende > MIDI-Command-Libraries für STM32 finde ? Man braucht doch keine Library, um eine Hand voll Bytes zu senden!
Uli A. schrieb: > weißt Du zufällig, wo ich ggfs. entsprechende MIDI-Command-Libraries für > STM32 finde ? Oder darf es gleich eine fertige App sein? Ich lese nur Fragen über Fragen, hast du überhaupt schon mal eine Zeile eigenen Code geschrieben?
Uli A. schrieb: > Kannst Du (oder sonst wer) mir sagen, wo ich Ressourcen zu dem Thema > finde, also Programmierung von MIDI in C ? Also etwas eingängiger als > die MIDI-Spezifikation durchzulesen ? ;-) Also wenn du dich im Pro Audio Umfeld bewegst und nicht mal Midi verstanden hast, dann kann dir hier keiner mehr helfen. Das ist eines der simpelsten Protokolle überhaupt. Die komplexeren Dinge darin wie Sysex u.s.w kannst du ja erst mal links liegen lassen. Aber wenn du die Bytes für NoteOn/Off, Program Change und Control Change nicht im Schlaf, 3.8 auf dem Kessel und Vollmond nicht aufsagen kannst, dann wird das in diesem Leben nichts mehr. Hier greift wieder mein alter Spruch: "je weniger man weiß, desto weniger weiß man dass man nichts weiß".
Also echt, Leute....kommt mal wieder runter... Ich bin mir meiner Wissenslücken durchaus bewusst aber deshalb noch lange kein Idiot ! Und ich bin seit 25 Jahren Pro Audio User(!) und habe diverse Tonstudios gehabt, gebaut und eingerichtet, was aber nicht heißt, dass ich deshalb selbst auch nur ein Byte MIDI Code gesendet haben muss.... Ich habe auch mehrfach erwähnt, was ich schon gemacht habe - eben ein bisschen Arduino und STM32 Registerprogrammierung - da aber bisher nur GPIO-bezogen. Wem ich deshalb "zu inkompetent" erscheine, der muss sich auf mein Niveau ja nicht herablassen und kann einfach schweigen, oder ? Danke dennoch allen, die sich "mir erbarmen"....;-)
Uli A. schrieb: > Und ich bin seit 25 Jahren Pro Audio User(!) und habe diverse Tonstudios > gehabt, gebaut und eingerichtet, was aber nicht heißt, dass ich deshalb > selbst auch nur ein Byte MIDI Code gesendet haben muss.... Brauchst du ja auch nicht. Aber eine Sequenzer mit Midi-Spuren wirst du doch schon bedient haben? Und da stehen die Bytes fast 1zu1 drin. https://de.wikipedia.org/wiki/Musical_Instrument_Digital_Interface Da steht die Tabelle drin. Oder mal ein kurzes Beispiel. Wenn der Sequenzer eine Note am Synt spielen soll, sendet er
1 | 0x91 0x45 0x7f aus der Midibuchse raus |
2 | | | | |
3 | | | Anschalgstärte |
4 | | Note |
5 | NoteOn Kanal 1 bzw. 2 je nach Zählart |
6 | |
7 | Beim Beenden des Tons: |
8 | |
9 | 0x81 0x45 0x00 |
10 | | | | |
11 | | | |
12 | | Note |
13 | NoteOff Kanal 1 bzw. 2 je nach Zählart |
Jetzt kannst du schon anfange zu basteln. Nimm einen Arduino 2 Widerstände und eine Din-Buchse und verbinde das mit einem beliebigen Tonerzeuger in deinem Studio. https://www.arduino.cc/en/Tutorial/BuiltInExamples/Midi Dann Initialisierst du eine serielle Schnittstelle und schickst einfach die o.g. Bytes raus. Wenn du das hingekriegt hast, können wir weiter reden.
Ja, ich denke das kriege ich gerade so hin....;-) Und ja, ich benutze seit 1992 Sequenzersoftware.. Weswegen ich so blöd gefragt habe, war, dass ich nicht wusste, ob bei der Midi-Übertragung auch eine Form von Header o.ä. mit übertragen werden muss.....wenn man einfach nur die drei Bytes mit den entsprechenden Daten rüberschicken muss, ist das natürlich einfach.... Danke nochmal für die Anleitung. Nur eine kleine Randnotiz zu Deiner Idee, das mit Note On/ Not Off zu machen.....keine gute Idee...wenn dann nämlich beim Sprung an eine andere Stelle im Song andere Schaltzustände von der Automation wiedergegeben werden weil man beim Aufnehmen einen Taster gedrückt hat, kriegt man ein heilloses Durcheinander mit falschen Daten / Zuständen - mit das älteste MIDI-Problem der Welt.... Daher wäre es deutlich besser, statt der Notenbefehle Continuous-Controllerdaten mit den Werten 0 und 127 zu verwenden. Die werden dann auch beim Start "mittendrin" von der DAW immer aktualisiert ausgegeben...
:
Bearbeitet durch User
temp schrieb: > Nimm einen Arduino 2 > Widerstände und eine Din-Buchse Wenn ich das Ganze mit einem STM32 und dementsprechend unter 3.3V mache, kann ich dann die beiden 220Ω Widerstände einfach für den gleichen Strom analog zu 147Ω umrechnen ? Oder klappt das so nicht ? Und funktioniert das mit dem STM32 auch mit nem 6N138 Optokoppler (für MIDI IN)? Und noch was ganz anderes an die STM32-Cracks: Sehe ich das richtig, dass ich die 31,25 kHz für die MIDI-Schnittstelle in dem jeweiligen UART als asynchronous einrichten muss und dann von Hand die 31,25 kHz als Baud Rate ? Hat diese Übertragungsrate was mit der 32kHz LSI-RTC zu tun oder wird die davon unabhängig einfach nur beim UART konfiguriert ?
:
Bearbeitet durch User
Uli A. schrieb: > Und funktioniert das mit dem STM32 auch mit nem 6N138 Optokoppler (für > MIDI IN)? Ja. Uli A. schrieb: > Sehe ich das richtig, dass ich die 31,25 kHz für die MIDI-Schnittstelle > in dem jeweiligen UART als asynchronous einrichten muss und dann von > Hand die 31,25 kHz als Baud Rate ? Ja. Uli A. schrieb: > Hat diese Übertragungsrate was mit > der 32kHz LSI-RTC zu tun Nein. Uli A. schrieb: > oder wird die davon unabhängig einfach nur beim > UART konfiguriert ? Ja.
Uli A. schrieb: > Daher wäre es deutlich besser, statt der Notenbefehle > Continuous-Controllerdaten mit den Werten 0 und 127 zu verwenden. Die > werden dann auch beim Start "mittendrin" von der DAW immer aktualisiert > ausgegeben... Super, das hast du gut erkannt. Allerdings konnte ich bisher nicht ahnen auf welchem Niveau wir uns unterhalten, da es oben im Thread ziemlich durcheinander ging. Wenn du es selbst baust, kannst du das machen wie du willst. Ein Program Change könnte aber auch gehen. Das darf ein guter Sequenzer auch nicht überspringen beim ändern der Position. Man kann sich hier viel ausdenken, und bleibt trotzdem im gewohntem und standardisiertem Umfeld. Uli A. schrieb: > Wenn ich das Ganze mit einem STM32 und dementsprechend unter 3.3V mache, > kann ich dann die beiden 220Ω Widerstände einfach für den gleichen Strom > analog zu 147Ω umrechnen ? Oder klappt das so nicht ? > > Und funktioniert das mit dem STM32 auch mit nem 6N138 Optokoppler (für > MIDI IN)? Man kann den UART-Ausgang auch als OpenDrain konfigurieren, dann kann das ganze auch gegen 5V arbeiten.
https://www.st.com/en/evaluation-tools/nucleo-f429zi.html hat STM32F4 und Ethernet, wie gewünscht STM32CubeIDE installieren, aus dem Repository das Beispielprojekt: Repository\STM32Cube_FW_F4_V1.26.0\Projects\STM32F429ZI-Nucleo\Applicati ons\LwIP durcharbeiten und verstehen. Hardware ist billig und fast fertig zu kaufen. Firmware erfordert einige an Eigenleistung.
Okay. Kurzes Zwischenfazit: Ich bin nun ziemlich sicher, dass generell der MIDI Weg für mich der Richtige ist - und sozusagen auch "Genre-konform". Und das Ganze Netzwerkding ist für mich zu komplex um es in absehbarer Zeit zu lernen. Damit lassen sich auch alle von mir angedachten Konfigurationen gut umsetzen, und die Anbindung an eine DAW-Software oder an entsprechende dortige Steuer-Plugins wäre auch gut machbar. Wenn ich nun mittelfristig einen Schritt weiter gehen möchte und statt mit dem DIN-MIDI mit MIDI über USB arbeiten will, brauche ich dafür dann einen STM32 mit der Möglichkeit von USB-OTG oder kann ich das trotzdem über einen USART konfigurieren ? Was wäre hardwareseitig einfacher, was programmierseitig ? Gerade in der erweiterten Konfiguration von gleichzeitiger Nutzung von Hardware-Remote und PC-basierender Steuerung wäre das (die Kombination von USB-MIDI und "einfachem MIDI") die schickste Lösung... Es gäbe dann eine sozusagen bidirektionale USB-MIDI-Verbindung zwischen PC und Remote und eine simple MIDI-Verbindung von der Remote zum Hauptgerät. Tasterbedienungen auf der Remote würden dann sowohl zum PC gesendet als auch zum HG, beim Playback der Sequenzersoftware oder beim Bedienen durch eine Software-Remote würden dann die Schaltimpulse bzw. deren Aktualisierung quasi die Remote ersetzen und diese wie gehabt die eigentlichen Schaltzustände dem HG mitteilen... Für die einfachen Konfigurationen a) Rein lokal Remote -> Hauotgerät b) Wie a), aber PC ersetzt die Remote wäre eine einfache unidirektionale (DIN)MIDI-Verbindung ohnehin völlig ausreichend...
Uli A. schrieb: > Wenn ich nun mittelfristig einen Schritt weiter gehen möchte und statt > mit dem DIN-MIDI mit MIDI über USB arbeiten will, brauche ich dafür dann > einen STM32 mit der Möglichkeit von USB-OTG oder kann ich das trotzdem > über einen USART konfigurieren ? Was wäre hardwareseitig einfacher, was > programmierseitig ? Es muss jetzt nicht unbedingt ein STM32 sein, aber um die USB-OTG Schnittstelle kommst du nicht herum. Es gibt Adapter von MIDI (seriell) nach USB-Host: https://www.amazon.de/CAMOLA-MIDI-Host-Interface-Converter/dp/B08MZY59B7/ref=asc_df_B08MZY59B7 (man beachte den Preis) Da der Titel des Threads nicht mehr so Rechts pass würde ich dir empfehlen, weitere Fragen in einem neuen Thread zu diskutieren. Damit schüttelst du alle ab, die noch bei Ethernet hängen geblieben sind (ist nicht böse gemeint).
temp schrieb: > Super, das hast du gut erkannt. Allerdings konnte ich bisher nicht ahnen > auf welchem Niveau wir uns unterhalten, da es oben im Thread ziemlich > durcheinander ging. Wenn du es selbst baust, kannst du das machen wie du > willst. Ein Program Change könnte aber auch gehen. Das darf ein guter > Sequenzer auch nicht überspringen beim ändern der Position. Man kann > sich hier viel ausdenken, und bleibt trotzdem im gewohntem und > standardisiertem Umfeld. Tatsächlich scheint mir die CC-Variante am sinnvollsten, nach weiterem Nachdenken sogar mit vier Werten pro Schaltblock für ein Audiogerät, der jeweils aus drei sich "gegenseitig auslösenden" Tastern besteht. Z.B. CC = 0 : kein Schaltzustand aktiviert CC = 42 : Schalter A aktiv CC = 84 : Schalter B aktiv CC = 126 : Schalter C aktiv o.ä. Programm Change bräuchte ich aber ggfs. für Presets.....;-)
Stefan ⛄ F. schrieb: > Da der Titel des Threads nicht mehr so Rechts pass Sorry, das sieht ja aus als sei ein Nazi. Es sollte heißen: > Da der Titel des Threads nicht mehr so recht passt
Uli A. schrieb: > Wenn ich nun mittelfristig einen Schritt weiter gehen möchte und statt > mit dem DIN-MIDI mit MIDI über USB arbeiten will, brauche ich dafür dann > einen STM32 mit der Möglichkeit von USB-OTG oder kann ich das trotzdem > über einen USART konfigurieren ? Was wäre hardwareseitig einfacher, was > programmierseitig ? USB ist meines Erachtens nur dazu geeignet aus dem Rechner zu kommen und nicht für lange Leitungswege. Gerade im Studioumfeld fehlt die galvanische Trennung die es bei Midi bzw. Ethernet zwangsläufig gibt. Solche USB-Midi Adapter sind aber so billig, da lohnt sich der Aufwand kaum es selbst zu bauen. Der STM kann auch als USBMid-Interface arbeiten einen Link hatte ich schon hier eingestellt. Dann ist der STM das Device. Was ziemlich aussichtslos ist einen STM32 egal welcher Art als USB-Host für die gefühlt 100tausend verschiedenen Controller zu verwenden die der Thomann Katalog hergibt und die nur USB können. Ausgenommen die paar wenigen die USB Class Conform Midi verwenden haben die meisten propriotäre Treiber die nur auf Windows, MAC, und manchmal auch unter Linux laufen. Für das Midi-Routing über LAN gibt es rtpMidi, das können Apple Geräte von Haus aus: https://www.tobias-erichsen.de/software/rtpmidi.html https://www.bonedo.de/artikel/einzelansicht/bome-bomebox-universal-ethernet-midi-usb-wifi-hub-ab-sofort-verfuegbar.html https://www.midi.org/midi-articles/rtp-midi-or-midi-over-networks https://en.wikipedia.org/wiki/RTP-MIDI So jetzt hast du Ostern was zum Lesen... Ich denke für alle denkbaren Konstellationen für Midi-over-Lan gibt es bereits Lösungen.
ja, man kann sich auch einreden lassen das Ethernet fürchterlich kompliziert ist. Der F407 kann alles, Ethernet und USB und seriell gleichzeitig. Mit Mbed leider einfach nur USB device, aber eine USBMidi Klasse die Controller oder Note messages liefert/sendet ist auch vorhanden. https://os.mbed.com/docs/mbed-os/v6.9/apis/usbmidi.html Wenn das Board keinen Phy hat, der kostet ca. 5€ und wird mit 11 Kabeln angeschlossen. Einfacher für den Anfang sind natürlich die Nucleos die das gleich on Board haben. UDP Beispiel hatte ich ja schon genannt, ist aber auch in der Doku zu finden: https://os.mbed.com/docs/mbed-os/v6.9/apis/udpsocket.html UDP ist für den Anfang einfacher, da kann man auch einfach die MIDI messages versenden, das werden die Gateways auch nicht anders machen.
Stefan ⛄ F. schrieb: > Es gibt Adapter von MIDI (seriell) nach USB-Host: > https://www.amazon.de/CAMOLA-MIDI-Host-Interface-Converter/dp/B08MZY59B7/ref=asc_df_B08MZY59B7 > (man beachte den Preis) Hier gilt auch das von mir gesagte. Solange die USB Geräte die angeschlossen werden sollen Class Compilant sind geht das. Alle anderen die eigene Treiber auf dem Host brauchen sind damit außen vor. Und das sind nicht wenige.
Johannes S. schrieb: > ja, man kann sich auch einreden lassen das Ethernet fürchterlich > kompliziert ist. Der F407 kann alles, Ethernet und USB und seriell > gleichzeitig. Mit Mbed leider einfach nur USB device, aber eine USBMidi > Klasse die Controller oder Note messages liefert/sendet ist auch > vorhanden. Du kannst es lassen, es geht mittlerweile nicht mehr um Ethernet. Nicht wegen leicht oder schwer sondern wegen grundlegenden Überlegungen. Was der F407 alles kann ist das eine, was der mbed oder arduino User kann das andere. Fakt bleibt aber, als Protokoll bleibt Midi für den Zweck die fast einzige Alternative. Wenn du anderer Meinung bist, dann erklär mal wie du dir die Kommunikation eines Sequenzers aus der Profiliga mit deinem Ethernetcode auf dem 407 vorstellst.
Der TO wollte keinen Sequenzer der Profiliga bauen, sondern zwei Controller per Ethernet verbinden, Remote und Controller in seinem 'Mainframe'. Zusätzlich sollte der Controller im Mainframe jetzt per Midi gesteuert werden können. Korrigiert mich wenn ich das falsch verstanden habe. Und für die Fernsteuerung Remote-Cotroller im Mainframe ist man damit wahlfrei was beim Senden einer Taste passiert oder man sendet da auch eine MIDI Message um die Auswertung beim Empfanger gleich zu halten. Und ob die Daten jetzt per Ethernet oder USBMidi oder seriell reinkommen sollte doch wohl Jacke wie Hose sein.
Johannes S. schrieb: > Der TO wollte keinen Sequenzer der Profiliga bauen nein aber benutzen. Er will seine Hardware syncron zum Projekt im Sequenzer steuern und auch alternativ über die Bedieneinheit. Und bei so einem Vorhaben muss man sich schon an die Standards im Studio halten.
Ja, deshalb per USB MIDI an den Steuer PC. Und die 54 externen Tasten können über Ethernet angebunden werden, das war aus dem ursprünglichen Konzept noch übrig. Und diese Tasten können auch MIDI Befehle senden wenn man will.
temp schrieb: > Stefan ⛄ F. schrieb: >> Es gibt Adapter von MIDI (seriell) nach USB-Host: >> > https://www.amazon.de/CAMOLA-MIDI-Host-Interface-Converter/dp/B08MZY59B7/ref=asc_df_B08MZY59B7 >> (man beachte den Preis) > > Hier gilt auch das von mir gesagte. Solange die USB Geräte die > angeschlossen werden sollen Class Compilant sind geht das. Alle anderen > die eigene Treiber auf dem Host brauchen sind damit außen vor. Und das > sind nicht wenige. Hm. Danke für den Hinweis. Das ist aber hier nicht das richtige Gerät - so eine Art Host braucht man für die direkte Verkopplung (ohne PC!) zweier autarker MIDI Geräte, wovon das eine nur DIN-MIDI und das andere nur USB kann.... In meinem Fall wäre nur der PC (automatisch) USB-Host, die Remote wäre USB Peripheral Node Endpoint / Device....wie auch immer man das nennen möchte....da braucht man keinen externen USB-Host mehr sondern wenn überhaupt ein normales USB-MIDI-Interface, wenn ich USB nicht in bzw. von der Remote selbst zur Verfügung stellen möchte sondern meine beiden Geräte (Remote & Hauptgerät) nur DIN-MIDI können sollen...
temp schrieb: > Johannes S. schrieb: >> Der TO wollte keinen Sequenzer der Profiliga bauen > > nein aber benutzen. Er will seine Hardware syncron zum Projekt im > Sequenzer steuern und auch alternativ über die Bedieneinheit. Und bei so > einem Vorhaben muss man sich schon an die Standards im Studio halten. Ja, so ist das...
temp schrieb: > USB ist meines Erachtens nur dazu geeignet aus dem Rechner zu kommen und > nicht für lange Leitungswege. Ja, das stimmt zwar im Grundsatz, aber de facto hat man im Studio eigentlich auch überall USB Hubs (natürlich entsprechend hochwertige und extern bestromte) rumliegen, besonders zentral am Arbeitsplatz....von da aus ist der Weg zu einer Remote, die als eines der Haupt-Bedienelemente fungiert, ja auch nur kurz. temp schrieb: > Solche USB-Midi Adapter sind aber so billig, da lohnt sich der Aufwand > kaum es selbst zu bauen. Ja, das stimmt. Es ist nur mittlerweile (ob zum guten oder schlechten) sehr üblich, dass quasi jedes MIDI-Gerät auch USB hat...ist schlicht bisschen geschmeidiger, statt der Gurkerei mit zwei MIDI-Kabeln plus Interface einfach nur ne USB-Leitung zu haben. Das mit der galvanischen Trennung ist natürlich ein bedenkenswerter Aspekt. temp schrieb: > Was ziemlich aussichtslos ist einen STM32 egal welcher Art als USB-Host > für die gefühlt 100tausend verschiedenen Controller zu verwenden die der > Thomann Katalog hergibt und die nur USB können. Das ist ja auch gar nicht angestrebt....wie gesagt, in jedem Fall ist nur der PC der Host, für die beiden 2-Geräte-Konfigurationen Remote->Mainframe und PC->Mainframe wird eh nur MIDI in einer Richtung verwendet ======> der Mainframe ist IMMER nur Empfänger der Steuerdaten... temp schrieb: > Für das Midi-Routing über LAN gibt es rtpMidi, das können Apple Geräte > von Haus aus: Ja, da hatte ich gar nicht dran gedacht, ist mir aber bekannt....benutze ich auch zwischen mehreren Macs...
Johannes S. schrieb: > Ja, deshalb per USB MIDI an den Steuer PC. Und die 54 externen Tasten > können über Ethernet angebunden werden, das war aus dem ursprünglichen > Konzept noch übrig. Und diese Tasten können auch MIDI Befehle senden > wenn man will. Das habe ich leider gar nicht verstanden....könntest Du das nochmal aufdröseln, was Du damit meinst ? Also wie die Konfiguration dann genau aussehen würde ? Was wird da per USB MIDI an den PC angebunden ?
Uli A. schrieb: > https://www.amazon.de/CAMOLA-MIDI-Host-Interface-Converter/dp/B08MZY59B7/ref=asc_df_B08MZY59B7 > Das ist aber hier nicht das richtige Gerät - > so eine Art Host braucht man für die direkte Verkopplung (ohne PC!) Ja, genau dafür galt mein Vorschlag. Ich dachte dabei gar nicht an den PC, sondern an dein Mikrocontroller Board mit UART bzw. Midi Buchsen. >Falls du da doch mal ein gerät anschließen musst, dass unbedingt einen USB Host erfordert, dann wäre das womöglich eine Option.
Uli A. schrieb: > Das habe ich leider gar nicht verstanden....könntest Du das nochmal > aufdröseln, was Du damit meinst ? Also wie die Konfiguration dann genau > aussehen würde ? Was wird da per USB MIDI an den PC angebunden ? Wie ich es verstanden habe sollte nach Vorschlag von temp ja Standard MIDI für die Steuerung des 'Mainframe' benutzt werden damit die Befehle z.B. von einem Sequencer Taktsynchron an den Controller im Mainframe gesendet werden. Der Sequencer (PC?) kann dann per USB mit dem Controller verbunden werden, der Controller ist dann ein USB Device das sich als USB-Midi Gerät anmeldet. Das wäre ein Weg um Funktionen im Mainframe Controller auszulösen, welche MIDI Befehle man da geschickterweise nimmt, das weiss ich nicht. Meine MIDI Erfahrung beschränkt sich bisher auf das Zocken des legendären MIDI-Maze auf dem ebenso legendären Atari ST :) Zum Testen von USB auf einem H743 hatte ich aber das USBMidi von Mbed benutzt und das Senden von Noten an den PC war einfach, das Beispiel in der Doku funktioniert. Der µC meldet sich als 'Mbed Audio' Gerät am PC an und als Testprogramm habe ich den MidiPlayer5 (Empfehlung hier aus dem Forum) benutzt. Gibbet hier: http://falcosoft.hu/softwares.html Jetzt habe ich noch die andere Richtung probiert, das Empfangen von MIDI Messages per USB. In einer loop mit polling funktionierte das auch: in dem MidiPlayer Setup kann man das Midi Gerät für in/out getrennt auswählen. Ich habe aber festgestellt das der Player beim Start den µC mit Messages zuballert und die testweisen printf() nicht hinterher kamen. Dann habe ich das auf Eventhandling mit Pufferung umgebaut. Das war auch etwas tricky weil die Mailbox vom OS keine Objekte mag, das MidiMessage Objekt im Konstruktor aber einen 256 Byte Puffer auf dem Heap anlegt. Nachdem ich den testweise als festes Array angelegt hatte, da funktionierte es. Der Midi Player feuert beim Start 171 Messages und wenn man die Mailbox groß genug macht, dann werden die auch alle gepuffert. So ein echter MidiController muss also schon reichlich Power haben. Für eine Anwendung, die nur auf bestimmte Befehle reagieren soll ist das entspannter, man muss ja nicht alles puffern und kann beim Empfang im Interruptkontext schon filtern. Getetst habe ich es jetzt auf einem F746, es wird aber auch auf einem F407 laufen. Teil der Ausgabe wenn ich den MidiPlayer starte und ein paar Noten spiele:
1 | #66 received ControlChangeType: value 2 |
2 | #67 received ControlChangeType: value 40 |
3 | #68 received other: type 5 |
4 | #69 received other: type 7 |
5 | #70 received other: type 6 |
6 | #71 received ControlChangeType: value 127 |
7 | #72 received other: type 9 |
8 | #73 received other: type 8 |
9 | #74 received other: type 5 |
10 | #75 received other: type 5 |
11 | #76 received ControlChangeType: value 0 |
12 | #77 received other: type 5 |
13 | #78 received ControlChangeType: value 40 |
14 | #79 received other: type 5 |
15 | #80 received other: type 5 |
16 | #81 received other: type 5 |
17 | #82 received ControlChangeType: value 127 |
18 | #83 received other: type 5 |
19 | #84 received ControlChangeType: value 40 |
20 | #85 received other: type 6 |
21 | #86 received other: type 5 |
22 | #87 dropped: 91 received NoteOn: key 64 |
23 | #88 received NoteOff: key 64 |
24 | #89 dropped: 91 received NoteOn: key 79 |
25 | #90 received NoteOff: key 79 |
26 | #91 dropped: 91 received NoteOn: key 91 |
27 | #92 received NoteOff: key 91 |
28 | #93 dropped: 91 received NoteOn: key 28 |
29 | #94 received NoteOff: key 28 |
30 | #95 dropped: 91 received NoteOn: key 43 |
31 | #96 received NoteOff: key 43 |
32 | #97 dropped: 91 received NoteOn: key 76 |
33 | #98 received NoteOff: key 76 |
34 | #99 dropped: 91 received NoteOn: key 83 |
35 | #100 received NoteOff: key 83 |
In der 'NoteOn' Ausgabe ist noch die Anzahl der verpassten Messages drin wenn die ISR die Daten nicht in die Queue schreiben kann. Der MidiPlayer kann übrigens auch per Netzwerk senden, ich weiß nicht ob die da einen Standard benutzen oder einfach die Messages in UDP verpacken. Das war mein Vorschlag um das gleiche Gerät auch per Ethernet bedienbar zu machen. In dem Fall den MIDI und den UDP Receiver jeweils in einen eigenen Thread packen, fertich.
Wow. Vielen Dank Johannes für Deine Bemühungen beim Ausprobieren...!!!! Werde das die nächsten Tage auch mal testen...! Kurz ne Nebenfrage: Johannes S. schrieb: > Zum Testen von USB auf einem H743 hatte ich aber das USBMidi von Mbed > benutzt Was meinst Du mit "von Mbed" ? Mbed als IDE-Plattform ? Und wenn ja, wie findest Du Mbed Studio im direkten Vergleich zu CubeIDE und was waren ggfs. Deine Gründe Mbed vorzuziehen ?
Uli A. schrieb: > Was meinst Du mit "von Mbed" ? Mbed ist ein Open Source Projekt von ARM, https://os.mbed.com/docs/mbed-os/v6.9/introduction/index.html Es ist ein OS für Cortex-M mit einem mittlerweile recht umfangreichen API für Standard IO wie GPIO, Serial, I2C, SPI und komplexere Sachen wie USB, Ethernet, Dateisysteme uvm. Und ein RTOS (RTX5 von Keil/ARM) und die Komponenten passen auch zusammen. Das alles mit einem C++ API. C++ Komponenten gefallen mir besser um eigene Bibliotheken zu bauen als alles einem Codegenerator zu überlassen. CubeMX funktioniert zwar mittlerweile recht gut, aber der Arbeitsablauf ist einfach Kacke. Meine Meinung. Ich beschäfftige mich mit Mbed schon recht lange, vor ein paar Jahren hat ARM da ein gutes Team aufgestellt das dann das bisherige mbed2 kräftig überarbeitet und auf einen professionellen Level gehievt hat. Die Cortex-M habe ich mit dem LPCXpresso und LPC1769 erarbeitet, aber diese IDE hat wie die CubeIDE eben die Bindung an NXP oder STM. Mittlerweile hat ST ja ein Riesenprogramm und auch viel zu Mbed beigetragen, aber die kleinen LPC8xx mag ich immer noch und die kann man auch noch mit Mbed6 benutzen. Mittlerweile gibt es auch ein Mbed Studio das die Benutzung vereinfacht, ich habe mir aber vorher schon ein System mit VSCode zusammengebaut. Das ist vielleicht an einigen Stellen noch hakeliger, aber flexibler weil ich beliebige VSCode Extensions benutzen kann. Mit Mbed Studio ist der Anfang jedenfalls recht einfach, das Board sollte nur aktuell von Mbed unterstützt werden, siehe https://os.mbed.com/platforms/ Mit Mbed6 sind einige ältere Boards rausgeflogen, man kann die trotzdem noch damit benutzen aber das ist etwas aufwändiger. Ich kann mein Beispiel nochmal auf Polling umbauen, dann kann man das direkt benutzen. Für die Eventversion hatte ich wie geschrieben in den OS Quellen Änderungen vorgenommen, das sollte man vermeiden. Es ist aber alles git versioniert und damit hält sich das Chaos in Grenzen.
Nochmals danke für Deine Ausführungen, Johannes. Ich denke aber, ich werde erstmal bei meinem doch in vielen Punkten unterschiedlichen "Setup" für die Entwicklung bleiben: - C statt C++ (wenn auch vermutlich kein Riesensprung) - CubeIDE statt Mbed, weil ich nun die ganze Zeit mit dem F407 Disco arbeite, das in Mbed nicht gelistet ist... Sind für mich eh schon genügend Baustellen mit neuen Themen, da muss ich das nicht auch nochmal komplett auf den Kopf stelle bzw. neu lernen...aber ist trotzdem interessant, was es alles gibt ! ;o)
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.