Hallo zusammen, ich suche ein µC Board, welches einen HDMI Anschluss und GPIO hat. WLAN wäre gut, kann ja aber per GPIO ggf. angeschlossen werden. ESP32 ist leider zu schwach für HDMI und höhere VGA Farb-Photos. Raspberry Pi & Co fallen für mich raus, da OS auf der SD Karte liegen und diese teils sehr anfällig sind. Die Systeme sollen aber sehr schnell bootfähig sein und an recht schwer (aufwändig) erreichbaren Stellen angebracht werden. Also immer mal wieder eine SD Karte ersetzen fällt aus. Und so aufwändig ist das lesen eines Bildes und Anzeigen nicht, dass ich dafür ein Linux OS brauche. Der Arduino MKR VIDOR 4000 hat zwar miniHdmi fällt ebenfalls raus, da es nicht eine dokumentierte Funktion zur Nutzung der HDMI Schnittstelle gibt. Habt ihr Ideen ? Danke & viele Grüße, Kim
Kim J. schrieb: > Also immer mal wieder eine SD Karte ersetzen fällt aus. Dann sorg einfach dafür, dass das OS nicht (oder nur so weing wie möglich) auf die SD-Karte schreibt, dann lebt die ewig. Sogar die billigsten Consumer-Karten laufen dann im Dauertest jahrelang. Wenn du also 2 brauchbare SD-Karten nimmst, das OS nicht schreibt und du dann deine Daten, die sich per WLAN ab&an mal ändern, auf die zweite SD packst, lebt die Steuerung ewig und drei Tage.
Danke für die Rückmeldung.
Die Karten halten nicht ewig. Sie sind die absolute Schwachstelle und
das komplexere OS (logischerweise im Vergleich zum einfachen µC) sorgt
automatisch für viel Schreibzugriffe (Logs, Swap, usw). Wenn dann mal
z.Bsp. der Strom wegfällt, dann ist fast immer die SD hin.
> Dann sorg einfach dafür, dass das OS nicht (oder nur so weing wie
möglich) auf die SD-Karte schreibt
Das ist technisch bei OS wie Linux nicht zuverlässig machbar. Aber diese
Zuverlässigkeit brauche ich für dieses Projekt. Daher der deutliche
Ausschluss dieser Technik.
Kim J. schrieb: > Die Karten halten nicht ewig. Sie sind die absolute Schwachstelle und > das komplexere OS (logischerweise im Vergleich zum einfachen µC) sorgt > automatisch für viel Schreibzugriffe (Logs, Swap, usw). Wenn dann mal > z.Bsp. der Strom wegfällt, dann ist fast immer die SD hin. Eigene Erfahrung oder Hören-Sagen? Ich hab seit Jahren zwei Pi2b dauerhaft laufen und noch keine Probleme mit den SD-Karten gehabt. Die booten von der Karte und alles andere passiert auf einer SSD am USB. Da ein Pi4 direkt von USB-Festplatte booten kann, sollte es inzwischen garkeine Kartenprobleme mehr geben können.
Hat der Raspberry Pi Pico nicht integrierten Flash? Dafür gibt es Quellcode für VGA oder DVI-Ausgabe. Letzteres kann an HDMI adaptiert werden. Wenn es Linux sein darf, und etwas mehr Leistung: PcDuino V3 hat NANDFlash onboard, und diverse Olinuxino-Boards von Olimex auch.
Kim J. schrieb: > Die Karten halten nicht ewig. Sie sind die absolute Schwachstelle und > das komplexere OS (logischerweise im Vergleich zum einfachen µC) sorgt > automatisch für viel Schreibzugriffe (Logs, Swap, usw). Wenn dann mal > z.Bsp. der Strom wegfällt, dann ist fast immer die SD hin. Das wage ich zu bezweifeln. Nur weil eine Horde von Bastlern das Ding immer wieder abschießen kann, bedeutet das nicht, daß man das mit einer GESCHEITEN Stromversorgung + gescheites Softwarekonzept wie schon beschrieben betreiben kann. Man kann vermutliche das OS auf eine read only Partition packen und Read/write auf einer zweiten Partition machen, ggf. auch komplett nur im RAM. Wo ein Wille ist, ist auch ein Weg. Wegen deiner Anforderungen eine komplett neue CPU-Plattform aufzubauen ist maximaler Overkill. > Das ist technisch bei OS wie Linux nicht zuverlässig machbar. Aber diese > Zuverlässigkeit brauche ich für dieses Projekt. Daher der deutliche > Ausschluss dieser Technik. Du verbaust dir ohne Not von vorn herein Optionen. Viel Spaß damit.
Kim J. schrieb: > Raspberry Pi & Co fallen für mich raus, da OS auf der SD Karte liegen > und diese teils sehr anfällig sind. Die Systeme sollen aber sehr schnell > bootfähig sein und an recht schwer (aufwändig) erreichbaren Stellen > angebracht werden. Nur so als Randnotiz: Die aktuellen Raspis booten inzwischen auch ohne wilde Hacks von USB-Laufwerken. Oliver
Kim J. schrieb: > Die Karten halten nicht ewig. Sie sind die absolute Schwachstelle und > das komplexere OS (logischerweise im Vergleich zum einfachen µC) sorgt > automatisch für viel Schreibzugriffe (Logs, Swap, usw). Wenn dann mal > z.Bsp. der Strom wegfällt, dann ist fast immer die SD hin. > >> Dann sorg einfach dafür, dass das OS nicht (oder nur so weing wie > möglich) auf die SD-Karte schreibt > > Das ist technisch bei OS wie Linux nicht zuverlässig machbar. Aber diese > Zuverlässigkeit brauche ich für dieses Projekt. Daher der deutliche > Ausschluss dieser Technik. nur booten von sd, der rest auf usb -> dafür gibt es viele anleitungen
Falk B. schrieb: > Man kann vermutliche das OS auf eine read > only Partition packen und Read/write auf einer zweiten Partition machen, > ggf. auch komplett nur im RAM. So isses. Das haben wir schon vor 20 Jahren mit uCLinux so gemacht, als wir aus dem Flash gebootet haben. Da legt man /var im RAM an, benutzt sowieso keinen Swapspace (wer sowas macht, nimmt besser das Board mit mehr RAM) und macht keine Schreibvorgänge auf die SD (was beim Flash des uCSimm sowieso nicht ging). Alles nicht schwierig und der kleine uCSimm bootet heute noch brav sein damals konfiguriertes Linux.
Kim J. schrieb: >> Dann sorg einfach dafür, dass das OS nicht (oder nur so weing wie >> möglich) auf die SD-Karte schreibt > Das ist technisch bei OS wie Linux nicht zuverlässig machbar. Es gibt genügend Tutorials im Internet, die das Gegenteil behaupten. Stichwort: Ramdisk Oliver S. schrieb: > Nur so als Randnotiz: Die aktuellen Raspis booten inzwischen auch ohne > wilde Hacks von USB-Laufwerken. Korrekt. Das habe ich bereits mit Crucial- und Samsung-SSDs erfolgreich getestet. Läuft einwandfrei - zumindest mit SATA-SSDs und billigem USB-Adapter. NVME-SSDs sind da ein wenig zickiger. Hier braucht man noch einen aktiven USB-Hub dazwischen, weil die USB-Ports des RasPi4 nicht genügend Strom liefern. Interessante Seite dazu: https://jamesachambers.com/new-raspberry-pi-4-bootloader-usb-network-boot-guide/ Eigene Benchmarks mit PI4 und SSD: https://uclock.de/bonnie/
@falk: > Das wage ich zu bezweifeln. Nur weil eine Horde von Bastlern das Ding > immer wieder abschießen kann, bedeutet das nicht, daß man das mit einer > GESCHEITEN Stromversorgung + gescheites Softwarekonzept wie schon > beschrieben betreiben kann. Man kann vermutliche das OS auf eine read > only Partition packen und Read/write auf einer zweiten Partition machen, > ggf. auch komplett nur im RAM. Naja, als Informatiker nehme ich mich mal aus der "Horder der Bastler" raus - obwohl ich vor sehr vielen großen Respekt habe. Viele haben sich ein "Bastlerwissen" über Linux etc. angeeignet, dass ich bei manchen Kollegen vermisse. Selbst die beste Stromversorgung kann verbrechen und eine redundante Versorgung (USV) etc. für eine Monitoranzeige ist vollkommen überdimensioniert und sorgt für wieder andere Probleme (Gefahr mit Akkus, Brandhinweise, usw. usw.). > Wo ein Wille ist, ist auch ein Weg. Wegen deiner Anforderungen eine > komplett neue CPU-Plattform aufzubauen ist maximaler Overkill. Solche Sprüche liebe ich :) Daher habe ich Raspi & Co in meiner Frage ausgeschlossen - interessant, dass nur eine Antwort diese "Anforderung" berücksichtigt und ich ansonsten (wieder mal) eine Diskussion über Raspberry Pi und deren Einsatz erlebe. Auch die RPi V4 mit Booten via USB Stick/SSD ist keine Option. Alleine der Platzbedarf und Strommverbrauch steht im Vergleich zu einem µC steht in garkeinem Vergleich mehr.
Allgemeine Bitte: Kann die Diskussion über Möglichkeiten mit Raspberry Pi bitte in einen anderen Thread verlagert werden ? Ich habe diese Technik deutlich ausgeschlossen - genau aus diesem Grund. Danke für das Verständnis
Kim J. schrieb: > Ich habe diese Technik deutlich ausgeschlossen - genau aus diesem Grund. Akzeptiert. Ich nehme aber an, dass Du dann keine weiteren hilfreichen Hinweise mehr bekommen wirst, denn es gibt schlichtweg keine Lösung für "µC & HDMI" - jedenfalls nicht in Deiner Denke.
:
Bearbeitet durch Moderator
Danke für die Akzeptanz. Wie man am Arduino MKR VIDOR 4000 sieht, muss es ja was geben. Ich kann ja auch nicht der erste sein, der eine einfache HDMI/VGA Anzeige in höherer Auflösung (mind. 1600 Pixel breit) realisieren will. Wenn das Gerät in 20m Höhe angebracht wird, ist jedes Wartungsrisiko zu hoch - in doppeltem Sinn ;) Mit meinen ESP32 Chips und Projekten habe ich seit Jahren nicht ein Problem (Update und Setup per WLAN geht ja problemlos). Daher suche ich was in diese Richtung. Zu µC und VGA habe ich nur Bastellösungen mit geringer Auflösung oder farblos gefunden. Wäre ja im Notfall (bei höherer Auflösung) eine Alternative.
Sebastian schrieb: > Hat der Raspberry Pi Pico nicht integrierten Flash? Dafür gibt es > Quellcode für VGA oder DVI-Ausgabe. Letzteres kann an HDMI adaptiert > werden. > > Wenn es Linux sein darf, und etwas mehr Leistung: PcDuino V3 hat > NANDFlash onboard, und diverse Olinuxino-Boards von Olimex auch. Ein interessanter Ansatz. Nach solchen Boards hatte ich schon gesucht, Olimex ist scheinbar an mir vorbei gegangen. SD als optionaler Datenspeicher, LAN und HDMI. Danke für den Hinweis ! Hast Du Erfahrungen mit den Olinuxino-Boards ?
Kim J. schrieb: > Danke für die Akzeptanz. > > Wie man am Arduino MKR VIDOR 4000 sieht, muss es ja was geben. Ich kann > ja auch nicht der erste sein, der eine einfache HDMI/VGA Anzeige in > höherer Auflösung (mind. 1600 Pixel breit) realisieren will. Was willst du denn anzeigen? Einfache, statische Bilder bzw. Zahlen und Texte? Oder schon schnellere Bildwechsel oder gar Animationen und Video? Klar kann auch ein oller Arduino mit dem passenden Shield ein HDMI-Signal generieren und ab und an mal ein paar Texte darstellen, aber all das hat man schon fertig im R***** https://de.rs-online.com/web/p/entwicklungstools-display/1743283/?cm_mmc=DE-PLA-DS3A-_-google-_-CSS_DE_DE_Raspberry_Pi_%26_Arduino_und_Entwicklungstools_Whoop-_-(DE:Whoop!)+Entwicklungstools+Display-_-1743283&matchtype=&aud-826607885427:pla-331169378088&gclid=EAIaIQobChMIlI74s4Sc8gIVDtd3Ch3Lug_7EAQYASABEgL05vD_BwE&gclsrc=aw.ds Keine Ahnung was das Ding kann, billig ist es aber ;-) https://www.seeedstudio.com/Seeed-Studio-BeagleBoner-Green-HDMI-Cape.html Ok, kann nur HD-Ready mit 1280x720 https://hackaday.com/2019/07/26/hdmi-from-your-arduino/ > Wenn das > Gerät in 20m Höhe angebracht wird, ist jedes Wartungsrisiko zu hoch - in > doppeltem Sinn ;) OK > Mit meinen ESP32 Chips und Projekten habe ich seit Jahren nicht ein > Problem (Update und Setup per WLAN geht ja problemlos). Daher suche ich > was in diese Richtung. Dann brauchst du einen HDMI-Shield ohne Intelligenz bzw. ohne verstecke CPU mit Linux, den du per SPI oder ähnlich etc. ansteuern kannst. > Zu µC und VGA habe ich nur Bastellösungen mit geringer Auflösung oder > farblos gefunden. Wäre ja im Notfall (bei höherer Auflösung) eine > Alternative. Mit sowas würde ich im Jahr 2021 nicht mehr anfangen, wo HDMI einfach, preiswert und mit deutlich besserer Qualität als Standard verfügbar ist.
Ich habe dafür Raspi Compute Module. Die haben integrierten Flash. Keine SD-Karte notwendig. Rev 3 https://de.rs-online.com/web/p/raspberry-pi/1232011/ Rev 4 https://de.rs-online.com/web/p/raspberry-pi/2064847/
PittyJ schrieb: > Ich habe dafür Raspi Compute Module. Die haben integrierten Flash. Keine > SD-Karte notwendig. Und wo ist der HDMI-Ausgang? :-)
Falk B. schrieb: > Was willst du denn anzeigen? Einfache, statische Bilder bzw. Zahlen und > Texte? Oder schon schnellere Bildwechsel oder gar Animationen und Video? Statische Bilder in höherer Auflösung (1600+ Pixel). Optional animierte Symbole (animiertes Font Awesome, damit man eine Vorstellung von der "Komplexität" der "Animation" hat) > Klar kann auch ein oller Arduino mit dem passenden Shield ein > HDMI-Signal generieren und ab und an mal ein paar Texte darstellen Die hatte ich schon gefunden, aber die können wirklich meist nur bunten Text anzeigen (wie damals 80x25 DOS, wem's noch was sagt). > Dann brauchst du einen HDMI-Shield ohne Intelligenz bzw. ohne verstecke > CPU mit Linux, den du per SPI oder ähnlich etc. ansteuern kannst. Wenn Du eines kennst, immer raus damit. >> Zu µC und VGA habe ich nur Bastellösungen mit geringer Auflösung oder >> farblos gefunden. Wäre ja im Notfall (bei höherer Auflösung) eine >> Alternative. > > Mit sowas würde ich im Jahr 2021 nicht mehr anfangen, wo HDMI einfach, > preiswert und mit deutlich besserer Qualität als Standard verfügbar ist. Da stimme ich Dir zu - wäre nur besser als Nix.
Von Informatiker zu Informatiker: Auch wenn du es ausgeschlossen hast, schau dir den Rpi bzw. sonstige Linux SBC noch mal an. Wenn man ein Read-Only Linux nicht hinbekommt dann liegt das ausschließlich an dem Informatiker(?) der es in Betrieb genommen hat. Vermutlich läuft sogar die Mehrzahl der Linuxe im Read-Only betrieb oder mit einem RAM-Overlay über das RO-FS auf irgendwelchen Geräten denen man es nicht ansieht, dass da überhaupt ein OS drauf ist. Linux kann das und es geht auch sehr gut. Man muss sich halt damit auskennen. Ansonsten schau dir das doch mal von den Anforderungen her an: Du willst 1600x1200 Auflösung, mit Animationen. Bilder --> 32bits/Pixel. Du brauchst dafür viel Video-RAM und eine Bandbreite von wenigstens 440MB/s allein für den Ausgang, ganz zu schweigen von den Animationen. Du willst also eine GPU mit dediziertem VRAM. Willst du den Treiber dafür wirklich selbst schreiben? Klar die GPU muss nur 2D können, aber ich bezweifle, dass du die 440MB/s über die CPU sauber und zuverlässig hinbekommst.
Johannes schrieb: > Von Informatiker zu Informatiker: Auch wenn du es ausgeschlossen hast, > schau dir den Rpi bzw. sonstige Linux SBC noch mal an. Es hat diverse Gründe, warum diese Boards asgeschlossen sind. Diese hier zu diskutieren würde jedoch den Rahmen/Thread sprengen und (sh. oben) die Frage in eine andere (hier falsche) Richtung leiten. Leider gibt's immer eine breite Masse, welche nur den RPi (und Derivate) kennt und dann krampfhafte versucht, dafür eine Lösung und Argumente zu finden. Wie ein Navi: "Fahren Sie auf die Autobahn" - mag ja die schnellste und beste Lösung sein ... nur gibt's halt Fälle, die einen anderen Weg brauchen. > Wenn man ein Read-Only Linux nicht hinbekommt dann liegt das > ausschließlich an dem Informatiker(?) der es in Betrieb genommen hat. Stimmt :) > Vermutlich läuft sogar die Mehrzahl der Linuxe im Read-Only betrieb oder > mit einem RAM-Overlay über das RO-FS auf irgendwelchen Geräten denen man > es nicht ansieht, dass da überhaupt ein OS drauf ist. Stimmt auch :) > Linux kann das und es geht auch sehr gut. Man muss sich halt damit > auskennen. Und wieder richtig :) Ich bin durchaus ein Freund der RPi und seit V4 und der Fähigkeiten des SSD/USB Bootens habe ich einige Geräte als Mini-Mailserver etc. im Einsatz. Feine Sache - nur nicht für dieses Projekt. > Du willst 1600x1200 Auflösung, mit Animationen. Bilder --> 32bits/Pixel. Animation rein optional und ein "nice to have". Die RPi sind eine wunderbare Erfindung für Bastelgrundlagen und Testprojekte. Auch für kleine private Lösungen fast immer eine gute Grundlage. Für eine reine Anzeige in einem sehr schwer zugänglichen Bereich gibt es teure Fertiglösungen - dann würde ich aber weder lernen noch hier fragen. Daher ist es im ersten Schritt das Ziel, eine 1600 Pixel Grafik per µC auf einen angeschlossenen Monitor zu bekommen.
Falk B. schrieb: > Und wo ist der HDMI-Ausgang? :-) Auf der Rückseite. Auszug aus https://www.golem.de/news/compute-module-4-der-raspberry-pi-4-auf-einer-halben-kreditkarte-2010-151591.html Auf der Unterseite des Compute Module 4 sind zwei kompakte High-Density-Verbinder angebracht. Über diese Schnittstellen lässt sich etwa das separat erhältliche IO Board anschließen. Das bringt neben zwei USB-2.0-Ports, USB-C, GPIO, RJ45 und einem SD-Kartenleser auch einen kurzen PCIe-x1-Slot für diverse Standard-Erweiterungskarten. Auch zwei HDMI-Ports in voller Größe sind hier vorhanden.
Kim J. schrieb: > Ein interessanter Ansatz. Nach solchen Boards hatte ich schon gesucht, > Olimex ist scheinbar an mir vorbei gegangen. SD als optionaler > Datenspeicher, LAN und HDMI. Danke für den Hinweis ! > > Hast Du Erfahrungen mit den Olinuxino-Boards ? Ich habe iMX233-Olinuxino und A13-Olinuxino (mit VGA) schon eingesetzt, die Zuverlässigkeit war absolut kein Problem. Für HDMI wäre wohl der neuere A20-Olinuxino geeignet.
Jetzt muss ich mal blöd fragen - der OLinuXino ist ja auch nur ein Linux SBC, die hattest du ja prinzipiell ausgeschlossen. (Ich schrieb von "RPi bzw. sonstigen Linux SBC".) Wie jetzt also? Ist das Problem die Hardware oder die Software? Willst du die GPU auf dem OLinuXino selbst in C ansteuern?
Möchte dem TE nichts vorwegnehmen, aber ich denke, ein SBC mit NandFlash, also ohne SD-Karte, war okay, es ging nicht gegen das Linux an sich, sondern an verschleißärmeren Speicher.
Die Beagle-Bones mit TI Sitara haben HDMI, allerdings über einen Adapter. Dafür sind sie günstig und verbreitet. Für die NXP i.MX gibt es auch diverse Boards mit HDMI und auch DisplayPort. Die haben dann auch leistungsfähige Grafikbeschleuniger mit OpenGL/Vulkan-Unterstützung. z.B. hier: https://www.variscite.com/products/system-on-module-som/?display=Display%20HDMI . Mit diesem hab ich gute Erfahrungen gemacht: https://www.variscite.com/product/evaluation-kits/dart-mx8m-kits/ allerdings nicht ganz billig. Alle diese Varianten können auch Bare-Metal ohne Linux programmiert werden; bei den TI Sitara ist es allerdings einfacher/besser unterstützt. Gerade HDMI ist dabei aber sehr komplex, und die Grafikbeschleuniger praktisch gar nicht benutzbar (keine Doku verfügbar).
PS: Die genannten Boards haben eMMC-Flash und optional SD-Karte. Die Variscite-Boards starten mit Linux auch recht schnell. Yocto Linux wird gut unterstützt und ist bekanntlich gut anpassbar, sodass man die Boot-Zeit sicher noch optimieren kann. Es gibt auch noch PI-Varianten wie den "Revolution-PI" für industrielle Anwendungen, mit eMMC-Flash und HDMI-Ausgang.
Falk B. schrieb: > PittyJ schrieb: >> Ich habe dafür Raspi Compute Module. Die haben integrierten Flash. Keine >> SD-Karte notwendig. > > Und wo ist der HDMI-Ausgang? :-) Beim Compute Modul 3 liegt alles an den 200 Pins dran. Da kann man sich ein Eval-Trägerboard kaufen, oder selbst designen. (Hat ein Kollege von mir gemacht)
Kim J. schrieb: > Daher ist es im ersten Schritt das Ziel, eine 1600 Pixel Grafik per µC > auf einen angeschlossenen Monitor zu bekommen. Bei dieser Auflösung ist eine FPGA-Lösung der einzige realistische Weg unterhalb der Linux-Applikationsprozessoren. Auch das MKR VIDOR 4000 basiert ja auf einem FPGA. Also wirst Du Dich mit VHDL oder Verilog und mit digitaler Logik befassen müssen. Der uC ist dann überflüssig - der kann als Logik dann gleich mit ins FPGA rein. Viel Spaß beim Lernen. fchk
Frank K. schrieb: > Bei dieser Auflösung ist eine FPGA-Lösung der einzige realistische Weg > unterhalb der Linux-Applikationsprozessoren. Was heißt "unterhalb"? Eine FPGA-Lösung ist so ziemlich in jeder Hinsicht aufwendiger, komplizierter und vermutlich teurer als eine Lösung mit Anwendungsprozessor. Einen FPGA für etwas zu nehmen wofür es jede Menge dedizierte Hardware auf dem Markt gibt klingt realitätsfern.
Programmierer schrieb: > Frank K. schrieb: >> Bei dieser Auflösung ist eine FPGA-Lösung der einzige realistische Weg >> unterhalb der Linux-Applikationsprozessoren. > > Was heißt "unterhalb"? Eine FPGA-Lösung ist so ziemlich in jeder > Hinsicht aufwendiger, komplizierter und vermutlich teurer als eine > Lösung mit Anwendungsprozessor. Einen FPGA für etwas zu nehmen wofür es > jede Menge dedizierte Hardware auf dem Markt gibt klingt realitätsfern. Die Alternativen will der Fragesteller ja nicht. Er will ja lernen. Ok, kein Problem. fchk
Frank M. schrieb: > Falk B. schrieb: >> Und wo ist der HDMI-Ausgang? :-) > > Auf der Rückseite. > > Auszug aus > https://www.golem.de/news/compute-module-4-der-raspberry-pi-4-auf-einer-halben-kreditkarte-2010-151591.html Aber nicht auf dem Modul, welches hier verlinkt war. Beitrag "Re: µC Board mit HDMI (notfalls VGA) Ausgang" Ok, ich hab nur den 1. Link angeclickt. Mein Fehler! > Auf der Unterseite des Compute Module 4 sind zwei kompakte > High-Density-Verbinder angebracht. Über diese Schnittstellen lässt sich > etwa das separat erhältliche IO Board anschließen. Das bringt neben zwei > USB-2.0-Ports, USB-C, GPIO, RJ45 und einem SD-Kartenleser auch einen > kurzen PCIe-x1-Slot für diverse Standard-Erweiterungskarten. Auch zwei > HDMI-Ports in voller Größe sind hier vorhanden. Schön und gut, aber warum das Rad neu erfinden, wenn es schon Raspberry Pis mit HDMI Stecker gibt? Sind die alles Schrott und nur das Compute Modul mit Flash nutzbar? Nö. AUßerdem ist es nicht ganz trivial, da ein Baord mit HDMI-Stecker anzuflanschen, das kostet gerade als Einzelstück viel Aufwand. Oder gibt es das schon fertig? Kann man alles machen, ist aber in meinen Augen ein Krampf, der nur in der SD-Karten Phobie begründet liegt. Edit Ach so, in deinem Link sieht man ja ein großes IO-Board, allerdings ohne Preis und Bezugsquelle. Ändert aber nix an meinem Standpunkt ;-)
:
Bearbeitet durch User
https://www.phytec.de/produkte/system-on-modules/phycore-imx-6/ Dieses, bzw. etwas aus der Familie, dürfte ungefähr die am wenigsten überdimensionierte Hardware sein, also für HDMI mit 1600x1200. Damit man schnell ein Ergebnis sieht, läuft erstmal Linux. Anschließend kann man selbst etwas kleineres programmieren. Und bei Bedarf auch ein eigenes Board entwickeln.
Dann Hätten wir noch eine Industrial microSDHC / SDXC Memory Card von swissbit https://www.mouser.de/datasheet/2/615/S_56u_fact_sheet-1868437.pdf Mit Advanced power-off reliability technology Dann noch Read-Only beim Pi. Damit sollte dann wirklich nichts mehr passieren. Leider im Moment nicht zu haben, wie so vieles...
Moin, Falk B. schrieb: > Kann man alles machen, ist aber in meinen Augen ein Krampf, der nur in > der SD-Karten Phobie begründet liegt. Nicht nur, denn: Kim J. schrieb: > Es hat diverse Gründe, warum diese Boards asgeschlossen sind. Diese hier > zu diskutieren würde jedoch den Rahmen/Thread sprengen und (sh. oben) > die Frage in eine andere (hier falsche) Richtung leiten. Es sind wohl auch die "diversen" Gruende; diese koennten aber Teile der Bevoelkerung verunsichern :-P SCNR, WK
Persoenliche Erfahrung: Habe hier 2 Sheva Pogoplug Linux mit Marvel processor seit ueber 10 Jahre ohne Probleme. Hat alle Stromausfaelle ueberlebt. Der Trick: SD Karte ist schreibgeschuetzt und system mountet "ro" read only. Linux mit SD kann also durchaus eine Option sein. Auch meine 7 alte Banana Pis (erste Version) laufen genau so stabil. Weiss nicht wie lange, aber Jaaaaahre. ;) My 2 cents
Lothar M. schrieb: > Dann sorg einfach dafür, dass das OS nicht (oder nur so weing wie > möglich) auf die SD-Karte schreibt, dann lebt die ewig bla bla bla... Auch für dich als Moderator gild: das Anliegen des Fragestellers beantworten und nicht dein besseren Willen durchsetzen! Kim J. schrieb: > ich suche ein µC Board, welches einen HDMI Anschluss und GPIO hat. > WLAN wäre gut, kann ja aber per GPIO ggf. angeschlossen werden.
Content B. schrieb: > Auch für dich als Moderator gild: das Anliegen des Fragestellers > beantworten und nicht dein besseren Willen durchsetzen! Ist das jetzt deine Antwort auf die Frage des TO? (Habe gerade keine Lust, dir an die Nase zu fassen - musst du selber machen.)
Kim J. schrieb: > Wenn das > Gerät in 20m Höhe angebracht wird, ist jedes Wartungsrisiko zu hoch - in > doppeltem Sinn ;) Kim J. schrieb: > Daher ist es im ersten Schritt das Ziel, eine 1600 Pixel Grafik per µC > auf einen angeschlossenen Monitor zu bekommen. Wie gross (in Metern) soll die Anzeige denn eigentlich werden?
Klaus W. schrieb: > (Habe gerade keine Lust, dir an die Nase zu fassen - musst du selber > machen.) Merkst selber das du scheiße geschrieben hast?
Kim J. schrieb: > das komplexere OS (logischerweise im Vergleich zum einfachen µC) sorgt > automatisch für viel Schreibzugriffe (Logs, Swap, usw) Das stimmt nicht. Linux lässt sich so konfigurieren, dass es die Karte überhaupt nicht beschreibt. Es gibt auch sogenannte "Live DVDs", die einen fast vollständigen Linux Desktop samt Web Browser enthalten, die ganz ohne beschreibbares Medium auskommen. Es ist nur eine Frage der Konfiguration. In der Standard Konfiguration schreibt der Raspberry Pi einiges auf die Karte, aber nicht so viel dass man sich Sorgen machen muss. Ich hatte einen 2,5 Jahre lang laufen, um die Verfügbarkeit/Performance mehrerer Webserver zu testen und zu protokollieren. In der Zeit wurde das Ding mehrfach einfach vom Stromnetz getrennt, ohne herunter zu fahren. Das Ding hat in der ganzen Zeit keine Fehlfunktion gehabt. Lothar M. schrieb: > Dann sorg einfach dafür, dass das OS nicht (oder nur so weing wie > möglich) auf die SD-Karte schreibt Kim J. schrieb: > Das ist technisch bei OS wie Linux nicht zuverlässig machbar. Doch ist es.
Auch wenn du es nicht mehr hören magst: Ich schließ mich der Raspberry Pi/"oder irgendein alternativer SBC"-Fraktion an. Wenn du dich um die ganzen Details nicht kümmern magst, dann schau dir Projekte wie NARD (http://www.arbetsmyra.dyndns.org/nard/) an. Wenn du unbedingt irgendwas mit uC machen willst, dann kannst du ja z.B die Versorgungsspannung mit nem uC überwachen. Wenn die Versorgungsspannung wegbricht, dann schaltest du auf ne Powerbank um und schickst dem SBC ein Signal zum sauberen Runterfahren.
Stefan ⛄ F. schrieb: > Das stimmt nicht. Linux lässt sich so konfigurieren, dass es die Karte > überhaupt nicht beschreibt. Es gibt auch sogenannte "Live DVDs", die > einen fast vollständigen Linux Desktop samt Web Browser enthalten, die > ganz ohne beschreibbares Medium auskommen. > > Es ist nur eine Frage der Konfiguration. In der Standard Konfiguration > schreibt der Raspberry Pi einiges auf die Karte, aber nicht so viel dass > man sich Sorgen machen muss. Ich hatte einen 2,5 Jahre lang laufen, um > die Verfügbarkeit/Performance mehrerer Webserver zu testen und zu > protokollieren. In der Zeit wurde das Ding mehrfach einfach vom > Stromnetz getrennt, ohne herunter zu fahren. Das Ding hat in der ganzen > Zeit keine Fehlfunktion gehabt. full ack. In der Anfangszeit (zu Raspberry Pi 1 Zeiten) hab ich's öfters mal geschafft ne SD Karte zu killen. Aber das ist mir jetzt schon seit Jahren nicht mehr gelungen (obwohl ichs öfters mal drauf anlege). Wer dennoch etwas die SD Karte entlasten möchte kann sich z.B mal log2ram (https://github.com/azlux/log2ram) ansehen. Einfach zum Einrichten und bringt einiges.
Irgendwie witzig. Wenn ich die mit Abstand beste Option ausschließe und dabei nur einen Grund nenne der nun wirklich Bullshit ist, dann ist es klar, gut und richtig dass man mit Nachdruck darauf hingewiesen wird. Ich selbst mag Raspi nicht soo besonders, einfach weil heutzutage jeder Lurch damit spielt. Aber es ist hier einfach die beste Option. Die SD-Karten sind sehr zuverlässig. Und selbst wenn sie es nicht wären, könnte man der Variante mit SD aus dem Weg gehen.
Veit D. (devil-elec) schrieb: > Wenn ich die mit Abstand beste Option ausschließe Ich denke es ist realistisch betrachtet auch die einzige Option. Damit meine ich nicht nur den Raspberry Pi sondern offene (frei programmierbare) Systeme mit Linux. Es gibt ja noch andere.
Content B. schrieb: > Lothar M. schrieb: >> Dann sorg einfach dafür, dass das OS nicht (oder nur so weing wie >> möglich) auf die SD-Karte schreibt, dann lebt die ewig bla bla bla... > > Auch für dich als Moderator gild: das Anliegen des Fragestellers > beantworten und nicht dein besseren Willen durchsetzen! > > Kim J. schrieb: >> ich suche ein µC Board, welches einen HDMI Anschluss und GPIO hat. >> WLAN wäre gut, kann ja aber per GPIO ggf. angeschlossen werden. Danke !! Das ist GENAU mein Empfinden. Es wird wild in der Gegend rumgeschrieben, egal nach was ich genau fragte. Über das WARUM kümmert sich kaum jemand oder man man sich gerne auch lustig (@derguteweka). Es wäre mEn nicht zielführend gewesen, hier alle Gründe anzuführen, denn dann würden die Gründe nur zerpflückt. Leider ohne Rücksicht, ob es vielleicht einfach Teil der Frage ist. Aber wehe, man kritisiert solches Verhalten im Forum ... dann bricht ein Shitstorm los (und ja, das war auch in diesem Thread so und wird wohl auch auf diesen Beitrag passieren). In fast jedem Forum gilt es, die Frage des TO zu bearbeiten und nur nebenbei alternative Ideen anzusprechen. Sollten diese dann nicht erwünscht sein, so wird der TO seine Gründe haben. Auch ich habe mir von einigen wenigen der oberen Beiträgen gute Ideen gezogen und dann (recht schnell) die Beobachtung des Threads beendet. Das ist eigentlich schade, denn dadurch können gute (aber späte) Beiträge untergehen. Aber dieses ständige "doch doch doch, da hilft nur das oder das" ist höchst nervend. Als Praxis-Beispiel für alle "ja, aber ..." Leser: Das Navi schickt jeden möglichst auf die Autobahn. Auch hier bei uns in Stadtnähe - selbst wenn der Weg über Land kürzer ist. Für alle Auswärtigen, Neulinge u.a. wird das meist keinen großen Unterschied machen, nicht deutlich länger dauern und eine gute Lösung sein. Wenn ich nun allerdings gezielt nach dem Weg über Land frage, warum wird dann bis auf's Blut über den Sinn dieses Weges diskutiert und jede "Korrektur" auf diese Frage teils lächerlich beantwortet ? Nicht genügend Gründe ? Nun ja, Beispiele: - Mein Auto fährt nicht schneller als 50 - ich habe einen Anhänger dran - die Autobahn ist zu der Zeit überlastet (und ich weiß es aus Erfahrung) - die Landschaft ist schöner - ich habe Angst vor Autobahnen - auf dem Landweg kann ich vielleicht spontan am Bauernhof anhalten oder mal eine Pause machen - ich habe eine Sextanerblase und muss vielleicht häufiger "mal eben" anhalten - ich muss tanken und das geht an der Landstraße leichter und günstiger, - ich liebe die Landluft - ... System verstanden ? Ich gehe Wetten ein, dass ich bei einer solchen Frage in einem Autofahrerforum (um beim Bild zu bleiben) eine völlig chaotische Diskussion über Ängste, Tankstellen, bessere Navis mit Verkehserkennung, schnellere Autos und Toiletten bekomme ... aber eine einfache Antwort wird dabei schwer zu finden sein. Das gleich passiert hier - fast in jedem Thread. Für meine gezielte Frage habe ich Gründe, auch wenn's viele nicht nachvollziehen können oder wollen (und ich aus o.a. Gründen nicht ausführlich schreibe). Bin ich keinem böse und kann ich akzeptieren - stellt sich mir nur stets die Frage, warum meine Frage und die einfache und deutliche Begrenzung nicht akzepiert wird. Wenn jemandem meine Frage nicht gefällt: Es gibt andere Threads. Wenn jemandem meine Eingrenzung nicht gefällt: Es gibt andere Threads. Wenn jemandem meine Meinung als TO nicht gefällt: Es gibt andere Threads. Kann doch nicht so schwer sein, oder ? Und jetzt kann's losgehen mit dem Shitstorm und Abwerten dieses Beitrages .... aber das musste mal raus, denn es nervt mich schon lange und ich denke, ich bin damit echt nicht alleine.
Dann geh halt deinen eigenen besseren Weg. Du wirst schon feststellen, warum du auf diesem alleine bist. Tip: Es hängt damit zusammen, dass Multimedia-Funktionen wie eben HDMI und hohe Auflösung Hand in Hand mit allgemeinen hohen Anforderungen an die Leistung gehen, und die wird nun mal von Anwendungsprozessoren geboten. Wenn du unbedingt deinen "HDMI-Sattelschlepper" über einen Trampelpfad schicken möchtest um die Autobahn zu vermeiden - vielleicht geht es ja irgendwie, aber kosteneffizient und flexibel wird es nicht. Du kannst ja berichten wenn du es schaffst. Wissen über solch eine spezielle Lösung wirst du dir aber selbst aneignen müssen, da kann dir kaum jemand helfen können. Daher ist es auch sinnlos so etwas öffentlich zu fragen. Nach dieser Tirade traut man sich jedenfalls nicht mehr hybride Lösungen vorzuschlagen, z.B. Anwendungsprozessor für Grafik plus Mikrocontroller für die hochgeheimen Anforderungen (Echtzeit? Leistungsaufnahme?).
Kim J. schrieb: > Wenn jemandem meine Frage nicht gefällt: Es gibt andere Threads. Wenn jemandem eine Antwort nicht gefällt: Höflich Danke sagen und was anderes nehmen. Wenn es nichts anderes gibt oder niemand hier das gewünschte kennt: Lass deinen Frust nicht an uns aus. Wir sind nicht daran Schuld.
PS: Es ist den Antwortenden gegenüber sehr unhöflich, die wichtigsten Anforderungen ("meine Gründe"), geheim zu halten. Es gibt diverse Möglichkeiten die bisher genannten Anforderungen zu erfüllen, aber kategorisch auf einem Mikrocontroller zu bestehen - insbesondere weil die Definition dessen ohnehin nicht scharf ist und es Dinge wie die PRU-ICSS der Ti Sitara gibt - ist nicht sehr produktiv.
Stefan ⛄ F. schrieb: > Kim J. schrieb: >> Wenn jemandem meine Frage nicht gefällt: Es gibt andere Threads. > > Wenn jemandem eine Antwort nicht gefällt: Höflich Danke sagen und was > anderes nehmen. Danke für diese dusselige Antwort. Ich muss mich als TO durch den "Mist" durchlesen. Auch viele andere Threads haben das gleiche Problem. Die Threads werden "gekapert" und nach wenigen Beiträgen ist das Ziel verfehlt. Wie damals in der Schule: "Netter Aufsatz - -aber leider völlig am Thema vorbei". Das ist extrem schade für viele TO, die eine Frage haben und dann über Rahmenbedingungen und Kriterien diskutieren müssen. Nichts gegen solche Ideen - wenn sie aber ausgeschlossen sind, dann muss ich darüber in DEM Thread doch nicht noch diskutieren, oder ? @Moderator: Dieser Thread kann gerne geschlossen werden, falls es sowas gibt. Ich bin raus. Danke an Martin, Frank M (ukw) und Content B.
Kim J. schrieb: > Danke für diese dusselige Antwort. Bist du dir eigentlich im klaren wer du bist und wo du uns gegenüber stehst? Du bist hier der Bittsteller. Doch anstatt dich dementsprechend zu verhalten, hast du zahlreiche Leute abgeschreckt, die noch nicht geantwortet haben aber nun auch nicht mehr wollen, nachdem du alle nieder gemacht hast, die die gerne helfen wollten. Du trittst hier sehr unhöflich und undankbar auf. Richtig unangenehm ist das. Ein einfaches "Nein danke, ich möchte nichts mit Linux", ohne persönliche Angriffe wäre in Ordnung gewesen.
Moin, Stefan ⛄ F. schrieb: > Du trittst hier sehr unhöflich und undankbar auf. Richtig unangenehm ist > das. Aber auch lustig :-) SCNR, WK
@Kim J.: Dein Problem ist die hohe Auflösung. Bis 800*480 Pixel hättest Du beispielsweise den hier nehmen können: https://www.microchip.com/en-us/product/PIC32MZ2064DAS176 Bis 1366*768 Pixel hättest Du das hier nehmen können: https://www.raio.com.tw/en/RA8889.html Darüber bleibt Dir im Rahmen Deiner Vorgaben nur eine FPGA-Lösung. Das ist machbar, eigentlich so kompliziert nicht, aber eine recht steile Lernkurve, wenn Du das noch nie gemacht hast. https://www.fpga4fun.com/HDMI.html https://github.com/hdl-util/hdmi/ fchk
Frank K. schrieb: > Bis 800*480 Pixel hättest Du beispielsweise den hier nehmen können: > https://www.microchip.com/en-us/product/PIC32MZ2064DAS176 > Bis 1366*768 Pixel hättest Du das hier nehmen können: > https://www.raio.com.tw/en/RA8889.html Können die beide HDMI?
Stefan ⛄ F. schrieb: > Frank K. schrieb: >> Bis 800*480 Pixel hättest Du beispielsweise den hier nehmen können: >> https://www.microchip.com/en-us/product/PIC32MZ2064DAS176 > >> Bis 1366*768 Pixel hättest Du das hier nehmen können: >> https://www.raio.com.tw/en/RA8889.html > > Können die beide HDMI? Nein, aber entsprechende Umsetzer auf DVI/HDMI existieren und sind leicht anschließbar. z.B. https://www.ti.com/product/TFP410 fchk
Kim J. schrieb: > Danke an Martin, Frank M (ukw) und Content B. Jetzt wüsste ich ja schon gerne was an meinen Vorschlägen (Sitara & Co) schlecht war - ja, kein Mikrocontroller, aber haben nicht die Nachteile von Raspberry PIs. Aber ich weiß, du hast deine Gründe, und wer bin ich schon danach zu fragen.
Kim J. schrieb: > Der Arduino MKR VIDOR 4000 hat zwar miniHdmi fällt ebenfalls raus, > da es nicht eine dokumentierte Funktion zur Nutzung der HDMI > Schnittstelle gibt. Zumindest gibt es irgendwas: https://github.com/vidor-libraries/VidorBitstream Arduino halt... Jemand, der noch nie ein Arduino-Board in den Fingern hatte, muss wohl viel lernen. Aber die HDMI-Benutzung an sich scheint nicht das Problem zu sein. Im Forum finde ich überwiegend Fragen wie "Ich sehe nur das Logo oder das Bild von der Camera, aber er erkennt meinen QR-Code nicht". Die Hardware vom MKR VIDOR 4000 ist doch geradezu perfekt? Oder ist das Board genauso geächtet wie der RPi?
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.