Moin,
bin gerade dabei, eine Art Feature-Phone zu bauen. Grund dafür sind
Bastelwut und gnadenlose Selbstüberschätzung, man kennt es :-)
TL;DR: Kennt ihr geeignete Linux-fähige SoM mit geringem
Standby-Verbrauch für so ein Projekt, vergleichbar mit diesem hier:
https://www.acmesystems.it/roadrunner ?
Ich ziele auf folgende Eigenschaften ab:
-Akzeptable Standby-Laufzeit, ~1 Woche mit einem ~15 Wh Akku
5
-Über kompilierte Programme erweiterbar, möglichst ohne Reboot
Ich habe NICHT vor, Android nachzubauen. Ich habe auch NICHT vor, einen
modernen Browser da einzubauen, oder sonst irgendwelche
Himmelfahrts-Programmieraktionen anzugehen. Die Programme, die später
darauf laufen sollen, sind sowas wie ein Chat-Client, Notizblock,
Bildaufnahme, SSH-Console usw. Wie man es von den alten Nokias und
Sony-Ericssons halt kennt.
Allein aufgrund des Stromverbrauchs sind Raspberry Pi und Konsorten von
vornherein ausgeschlossen, da müsste man alle 4 Stunden Akku aufladen...
Einen STM32 F/H7 Mikrocontroller habe ich auch in Betracht gezogen,
allerdings ist da die USB-Hardware etwas beschränkt was die Anzahl
Endpoints angeht und die Treiber für WLAN und LTE-Modem müsste ich
erstmal selber schreiben, da wären wir dann wieder bei der
Selbstüberschätzung angekommen.
Bisherige BOM:
1
-5.0" oder 4.3" IPS Touch-Display
2
-Lichtsensor zur Anpassung der Hintergrundbeleuchtung
3
-Mikrofon/Sound-Codec/Kamera je nachdem was der Prozessor an Interfaces hat
4
-SIMCOM A7600E LTE-Modem (via USB)
5
-GN-801 GNSS Modul (Ublox UBX-M8030)
6
-REALTEK RTL8188ETV SoM oder ähnliches für Wifi (via USB)
7
-SD-Karte oder QSPI-Flash-IC als Bootdrive
Daher möchte ich ein Linux-fähiges SoM heranziehen. Ich habe bereits von
ACME-Systems das RoadRunner SoM im Visier. Es unterstützt alle
benötigten Interfaces und Suspend-to-RAM fürs beschleunigte Aufwachen,
hat aber "nur" einen Kern mit "nur" 500MHz:
https://www.acmesystems.it/roadrunner
Wenn ich schon ein Betriebssystem darauf laufen lasse, dann auch gerne
mit mehr Bumms. Kennt ihr ähnliche Module, die 2xUSB, MMC,
24bit-RGB-Display und die üblichen UART, SPI, I2C etc unterstützen UND
auch noch für Bastler beschaffbar sind?
Schieße ich mir mit dem SIMCOM Modem ins Bein bzw. habe ich was
übersehen?
Diesen Hersteller hatte ich noch nicht auf dem Schirm. Dokumentation und
Softwarepakete scheinen öffentlich verfügbar zu sein, sehr sympathisch:
https://www.phytec.de/support/downloads/
STM32MP15 und iMX6 finde ich interessant, werde mich da mal durchwälzen.
Vielen Dank für den Tipp!
Florian S. schrieb:> Allein aufgrund des Stromverbrauchs sind Raspberry Pi und Konsorten von> vornherein ausgeschlossen, da müsste man alle 4 Stunden Akku aufladen...
Da musst du aber nochmal drüber nachdenken, denn nach meiner Erfahrung
kochen die Hersteller von Prozessoren der selben Leistungsklasse auch
mit ähnlichen Wasser ähnlich heiß.
> Wenn ich schon ein Betriebssystem darauf laufen lasse, dann auch gerne> mit mehr Bumms.
Oder andersrum: wenn du die Rechenleistung des RPi willst/brauchst, dann
wird auch dein i.MX6 gut warm.
> -Grafisches Touchdisplay, kapazitiv, 24-bit RGB Interface
Mir fällt dazu "Backlight" ein. Und die passende Frage dazu: wieviel
Strom/Energie braucht dein Display?
No Y. schrieb:> Ein i.MX6ULL kommt aber Leistungsmäßig nie in die Sphären eines RPi4..
Sag ich ja: von nix kommt nix.
Wenn ich Rechenleistung will, bekomme ich Wärme.
Nur bei den Idle- und Sleep-Modi kann dann eine Low-Power-CPU wirklich
stechen. Und dann kommt es auf die verbaute Peripherie an...
Moin,
Hier gaebs Board mit SoMs von Qualcomm:
https://eragon.einfochips.com/
Datenblattsituation ist wahrscheinlich immernoch voellig desastroes;
aber potentiell sollten diese Chips sich auch
runtertakten/schlafenlegen/... lassen, um Energie zu sparen.
Gruss
WK
Wir hatten sowas vor 10 Jahren auf Basis des OMAP3 durchgezogen (weil es
die Chips gab und mehrere 1000 Seiten technische Dokumentation). Das
Ergebnis hieß dann "GTA04" und hatte in etwa die Rechenleistung eines
iPhone 3GS. Erfüllte alle Deine Anforderungen (plus weitere).
Bis heute nicht wirklich gelöst ist das Problem der
Standby-Stromaufnahme. Da hört Standard-Linux auf, weil irgendwelche
Treiber ihren Teil im Chip nicht rechtzeitig runterfahren und sich
niemand auf diese Optimierungen konzentriert. Wir haben den OMAP3 mit
einem 3.12-Kernel auf ca. 20mA im Standby runterschrauben können. Und
das Funkmodul auf 3mA. Das gab dann eine Standbyzeit von max. 48
Stunden. Leider ist es mit neueren Kernels nie gelungen an diese
Bestwerte wieder heranzukommen.
Dann gab es von anderen mal ein Projekt "ZeroPhone" auf Basis des RasPi
Zero. Ist leider eingeschlafen.
Aktuelle Projekte sind Purism Librem 5 und PinePhone. Letzteres auch vom
Preis her interessant.
Beide kann man dazu nutzen um seine eigene GUI zu stricken.
>>> Da musst du aber nochmal drüber nachdenken, denn nach meiner Erfahrung>>> kochen die Hersteller von Prozessoren der selben Leistungsklasse auch>>> mit ähnlichen Wasser ähnlich heiß.
Du nimmst wohl an, dass ich Leistung für lau plus
Microcontroller-ähnlichen Stromverbrauch erwarte, nur weil ich so ein
Modul heranziehe :-) Ich habe mir schon ein paar Gedanken dazu gemacht.
Mir ist klar, dass man wegen dem DRAM und anderer Peripherie kaum unter
20mA im Standby kommen wird.
Diese Module bieten aber wenigstens Unterstützung für Suspend-to-RAM
plus jede Menge Interfaces. Rechenleistung ist nice-to-have. Beim
Standby-Verbrauch glänzt der Pi ganz und gar nicht:
https://github.com/raspberrypi/linux/issues/1281https://www.raspberrypi.org/forums/viewtopic.php?t=202067
Die Pi Foundation gibt sich keine besondere Mühe, wenn es darum geht
irgendwelchen Software/Hardware Support dafür an den Start zu bringen.
Selbst das "Compute Module" ist nicht optimal. Es bietet 28 GPIO, was
auch kein Problem wäre, wenn man denn ein MIPI-DSI Display nutzt (Ein
Paralleldisplay würde 26 der 28 GPIO wegfressen). Die DSI Schnittstelle
wird als "Ist undokumentiert und unterstützt nur offizielle Displays"
bezeichnet. CM4 Datenblatt, Seite 12:
https://datasheets.raspberrypi.org/cm4/cm4-datasheet.pdf
Da soll man doch bitte Paralleldisplays nutzen, ja sehr witzig.
Sucht mal nach "Raspberry Pi Suspend to ram" oder "Raspberry Pi Sleep
Mode", da erwartet einen ein Trauerspiel...
>>> Hier gaebs Board mit SoMs von Qualcomm: https://eragon.einfochips.com/ [...]
Nette Hardware, leider ist die Situation mit der "Verfügbarkeit" von
Dokumentation in diesem Fall ein No-Go für mich.
>>> [...] "GTA04" [...]
Tolles Projekt, ihr habt meinen vollen Respekt. Sowas in der Art möchte
ich auch bauen, nur mit anderem Display und Modem. Ich will keine volle
Mainstream-Distribution darauf laufen lassen, eher Buildroot oder Yocto
mit eigenem GUI-Stack und Applikationen. Es geht mir halt ums Bauen bei
der ganzen Sache. Ich möchte embedded Linux kennenlernen.
>>> [...] Librem 5 [...]
Als Dailydriver finde ich normale Android Smartphones mit LineageOS oder
ähnliches ganz nett. PureOS scheint viel Bloat von den
Desktop-Distributionen übernommen zu haben. Es wirkt auf mich als
wüssten die Entwickler nicht ganz, ob sie jetzt ein Linux-Notebook im
Smartphonekostüm oder ein Smartphone bauen. Die Hardware die sie
verbauen ist wirklich großartig, aber Overkill für das was ich vorhabe.
Schaut euch mal ein paar Videos vom Librem 5 an, das Teil krebst rum wie
sau und das bei der netten Hardware die sie verbauen.
Auch wenn der Raspberry Zero nichts für Dich ist und das Zerophone
leider mausetot, wende Dich ruhig mal an den Entwickler, Arsenijs aus
Riga. Er ist nett, hat lange an dem Thema gearbeitet und anscheinend auf
allen Ebenen mit dem System zu tun, von der Hardware bis zum UI ("ZPUI",
in Python geschrieben).
Da ich so oder so ein Trägerboard machen muss, wäre das sicher machbar
sowas wie den ATSAMA5D27C-LD1G einzusetzen, gibt dann auch ein schickes
Mainboard ohne Sockel und ohne große Tochterboards. Der LPDDR2 RAM darin
hat auch einen geringen Verbrauch im Self-Refresh, das ist super. Fanout
sieht nicht extrem dramatisch aus:
https://www.microchip.com/content/dam/mchp/documents/OTH/ProductDocuments/BoardDesignFiles/SAMA5D27_LPDDR2BGA361Routing.pdf
Mit JLCPCB 4-Lagig sicher machbar, aber ich weiß nicht ob ich mir das
wirklich antun möchte. Eher wegen dem Löten und dem potentiellen in den
Sand setzen von Chips und nicht wegen dem Routing selbst. Ich halte das
aber im Hinterkopf, fände es schon geil sowas mal zu machen.
Das SODIMM-200 Modul von VisionSOM finde ich ehrlich gesagt auch nicht
schlecht, die 512 MByte DDR3L RAM darauf brauchen 15mA bei 1.35 Volt,
das geht noch klar dank DC-DC Regler für RAM und MPU. Formfaktor des
Sockels gefällt mir auch, da muss ich mir keine Sorgen ums Alignment
machen UND kann das wahlweise nach dem Reflow schonend per Hand
einlöten.
Wenn Phytec sich nicht mehr weiter meldet, besorge ich mir einfach das
VisionSOM-Kit und fertig.
>>> [...] Zerophone [...] wende Dich ruhig mal an den Entwickler,>>> Arsenijs aus Riga.
Jo, ich schaue ich mir mal was der so gemacht hat!
Finde ich super, Deinen Ansatz! Habe das vor einem Dutzend Jahren mit
ein paar Mitstreitern selbst probiert, aber wir haben zu viele Fehler
gemacht.
Hast Du Dir schon überlegt, wie die Infrastruktur bzw. Middleware
aufgebaut werden soll? Ich hatte damals auf dbus gesetzt - das würde ich
jetzt nicht nochmal machen. Vala als Sprache für system level daemons
finde ich nach wie vor eine gute Idee, aber mittlerweile gibt es auch
swift, rust und go, die in Frage kämen.
Welches UI-Toolkit möchtest Du einsetzen?
Yocto (oder gleich „pures“ OpenEmbedded) halte ich ebenfalls für eine
gute Wahl. Viel Erfolg!
>>> Hast Du Dir schon überlegt, wie die Infrastruktur bzw. Middleware>>> aufgebaut werden soll?
Keine Ahnung, da muss ich mich noch reinlesen.
>>> Welches UI-Toolkit möchtest Du einsetzen?
Habe mir LVGL und Qt angesehen, finde LVGL sympathischer, Qt ist schon
fast ein eigenes Betriebssystem. Das Schwierigste ist ja Font-Rendering
und Layout, das wäre ein Grund auf eines dieser Frameworks zu setzen.
Ansonsten kann man noch probieren selbst was zusammen zu hacken. Kann
mir bei LVGL schonmal abschauen wie man die PXP Einheit ansteuert:
https://github.com/lvgl/lvgl/tree/master/src/gpu
Damit kann man Bitmaps parallel zur CPU kopieren, skalieren und das
Pixelformat konvertieren.
Schau Dir mal die Teile von Octavo Systems an.
https://octavosystems.com/
Die haben Module für STM32MP1x und für TI AM3358 (quasi ein Beaglebone
als Chip). Die Module beinhalten alles lebensnotwendige, inkl PMIC und
RAM, d.h. die kritischen Sachen sind bereits erledigt.
Der hier
https://octavosystems.com/octavo_products/osd335x-c-sip/
hat ein 1.27mm Raster, d.h. etwas einfacheres gibts bei BGA nicht. 400
Pins sind dann aber doch ein Haufen Arbeit, wobei Du ja nicht alles
benutzen musst.
Bevor Du Dich da ranmachst, kannst Du erst mal mit dem Devkit-Beaglebone
schauen, ob das was für Dich ist.
fchk
Mickey L. schrieb:> Finde ich super, Deinen Ansatz! Habe das vor einem Dutzend Jahren mit> ein paar Mitstreitern selbst probiert, aber wir haben zu viele Fehler> gemacht.
Die Idee ist natürlich schrott. Weil man leider ein solches
State-of-the-Art Gerät nicht einfach nachbasteln kann.
Es wird am Ende immer ein riesiges Akku fressendes langsames
unbenutzbares Monster das zu nichts kompatibel oder nütze ist.
Meistens jedoch wird es niemals fertig.
Cyblord -. schrieb:> Mickey L. schrieb:>> Finde ich super, Deinen Ansatz! Habe das vor einem Dutzend Jahren mit>> ein paar Mitstreitern selbst probiert, aber wir haben zu viele Fehler>> gemacht.>> Die Idee ist natürlich schrott. Weil man leider ein solches> State-of-the-Art Gerät nicht einfach nachbasteln kann.> Es wird am Ende immer ein riesiges Akku fressendes langsames> unbenutzbares Monster das zu nichts kompatibel oder nütze ist.> Meistens jedoch wird es niemals fertig.
Indiskutable Antwort, ist das hier Standard? Zunächst mal hat der OT
bereits geschrieben, dass er eben KEIN State-of-the-Art-Gerät nachbauen
will. Davon abgesehen will er es auch noch nicht mal kommerzialisieren.
Und Sie maßen sich an, seine Hobby-Idee als „Schrott“ zu diskreditieren?
Lausige Umgangsformen.
Mickey L. schrieb:> Indiskutable Antwort, ist das hier Standard?
Trinken was klar ist, reden was wahr ist.
> Zunächst mal hat der OT> bereits geschrieben, dass er eben KEIN State-of-the-Art-Gerät nachbauen> will.
Ist es immer noch. Auch wenn das Ziel nur ein Iphone 3s wäre. Immer noch
utopisch. Und
> Davon abgesehen will er es auch noch nicht mal kommerzialisieren.
Das wäre auch noch absurder. Davon redet doch niemand. Warum dann du?
> Und Sie maßen sich an, seine Hobby-Idee als „Schrott“ zu diskreditieren?
Ist halt so. Solche Projekte sind zum scheitern verurteilt.
>>> Die Idee ist natürlich schrott.
Falls man am Ende was funktionierendes, praxistaugliches erwartet, dann
hast du damit 100% recht! Das ist hier aber nicht ganz der Fall.
Funktionieren ja, praxistauglich nein.
>>> Weil man leider ein solches State-of-the-Art Gerät nicht einfach>>> nachbasteln kann.
Korrekt. Ist hier allerdings nicht das Ziel.
>>> Es wird am Ende immer ein riesiges Akku fressendes langsames>>> unbenutzbares Monster das zu nichts kompatibel oder nütze ist.
Fett wird es auf jeden Fall, ich visiere ~15mm Tiefe an, das wäre schon
ziemlich gut. Wenn das Teil Akku frisst dann habe ich versagt. Ziel von
diesem Projekt ist es, ein mobiles, programmierbares, Linux-basiertes
Gerät entworfen und gebaut zu haben, mit der Motivation Erfahrungen zu
sammeln.
>>> Meistens jedoch wird es niemals fertig.
Trifft auf viele meiner Bastelprojekte zu, wenn der "Proof of Concept"
da ist, verliere ich meist das Interesse und es geht weiter zum nächsten
Projekt. Sind wohl alles eher Lernobjekte für mich. Und das wird bei
diesem Projekt wahrscheinlich genauso laufen, ist nur die Frage wann
dieser Punkt kommt. Wenn ich mich einmal durch alles durchgewühlt habe
und die einzelnen Basisfunktionen laufen, dann ist mein Ziel eigentlich
schon erreicht.
>>> Indiskutable Antwort, ist das hier Standard?
Jo, wir sind hier schließlich im mikrocontroller.net Forum, das 4chan
der Elektrotechnik! Ich habe mich schon echt gewundert, dass es
geschlagene 15 Posts braucht, bis mir endlich jemand erklärt, dass das
doch alles nicht funktionieren kann und scheiße ist und nie fertig wird.
Ach ja, habe jetzt das VisionSOM-6ULL SoM in der SD-Karte + Wifi +
512MByte RAM Variante bestellt inkl. DevBoard, Antenne und unverlötetem
SODIMM-200 Sockel für mein Prototyp-PCB (
https://kamami.pl/en/15413-somlabs ).
Danke für alle Vorschläge nochmal!
Florian S. schrieb:> bin gerade dabei, eine Art Feature-Phone zu bauen. Grund dafür sind> Bastelwut und gnadenlose Selbstüberschätzung, man kennt es :-)
Frag hier mal, vielleicht ist er mittlerweile fertig:
Beitrag "einfaches handy selber bauen"
Das i.MX6ULL SoM (
https://wiki.somlabs.com/index.php?title=VisionSOM-6ULL ) sowie
Demoboard und Zubehör sind in der Zwischenzeit angekommen.
Habe zunächst die verschiedenen Optionen zum Bauen einer Distribution
ausprobiert. Der Hersteller hat Anleitungen für Debian (fertiges Image),
Yocto und Buildroot. Das Debian-Image funktioniert wie erwartet ohne
weitere Probleme, ist aber knackige 1.45GB groß dank einer Vielzahl an
vorinstallierten Paketen und Treibern.
Die Anleitungen zu Buildroot scheinen nicht mehr aktuell zu sein, ich
musste den Wifi-Treiber nachträglich hinzufügen und ein paar URLs auf
das neue Treiber-Repo von NXP umstellen, welches auf Github verschoben
wurde.
Yocto hat zwar 5 Stunden für den Initialen Build gebraucht, dann aber
gut funktioniert und macht insgesamt einen guten Eindruck, werde
wahrscheinlich damit weitermachen.
Ich habe den Energieverbauch mal grob gemessen und die Rechnung in den
Anhang gepackt. Das Demoboard war mit LEDs und anderen Extras gespickt,
also habe ich das erstmal indirekt gemessen: Zunächst den Unterschied
zwischen Idle und Sleep-Verbrauch mit Demoboard, dann den Idle-Verbrauch
ohne das Demoboard. Aus den drei Werten lässt sich dann grob der reine
Verbrauch des Moduls im Schlafmodus berechnen.
Ergebnis sind, dass inklusive GSM/LTE-Modem mit ~13 Tagen Standby zu
rechnen sind, das ist gut genug für mich. Warte jetzt grade auf Display
und Modem.
Thread beobachten
Seitenaufteilung abschalten