Für eine mobile Musikbox würde ich gerne einen MP3-Player mit Touchscreen basteln. Mit einem herkömmlichen Mikrocontroller-System wird so etwas schnell zur Lebensaufgabe, mit einem Linux-System kann man sich das recht flott aus vorgefertigten Software-Bausteinen zusammentüdeln. Leider besitzen die üblichen Einplatinencomputer wie z.B. der Raspberry Pi kein Powermanagement. Bei einer Akkubetriebenen Musikbox möchte ich allerdings nicht 24h am Tag den Computer ständig seine 0,5W verbrauchen lassen, obwohl er überhaupt nicht genutzt wird. Abschalten kommt aber auch nicht in Frage weil mir Bootzeiten um die 30 Sekunden viel zu lang sind. Die Musikbox sollte innerhalb von 2 Sekunden betriebsbereit sein. Wenn ich Musik möchte soll es nur den Druck auf einen Knopf benötigen und 2 Sekunden später spielt der erste Song ab. Gibt es hierfür schon Lösungen oder sind die üblichen Einplatinencomputer alle nicht darauf ausgelegt? Mich wundert das ehrlich gesagt. Gerade aufgrund ihrer Größe und flexibilität würde sich die Verwendung in Akkubetriebenen Geräten doch anbieten. Aber gerade da sind Energiesparoptionen doch mehr oder weniger essentiell. lg
Paul H. schrieb: > Für eine mobile Musikbox würde ich gerne einen MP3-Player mit > Touchscreen basteln. Mit einem herkömmlichen Mikrocontroller-System wird > so etwas schnell zur Lebensaufgabe Nicht wenn man einen mp3-Decoder wie den VS1011 verwendet, damit reduziert man den Aufwand für den Mikrocontroller erheblich.
Edi R. schrieb: > Paul H. schrieb: >> Für eine mobile Musikbox würde ich gerne einen MP3-Player mit >> Touchscreen basteln. Mit einem herkömmlichen Mikrocontroller-System wird >> so etwas schnell zur Lebensaufgabe > > Nicht wenn man einen mp3-Decoder wie den VS1011 verwendet, damit > reduziert man den Aufwand für den Mikrocontroller erheblich. Klar, aber es geht auch um das Abspielen von m4a-Dateien, Touchscreen, GUI, dann eventuell noch die Ansteuerung diverser LED-Effekte auf Basis der Audio-Daten. Ich möchte lieber mehr Zeit in die eigentliche Anwendung stecken als das Framework dafür in einen Mikrocontroller reinzu basteln.
Vielleicht ist ein billiges Tablet das was du suchst?
Ich hab mir in meine "Mobilbox" sowas eingebaut. http://m.ebay.de/itm/MP3-Player-Modul-M011-DC-6V-12V-MP3-Bluetooth-USB-SD-AUX-FM-Radio-Fernbedienung-/252611211294 Spielt MP3 direkt von USB oder SD Karte ab, hat FM Radio, Fernbedienung und lässt sich per Bluetooth als Audiodevice mit dem Handy pairen. Zugegeben, der Bastel- und Programmierspaß kommt etwas kurz, aber das Teil erfüllt seinen Zweck. Gruß Roland
Von der Größe her eher ein Smartphone. Ich habe ca. 16x16cm Fläche zur Verfügung für Anschlüsse und Display, da bleibt fürs Display selbst nicht mehr als 5" Diagonale übrig, eher 4". Smartphones haben halt wieder das Problem, dass die Schnittstellen sehr begrenzt sind. Über USB-OTG könnte man zwar USB-Sticks anschließen, Sound gibts über die Klinkenbuchse, wobei mir I2S eignetlich lieber wäre, da das Signal vorher eh nur durch den DSP muss und der schon I2S-Eingänge bereithält. Und wie versorgt man das Teil dann mit Energie, wenn der USB OTG schon belegt ist? Man müsste das Smartphone öffnen und den Akku anzapfen. Da das System wahrscheinlich die aus dem Akku herausgeflossene Energie mitzählt wird das System irgendwann denken, der Akku sei leer, das Display zwangs-dimmen und rummeckern. Also muss ich auch erst mal ein Smartphone finden, welches gut zerlegbar ist und USB-OTG Support bietet. Vielleicht alles lösbar aber ich sehe das etwas skeptisch.
Also die Bootzeit von Linux lässt sich schon ordentlich beschleunigen: http://elinux.org/Boot_Time Müsst ich auch langsam mal machen bei unserer Uhr: http://www.fritzler-avr.de/HP/dasuhr.php Der RasPi SoC kommt ja aus dem Handybereich und unterstützt eigentlich all diese Stromsparmechanismen, aber die stehen eben nicht im Datenblatt. Zumindest runtertakten geht, aber der USB Hub /LAN IC frisst imemr ordentlich Strom. edit: hier haste deine 3 Sekunden: http://www.samplerbox.org/article/fastbootrpi
:
Bearbeitet durch User
Roland P. schrieb: > Ich hab mir in meine "Mobilbox" sowas eingebaut. So etwas ist in meiner gerade drin aber davon will ich wegkommen ;-) Mw E. schrieb: > all diese Stromsparmechanismen, aber die stehen eben nicht im > Datenblatt. Zumindest runtertakten geht, Das nützt mir alles nur so lange ich diese Features auch nutzen kann, ohne mir ein Bein auszureißen. Ein hartes Kriterium ist auch die Entwicklungszeit. Wenn ich mich zuerst in alles mögliche wochenlang einarbeiten muss und hundert Probleme lösen muss nur um an Problem #77 dann zu hängen zu bleiben scheitert das ganze Projekt.
Mw E. schrieb: > hier haste deine 3 Sekunden: > http://www.samplerbox.org/article/fastbootrpi Naja mit Touchscreen, GUI usw usw. wird das schon >4..5s dauern. Sicher kein Beinbruch aber nicht mein Ziel. Die Box sollte schon always ready sein. Die Benutzung muss sich agil anfühlen. Dazu gehört v.A., jegliche Verzögerungszeiten an allen Stellen zu minimieren. Sowohl das Anschalten als auch das GUI muss blitzschnell und agil reagieren.
:
Bearbeitet durch User
Paul H. schrieb: > Und wie versorgt man das Teil dann mit Energie, wenn der USB OTG schon > belegt ist? Mit einem USB-OTG-Hub. Damit geht das üblicherweise. Kann man sich auch selbstbauen, wenn man einen Micro-USB-Stecker zum Selbstkonfektionieren hat. Das Grundprinzip sieht man hier: http://cdn.head-fi.org/7/78/500x1000px-LL-781bd011_Y_OTG_CABLE.png (da fehlt der eigentliche Hub, den muss man sich halt rechts dazudenken, aber der ist hier ja vielleicht auch gar nicht nötig)
Also irgendwas selber entwickeln musste schon und wer die Arbeit scheut wird nie etwas schaffen...
Mw E. schrieb: > Also irgendwas selber entwickeln musste schon und wer die Arbeit > scheut > wird nie etwas schaffen... Das ist klar ;-) Aber ich muss aus Vernunftgründen ein System auswählen, welches mir schon einigermaßen die Grundfunktionen liefert, damit ich möglichst bald mit der eigentlichen Implementierung der Anwendung beginnen kann, ohne mich Monate lang nur damit rumzuschlagen, das System so zusammenzubasteln, dass es die Grundvoraussetzungen erfüllt. Das ist bei jedem Projekt so.
Paul H. schrieb: > Klar, aber es geht auch um das Abspielen von m4a-Dateien, Touchscreen, > GUI, dann eventuell noch die Ansteuerung diverser LED-Effekte auf Basis > der Audio-Daten. > > Ich möchte lieber mehr Zeit in die eigentliche Anwendung stecken als das > Framework dafür in einen Mikrocontroller reinzu basteln. Wo ist das Problem? Bei mir läuft das alles schon. Ein STM32 als Controller, ein VS1053B (VS1063 geht auch), dazu ein günstiges Touch-Display aus China sowie WS2812-Ansteuerung. Die VS-Chips können nicht nur mp3, sondern auch m4a dekodieren. Ausserdem noch der 23Band-Spektrum-Analyser, der die Audio-Daten liefert. Gibt es alles als Module aus China, Hardware-Kosten ca. 15-20 Euro, zusammenstöpseln, bisschen programmieren und fertig ist die Laube. Ein STM32F103 ist nicht kompliziert, für den VS1053B gibt es genug Beispiele im Netz (wenn Dir das überschaubar dünne Datenblatt schon zu aufwendig ist...), für ein ILI9341-Display gibt es ebenfalls Bibliotheken zu Hauf. 3-4 Wochenenden und die erste Fassung steht. Das aufwendigste ist hinterher eh das Userinterface mit GUI. Aber das Problem hast Du mit den anderen Lösungen auch.
Paul H. schrieb: > Das ist klar ;-) Aber ich muss aus Vernunftgründen ein System auswählen, > welches mir schon einigermaßen die Grundfunktionen liefert, damit ich > möglichst bald mit der eigentlichen Implementierung der Anwendung > beginnen kann, ohne mich Monate lang nur damit rumzuschlagen, das System > so zusammenzubasteln, dass es die Grundvoraussetzungen erfüllt. Das ist > bei jedem Projekt so. ist ja nicht falsch, aber du must dann auch deine Anforderungen anpassen, die sind ein wenig..... unrealistisch.
STMler schrieb: > Bibliotheken zu Hauf. 3-4 Wochenenden und die erste Fassung steht. > Das aufwendigste ist hinterher eh das Userinterface mit GUI. Aber das > Problem hast Du mit den anderen Lösungen auch. Hm.. so wie du das beschreibst könnte ich wirklich überlegen, das wieder in die nähere Betrachtung zu ziehen. Die Flexibilität bei der Programmierung ist halt ein immenser Vorteil.
Angehängte Dateien:
-
MP3.JPG
97 KB
Paul H. schrieb: > Hm.. so wie du das beschreibst könnte ich wirklich überlegen, das wieder > in die nähere Betrachtung zu ziehen. Die Flexibilität bei der > Programmierung ist halt ein immenser Vorteil. Hab mal als kleine Motivation meinen ersten Bastelprototypen fotografiert, mit dem ich mal angefangen hatte. Fehlen mittlerweile ein paar Kabel, aber damit Du siehst, dass das wirklich nur Kinderkram ist...
hmm, ich hab grad meinen (ca.5 Jahre alten) MP3-Player eingeschaltet. Bis der einsatzbereit ist hat auch der Raspi daneben gebootet (in die shell). Und mein one plus one hängt der Raspi sogar mit X-Oberfläche ab...
Manche Smartphones unterstützen Fast-Boot. Die starten innerhalb von etwa 5 bis 10 Sekunden. Für eine Musikbox brauchst du allerdings ohnehin eine große Batterie, da kannst du das Smartphone auch einfach immer an lassen. Im Flugmodus ist die Standby-Stromaufnahme gering. > Aber ich muss aus Vernunftgründen ein System auswählen, > welches mir schon einigermaßen die Grundfunktionen liefert, damit ich > möglichst bald mit der eigentlichen Implementierung der Anwendung > beginnen kann, ohne mich Monate lang nur damit rumzuschlagen, das System > so zusammenzubasteln, dass es die Grundvoraussetzungen erfüllt. Dann ist ein Smartphone doch geradezu ideal. > Smartphones haben halt wieder das Problem, dass die > Schnittstellen sehr begrenzt sind. Ich weiß ja nicht, was du da außer dem Lautsprecher noch anschließen willst. Aber per Bluetooth (http://stefanfrings.de/serial_io/index.html) kann man relativ simpel eigene Basteleien ankoppeln. Oder per WLAN (ESP8266). OTG haben die billigen Smartphones nicht und außerdem fehlt Dir dann eine Ladebuchse und eventuell auch Treiber für das Ding, dass du anschließen willst.
STMler schrieb: > Hab mal als kleine Motivation meinen ersten Bastelprototypen > fotografiert Interessanter USB-Host-Adapter! Ich wusste gar nicht, dass es die Dinger mittlerweile schon für 3€ gibt. Stefan U. schrieb: > Für eine Musikbox brauchst du allerdings ohnehin eine große Batterie, da > kannst du das Smartphone auch einfach immer an lassen. Korrekt. So Geschichten wie "fast-boot" klingen zwar nett, gehen aber dennoch an meinem Ziel immer noch völlig vorbei und sind daher nicht in Erwägung zu ziehen. Der Computer muss immer an und betriebsbereit sein, sofern die Boot-Zeit nicht unter einer Sekunde liegt. Ich könnte ehrlich gesagt auch die 0,5W Idle eines Raspberry Pis verschmerzen. Schön ist es halt nicht :-D Stefan U. schrieb: > Ich weiß ja nicht, was du da außer dem Lautsprecher noch anschließen > willst. Aber per Bluetooth (http://stefanfrings.de/serial_io/index.html) > kann man relativ simpel eigene Basteleien ankoppeln. Oder per WLAN > (ESP8266). OTG haben die billigen Smartphones nicht und außerdem fehlt > Dir dann eine Ladebuchse und eventuell auch Treiber für das Ding, dass > du anschließen willst. Also Bluetooth brauche ich schon mal, um andere Smartphones (als Fernsteuerung) damit verbinden zu können. Die Daten über 3cm per WLAN zu übertragen empfinde ich wie mit Kanonen auf Spatzen, aber es gibt ja USB-OTG kompatible RS232-Adapter. Bei gh.de kann man explizit Smartphones mit USB-OTG Funktionalität finden. Allerdings gibt es immer weniger Smartphones, bei denen der Akku noch wechselbar ist. Wird mittlerweile alles fest verbaut, weil man das im Falle eines Defektes teurer reparieren lassen kann. Noch bekommt man aber welche. Und für meine Zwecke dürften die hardwaremäßig locker ausreichen. Ja, Ladeproblematik habe ich ja schon angesprochen aber die Lösung von Rufus Τ. Firefly muss ich mal ausprobieren. Spätestens bei einer externen Soundkarte mit I2S-Ausgang wirds dann jedoch tricky, wobei die ja eher nice-to-have ist und mit einem System auf STM32- oder RPi-basis ganz nebenbei abfällt. Wenn ich mich halt erst in Treiberprogrammierung einarbeiten muss könnte es problematisch werden, davon hab ich (noch) keine Ahnung.
:
Bearbeitet durch User
> Die Daten über 3cm per WLAN zu > übertragen empfinde ich wie mit Kanonen auf Spatzen, Stimmt - technisch betrachtet. Allerdings sind diese Kanonen (ESP-01 Module) billiger, als Bluetooth Module und in der Android App etwas einfacher zu programmieren. > Also Bluetooth brauche ich schon mal, um andere > Smartphones (als Fernsteuerung) damit verbinden zu können. Du weißt schon, dass die Bluetooth Schnittstelle von Smartphones mehrere Verbindungen gleichzeitig nutzen kann? So ein Bluetooth Modul (HC-05, HC-06, BTM-222) behindert nicht die Verbindung zu anderen Smartphones.
Thread beobachten
Seitenaufteilung abschalten
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.