Hallo Liebes Forum, Ich habe einige Fragen zur Entwicklung mit ARM µCs. Ich hatte vorher einen langen Text geschrieben, musste aber feststellen, dass ich selbst keine Lust hätte den durch zu lesen. Ich fasse mich kurz: - Wie bekomme ich einen WebSocket-Server auf einen ARM Cortex M3 ohne Arduino und Betriebsystem zum laufen? - Gibt es Unterschiede zwischen den Verschiedenen IDEs für ARM was C-Befehle und Funktionen angeht? - Mit welchen Begriffen google ich am besten wenn ich Bibliotheken für "blanken" ARM C-Code suche ohne Betriebssystem? (Auch im Hinblick auf Frage 1) Vielen Dank für Hilfe! Falk
Falk S. schrieb: > - Wie bekomme ich einen WebSocket-Server auf einen ARM Cortex M3 ohne > Arduino und Betriebsystem zum laufen? Mit einem Netzwerk MAC+PHY, einem TCP/IP Stack und einer WebSocket Implementierung. Keine Ahnung ob es eine Mikrocontroller-taugliche gibt. Aber was bringen schon WebSockets ohne Web Server? Tuts da nicht auch einfach TCP? Falk S. schrieb: > - Gibt es Unterschiede zwischen den Verschiedenen IDEs für ARM was > C-Befehle und Funktionen angeht? Nur zwischen denen, die verschiedene Compiler nutzen. Aber auch da verhalten sich die im C Standard definierten Funktionen meist entsprechend. Nur Mikrocontroller spezifische Dinge unterscheiden sich oft. Allerdings unterstützen verschiedene Compiler oft nicht die neusten C Standards (zB C11 vs C89). GCC hat das bessere Front End, ARMCC das bessere Back End... Falk S. schrieb: > Mit welchen Begriffen google ich am besten wenn ich Bibliotheken für > "blanken" ARM C-Code "bare metal". Was ist so schlimm an einem Betriebssystem? Komplexe Dinge wie Netzwerk machen sich gut zusammen mit einem RTOS..
Schau dir die Arm eigene Plattform mbed an oder das Projekt Zephyr Beide sind aber mit os
>- Wie bekomme ich einen WebSocket-Server auf einen ARM Cortex M3 ohne >Arduino und Betriebsystem zum laufen? Du vermutlich gar nicht. Das erkennt man an deinen Fragen. Denk lieber darüber nach das evtl. mit einem Raspi zu machen.
holger schrieb: > Du vermutlich gar nicht. Das erkennt man an deinen Fragen. Sehe ich auch so. Einfach nur Code aus dem Netz zusammen kopieren und hoffen das dann was geht wird nicht reichen. Mach dich erst mal mit deinem µC und der Entwicklungsumgebung vertraut und löse erst mal die Teilaufgaben wie Netzwerkinterface und TCP/IP Stack. Wenn das geht den Webserver und eventuell das Filesystem auf SD-Karte. Wenn du bis dahin den Kram noch nicht in die Ecke geschmissen hast sehen wir weiter. Dr. Sommer schrieb: > Was ist so schlimm an einem Betriebssystem? Komplexe Dinge wie Netzwerk > machen sich gut zusammen mit einem RTOS.. Ich glaube nicht dass er ein RTOS als Betriebssystem meint sondern ehr sowas was man auch wirklich Betriebssystem nennen kann wie Linux. Die üblichen RTOS Geschichten decken doch außer den Taskmanagement nichts ab.
temp schrieb: > Dr. Sommer schrieb: >> Was ist so schlimm an einem Betriebssystem? Komplexe Dinge wie Netzwerk >> machen sich gut zusammen mit einem RTOS.. > > Ich glaube nicht dass er ein RTOS als Betriebssystem meint sondern ehr > sowas was man auch wirklich Betriebssystem nennen kann wie Linux. Die > üblichen RTOS Geschichten decken doch außer den Taskmanagement nichts > ab. TCP/IP fordert einiges an Timing: ARP, TCP-ACK-Windows u. -Timeout, TCP-Retransmits etc. Das ist "bare metal" mühsam. Ein RTOS welches Multithreading, virtuelle Timer etc. bereitstellt macht einem da das Leben wesentlich einfacher. Viele RTOSse haben auch gleich eine Schnittstelle zu einem TCP/IP-Stack wie lwIP oder uIP.
Gerd E. schrieb: > Viele RTOSse haben auch gleich eine Schnittstelle zu einem TCP/IP-Stack > wie lwIP oder uIP. uIP ist ja gerade für minimale Hardware ohne RTOS geschrieben. Und wenn man es in einem RTOS findet, läuft die bekannte uIP-Loop fast unverändert zu den Originalbeispielen in einem Thread oder einer Task, je nachdem wie das jeweilige RTOS es nennt. lwIP ist von der Sache her auch nicht für ein RTOS entwickelt. Klar macht es vieles einfacher. Den Umgang mit parallelen Fäden und die absturzfreie Kommunikation zwischen ihnen ist für Einsteiger trotzdem nicht unbedingt die beste Spielwiese. Jedenfalls hat Falk erst mal genügend Stoff für die langen Winterabende...
gibt auch FreeRTOS mit TCP websocket ... hab ich selbst ewig gesucht und am ende selbst geschrieben
hust schrieb: > gibt auch FreeRTOS mit TCP Das beobachte ich auch schon eine Weile. Nachdem lange Zeit nur eine Implementierung für Windows in den Samples zu finden war gibts jetzt auch was für STM32F407 bzw Atmel. Hat schon jemand Erfahrungen damit gesammelt und kann berichten? Wenn ich das nächste mal Ethernet brauche versuche ich das auch mal, hoffe aber jemand macht mal ein Sample für LPC17xx.
ich wollte das demnächst mal anfassen... da ich eh nur socket API brauche und auch bisher genutzt hab. vieleicht passt das ganze besser zum RTOS lwip hat da scheinbar hier und da kleine bugs ...
Ich würde TCP mit komplexeren Protokollen, also mehr als UDP, nicht ohne Betriebssystem machen wollen. Ansonsten müßte man zu viele fehlerträchtige Dinge selber implementieren. Lieber ein kleines Linux drunter. Das erspart wochenlanges Debuggen in Netzwerkprotokollen. Und soweit ich das verstanden habe sind WebSockets eine Nummer komplexer als normale Sockets. Das müßte dann auch behandelt werden.
Linux auf einem Cortex-M wird eher schwierig. Dort also tatsächlich lieber ein RTOS wie z.B. SEGGER embOS. Dazu gibt es auch passend den TCP/IP Stack embOS/IP und die Toolchain Embedded Studio. Ist natürlich kommerziell aber zum privat rumspielen kann man das auch benutzen. Der Vorteil ist das alles out of the Box läuft. FreeRTOS zu benutzen ist so ein bisschen wie mit einem stumpfen Küchenmesser ein Herz OP zu versuchen obwohl das sterile OP Besteck gleich daneben liegt. Bitte nicht falsch verstehen, FreeRTOS ist ein super Bastelprojekt aber wer einfach etwas fertiges haben möchte nimmt eher embOS.
Falk S. schrieb: > - Wie bekomme ich einen WebSocket-Server auf einen ARM Cortex M3 ohne > Arduino und Betriebsystem zum laufen? Mit SEHR viel Aufwand. Mit soviel Aufwand, daß Du es auf einem M3 meiner Meinung nach so ziemlich getrost vergessen kannst. > - Gibt es Unterschiede zwischen den Verschiedenen IDEs für ARM was > C-Befehle und Funktionen angeht? Die IDE hat damit nichts zu tun, sondern der verwendete Compiler. Was C selber angeht nicht. Allerdings sind die nicht-standardisierten Erweiterungen compilerspezifisch. Beispielsweise die Pragmas, mit denen man bestimmte Code-Abschnitte mit einem bestimmten Optimierungslevel compilieren kann, unabhängig von den Compileroptionen auf der Kommandozeile bzw. im Makefile. Auch sog. Compiler-Builtins sind natürlich spezifisch. Etwa eines, mit dem man dem Compiler das Ergebnis einer Verzweigung in der ganz überwiegenden Zahl der Fälle schon zur Compile-Zeit mitteilen kann. Oder wie man ihn dazu bekommt, bestimmte Funktionen immer zu inlinen (nein, GCC hört da nicht auf das Schlüsselwort "inline", sondern tut bei "inline", wozu er gerade Bock hat). Oder auch, sie garantiert nicht zu inlinen, etwa weil dann der Stackverbauch zu heftig würde (auch hier ist GCC mit seiner Eigenlogik mitunter ziemlich krank).
Guest schrieb: > Linux auf einem Cortex-M wird eher schwierig. µC-Linux geht im Prinzip schon - allerdings braucht man dafür erstens einen externen Speicher, wo das Linux gespeichert wird, etwa eine SD-Karte. Paßt nicht ins interne Flash-ROM. Von einer SD-Karte kann man natürlich zweitens keinen Code ausführen, also muß der ins RAM geladen werden. Drittens braucht man dazu so in etwa 4MB-8MB externes RAM auf dem Board. Viertens wird das dann ziemlich lahm, ein Faktor 6-9 im Vergleich zu interner Ausführung ist realistisch.
Nop schrieb: > Mit SEHR viel Aufwand. Mit soviel Aufwand, daß Du es auf einem M3 meiner > Meinung nach so ziemlich getrost vergessen kannst. das muss mir mal bitte jemand erklären wenn man sogar WSS machen will geht das ganz easy auf einem M3 einzig der TLS handshake brauch manchmal je nach schlüssel 500ms aber danach wars das nur weil so was simples wie ein websocket plötzlich SHA1 und base64 codierung braucht heißt das nicht das das unmöglich ist. Websocket: FAST normales HTTP Aufbau: HTTP GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Antwort vom server : HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= man nimmt seinen Key dGhlIHNhbXBsZSBub25jZQ== und verbackt den mit dem GUID "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" zu "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11" das hasht man mit SHA1 und nochmal base64 dann muss das mit dem Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= übereinstimmen passt das , steht die verbindung der header ist recht einfach aufgebaut und ist schnell durchgeparsed man muss dannn noch anhand der headerinformationen das PING/PONG implementieren. beenden und datenempfang steht auch im header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload Data | +-------------------------------- - - - - - - - - - - - - - - - + : Payload Data continued ... : + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Payload Data continued ... | +---------------------------------------------------------------+ WAS in der payload steht ist dem nutzer überlassen ... sollte dann am besten auch ein andere teil der applikation machen alles nachzulesen: https://tools.ietf.org/html/rfc6455 Websocket gibts mitlerweil auch für arduinos ... also von daher ist die ausrede das es komplex ist falsch einzig SHA1 und base64 sind komplex... gibts aber oft als source der fertige libs
SHA1 und base64 sind zB in der polarssl lib enthalten
Seid wann ist base64 denn schwer? 3Byte nehmen, die 5Bit Gruppen maskieren und damit in einer LUT nachsehen. Wenns mal nicht 3Byte sind, dann auffüllen.
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.