[MP1993]

(23.02.2017, 10:24 PM)Basstler schrieb: Mache grad eine steile Lernkurve durch   Hatte mit Linux bisher nur Anwenderkontakt, nen Kernel umzufrickeln ist absolutes Neuland.

Fazit bisher, immerhin ist schon ASoC drin - Alsa SoC - Die Basis für alles an I2S.
Nun muss ich nur noch verstehen, wie ich dem Kernel klar mache das er auch nach etwas anderem als den WM8960 suchen darf, bzw. wie ich den Treiber Code für den PCM compiliert und als Modul integriert bekomme ... 

Würde man sich mit nem USB DAC zufrieden geben wollen - das geht out-of-the-box - aber wer will das schon 

Mir geht es nicht anders, vor 4 Monaten wusste ich noch nicht mal was eine objektorientierte Programmiersprache ist und fand es nicht so gut, dass ich Java lernen musste. Nun bin ich aber froh, dass ich es kann, denn Python ist kein großer Unterschied.  
Vorher hatte ich auch kaum etwas mit Linux zu tun und kannte die ganzen commands für die Konsole nicht. Ein harter Weg, aber wenn man es erstmal kann stehen einen alle Türen offen.
Das mit USB ist so, als ob man sich einen Falschenhals einbaut, wenn man die Möglichkeit hat was besseres zu benutzen, sollte man dies auch tun.

Falls noch nicht bekannt: Link

[Basstler]

(24.02.2017, 08:22 AM)MP1993 schrieb:

(23.02.2017, 10:24 PM)Basstler schrieb: Mache grad eine steile Lernkurve durch   Hatte mit Linux bisher nur Anwenderkontakt, nen Kernel umzufrickeln ist absolutes Neuland.

Fazit bisher, immerhin ist schon ASoC drin - Alsa SoC - Die Basis für alles an I2S.
Nun muss ich nur noch verstehen, wie ich dem Kernel klar mache das er auch nach etwas anderem als den WM8960 suchen darf, bzw. wie ich den Treiber Code für den PCM compiliert und als Modul integriert bekomme ... 

Würde man sich mit nem USB DAC zufrieden geben wollen - das geht out-of-the-box - aber wer will das schon 

Mir geht es nicht anders, vor 4 Monaten wusste ich noch nicht mal was eine objektorientierte Programmiersprache ist und fand es nicht so gut, dass ich Java lernen musste. Nun bin ich aber froh, dass ich es kann, denn Python ist kein großer Unterschied.  
Vorher hatte ich auch kaum etwas mit Linux zu tun und kannte die ganzen commands für die Konsole nicht. Ein harter Weg, aber wenn man es erstmal kann stehen einen alle Türen offen.
Das mit USB ist so, als ob man sich einen Falschenhals einbaut, wenn man die Möglichkeit hat was besseres zu benutzen, sollte man dies auch tun.

Falls noch nicht bekannt: Link

Danke für den Link, den Code von freelectrons habe ich schon entdeckt, darum gehts ja.
Grundsätzlich sollte die DAC Unterstützung in OpenWRT laufen, das wie muss noch geklärt werden.

Bzgl. USB, nicht unbedingt Flaschenhals, nur Schade weil ja I2S da ist und halt nur eine USB Host Schnittstelle.
Das kommt aber hauptsächlich aus der Router Ecke, USB haben quasi alle Chipsätze im Bauch (wenn es auch nicht bei allen Routern rausgeführt ist).

[MP1993]

Fertiger Core eines Chinesen für den WM8731
Treiber generell schreiben
Leider habe ich momentan kein Board mit einem anderen Audio DAC da. Mal schauen ob ich eins besorgen kann.

[Basstler]

(25.02.2017, 08:33 AM)MP1993 schrieb: Fertiger Core eines Chinesen für den WM8731
Treiber generell schreiben
Leider habe ich momentan kein Board mit einem anderen Audio DAC da. Mal schauen ob ich eins besorgen kann.

Es sollte noch einfacher sein, für nen Broadcom 2708 (aka Pi) existiert bereits ein Treiber unter openWRT.
das muss ich 'nur' für den 7688 umsetzen.
Letztlich ist mir der Vorgang noch unklar, also makefile anpassen bzw. wie sag ich dem crosssmpiler von wo er den source code her bekommt (git pull ?!).

Muss mir mal @home nen Linux hochziehen 

[MP1993]

Hier ein paar Aufnahmen vom I2S Bus im Betrieb.

Gelb=CLK / Grün=Data
   

gelb=clk / grün=ws
   

gelb=ws / grün=data
   

Auswertung:
CLK Freq.~3Mhz -> Faktor 64 -> 48kHz Sampling Rate
Datenwortlänge= 16Bit

Aufbau: I2S Audio Standart Format

Nun stellt sich mir die Frage, warum den I2S Bus anders einstellen im System?
Der PCM5102A sollte damit laufen.
I2S Format mit CLK=64fs und 16 Bit Datenwortlänge wird unterstützt.

[christianw.]

Die PCM brauchen doch garkeinen MCLK.

[Basstler]

(27.02.2017, 07:33 PM)MP1993 schrieb: ...
Nun stellt sich mir die Frage, warum den I2S Bus anders einstellen im System?
Der PCM5102A sollte damit laufen.
I2S Format mit CLK=64fs und 16 Bit Datenwortlänge wird unterstützt.

Weil Linux noch nicht 'weiß' das es eine 'Soundkarte' hat !

I2S ist verhältnismäßig dumm, da gehen idR. nur Streams über die Daten bzw. Taktleitungen.
Trotzdem muss ein Treiber mit den Schnittstellen Specs geladen und gestartet werden.

Der Wolfson auf dem Breakoutboard hat (da er ja bidirektional arbeiten kann) zusätzlich eine I2C Schnittstelle zur Konfiguration.
Dieser Treiber wird beim LinkIt per default gestartet, findet er den Wolfson nicht über I2C, wird auch die I2S wieder zu gemacht und Linux hat keinen Sound.

---

(27.02.2017, 08:37 PM)christianw. schrieb: Die PCM brauchen doch garkeinen MCLK.

Die nicht, aber der 

[MP1993]

(28.02.2017, 08:12 AM)Basstler schrieb: Der Wolfson auf dem Breakoutboard hat (da er ja bidirektional arbeiten kann) zusätzlich eine I2C Schnittstelle zur Konfiguration.
Dieser Treiber wird beim LinkIt per default gestartet, findet er den Wolfson nicht über I2C, wird auch die I2S wieder zu gemacht und Linux hat keinen Sound.

Also ist das einzige Problem, dass er den I2S Bus abschaltet sehe ich das richtig? 
Somit sollte es gehen, wenn ich den PCM5102A den Bus mitlesen lasse.(Parallel zum WM8960)

Hab mir mal ein Board mit dem PCM5102A bestellt mal schauen.

So wie es aussieht, werden die Dateien für die Config unter  lks7688.img\lib\modules\3.18.21\ gespeichert.

Somit könnte man einfach eine neue Firmware zusammenstellen und den Treiber vom PCM5102 vom PI ein wenig umändern. Hast du schon eine Quelle, wo man den Treiber für den PI bekommt?

Links zur Firmwareerstellung

Allgemein: https://wiki.ubuntuusers.de/Kernel/Kompilierung/  (die Idee vom Ordner am Anfang gefällt mir gut)
LinkIt Smart 7688 biuld your own Fw: https://github.com/MediaTek-Labs/linkit-smart-7688-feed
DAC Example von TI: http://processors.wiki.ti.com/index.php/...AC_Example

[Basstler]

(28.02.2017, 09:06 AM)MP1993 schrieb:

(28.02.2017, 08:12 AM)Basstler schrieb: Der Wolfson auf dem Breakoutboard hat (da er ja bidirektional arbeiten kann) zusätzlich eine I2C Schnittstelle zur Konfiguration.
Dieser Treiber wird beim LinkIt per default gestartet, findet er den Wolfson nicht über I2C, wird auch die I2S wieder zu gemacht und Linux hat keinen Sound.

Also ist das einzige Problem, dass er den I2S Bus abschaltet sehe ich das richtig? 
Somit sollte es gehen, wenn ich den PCM5102A den Bus mitlesen lasse.(Parallel zum WM8960)

Hab mir mal ein Board mit dem PCM5102A bestellt mal schauen.

So wie es aussieht, werden die Dateien für die Config unter  lks7688.img\lib\modules\3.18.21\ gespeichert.

Somit könnte man einfach eine neue Firmware zusammenstellen und den Treiber vom PCM5102 vom PI ein wenig umändern. Hast du schon eine Quelle, wo man den Treiber für den PI bekommt?

Links zur Firmwareerstellung

Allgemein: https://wiki.ubuntuusers.de/Kernel/Kompilierung/  (die Idee vom Ordner am Anfang gefällt mir gut)
LinkIt Smart 7688 biuld your own Fw: https://github.com/MediaTek-Labs/linkit-smart-7688-feed
DAC Example von TI: http://processors.wiki.ti.com/index.php/...AC_Example

Naja, anders rum, der I2S wird gar nicht erst gestartet.
Im Treiber wird hauptsächlich das Timing und die möglichen Abtastfrequenzen sowie die Bitrate festgeschrieben.
Die Source habe ich (nen Haufen Links auch, nur noch nicht hier abgelegt), was mir einzig fehlt, ist das Grundsätzliche Verständnis bzgl. des Modulbaus.
Letztlich ist es wahrscheinlich zu schreien einfach, hab es nur noch nicht durchdrungen - bin dran !

Btw, die Buildroot Umgebung von openWRT unterscheidet sich vom Standard Linux bzw. Pi, zum Glück   

Links bzgl openWRT Build

http://telecnatron.com/articles/Cross-Co...-On-Linux/
https://wiki.openwrt.org/doc/devel/crosscompile
https://wiki.openwrt.org/doc/devel/packages
https://downloads.openwrt.org/docs/build...ation.html
https://sites.google.com/site/guenterbar...rnelmodule
https://de.slideshare.net/antonywcl/open-wrt
http://www.ccs.neu.edu/home/noubir/Cours...torial.pdf
https://randomcoderdude.wordpress.com/20...n-openwrt/

[Basstler]

Nabend,

diese Woche hab ich mich Linux, XCompiler, untauglichen Skripten, inkompatiblen Builds rum geschlagen 

Heute, 17.04 Uhr hab ich das erste mal einen fehlerfreien Build Run vom LinkIt hinbekommen - dafür ist das WLAN tot   
Und um da hinzu kommen hab ich viel Nerven gebraucht, die notwendigen Links, Kniffe und Tricks werde ich nach reichen.
Hintergrund, der DAC ist erstmal nach hinten gerutscht, neues primär Ziel ist es, Node.js in einer einigermaßen aktuellen Version (4.x ) auf den LinkIt zu bekommen.

Warum ? -> Node Red   
Ansonsten heute mal 100 ESP WROOM2 bestellt, zu 2,5€ das Stück, auf Kostenstelle   
In Stückzahlen (>=5k) bekommen wir die Dinger unter 2,- - ein MSP430 mit FRAM kommt bei gleichen Stückzahlen nur auf 2,20 runter,
ergo werden wir mal sehen ob der WLAN Keks nicht auch als uC Ersatz (mit viel extra PlingPling) taugt.

[MP1993]

Mit dem wlan hatte ich zwischenzeitlich auch Probleme beim Verbinden von neuen Netzwerken. Gibt es sicherlich eine Möglichkeit, die wlan einstellung zu resetten.

Schade, dass der dac warten muss.
Der Link hört sich sehr interessant an.

Ich hoffe bald kommen die ganzen Pakete, um alles testen zu können.

Da ich mich momentan mit vhdl,fpga,cpld beschäftigen muss/darf... Labor und so .... ,kam ich leider bislang nicht dazu, das modul weiter zu konfigurieren.

[Basstler]

Update:

Heute einen Build mit Node.js 4.8 & NodeRED erfolgreich hinbekommen 

Der Weg ist nicht nur steinig, eher nen Albtraum gewesen.
Letztlich hab ich die UPM und die ganze MRAA Geschichte raus geworfen (nen Akt für sich), dann gab es keine Fehler mehr.
Habe zwischenzeitlich nicht nur diverse makefiles modifiziert, ne auch Patches gepatcht 
Linux ist und bleibt ein Bastelsystem, aber wenigstens in Klartext lesbar und relativ logisch aufgebaut.
Das letzte Mal, wo ich so tief abgetaucht bin, war zu Amiga Zeiten - auch ein UNIX Abkömmling - und das habe ich wiedererkannt, war schön.

NodeRED läuft, frisst aber den Ram von 56MB (frei) auf, bis runter zu ~2MB 
Nächster Schritt, alles rauswerfen, was nicht benötigt wird, da openWRT den Kernel ins Ram entpackt und von dort als readonly FS mountet.
Ergo, umso kleiner der Kernel, umso mehr Ram frei.

Die notwendigen Schritte werde ich hier zwecks Archivierung demnächst niederlegen.
Des Weiteren werde ich für NodeRED ne andere Plattform suchen ... bald mehr dazu 

Sobald das durch ist, baue ich den I2S Codec ein ... oder gleich alle aus dem Linux GIT, inzwischen habe ich eine Ahnung wie das geht.

[alfsch]

Zitat:auch Patches gepatcht 

jepp - DAS is das richtige level

[Basstler]

(08.03.2017, 10:17 PM)alfsch schrieb:

Zitat:auch Patches gepatcht 

jepp - DAS is das richtige level

  
Geht ja alles, ist auch logisch nachvollziehbar - nur muss man idR. erstmal 20-40m warten, um zu sehen wo der Build Prozess gegen die Wand läuft (bei -j1).
Multithreaded gab es öfters Abbrüche aufgrund von Abhängigkeiten, welche nicht sauber mit den makefiles abgefangen wurde ... irgendwas ist immer 

Btw :

Zitat:Des Weiteren werde ich für NodeRED ne andere Plattform suchen ... bald mehr dazu  undefined  

-> http://wiki.friendlyarm.com/wiki/index.p...Pi_NEO_Air

gibts für ~35,- hier und auch ohne 'Air' für ~20,- ... 

[MP1993]

(08.03.2017, 09:58 PM)Basstler schrieb: Heute einen Build mit Node.js 4.8 & NodeRED erfolgreich hinbekommen 

NodeRED wäre natürlich sehr schön und einfach, aber mit anderen Methoden, ist das gleiche möglich und ich denke es braucht weniger Ressourcen.
Was zur Folge hat -> weniger Stromverbrauch -> Effizienter

(08.03.2017, 09:58 PM)Basstler schrieb: Letztlich hab ich die UPM und die ganze MRAA Geschichte raus geworfen (nen Akt für sich), dann gab es keine Fehler mehr.

Oo... dann wird es jetzt sehr schwer die GPIO's anzusteuern, sowie uart usw...

(08.03.2017, 09:58 PM)Basstler schrieb: NodeRED läuft, frisst aber den Ram von 56MB (frei) auf, bis runter zu ~2MB 
Die notwendigen Schritte werde ich hier zwecks Archivierung demnächst niederlegen.
Des Weiteren werde ich für NodeRED ne andere Plattform suchen ... bald mehr dazu   

Mein Resümee -> Board für Node Red nicht geeignet, da an anderen Stellen zu viele Abstriche gemacht werden müssen.

(08.03.2017, 09:58 PM)Basstler schrieb: Sobald das durch ist, baue ich den I2S Codec ein ... oder gleich alle aus dem Linux GIT, inzwischen habe ich eine Ahnung wie das geht.

Oh, wie sehr ich mich darauf freue.  

Dann hat man alles unter einem Hut.
- Betrieben von vielen verschiedenen DAC's
- Internetradio(Beispielcode fertig)
- Abspielen von Audiodateien von USB Massenspeichern (Beispielcode fertig)
- Airplay(Momentan Probleme mit Android Gerät -> kein Apple Gerät da)
- Touchscreen zum Bedienen(Noch in der Post, sollte aber bald ankommen)
- Encoder zum Einstellen der Lautstärke (Ich finde es schöner ein wenig Feedback beim Einstellen zu haben -> somit nicht über Touchscreen; Idee vorhanden/Code noch nicht)

Und bestimmt noch vieles mehr was mir gerade nicht einfällt...

[Basstler]

Mach mal kein Inline Reply, wegen Übersicht....


Bzgl. NodeRed - klar geht es anders, der Witz ist, das es letztlich ein Point&Click Adventure ist und man hat diverse Sachen und Schnittstellen mal eben ohne Aufwand im Browser zusammen geklickt - das ist mehr als Cool !
Zumal ich da noch eine ernsthafte Anwendung (im Arbeitsumfeld) vor Augen habe...

Bzgl. Ressourcen und Stromverbrauch - ob der Ram nun 45% oder 97% belegt ist, ändert an der Stromaufnahme rein gar nichts.
Die CPU wird durch NodeRed nicht wirklich gefordert, da passiert nur beim Starten bisschen was.

Bzgl. UPM und RMAA - das hat nichts mit den GPIOs zu tun, das sind fertige Bibliotheken für diverse Sensoren und Aktoren.
Zielgruppe ?! - Leute denen Arduino schon zu viel ist.
Dank den Treibern in OpenWRT und Mediateks Bibliothek ist der durchgriff auf die GPIOs kein Hexenwerk, auch SPI und I2C sind ohne UPM nutzbar, man muss halt selber die gewünschten Sensoren implementieren (im Allgemeinen viele Register setzen).
Ergo, keine Einschränkung - nur mehr Eigeninitiative nötig.

Wobei bei meinem Bild im Kopf, die Kiste eh keine direkt angebundenen IOs hat ! - Da wird der LinkIt zu einem MQTT Broker und NodeRED Hoster, die Sensorik & Aktorik hängt über Netzwerk am LinkIt und kommt von diversen ESP8266ern, Enocean Geräten, etc.
Btw, mein Raumteiler hat heute nen altes Galaxy SII mit NodeRED verheiratet - schon hat man die Smartdinges Sensoren zur Verfügung, kann Fotos schießen, Position von GPS abfragen und *der Knüller* - Androids Txt-to-Speech nutzen ...
Plötzlich fängt das SII an zu quatschen, erzählt dir wie Warm es im Raum ist 

Also eher weniger Abstriche, als anderer Einsatzfall !
Da mich der Speicherverbrauch auch nervt, und ich das Image nicht unter 26,9MB bekomme, wird morgen probiert openWRT von der SDKarte zu booten, dann bleibt der Ram frei !
Wird also beim ersten Starten langsamer hoch kommen, das wars dann aber auch schon, dafür min. 50MB mehr Ram nutzbar und kein Problem mehr mit NodeRED 

[Basstler]

Status update:

Konnte root auf die SD Karte per overlay aktivieren, hilft aber nur eingeschränkt !
Squashfs bleibt ein RAM-RO-Filesystem - prinzipbedingt. Was aber geht ist nen SWAP auf die SD Karte und somit etwas mehr Luft, aber nicht perfekt.
Ansonsten hilft der overlay für grobere Pakete, nur macht das mit 128MB Ram nicht viel Sinn, es geht halt nur.

Ansonsten konnte ich beobachten, dass node red nach dem Starten und den ersten Zugriffen wieder Ram frei gibt, so um die 6-12MB.
Danach wurde node Red noch mit der Dashboard Erweiterung ergänzt, läuft, noch gut 2-4MB frei 

Erkenntnis : Grundsätzlich geht das alles, also MQTT Broker, node Red + Dash + WLAN-AP als 'Smart Home' Hub auf dem LinkIt
Aber es ist auf Kante genäht, durch die ziemlich monolithische Konstruktion des Mediateks OpenWRT Kernels, 
ist es nicht ganz trivial nicht benötigte Libs aus dem Kernel zu bekommen.
Am Ende bleiben über all noch Reste hängen, bsp. MJPEG Streamer hab ich nicht ganz weg bekommen, unter Anderem   

Soweit so gut, hab ja nun die nanoPis NEO Air am Start - ganz andere Nummer, Power pur - 4800 BogoMIPS, 1/2 Gig DDR3, 8GB eMMC - das ist eher etwa für nen leistungsfähigen 'Smart Home' Hub.
Die Portierung ist fast fertig, nächste Woche sollte der LinkIt wieder befreit sein und ich kann mich dran machen die DAC Treiber rein zuwürgen.
Dafür passt der perfekt ...

[MP1993]

Bin immer noch nicht dazu gekommen die Leistungsaufnahme vom modul aufzunehmen. Interessant wäre es zu wissen, ob die Module sich von der Leistungsaufnahme unterscheiden.

Das Display ist auch gestern angekommen.



Wenn mal Zeit ist, werde ich mal schauen, wie es läuft.

Der pcm5102a sollte auch bald kommen.

Dann würde ich vorschlagen, eine Firmware mit airplay , mraa und dac support zu schreiben.
Vielleicht auch noch intetessant: [URL]https://github.com/mps-youtube/mps-youtube/blob/develop/README.rst
[/URL]

[MP1993]

Das Display zum Leben erweckt. UART senden funktioniert schon(Mit Erkennung vom LinkIt Smart 7688).
Die Auflösung und Farben sind besser als erwartet. Obwohl es nicht kapazitiv ist sondern resestiv, muss man kaum Druck auf das Display ausüben (nicht so wie bei manchen Navigationsgeräten ).
Sehr schöne Entwicklungsumgebung.
Ich bin mit dem Display vollkommen zufrieden. Was hier für ca. 30 Euro geboten wird ist wirklich erstaunlich.
   
Versorgung: Regulär mit 5V. Vielleicht auch 3,3V möglich (Anschluss auf Platine vorhanden), je nach dem welche Spannung die Hintergrundbeleuchtung benötigt.
UART Spannung: 3,3V

[christianw.]

Feine Sache!