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).
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. ;-))
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...
