Hallo liebes Forum, wir wollen Informationen von einem zentralen Server mittels Ethernet auf Displays übetragen und grafisch darstellen. Da Kunden die Möglichkeit haben sollen die Darstellung der Informationen an ihr Corporate Design anzupassen, war nun die Überlegung die Informationen serverseitig als HTML zu generieren, an das Display mit dem uC zu senden, und das HTML dort auf ein 1600x1400 Pixel-Display zu rendern. Nun habe ich nach erster Recherche festellen müssen, dass es scheinbar keine HTML-Renderer gibt, die ohne OS und xy MB RAM auskommen. Das einfachste wäre wohl tatsächlich einen ausreichend großen Prozessor zu verbauen und einen Browser auf Embedded Linux laufen zu lassen. Das kommt kostentechnisch aber nicht in Frage. Meine Fragen sind daher: 1. Gibt es HTML-Renderer für Bare-Metal-Embedded-Anwendungen, die mit 512 kB RAM auskommen? 2. Falls 1. nein, warum ist das HTML-Rendern so aufwändig? Wozu wird ein OS und mehrere MB RAM benötigt? 3. Welche Alternativen Beschreibungs-/Mockup-Sprachen bieten sich außer HTML noch an, vor allem hinsichtlich der Renderbarkeit auf dem o.g. uC und einfacher serverseitiger Generierbarkeit? 4. Alternative Konzepte? Gerne her damit. Grüße, Andreas
Andreas F. schrieb: > 3. Welche Alternativen Beschreibungs-/Mockup-Sprachen bieten sich außer > HTML noch an, vor allem hinsichtlich der Renderbarkeit auf dem o.g. uC > und einfacher serverseitiger Generierbarkeit? Eventuell wäre SVG einfacher?
Du könntest auch XML verwenden um die Daten zu positionieren usw. XML Parser gibt es einige, die in C geschrieben sind (für µC Anwendungen). Mir stellt sich nur die Frage, wie du die Daten auf das Display bekommen möchtest. Falls du kein externes RAM hast, dann musst du zur Laufzeit interpretierte XML Daten direkt einzeln an das Display übertragen. Oder du hast ein externes RAM und baust dir ein Framebuffer, baust erst das Bild auf und überträgst es dann. 1600x1400px = 2240000px (angenommen du verwendest RGB565) 2240000px * 2 Byte = 4,272 MB Wobei so große Displays wohl 32bit Farbwerte verwenden.
:
Bearbeitet durch User
Andreas F. schrieb: > Falls 1. nein, warum ist das HTML-Rendern so aufwändig? Wozu wird ein OS > und mehrere MB RAM benötigt? Hast du dir mal den Umfang von HTML angeschaut? Ordentlich viele Elemente mit jeweils etlichen möglichen Attributen. Dazu kommt natürlich noch CSS um die Darstellung zusätzlich verändern zu können. Außerdem müssen nicht nur Texte sondern auch Bilder und Videos angezeigt werden können. Die allesamt auch noch von externen Quellen geladen werden können. Wenn die Auflösung immer gleich ist, dann vielleicht auf dem Server ein Bild (Bitmap) statt HTML erzeugen und das auf dem uC anzeigen.
Adam P. schrieb: > Mir stellt sich nur die Frage, wie du die Daten auf das Display bekommen > möchtest. > Falls du kein externes RAM hast, dann musst du zur Laufzeit > interpretierte XML Daten direkt einzeln an das Display übertragen. Das war die Idee, nur sehe ich langsam ein dass das mit HTML wohl nicht machbar sein wird. Wäre das mit XML praktikabel? Gehe ich richtig in der Annahme, dass Du mit XML z.B. den Pfad eines Bildes angeben würdest, sowie die Koordinaten auf dem Display wo dieses dargestellt werden soll? Oder den Text und die zugehörige Schrift sowie die Koordinaten?
ThomasW schrieb: > Wenn die Auflösung immer gleich ist, dann vielleicht auf dem Server ein > Bild (Bitmap) statt HTML erzeugen und das auf dem uC anzeigen. Das habe ich mir auch schon überlegt. Geschwindigkeit ist zweitrangig sodass die Übertragungszeit von den 4MB Bilddaten erstmal egal ist. Die Frage die sich mir hier stellt ist: Ist das serverseitig einfach zu implementieren? Die Daten werden momentan auf dem aktuellen Funktionsmuster als JSON mittels HTTP POST an den uC übertragen und dort unflexibel dargestellt (Titel, Infozeile 1, Infozeile 2, ...). Gibt es eine Möglichkeit die POST Daten in definierte Pakete zu splitten? Dann könnte man sogar auf ein externes RAM verzichten und die Bitmap direkt Paketweise aufs Display schreiben.
Wir wäre der Einsatz von VNC? Das regelt sich die Übertragung von veränderten Anzeigenbereiche. Und es gibt VNC Client für MCs.
Andreas F. schrieb: > Die Daten werden momentan auf dem aktuellen Funktionsmuster als JSON > mittels HTTP POST an den uC übertragen und dort unflexibel dargestellt > (Titel, Infozeile 1, Infozeile 2, ...). Gibt es eine Möglichkeit die > POST Daten in definierte Pakete zu splitten? Dann könnte man sogar auf > ein externes RAM verzichten und die Bitmap direkt Paketweise aufs > Display schreiben. Du könntest den Endpoint in mehrere einzelne aufteilen, zB nach Segmenten. Also sowas wie /display in /display/1 /display/2 /display/3 ... aufteilen. Oder die Auswahl per Parameter machen, also /display?segment=1 .
Andreas F. schrieb: > Ist das serverseitig einfach zu implementieren? Für sowas gibt es Imagemagick - ein Grafikprogramm ohne Frontend. Kann man einfach per Konsole nutzen und damit gut aus nem Script/Programm heraus. Andreas F. schrieb: > Die Daten werden momentan auf dem aktuellen Funktionsmuster als JSON > mittels HTTP POST an den uC übertragen und dort unflexibel dargestellt > (Titel, Infozeile 1, Infozeile 2, ...). Gibt es eine Möglichkeit die > POST Daten in definierte Pakete zu splitten? Dann könnte man sogar auf > ein externes RAM verzichten und die Bitmap direkt Paketweise aufs > Display schreiben. Vielleicht den Screen in Segmente aufteilen und dann diese Bereiche einzeln hochladen. HTTP POST erlaubt den Versand mehrerer Files. Hängt aber von Client ab, ob er damit wirklich umgehen kann. Grundsätzlich ist es möglich. Klaus schrieb: > Wir wäre der Einsatz von VNC? > Das regelt sich die Übertragung von veränderten Anzeigenbereiche. > Und es gibt VNC Client für MCs. VNC finde ich aber auch spannend!
Klaus schrieb: > Wir wäre der Einsatz von VNC? > Das regelt sich die Übertragung von veränderten Anzeigenbereiche. > > Und es gibt VNC Client für MCs. Das wäre im Prinzip optimal, auch mit Blick auf zukünftige Anwendungsfälle wenn z.B. noch ein Touchdisplay verbaut werden soll. Nur kann ich mir beim besten Willen nicht vorstellen dass es tatsächlich VNC-Clients gibt die auf so minimalistischer HW und ohne OS auskommen? Kann leider erst heute Abend richtig googeln.
Andreas F. schrieb: > wir wollen Informationen von einem zentralen Server mittels Ethernet auf > Displays übetragen und grafisch darstellen. Das ist nicht neu, nennt sich Digital Signage und dazu gibt es eine Menge Lösungen. Für eine halbwegs komfortable Steuerung werden da aber immer x86 oder Cortex-A eingesetzt. Vor allem auch bei der hohen Auflösung und dem dafür nötigen Speicher ist das keine Anwendung mehr für µC, es sei denn die Inhalte ändern sich wenig und sind statische Anzeigen, da gibt es auch Projekt mit ePaper und ESP32 mit WLAN. Aber große ePaper Displays sind auch nicht billig. Als Digital Signage Lösung habe ich mal Xibo (Open Source) installiert, für den Server bekommt man fertige Images (Container) die unter einem Linux laufen. Player gibt es für verschiedene Plattformen. Unterschiedlich sind vor allem die Formate die die Player abspielen können, unter Windows ging da mehr wenn es um PowerPoints und MS Formate ging. Aber die können alle HTML, AVIs u.v.m. und alles Zeit- oder Eventgesteuert. Recht komplex, aber solche Software gibt es nicht in 'einfach' weil da immer jemand kommt der noch dieses und jenes darüber darstellen will. PS: ich habe mal eine Zeitlang so einen X96 mini als Settop Box benutzt, für knappe 30€ ein kompletter Rechner der jeden µC abhängt. Darauf müsste auch so ein Digital Signage Player laufen, günstiger bekommt man das mit selbstgestrickter HW niemals hin. https://www.amazon.de/X96mini-Amlogic-S905W-Android-Stecker-1-8G/dp/B075RTRVFR/ref=dp_prsubs_1?pd_rd_i=B075RTRVFR&psc=1
Johannes S. schrieb: > Vor allem auch bei der hohen > Auflösung und dem dafür nötigen Speicher ist das keine Anwendung mehr > für µC, es sei denn die Inhalte ändern sich wenig und sind statische > Anzeigen, da gibt es auch Projekt mit ePaper und ESP32 mit WLAN. Das ist genau die Crux: Die Inhalte ändern sich etwa einmal pro Stunde, es steht prinzipiell unendlich viel Rechenzeit zur Verfügung. Insofern halte ich die Lösung, eine Bitmap serverseitig zu rendern und dann über den uC direkt aufs Display zu schreiben für am sinnvollsten. Oder altenativ eben ein VNC Client, wenn sich da etwas findet das auf der schwächlichen HW lauffähig ist.
Es gibt eine VNC Client Implementierung für Arduino: https://github.com/Links2004/arduinoVNC Wenn die Daten sich aber wirklich nur alle Stunde ändern würde ich das ganze komplett runterbrechen und die Bitmap (ggf in kleineren Kacheln) direkt an den µC übertragen. * Steuerung per Tasten ist nicht notwendig? * Wieviele Displays sollen parallel angesteuert werden? Alle das gleiche Bild oder jedes individuell anders?
Klaus schrieb: > Es gibt eine VNC Client Implementierung für Arduino: > https://github.com/Links2004/arduinoVNC Die schaue ich gerade an, die Implementierung sieht überschaubar aus. VNC ist halt spannend weil man sich damit offen hält ein Touchdisplay verbauen zu können, um z.B. Untermenüs usw. anzuzeigen. Was ich noch nicht ganz verstehe: Benötigt der Client einen Framebuffer oder kann er die Daten direkt aufs Display zeichnen? Klaus schrieb: > Wenn die Daten sich aber wirklich nur alle Stunde ändern würde ich das > ganze komplett runterbrechen und die Bitmap (ggf in kleineren Kacheln) > direkt an den µC übertragen. Das scheint die einfachste Lösung zu sein, zumal Imagemagick die Bitmap direkt gekachelt erzeugen kann. Gibt es ein zusätzliche Protokoll, um dem Server mitzuteilen, dass der Benutzer den Punkt xy gerade angeklickt hat? Wobei sich hier die Frage stellt, woher der Server dann weiß, welches HTML-Element sich an Punkt xy befindet.
Andreas F. schrieb: > Wobei sich hier die Frage stellt, woher der Server dann weiß, > welches HTML-Element sich an Punkt xy befindet. Daher oben die Fragen: * Ist Interaktion gefordert? Steuerung per Tasten ist nicht notwendig? * Wieviele Displays sollen parallel angesteuert werden? Alle das gleiche Bild oder jedes individuell anders? Wenn du Interaktion hast, stimmt die Vorgabe "alle Stunde halt nicht". Dann geht es eher Richtung VNC. Die zweite Frage zielt auf die Anzal Instanzen: wieviel muss der VNC Server gleichzeitig verwalten: 1 , 2, ... 100? Wenn nur eine Instanz benötigt wird, kann man recht einfach den VNC Server mit einem Bildschirmfenster verknüpfen. Wenn Du 100 Instanzen hast, wird's vermutlich schwieriger...
Klaus schrieb: > Andreas F. schrieb: >> Wobei sich hier die Frage stellt, woher der Server dann weiß, >> welches HTML-Element sich an Punkt xy befindet. > > Daher oben die Fragen: > * Ist Interaktion gefordert? Steuerung per Tasten ist nicht notwendig? > * Wieviele Displays sollen parallel angesteuert werden? Alle das gleiche > Bild oder jedes individuell anders? Interaktion ist momentan nicht gefordert, es wäre aber wünschenswert sich diese Option offenzuhalten. Es sollen parallel zwischen 10 und 100 Displays angesteuert werden. Du hast recht, bei Interaktion stimmt die Vorgabe 1x pro Stunde nicht mehr. Auch die Annahme dass prinzipiell beliebig Rechenzeit zur Verfügung steht passt dann nichtmehr, da der Benutzer ja nicht stundenlang auf eine Systemreaktion waren möchte. Gehe ich richtig in der Annahme dass bei Verwendung von VNC schlimmstenfalls 100 serverseitige virtuelle Desktops bzw. Browser-Fenster erzeugt werden müssten?
:
Bearbeitet durch User
Andreas F. schrieb: > Gehe ich richtig in der Annahme dass bei Verwendung von VNC > schlimmstenfalls 100 serverseitige virtuelle Desktops bzw. > Browser-Fenster erzeugt werden müssten? Wenn alle etwas verschiedenes Anzeigen sollen: Ja. Wenn sie alle dasselbe Anzeigen sollen, geht es IMHO auch mit einem virtuellen Desktop. (Allerdings könnte sie sich mit der Steuerung in die Quere kommen...) Unter Linux sollte das ggf per Xvfb funktionieren.
Noch eine andere Idee: WRP Web Rendering Proxy Google auf Github Rendert komplexe Webseiten als Grafik. Peter
:
Bearbeitet durch User
Wenn embedded, warum nicht ein Windowsystem für embedded (z.B. Segger) nehmen und dynamisch nach einem einfachen Configfile aufbauen? Muss doch nicht immer alles so kompliziert sein. Ihr definiert ein paar Bausteine, welche dann über das ini file angesteuert werden. Sowas wird für Konfigurationsfiles im MDK-ARM (Keil) gemacht, nennt sich ConfigWizard: https://www.keil.com/support/man/docs/uv4/uv4_ut_configwizard.htm Sicherlich kann man das noch wesentlich weiter treiben, um eine frei plazierbare Anzeige zu erstellen.
:
Bearbeitet durch User
Random .. schrieb: > Wenn embedded, warum nicht ein Windowsystem für embedded (z.B. Segger) Logo, emWin ist sehr gut. Viele Fonts möglich. Mit einfacher Config wären Position, Font, Größe, Farbe recht einfach machbar. Gerade wenn es viele Clients sind, effektiver als Bitmaps zu übertragen. Dann würde ich allerdings die Konfiguration tatsächlich auch mit schicken (z.B. per Json). So bleibt die Intelligenz im Server. Ich vermute einen einfachen Parser hat man in wenigen Tagen erstellt.
Je nachdem welchen Chip du einsetzen möchtest ist emWin sogar kostenfrei: https://www.segger.com/products/user-interface/emwin/emwin-source-upgrade/ Hast dann aber keinen Support oder Source Code dabei. Ich würde dazu passend noch ein RTOS empfehlen (quasi so ganz uneigennützig ;-) ): https://www.segger.com/products/rtos/embos/
Na wenn die Softwarefrage jetzt geklärt ist, welches Display mit 1600 x 1400 klemmt man denn an einen μC mit 512 kB RAM (der nebenbei auch noch Ethernet macht)? Wenn es günstig ist, dann habe ich auch Interesse.
Til S. schrieb: > Ich würde dazu passend noch ein RTOS empfehlen (quasi so ganz > uneigennützig ;-) ): Hast du vielleicht auch eine nicht ganz uneigennützige Empfehlung hinsichtlich Embedded VNC-Client? :-)
Jetzt mal was ganz anderes: Was für ein Display wollt Ihr denn verwenden? 1600*1400 ist ein ungewöhnliches Format, 1600*1200 wäre 4:3 und 1680*1050 16:9. Bei 24 Bit RGB braucht man dafür 6-8MB Video-RAM. Die üblichen Cortex M4(f) gehen meist nur bis 1280*1024. Also: was habt Ihr da geplant? Davon hängt Eure Hardwareauswahl ab. fchk
Wir haben noch kein offizielles Produkt für VNC Client auf der Target Seite. Bis jetzt haben wir das nur als PC Applikation oder auf der Target Seite den VNC Server: https://www.segger.com/products/user-interface/emwin/add-ons/vnc-server/ Aber wir sind ja käuflich ;-). Falls Interesse besteht am besten einfach mal direkt bei uns melden.
Ich wuerde das mit der Rechenleistung und dem Ram nicht so eng sehen, und allenfalls auf Tablets, oder Mobil displays setzen. Dann ist eher die Frage, wie wird verbunden ? Am Einfachsten in diesem Fall : WiFi. Dann brauchst du effektiv nur noch einen Webserver, auf welchen alle Tablets connecten.
Andreas F. schrieb: > 3. Welche Alternativen Beschreibungs-/Mockup-Sprachen bieten sich außer > HTML noch an, vor allem hinsichtlich der Renderbarkeit auf dem o.g. uC > und einfacher serverseitiger Generierbarkeit? Z.B. RTF/LaTex/Postscript/PDF. RTF kann recht wenig, läßt sich dafür aber mit allen üblichen Office-Schreibprogrammen erzeugen und selbst auf recht kleinen µC noch relativ problemlos rendern. LaTex, PS und PDF sind sehr viel mächtiger, aber auch entsprechend aufwendiger zu rendern. Naja, man kann sich auf Teilmengen beschränken, um das Rendering zu vereinfachen, dann wird aber wiederum die Erstellung schwierig, weil es den zur Erstellung geeigneten Programmen nur schwer beizubringen ist, sich auf eben dieses Subset zu beschränken. Kompatibilitätsprobleme sind also quasi vorprogrammiert.
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.