Guten Morgen zusammen, wir arbeiten seit längerem mit dem STM32 M4. Dieser wird bei uns OHNE HAL programmiert. Meine Programmierumgebung ist EMBiz. Mitlerweile haben wir für viele Anwendungen eigene Bibliotheken und Standardbausteine erstellt, die auch ohne HAL recht gut funktionieren. Der M4 steuert ein grafisches Display über den FT810 mit Touch, regelt diverse Antriebseinheiten, steuert einen FU über Modbus und stellt externe Daten über USB zur Verfügung. Wir würden gerne im Rahmen einer Neuentwicklung nun auch die Ethernetschnittstelle des M4 nutzen. Einmal um Daten zur Verfügung zu stellen (Soweit so gut, kriegen wir denke ich hin) Zum Anderen wird die Forderung nach einem WEBINTERFACE immer lauter. Auf diesem Webinterface soll es die Möglichkeit geben Parameter einzustellen und Messdaten in Echtzeit anzuzeigen. Leider habe ich ÜBERHAUPT KEINE Ahnung wo ich hier ansetzen soll. Hat hier jemand vielleicht Erklärungen, gute Tips, Beispiele? Kann jemand vielleicht mal erklären wie so etwas grundsätzlich aussehen kann? Wo wird der HTML Code hinterlegt? Wird der HTML Code in C Code umgewandelt und auf dem µC gespeichert? Wo sind hier die Ansätze? Bin für jede konstruktive Antwort äußerst dankbar
Für den LwIP Stack gäbe es ein http server demo. Aber das Ganze ist schon recht komplex. Und so wie Du hier fragst, ist leider Deine Fähigkeit Dir Wissen anzueignen für diese Aufgabe nicht ausreichend. Note: Wenn man schon ein grafisches Display mit Strom versorgen muss, ist meistens auch genug Saft für einen RPi übrig, auf dem HTML vieeeel einfacher zu realsieren ist.
Hallo, Für jedes (auch ältere) STM Development Board "Discovery" and "Evolution" gab es sog: "Demonstration Firmware" auf der STM Homepage zu finden. Das betraf auch die älteren Versionen ohne CubeMX. Schau mal dort, ich habe schon 2013 Beispiel gefunden welche auch ein (dumimentäres) Webinterface hatten. Wobei es ja um erleuterung der Technik geht. Styling und auschmücken des Interafce ist dann "einfach".
Hallo, Für jedes (auch ältere) STM Development Board "Discovery" and "Evolution" gab es sog: "Demonstration Firmware" auf der STM Homepage zu finden. Das betraf auch die älteren Versionen ohne CubeMX. Schau mal dort, ich habe schon 2013 Beispiel gefunden welche auch ein (dumimentäres) Webinterface hatten. Wobei es ja um erleuterung der Technik geht. Styling und auschmücken des Interafce ist dann "einfach". PS: Auch wenn es kein STM32 ist für die M4 Infinion Controller XMC4800 gibt es für die "Reflex Boards" auch Beispiele für Webinterface auf SD Karte. Vielleicht kannst du hier aggucken ;-)
Guten Tag, oder wenn es nch einfacher gehen soll..... Einen PHY musst du eh noch davor hängen..... Wenn man dann gleich einen WIZNET W5500 davor nimmt.... Der übernimmt dann auch noch den IP-Stack.... OK man ist nicht ganz so offen, wie wenn man alles selbst macht... 8 IP Stacks reichen doch auch .... Source ... Siehe Arduino .... oder für Embitz's hab ich es fertig ... Gruß Thomas
Hanna schrieb: > Auf diesem Webinterface soll es die Möglichkeit geben Parameter > einzustellen und Messdaten in Echtzeit anzuzeigen. > Leider habe ich ÜBERHAUPT KEINE Ahnung wo ich hier ansetzen soll. > > Hat hier jemand vielleicht Erklärungen, gute Tips, Beispiele? > > Kann jemand vielleicht mal erklären wie so etwas grundsätzlich aussehen > kann? Wo wird der HTML Code hinterlegt? Wird der HTML Code in C Code > umgewandelt und auf dem µC gespeichert? > > Wo sind hier die Ansätze? > > Bin für jede konstruktive Antwort äußerst dankbar Ursprünglich hatte ich für diesen Zweck die Ressourcen von Uwe B. (Beispiel HTTP-Server, http://mikrocontroller.bplaced.net/wordpress/?page_id=399) angezapft, bin dann aber auf den Server von MaJerle umgestiegen wegen der gut strukturierten Callback-Funktionen (http://stm32f4-discovery.net/2015/02/library-52-ethernet-peripheral-on-stm32f4xx/). Beide Standard-Library, beide basierend auf lwip. Es ist trotzdem noch eine Schweinearbeit, das Webinterface zu basteln. Für jede Sorte Daten,also z.B. Temperaturdaten eines Sensors, oder WRGB-Daten eines LED-strips, oder einer checkbox ist ein eigener Eintrag im CGI erforderlich. Klar, irgendwann einmal wird das zur Routine, aber dann stößt man auf einmal (bei entsprechend datenüberfrachteter Seite) auf das Problem, daß mit der GET-Methode die URL zu lang wird. Sowieso ist bei dieser Herangehehensweise das Laden der Seite von einer SD-Karte oder Flashdisk hinfällig, weil das HTML der Seite fast schon komplett im STM-Flash erzeugt werden muß. Wenn ich noch Lust hätte mich in einen Raspberry einzuarbeiten, würde ich die Webgeschichte heute wohl eher so lösen. Wobei der STM32F4 von der Geschwindigkeit her völlig ausreichend ist, es ist einfach nur das Handling von (pure) HTML, was einem den Spaß vermiest. Wenn es aber kleiner Datenmengen sind, geht das schon gut. Eine Schaltmatrix für Hausautomation halbwegs bedienbar und übersichtlich zu gestalten, ist schon eine kleine Herausforderung, gerade, wenn man mit HTML sonst nichts am Hut hat. Also: Die Daten können von einer SD-Karte kommen, aber je nach Datenmenge ist der Anteil an von der Karte schnell prüfbarem Code (weil als HTML-Seite anzeigbar) gegenüber dem selbst zu erzeugenden Code (also checkbox konstruieren, Zahlen und Einheiten z.B. zusammenstellen) gering und man ist mehr mit dem Schreiben von Routinen beschäftigt, als mit der Webseiten-Erstellung. Es gibt da allerhand Hilfsmittel für größere Prozessoren mit Betriebssystem, Ajax, Json, Cancas, Script. Wenn man's kann oder lernen will, ist das Endergebnis dann wahrscheinlich besser als mit händischem Gepopel am STM32.
Jürgen S. schrieb: > weil das HTML der Seite fast schon komplett im > STM-Flash erzeugt werden muß Für das gibts HTML5 und JavaScript. Da kann man sehr einfach das GUI z.B. auf der SD-Karte ablegen und dann die variablen Daten separat z.B. mittels JSON vom Mikrocontroller zum Webbrowser übertragen. Ein JSON dynamisch zu generieren braucht nur sehr wenig Resourcen. Die variablen Daten in das GUI einzufügen erledigt dann der Webbrowser beim Anwender (mittels JavaScript).
:
Bearbeitet durch User
Hanna schrieb: > Mitlerweile haben wir für viele Anwendungen eigene Bibliotheken und > Standardbausteine erstellt, Schon so viel damit gearbeitet aber dennoch nicht dazu in der Lage den Controller richtig zu benennen? Es gibt keinen "STM32 M4". Es gibt "STM32F4" oder "STM32 mit ARM Cortex-M4-Kern" wie z.B. "STM32F4" oder "STM32F3".
Der lwIP Stack wird von deinem Programm so initialisiert, dass er Verbindungen auf einer bestimmten portNumemr (typisch 80) annimmt. Dann bjst du schon so wiet, dass du im Webbrowser die URL http://192.168.0.123:80/irgendwas aufrufen kannst. Sobald der Browser eine Verbindung aufgebaut hat, ruft lwIP eine Call-Back Funktion deines Programmes auf. Diese muss auf Ereignisse reagieren: - Neue Verbindung -> Verbindung annehmen - Daten empfangen -> In einen Puffer schreiben Sobald im Puffer zu erkennen ist, dass der ganze HTTP Request empfangen wurde, kannst du ihn verarbeiten und antworten. Du musst dich also mit dem HTTP Protokoll beschäftigen. Die Antwort ist dann typischerweise ein HTML Dokument. Diese muss dein Quelltext generieren und Paketweise mit lwIP senden. Auch dazu ruft lwIP eine CallBack-Funktion auf, nämlich immer dann, wenn das Netzwerk-Interface bereit ist, zu senden. Wenn du mit dem Senden fertig bist, schließt du die Verbindung. Was ich oben schrieb, bezieht sich auf die raw API von lwIP. Etwas einfacher, aber auch Speicherintensiver wird es, wenn du die Socket API verwendest. Die funktioniert so ähnlich, wie auf dem PC. Wo die Webseiten her kommen, bleibt Dir überlassen. Ich persönlich finde es am einfachsten, Seiten von einer SD Karte zu laden und die dynamischen Anteile mit Javascript zu ändern. Dann braucht dein C-programm nicht komplette HTML Seiten zu erzeugen, sonder nur die veränderlichen Teile oder gar nur Rohdaten, aus denen das Javascript dann HTML, SVG oder Canvas Grafiken erzeugt. SVG ist übrigens ein heißer Tip, sehr praktisch um Grafiken/Diagramme zu erzeugen.
Stefanus F. schrieb: > Der lwIP Stack wird von deinem Programm so initialisiert, dass er > Verbindungen auf einer bestimmten portNumemr (typisch 80) annimmt. Wie robust ist eigentlich der lwIP Stack wenn den schnell und in großen Mengen mit Scheiße bewirft?
Robusta schrieb: > Wie robust ist eigentlich der lwIP Stack wenn den schnell und in großen > Mengen mit Scheiße bewirft? Das weiß ich nicht. Er wird allerdings produktiv von vielen Firmen eingesetzt, also kann er nicht allzu schlecht sein. Der Vorgänger µIP ist jedenfalls 100% zuverlässig.
Hanna schrieb: > > Wir würden gerne im Rahmen einer Neuentwicklung nun auch die > Ethernetschnittstelle des M4 nutzen. > Einmal um Daten zur Verfügung zu stellen (Soweit so gut, kriegen wir > denke ich hin) > Zum Anderen wird die Forderung nach einem WEBINTERFACE immer lauter. > War bei meinen Kunden eine Zeit lang auch mal so, ist aber mittlerweile immer mehr verstummt, als die ersten Erfahrungen im Feld gesammelt wurden... Die grossen Themen sind Folgende: 1. Es sind zu jedem Zeitpunkt mindestens je 3 gängige Versionen von 4 verbreiteten Browsern auf dem Markt, d.h. der Web Server muss die Eigenheiten von 12 Browsern kennen und abhandeln können. Selbst wenn man sich auf allerrudimentärstes HTML beschränkt, darfst Du davon ausgehen, dass diese 12 Browservarianten mindestens 10 verschiedene (z.T. fehlerbehaftete) HTML header generiert und/oder 2 oder 3 nicht mit Jeder Antwort des Servers das selbe anfangen können. Wartungshölle. Für Softwareentwickler ist das Alltagsgeschäft, aber für ein "einfaches" Wartungsinterface in einem Embedded System kann die Angelegenheit leicht den Pflegeaufwand für die eigentliche Funktionalität übersteigen. 2. Sobald Ihr den ersten HTTP Server draussen habt, wird (dafür bin ich bereit so einiges zu verwetten) der nächste Ruf nach HTTPS kommen. Unverschlüsseltes Web ist "sowas von Zweitausender...," vor Allem wenn das Konfigurationsinterface Passwortgeschützt ist (was normalerweise der Fall ist). Dann wird es richtig interessant, weil ein TLS Layer den footprint für die Middleware nochmal so richtig anschwellen lässt. 3. Wie vorher schon angemerkt wurde, müsst Ihr im Web Umfeld auf Dinge wie Denial of Service Attacken vorbereitet sein. Das schliesst auch Fragen ein wie euer Prioritätsschema für die Webserver Task(s) (abhängig davon, wie komfortabel Ihr sein wollt/sollt) im Gesamtsystem angesiedelt werden muss. Ich will damit nicht davon abraten, es zu tun; viele Embedded Systeme haben Web Server zur Konfiguration und Diagnose, also geht es, und bei manchen auch recht gut. Aber die Entscheidungsetagen gehen da oft blauäugig dran, so nach dem Motto "da setzen wir Jemand aus der Softwareentwicklung eine Woche ran, das machen wir ja schon seit Jahren." Aber wenn der/diejenige dann merkt, dass von dem Toolset auf PC Seite nichts zur Verfügung steht und man sich seine HTML Seiten selbst zusammen basteln muss, sieht die Sache schon Anders aus...
Punkt 1 ist nicht grundsätzlich falsch, aber die Browser sind da in den vergangenen 20 Jahren kontinuierlich besser und ähnlicher geworden. Meine NET-IO Firmware (http://stefanfrings.de/net_io/index.html) hat seiter der Veröffentlichung im Jahr 2009 immer noch das selbe Webinterface ohne Browserweichen. Und es funktioniert mit jedem mir bekannten Browser. Punkt 2 möchte ich voll zustimmen. Wobei wirklich sicheres HTTPS auf so kleinen Mikrocontrollern schwierig umzusetzen ist. Wie will man beispielsweise mit ablaufenden oder kompromittierten Zertifikaten umgehen? Außerdem ist HTTPS schwierig zu debuggen. Ich empfehle daher HTTP durch einen VPN Tunneln. Punkt 3 stimme ich auch zu. Mikrocontroller sollten im öffentlichen eigentlich gar nicht erreichbar sein. Ein VPN Tunnel dürfte auch dieses Problem lösen (bzw auf die VPN Software verschieben, aber da kann man dann bewährte Standard-Software vom Hersteller der Vertrauens verwenden. Auf jeden Fall sind Web Interface in der Praxis schwieriger, als es die Tutorials erscheinen lassen. Nicht umsonst programmiert man heutzutage echte Webseiten mit Frameworks (wie NodeJS und Java EE) und lässt sie auf äußerst potenten Servern laufen. Da gibt man lieber Geld für Hardware und Strom aus, als jedes Bit persönlich kennen zu lernen. Wenn du damit langfristig durch permanente Pflege Geld verdienen willst, und deine Kunden schmerzfrei sind, dann mache es ruhig mit Webinterface. Am besten koppelst du das irgendwie an Software von SAP (z.B. Hybris), dann hst du bis zur Rente einen sicheren Job - es sei denn, der Kunde schmeißt den Kram weg. Vergiss daher nicht, ihm regelmäßig zu präsentieren, dass er das Beste gekauft hat, was die Welt zu bieten hat.
Stefanus F. schrieb: > > Punkt 2 möchte ich voll zustimmen. Wobei wirklich sicheres HTTPS auf so > kleinen Mikrocontrollern schwierig umzusetzen ist. Wie will man > beispielsweise mit ablaufenden oder kompromittierten Zertifikaten > umgehen? Außerdem ist HTTPS schwierig zu debuggen. Ich empfehle daher > HTTP durch einen VPN Tunneln. > Ebenfalls ACK, aber auf Serverseite ist das nicht ganz so wild. Der HTTPS Server stellt in der Regel "nur" sein Zertifikat zur Verfügung, muss sich also selber nicht um die Verifikation von Drittzertifikaten scheren. Was natürlich nichts daran ändert, dass auch das Serverzertifikat verwaltet werden muss, da sich die Browserclients natürlich aus verschiedensten Gründen am Zertifikat des Servers stören können. Also einmal ein Zertifikat in der Firmware hinterlegen und für den Rest der Zeit da zu lassen, reicht nicht. > Punkt 3 stimme ich auch zu. Mikrocontroller sollten im öffentlichen > eigentlich gar nicht erreichbar sein. Ein VPN Tunnel dürfte auch dieses > Problem lösen (bzw auf die VPN Software verschieben, aber da kann man > dann bewährte Standard-Software vom Hersteller der Vertrauens verwenden. > Deswegen ist eine öfter zu beobachtende Lösung, die Netzwerkseite komplett vom "Arbeitscontroller" abzukoppeln. Am Netz hängt in solchen Systemen ein Arduino, Raspberry, Beagle o.ä., das über eine zweite physikalische Schnittstelle mit dem Controller kommuniziert, die gesamte Netzwerksoftware implementiert und in ein einfacheres und eingekapseltes M2M Protokoll übersetzt. Damit überlässt man all die blutigen Details bereits existierender Software. Hat natürlich andere Nachteiel. Win some, lose some...
Ruediger A. schrieb: > muss sich also selber nicht um die Verifikation von Drittzertifikaten > scheren. Aber wenn der Server schützenswerte Daten liefert, sollte er sich vergewissern, wirklich mit dem richtigen Client zu reden. Und dann muss (bzw. sollte) er doch das Zertifikat des Client verifizieren.
Ruediger A. schrieb: > Am Netz hängt in solchen > Systemen ein Arduino, Raspberry, Beagle o.ä., das über eine zweite > physikalische Schnittstelle mit dem Controller kommuniziert, die gesamte > Netzwerksoftware implementiert und in ein einfacheres und eingekapseltes > M2M Protokoll übersetzt. Ja. Vor einigen Jahren fand ich die Vorstellung, Mikrocontroller mit Ethernet/WLAN auszustatten noch extrem spannend und vielversprechend. jetzt, wo man das für 2€ an jeder Ecke bekommen kann, bin ich skeptischer geworden. Wenn ich zwischen Internet und Maschine einen (mini-) PC schalte, kann ich auch gleich wieder die gute alte serielle Schnittstelle in einer ihrer Ausprägungen (USB, RS422, ...) benutzen. WLAN/Ethernet hat für mich einen großen Teil seines Reizes verloren. Aber das ist menschlich: Die blonde will braune Haare, die brünette lässt sie sich hell machen. Man will immer das haben, was man gerade nicht hat.
Ruediger A. schrieb: > Deswegen ist eine öfter zu beobachtende Lösung, die Netzwerkseite > komplett vom "Arbeitscontroller" abzukoppeln. Am Netz hängt in solchen > Systemen ein Arduino, Raspberry, Beagle o.ä., das über eine zweite > physikalische Schnittstelle mit dem Controller kommuniziert, die gesamte > Netzwerksoftware implementiert und in ein einfacheres und eingekapseltes > M2M Protokoll übersetzt. Damit überlässt man all die blutigen Details > bereits existierender Software. Hat natürlich andere Nachteiel. Win > some, lose some... Hat jemand eigentlich den stm32mp1 https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html schon in freier Wildbahn gesichtet?
Stefanus F. schrieb: > Ruediger A. schrieb: >> muss sich also selber nicht um die Verifikation von Drittzertifikaten >> scheren. > > Aber wenn der Server schützenswerte Daten liefert, sollte er sich > vergewissern, wirklich mit dem richtigen Client zu reden. Und dann muss > (bzw. sollte) er doch das Zertifikat des Client verifizieren. TLS sichert nur den Transport gegen Abhören von Dritten. Die Authentifizierung läuft nach wie vor über Passwort, nur halt eben kryptiert. Das ist ja gerade der Charme der Lösung: Einfach nur eine Kryptierschicht drunterlegen und den Rest so lassen wie es ist. (Theorie. ;-))
:
Bearbeitet durch User
Ruediger A. schrieb: > Die Authentifizierung läuft nach wie vor über Passwort, nur halt eben > kryptiert. Nicht unbedingt, der Server authentifiziert sich gegenüber dem Client über kryptographische Challenge-Response-Protokolle; daran wird die Echtheit der Website sicher gestellt (grüne Adresszeile im Browser). Umgekehrt geht es auch - der Browser kann sich genau so gegenüber dem Server ausweisen. Allerdings machen das nur ganz wenige Websiten - ich kenne da nur die (ehemalige) StartSSL-Seite und ElsterOnline, wobei das geschummelt ist weil das über JS statt den Browser geht. Das ist so natürlich deutlich sicherer als ein Passwort (Brute Force, Passwort Listen) aber auch für den Nutzer sehr umständlich, weil er immer die Zertifikatsdatei bereit haben und die auch geheim halten muss.
Dr. Sommer schrieb: > Ruediger A. schrieb: >> Die Authentifizierung läuft nach wie vor über Passwort, nur halt eben >> kryptiert. > > Nicht unbedingt, der Server authentifiziert sich gegenüber dem Client > über kryptographische Challenge-Response-Protokolle; daran wird die > Echtheit der Website sicher gestellt (grüne Adresszeile im Browser). Meines Wissens nach ist die grüne Farbe i.W. ein Indikator, dass das Zertifikat in der PKA Trust Chain als gültig anerkannt wurde. Die Challenge Response Verhandlung (und damit Transportsicherung) ist auch mit einem roten Zertifikat möglich (ist auch nicht mal so selten). Die (haarspalterisch) richtige Formulierung der obigen Aussage wäre also "der Server authentifiziert sich gegenüber dem Client mit einem als vertrauenswürdig angesehenen Zertifikat, mit dessen Hilfe über kryptographische Challenge-Response-Verfahren eine Transportsicherung etabliert wird." Nur damit keine Konfusion darüber entsteht, dass Authentifizierung und Transportsicherung erstmal zwei verschiedene Dinge sind, die bei TLS so ein bisschen miteinander verwoben werden... aber ich gebe das letzte Wort hier sehr gerne an Jemanden mit mehr Einsicht ab. ;-) > Umgekehrt geht es auch - der Browser kann sich genau so gegenüber dem > Server ausweisen. Allerdings machen das nur ganz wenige Websiten - ich > kenne da nur die (ehemalige) StartSSL-Seite und ElsterOnline, wobei das > geschummelt ist weil das über JS statt den Browser geht. Genau. Ich sehe Computersicherheit gerne als Schichtenmodell ähnlich wie ISO/OSI. Die kryptographischen Verfahren (z.B. AES) liegen dabei ganz unten, Verfahren wie block chaining da drüber, weiter oben (optional authentifizierte) session key Verhandlungen, und wenn dann erstmal ein sicherer Kanal entstanden ist, lässt sich auf Applikationsebene nochmal authentifizieren wenn nötig oder gewünscht. Also wie Du schreibst: Eine Zertifikatsverifikation über eine bereits (in diesem Fall durch Zertifikate) gesicherte Verbindung ist halt etwas Anderes als mutual TLS. Aber deswegen nicht weniger sicher! > Das ist so natürlich deutlich sicherer als ein Passwort (Brute Force, > Passwort Listen) aber auch für den Nutzer sehr umständlich, weil er > immer die Zertifikatsdatei bereit haben und die auch geheim halten muss. Ack.
Ruediger A. schrieb: > Genau. Ich sehe Computersicherheit gerne als Schichtenmodell ähnlich wie > ISO/OSI. Tja... Oft wird noch die Denkweise verfolgt, man könne "Sicherheit" so als Modul extern dazukaufen und in ein System einklinken. Das ist natürlich Blödsinn; alle Schichten und Komponenten müssen unter Sicherheitsaspekten entwickelt werden, das fängt schon beim Validieren von Nutzereingaben an (Buffer Overflow & Co vermeiden) und geht über Verschlüsselung und Authentifizierung bis zu organisatorischen Maßnahmen (Zugang zu Server-Räumen und so). Viele "Sicherheits-Maßnahmen" (einige Firewalls, SELinux, ASLR, Virenscanner...) sind tatsächlich nur dazu da, die Auswirkungen vorhandener Sicherheitslücken weniger schlimm zu machen. Viel besser ist es natürlich, wenn die Lücken gar nicht erst existieren...
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.