iRadioPico - iRadio Portierung für Raspberry Pico/Pico W und RP2040 Boards

[OttoBerger]

Das sollte in die globals.cpp rein Joe.
.h macht für andere bekannt, cpp definiert

Deine Lösung ist gut wenn man wieder die Namen für eine Skale gleich in der Senderliste eintragen will, so wie bei deiner iRadioAndroid Umsetzung. Man kann auch den Datenstrom vom Server direkt mitlesen und dann daraus Station, Titel, Cover ziehen wenn es der Sender überträgt. Aber das ist weniger statisch weil der Sender das jederzeit nach Belieben ändern kann.

[JoeXXL]

Ups, habe die globals.cpp total "übersehen"
Danke!

[OttoBerger]

Ist zwar nicht für den Umbau des Squeezebox Radios erforderlich, sondern für ein weiteres Radio und deshalb habe ich die Programmumschaltung mittels Poti/Preomat jetzt gleich mit reingenommen als gpiod_potentiometer . 

Den Pin für die Analogwertabfrage, Bittiefe der Abtastung, Abtastungsgeschwindigkeit und Randbegrenzung kann man im Quellcode des Moduls festlegen.

Das entspricht dann im Prinzip einer Programmumschaltung wie beim DSP-Baustein KT0936 den Jupp vor ein paar Tagen hier vorgestellt hat.




Für eine Umschaltung mittels Lokaloszillators eines Radios veweise ich auf den inet2RF Code im iRadioAndroid

https://github.com/BM45/iRadioAndroid/tr...n/firmware

welcher direkt übernommen werden kann und aus dem iRadioMini abgeleitet ist.

[OttoBerger]

Der Pico-core wurde von Version 3.7.2 auf 3.8 angehoben.

   

Ich habe das iRadioPico gegen den neuen Core bauen lassen, es gab bei mir keine Probleme.

[OttoBerger]

Ich habe dem Squezebox-Radioumbau und damit dem iRadioPico auch gleich noch ein einfaches Webinterface gegeben, was sehr leicht erweiterbar ist.


  httpd.jpg (Größe: 43,91 KB / Downloads: 271)

wie beim größeren iRadioMini kann man auch noch eine Equalizer, VU-Meter oder Spektrumanzeige hinzufügen aber dazu später mehr.



Das Webinterface "httpd" ist in einer frischen Standardinstallation noch deaktiviert und muss in der iRadioPico.ino durch Auskommentieren der Inkludedatei und von httpd_init(), httpd_run() auf einem MCU-Core gestartet werden.

Man könnte das durch defines und der bedingten Kompilierung auch noch so einrichten, dass man httpd über die globals.h aktivieren könnte (wie jedes andere Modul ja auch), aber so unübersichtlich finde ich die Sache noch nicht, das das nötig wäre. Auch wenn die globals den Vorteil hätte, ein zentrales (grafisches) Konfigtool vorzuschalten, wie beim iRadio2 for Raspberry SoC. Aber wie gesagt, so umfangreich finde ich das in den kleinen iRadios nicht. Vielleicht später. Vielleicht, wenn sich ein neues Team gebildet hat, dass so groß ist, dass man ein Grafisches Einrichtungstools für alle iRadios haben kann.


Desweiteren sagt Earle Philhower zwar zu seiner LWIP und WiFi-Stack Kapselung

Multicore is supported, but only core 0 may run WiFi related code.
The same restrictions for WiFi apply to these Ethernet classes, namely:
    Only core 0 may run any networking related code.

aber wir sind hier wohl soweit oben in den Layern, dass der httpd bei mir problemlos auf Core1 laufen kann! Das habe ich vorher schon an anderen Stellen gesehen und frage mich warum. Bei FreeRTOS geht es tatsächlich nicht, dort läuft das tatsächlich nur in setup und loop und in keinem anderen Task. Aber das liegt an FreeRTOS (andere LWIP Implementierung), was wir beim iRadioPico nicht nutzen, denn die paar Tasks die wir haben brauchen im Moment kein weiteres Betriebssystem.

Zum httpd in httpd.c

Dieser kleine Webserver hört auf Port 80. Wer das ändern möchte,kann das gleich zu Beginn der Datei festlegen. Eine Passwortabfrage haben wir nicht vor dem Interface. In Earle Philhowers 2040-core sind aber fertige Beispiele für diesen zusätzlichen Anwendungsfall.

Zu unserem httpd.
In der Init werden drei Webseiten an den Server gebunden.

server.on("/", handleRoot);

Das RootDocument, also die HTML-Hauptseite die man bekommt wenn man den Webserver anfunkt.
Die Seite wird durch die Funktion handleRoot zusammengesetzt.


server.onNotFound(handleNotFound);

Die 404-Seite, zusammengesetzt durch die Funktion handleNotFound


server.on("/nowPlaying", handleNowPlaying);

Und ein Handle auf eine "interne" Seite die dazu dient die AJAX Sache (XMLHttpRequest/XHR) Anfrage des RootDocuments nach "was wird nun gespielt" zu beantworten. Der Nutzer hat also das RootDocument im Webbroswer geöffnet und in diesem Dokument wird zyklisch weiterhin eine Anfrage an den Webserver gestellt, weitere Daten zu liefern ohne das die Seite im Browser neu geladen werden muss.

Wie die ganzen Knöpfe im RootDocument definiert sind, wie die durch das handleRoot beim Neuladen der Seite an den  Player im Hintergrund aktionsmäßig ihre Wirkung ausüben ist denke ich leicht erkennbar. Es soll als GET-Demo dienen, POST-Anfragen und andere Webtechniken findet man auch im Code der anderen iRadios als Muster für eigene Webseiten auf dem iRadioPico.

[saarfranzose]

das webinterface konnte ich heute abend noch in Betrieb nehmen

   

[OttoBerger]

Nach Rückmeldung von gestern werde ich die Sache weniger intensiv angehen und nicht gleich mit Apps auf VS1053 weitermachen.

Also zunächst die Lautstärkesteuerung im Webinterface (wie beim iRadioMini auch).

In httpd.cpp wurde der Handler der das RootDocument zusammenbaut (void handleRoot() ) erweitert.


Im Bereich der player controls wurden zwei weitere Knöpfe aufgenommen

// player controls
strcat(HTML,"<form action=\"\" method=\"get\"> \
<button name=\"command\" type=\"submit\"  value=\"Prev\"class=\"button\">Prev</button> \
<button name=\"command\" type=\"submit\"  value=\"Next\"class=\"button\">Next</button> \
<button name=\"command\" type=\"submit\"  value=\"Stop\"class=\"button\">Stop</button> \
<button name=\"command\" type=\"submit\"  value=\"Play\"class=\"button\">Play</button> \
<button name=\"command\" type=\"submit\"  value=\"Vol-\"class=\"button\">Vol-</button> \
<button name=\"command\" type=\"submit\"  value=\"Vol+\"class=\"button\">Vol+</button> \
</form>");

   

Immer wenn dort jemand draufklickt, wird das Webinterface neu geladen, in der URL Zeile steht aber zusätzlich der Parameter

http://192.168.1.xxx/?command=Vol-

oder

http://192.168.1.xxx/?command=Vol+

Mit dieser URL wurde beim Webserver auf dem RP2040  das RootDocument neu angefragt.

In void handleRoot() sehen wir das beziehungsweise können wir uns von jeder Client-Anfrage die URL-Parameter ausgeben lassen und darauf reagieren.

if ( server.argName(0).compareTo("command") == 0 ) {
   
    .
    .
    .

    if (server.arg(0).compareTo("Vol+") == 0) {
      volume_up();
    }
   
    if (server.arg(0).compareTo("Vol-") == 0) {
      volume_down();
    }
   .
   .
   .

Wenn wir "command" mit "Vol+" entdecken, rufen wir in der Playersoftware volume_up() auf. Leiser analog dazu.


Das sieht in player.cpp umgesetzt so aus.

PHP-Code:

void volume_down() {
   #ifdef USE_VS1053_DECODER
     if ( volume_L < 250 ) 
      volume_L+=5;
    
      if ( volume_R < 250)
      volume_R+=5;
    
    playerEvent = VOLUME_CHANGED;
   #endif
}

void volume_up() {
   #ifdef USE_VS1053_DECODER
    if ( volume_L > 5 ) 
      volume_L-=5;
    
    if ( volume_R > 5 )
        volume_R-=5;
            
      playerEvent = VOLUME_CHANGED;
   #endif
} 


Hier müssen wir wieder unterscheiden, haben wir einen VS1053 oder was anderes als Codec zu bedienen.
Die Frage warum bei lauter der Wert kleiner wird und andersrum ergibt sich aus der Doku zum VS1053 DSP Baustein

9.6.11 SCI_VOL (RW)

SCI_VOL is a volume control for the player hardware. The most significant byte of the volume
register controls the left channel volume, the low part controls the right channel volume. The
channel volume sets the attenuation from the maximum volume level in 0.5 dB steps. Thus,
maximum volume is 0x0000 and total silence is 0xFEFE.
Setting SCI_VOL to 0xFFFF will activate analog powerdown mode. */

Die Lautstärke stellen wir also mit dem Multiplikator eines Abschwächers ein. Je größer der Wert, je größer die Abschwächung, je leiser.

Da wir mit der Methode   VS1053Dekoder.setVolume(volume_L, volume_R);   nicht so einfach in die laufende Kommunikation reingrätschen können, eventuell sogar von einem anderen MCU-Kern aus, sagen wir mit einem Ereignis (Event) das sich die Lautstärke geändert hat.

Im Dauerläufer-Prozess behandeln wir dieses Ereignis wenn wir gerade keine Daten aus dem Internet holen oder zum Codec schicken.

PHP-Code:

void player_run(){
    #ifdef USE_VS1053_DECODER

        if (playerEvent == VOLUME_CHANGED) {
          SERIAL_PORT.println("PLAYER: VOLUME_CHANGED event (att in 0.5 dB steps) L/R=" + ....
          playerEvent = NO_EVENT;
          VS1053Dekoder.setVolume(volume_L, volume_R);
         }
 
        playerFillBufferTask();

    #endif

    player();
} 


So einfach signalisiert (ohne aufwendiges Mailbox-System eine RT-OS) stören wir keine Kommunikation.
Die Lautstärke wird im Kern des VS1053 angepasst

New volume settings are loaded only when the upsampled signal crosses the zero
point (or after a timeout). This zero-crossing detection almost completely removes all audible
noise that occurs when volume is suddenly changed.

[OttoBerger]

Im Datenblatt zum VS1053 ist der VS_DSP Kern und der DAC Audiopfad abgebildet.

   

Nachdem die AudioCodecs im ROM des DSP alles berechnet haben, landen ganz am Anfang des Pfades die dekodierten PCM Samples für den linken und rechten Audiokanal.

Im Speicherbereich 0xC000..0xC0FF wird die Peripherie des VS_DSP abgebildet, der oben markierte Bereich des Audiopfads ist hier zu sehen

   

die beiden Register mit den PCM-Samples sind an dieser Adresse

   

Die können wir ja über SPI auslesen und das machen wir mit der aktuellen Version stichprobenhaltig wenn im player_run etwas Zeit über ist.
Die Daten können wir bei aktivierter Auslesung in der PlayerInfo-Struktur an anderer Stelle weiterverarbeiten, dabei müssen wir den 16-Bit Wertebereich nach dB wandeln. Die Appnotes des Herstellers https://www.vlsi.fi/ geben für die Gleichung

dB = 20 × log10( m / 32768 ) + 96 einen Ersatzalgorithmus an

PHP-Code:

To implement a good approximation of this formula from linear to dB scale on architec-
tures where multiplications and logarithms are expensive operations, the following code
can be used:

const unsigned short linToDBTab[5] = {36781, 41285, 46341, 52016, 58386};
/*
Converts a linear 16-bit value between 0..65535 to decibels.
Reference level: 32768 = 96dB (largest VS1053b number is 32767 = 95dB).
Bugs:
- For the input of 0, 0 dB is returned, because minus infinity cannot
be represented with integers.
- Assumes a ratio of 2 is 6 dB, when it actually is approx. 6.02 dB.
*/
unsigned short LinToDB(unsigned short n) {
int res = 96, i;
if (!n) /* No signal should return minus infinity */
return 0;
while (n < 32768U) { /* Amplify weak signals */
res -= 6;
n <<= 1;
}
for (i=0; i<5; i++) /* Find exact scale */
if (n > linToDBTab[i])
res++;
return res;
} 


Ich habe das genutzt um Democode mit einem grafisch sehr einfachen und schlichten VU-Meter zu versehen.
Das kann ein Ausgangspunkt für weitere eigene Entwicklungen mit dem iRadioPico - Baukasten sein.

   

Die finnische Herstellerfirma des VS1053 gibt in ihren Appnotes auch noch weitere Hinweise und Designanregungen

   
  vu3.jpg (Größe: 79,73 KB / Downloads: 169)

[OttoBerger]

Moin!

Im letzten Post habe ich über SPI einfach fertige PCM - Werte aus dem Speicher des VS1053 gelesen, die 16 Bit Werte mit dem vom Hersteller vorgeschlagenen Code (weil die Formel zu teuer ist um sie anzuwenden) nach dB umgewandelt und dann angezeigt.

Wer das Beispiel durch Aktivieren von USE_INTERNAL_VU_METER in der global.h schon ausprobiert hat, wird sehen das der Datenpuffer sich deutlich langsamer füllt als ohne VU Meter.

Es muss in der player_run immer erst ein Zeiger in den Speicher des VS1053 gesetzt werden und dann wird das PCM - Sample ausgelesen. Das zweimal für Links und Rechts. Dann die Konvertierung nach dB.

Wesentlich schneller geht es wenn man die Sache direkt über eine App im VS_DSP Kern des VS1053 berechnen lässt und nur das fertige Ergebnis abholt.


  Screenshot 2024-04-26 at 10-19-12 VS1053 Datasheet - vs1053.pdf.png (Größe: 28,1 KB / Downloads: 136)

Der Hersteller bietet dazu kostenlos ein Entwicklungssystem was sich VSIDE nennt.

https://www.vlsi.fi/en/support/software/vside.html
VSDSP Application Development Environment
VSIDE is a full-featured application development suite for VSDSP signal processors
Familiar, user-friendly interface
Several sample projects to build upon
A complete set of utilities, including ANSI-C compiler, assembler, linker, profiler etc.
Supports emulator-based debugging using real hardware
Easy to get started, yet powerful and flexible

Ich empfehle das unbedingt mal anzusehen und auszuprobieren. Es gibt genug Tutorials beim Hersteller und im Web.
Im Forum http://www.vsdsp-forum.com/phpbb/index.php sind viele Mitarbeiter der finnischen Firma VLSI aktiv und geben Unterstützung in den unterschiedlichsten Bereichen.
Wenn man sich mal tiefer in den Chip und das VSOS Operating System eingelesen hat, sieht man diese DSP Reihe nochmal mit ganz anderen Augen und bekommt viele Ideen die man direkt auf VS10xx umsetzen könnte.
https://www.vlsi.fi/en/support/applicationnotes.html

Die Programme für den VS10xx die der VSIDE Compiler ausspuckt, das können Patches bekannter ROM-Funktionen, neue Codecs oder eigene Anwendungen sein, können über verschiedene Wege auf den DSP ausgespielt werden! 
Auf der Seite https://www.vlsi.fi/en/support/software.html findet man zahlreiche interessante Sachen.

Für unser VU-Meter Problem von oben gibt es im VS1053b Patches w/ FLAC Decoder von https://www.vlsi.fi/en/support/software/...tches.html eine Lösung.

VS1053b Patches w/ FLAC Decoder

• [i]Five versions of the patch included. With and without LATM/LOAS parser and with and without a FLAC (Free Lossless Audio Codec) decoder (1-2 channels, up to 24 bits, up to 48kHz) decoder, and with a pitch/tempo shifter.[/i]
  
• [i]VU meter (now with 1dB resolution) and other features, see the full list from the document.[/i]
  
• [i]Patches, among other things, the following:
  [/i]
  • [i]AAC: Unused data at the start of the mdat atom in MP4 is now skipped. (Some NERO versions generated extra data there.)[/i]
    
  • [i]HE-AAC: When parametric stereo (PS) is active, PS header frame was required to be present in the first encountered SBR frame or the decoding could crash. This patch fixes the problem.[/i]
    
  • [i]Vorbis: Removes an occasional windowing overflow from Vorbis decoding and thus increases playback quality.[/i]
    
  • [i]Ogg: Enables playing of Ogg streams that have the highest bit set in the stream number.[/i]
    
  • [i]IMA ADPCM: Enables also data transfer when IMA encoding mode is started.[/i]
    
  • [i]AAC: PNS of left channel could get corrupted during transition frames.[/i]
    
  • [i]AAC: crc now ignored correctly for ADTS format files.[/i]
    
  • [i]AAC: MP4 fixes.[/i]
    
  • [i]FLAC: sets DO_NOT_JUMP during header.[/i]
    
  • [i]HE-AACv2: slightly faster decoding.[/i]
    
• [i]Also contains the functionality of the old "VS1053b Ogg Vorbis Decoder Patch": sample counter and sample rate fine tuning.[/i]
  
• [i]15/16 Resampler allows samplerate tuning 'above 48kHz' even with 12.288MHz XTALI. Now can be automatically enabled only for 48kHz.[/i]
  
• [i]ID3 tag parser skips the tag data, so that binary data inside the tag is not erroneously interpreted as audio.[/i]
  
• [i]Can disable zero-sample insertion when out of stream data.[/i]
  
• [i]Experimental DSD64 decoder (.dff and .dsf)[/i]
  
• [i]Mono downmix mode for encoding.[/i]
  

Ich habe die Sammlung auch ins iRadioPico Repo gestellt https://github.com/BM45/iRadioPico/blob/...hes290.zip

Wenn man die Datei (oder generell solche Programmpakete) entpackt, ergibt sich so ein Gefüge.

   

Die PDF enthält immer eine sehr gute Beschreibung des Paketes, wie der Code in den DSP geladen wird, verschiedenen Tools zum externen Laden und die Patches/Apps selbst.

Dabei gibt es zwei Dateiformate. Ein altes (unkomprimiertes Format) und ein neues komprimiertes Format.

Das alte Format besteht aus zwei Arrays  atab und dtab. 
Im atab sind die Speicheradressen enhalten wohin das dazu passende dtab - Element im Chip geschrieben werden muss. Wer so einen Patch im alten Format öffnet, sieht das das atab-Array ziemlich redundant ist.  Beispiele findet man in den .c Dateien im Softwarepaket.

Weil das so ist, kann man diese Information komprimieren und man erhält das neue Format, die .plg Dateien im Softwarepaket.


  screen2.jpg (Größe: 65,52 KB / Downloads: 132)

Vergleich .c zu .plg , man spart fast die Hälfte ein.


In den .c und .plg Dateien wird auch immer schon ein generischer Code zum Laden der Software in den DSP mitgegeben.

Das findet man immer am Anfang der Dateien mit dem alten Format, man beachtet mein Gesagtes atab <- dtab

Code:

/* VS1053b vorbis patch */

#if 0
void LoadUserCode(void) {
  int i;
  for (i=0;i<CODE_SIZE;i++) {
    WriteVS10xxRegister(atab[i], dtab[i]);
  }
}
#endif

Im neuen Format ist am Dateianfang immer dieser Code zugegeben

Code:

/* User application code loading tables for VS10xx */
#if 0
void LoadUserCode(void) {
  int i = 0;

  while (i<sizeof(plugin)/sizeof(plugin[0])) {
    unsigned short addr, n, val;
    addr = plugin[i++];
    n = plugin[i++];
    if (n & 0x8000U) { /* RLE run, replicate n samples */
      n &= 0x7FFF;
      val = plugin[i++];
      while (n--) {
        WriteVS10xxRegister(addr, val);
      }
    } else {           /* Copy run, copy n samples */
      while (n--) {
        val = plugin[i++];
        WriteVS10xxRegister(addr, val);
      }
    }
  }
}
#endif

Wer also Software für den DSP entwickelt bekommt immer auch den generischen Code zum Laden mit und er braucht nur noch die Schreib/Lesefunktionen wie WriteVS10xxRegister ... auf seinem speziellen Mikrocontroller zu portieren.  In der Arduino Umgebung wurde das aber schon gemacht und die von uns benutzte Adafruit_VS1053 Lib hat den Code für das Laden des neuen Formats in diesen zwei Funktionen drin:


/*!
  * @brief Apply a code patch
  * @param patch Patch to apply
  * @param patchsize Patch size
  */
  void applyPatch(const uint16_t *patch, uint16_t patchsize);
  /*!
  * @brief Load the specified plug-in
  * @param fn Plug-in to load
  * @return Either returns 0xFFFF if there is an error, or the address of the
  * plugin that was loaded
  */
  uint16_t loadPlugin(char *fn);

Mit loadPlugin kann man einen Patch einfach auf eine angeschlossene SD-Karte spielen und laden lassen (mit zwei Codezeilenänderungen) geht auch das LittleFS im Controller selbst. 
Mit applyPatch schreibt man die Binärversion der DSP-Software aus dem Array der .plg Dateien ins System. Und so machen wir das auch.
Ich habe die .plg - Datei des Softwarepakets bereits mit wenigen Handgriffen in die Headerdatei vs1053b_patches.h überführt. Den generischen Einlesecode rausgeschmissen weil wir ihn ja nicht brauchen, was zusätzlich Platz im Flash frei lässt.

https://github.com/BM45/iRadioPico/blob/..._patches.h

Im Player des iRadioPico wird im Init-Teil, wenn VS1053 in der globals.h aktiv und USE_VLSI_VSDSP_VU_METER gesetzt, dieser Usercode in den VS1053 transferiert.  Zusätzlich schalte ich mit Bit 9 im SCI_STATUS Register die VU-Meter App an. Das ist in diesem Paket der "Doppelklick auf das ausführbare Programm".

Code:

  
       #ifdef USE_VLSI_VSDSP_VU_METER  
          // load vs1053 apps and patches from vs1053b_patches.h
          VS1053Dekoder.applyPatch(plugin, PLUGIN_SIZE);
         
          /*VU Meter -SCI_STATUS bit 9 enables VU meter, which calculates a leaking peak sample value
          from both channels and returns the values in 1 dB resolution through SCI_AICTRL3.
          The high 8 bits represent the left channel, the low 8 bits the right channel */
            VS1053Dekoder.sciWrite(0x01, VS1053Dekoder.sciRead(0x01) | (1<<9) );  // SCI_STATUS(0x01)     
       #endif

Im Runner des Player wird dann nur noch das SCI_AICTRL3 Register mit den beiden auf dem VS_DSP berechneten Werten gelesen und für die PlayerInfo-Struktur bereitgestellt. Im Democode für das ILI9341 wird dann das VU-Meter mit dieser Information gezeichnet.

Das Nachladen des Puffers läuft nun deutlich schneller, weil wir Rechenarbeit auf den VS1053 selbst ausgelagert haben, hier ein Video (Audio stummgeschaltet wegen Copyright) zu sehen.

https://youtube.com/shorts/MLZu73s7W9A

*Da das Video wohl so kurz ist, hat Youtube daraus ein Shorts gemacht und diese Video-URLs können über den Player hier in der Forensoftware im Moment wohl nicht eingebettet werden, deshalb bitte den Videolink anklicken.

[OttoBerger]

Ein bisschen Versionspflege und ein paar neue kleine Sachen sind dazugekommen.

Der RP2040 hat eine RTC (Real-Time-Clock) drin, die nutzen wir jetzt. Ist nicht verkehrt zu wissen welcher Tag und wie spät es ist.

Entweder ihr stellt die Uhr selbst über einen gpiod (also per Taster / Drehregler ) wie an einem Uhrenradio oder ihr lasst die Uhr automatisch stellen. 

Für das automatische Stellen der RTC gibt es den "Dienst" ntp_rtc (gleichnamiger Header, Cpp) und er wird in der globals.h

mit  #define USE_NTP_CLOCK_SYNC aktiviert/deaktiviert.

Gleich nach dem Anschalten wird versucht über die beiden NTP-Server

pool.ntp.org und time.nist.gov die GMT-Zeit zu holen. Ist das erfolgt, wird die Lokalzeit ausgerechnet. 
Wo man ist und welche Lokalzeit inklusive Sommer/Winterzeit benutzt werden soll, kann man in ntp_rtc.cpp an der Stelle

setenv("TZ", "CET-1CEST,M3.5.0,M10.5.0/3", 1); // see http://www.hs-help.net/hshelp/gira/v4_7/de/proj_tz.html
tzset();

ändern.  Den Aufbau der Zeile finden man beispielsweise an dieser Stelle http://www.hs-help.net/hshelp/gira/v4_7/de/proj_tz.html

Nach der Erstsyncronisation der RTC erfolgt in Abständen von einer Stunde jeweils ein weiterer Abgleich. Wahrscheinlich würde auch 1x täglich oder 1x pro Woche ausreichen.

______________________________________________________

Zusätzlich gibt es den "Dienst" autosave, der in globals.h durch #define USE_AUTO_SAVE aktiviert/deaktiviert werden kann.
Im Moment ist er nur für das LittleFS im Controller gedacht, SD-Karte kann man ganz schnell selbst aktivieren wenn man das so haben möchte und noch GPIOs für einen Kartenleser frei hat.

Mit autosave ist es möglich in Abständen nachzuschauen ob sich Parameter im Radio geändert haben. Wenn das passiert, dann kann man diese Parameter automatisch in eine Datei (settings.txt) schreiben lassen. Diese Datei wird dann beim Neustart des Systems eingelesen und das Radio spielt zum Beispiel auf dem letzten eingestellten Programmplatz weiter.

Speicherung von Lautstärke, Helligkeitsstufen eines Displays oder andere Parameter sind einfach machbar.

_______________________________________________________

Ich habe noch im WLAN-Betrieb ein paar Probleme beobachtet.  Während es im Ethernetbetrieb nie passiert, kann mein Versuchsaufbau im WLAN Betrieb immer mal wieder festfrieren, nach 1 - 2 Stunden WLAN-Spielzeit, aber auch oftmals nie.   Solche Fehler liebe ich.

Zuerst habe ich gedacht das irgendeine Komponente von uns Speicherverluste hat, also das  immer mehr Speicher allokiert, aber nicht mehr freigegeben wird.
Ich habe daraufhin den Heartbeat um diese Information erweitert, kann aber niemals einen Verlust an Speicher sehen. Nicht nach Minuten, nicht nach Stunden, auch wenn es einfriert ist genausoviel Speicher frei wie wenn das Radio stundenlang fröhlich spielt. *Kotz*    Schade, denn das  Leck hätte man schnell finden können.

Auch das WLAN bricht nicht zusammen, Puffer ist immer gefüllt, kein Underrun. Provizierte Underruns werden nach Neuanlage der Verbindung einfach wieder aufgefüllt und weitergespielt. Nach Verbindungstimeout muss man neu Verbinden oder Umschalten. Nichts, kein Problem.

Der WLAN Chip wird auch nach einer oder 2 Stunden Dauerstreaming nur fingerwarm, also vielleicht 30-40°C. Daher habe ich erst gar nicht mit der IR-Kamera geschaut. Ein thermisches Problem schließe ich aus, zumal man sofort danach wieder spielen kann ohne das man Abkühlzeit haben muss.

Die Sache passiert auch wenn man soviel wie möglich von unseren Komponten abklemmt, also wirklich nur den Player nimmt ohne GPIOD, ohne DISLAYD, ...

Ob es am Arduino-Core selbst liegt bzw. den dort verwendeten Libs? 
Habe ich noch nicht untersucht. Eventuell ist ja auch mein Verdrahtung schuld, Leitungen zum VS1053 und Display gehen noch sehr nah an den WiFi-Antennen vorbei. Aber man hat auch ein paar GPIOs auf dem Pico-Board  direkt neben das Antennensystem gepackt ->


  untitled.jpg (Größe: 27,71 KB / Downloads: 86)

Das betrifft GPIO14 bis 17, danach kommen gegenüberliegend Massepins. 
Es betrifft also die I2C/SPI 0 und 1 Schnittstelle, die ich an diesen Pins in meinem Aufbau dummerweise auch benutze! Hier muss ich vielleicht noch weiter untersuchen und Änderungen machen. Der Bereich hat mit Sicherheit Einkopplungen vom WiFi!

Bei den meisten ESP32 Boards dagegen geht die WiFi-Antenne über das eigene Board hinaus und ist damit nie direkt neben GPIOs . Das Design-Guide empfiehlt das klar

https://docs.espressif.com/projects/esp-...esign.html

Ich bin sicher das auch der im Pico W verbaute CYW43439 passende Guidelines zum Antenna Placement hat.

Der Arduino Nano RP2040 zum Beispiel hat bei seinem WiFi ein etwas abgesetztes Antennensystem !






Um dieses "Hänger"-Problem erstmal zu entschärfen, habe ich dem iRadioPico einen Wachhund beiseite gestellt. 
https://arduino-pico.readthedocs.io/en/l...e-watchdog

Dieser Wachhund verlangt spätesten nach 8.3 Sekunden wieder eine Streicheleinheit, sonst bellt er laut.
Man muss also dafür sorgen das innerhalb dieser Zeit aus irgendeinem Prozess (bei uns ist es der Heartbeat) der Timer zurückgesetzt wird. Wird er das nicht, weil der RP2040 einfriert (oder die Rückstellung sich verzögert), wird der Prozessor automatisch resetet. Da wir aber den Zustand im LittleFS gespeichert haben, spielt das Radio nach dem Reset wieder auf der letzten eingestellen Station. So betrachtet arbeitet autosave mit dem Wachhund also auch als dreckiger Workaround für das noch nicht lokalisierte Problem.     Ich habs aber lieber wenn ich das Problem direkt kenne.

[OttoBerger]

  Untitled.jpg (Größe: 33,32 KB / Downloads: 59)

fast 4 Std absolut fehlerfreies Verhalten, kein Watchdog Alarm, wenn man drauf wartet kommts nie

[saarfranzose]

mein Labormuster läuft jetzt seit 18:25. Also bis jetzt 4,5 Std, ohne Aussetzer. Es hat aber auch einen recht massiven Aufbau.

Oder sollte ich den Debug-Level höher setzen?

18:24:58.872 -> iRadioPico: Heartbeat
18:25:39.528 -> iRadioPico: Heartbeat
18:26:20.335 -> iRadioPico: Heartbeat
18:27:01.119 -> iRadioPico: Heartbeat
18:27:41.873 -> iRadioPico: Heartbeat
18:28:22.548 -> iRadioPico: Heartbeat
18:29:03.291 -> iRadioPico: Heartbeat
18:29:43.992 -> iRadioPico: Heartbeat
18:30:24.735 -> iRadioPico: Heartbeat
18:31:05.426 -> iRadioPico: Heartbeat
18:31:46.120 -> iRadioPico: Heartbeat
18:32:26.813 -> iRadioPico: Heartbeat
18:33:07.598 -> iRadioPico: Heartbeat
18:33:47.695 -> iRadioPico: Heartbeat
18:34:29.045 -> iRadioPico: Heartbeat

   

[OttoBerger]

Im HIL-System mit automatisch überwachten Test-Cases macht das jetzt auch keine Probleme.
3 Radios , 1 x Dauerstreaming auf einem Kanal, 2x mit simulierter Bedienung in unregelmäßigen Abständen , Watchdog ist seit fast 20h auf keinem System gekommen. Ich vermute das Umlegen der Leitungen in dem einem Fall hats gebracht und es war ein EMV Problem.

Dein Testsystem Jupp ist aber schon so kompakt und gut zusammengestellt, dass man mit einem kleinen gedruckten Gehäuse drum schon einen Zuspieler für eine HiFi-Anlage oder Modulator hat.

[saarfranzose]

es ist eine zweckentfremdete ESP32-Platine. Ich brauche sie so wie sie ist zum Testen und um auch mal schnell was zu ändern. Einer einfachen CPU-Adaptierung steht entgegen dass die ESP32-Schaltung für VS und TFT die Leitungen CLK, RST und MOSI gemeinsam nutzt, wogegen die Leitungen beim Pico auf getrennten gpio liegen. Ich arbeite aber schon an einer Pico-Platine.