FAQ zum iRadioMini

[saarfranzose]

Hallo zusammen!

Oh hatte Bernhard heute die Nachtschicht :-)

wie gesagt habe ich für gpio21 kaum Ausweichmöglichkeiten, weil nur ganz wenige Pin herausgeführt sind. Ich habe es jetzt mal (erfolglos) mit gpio18 versucht, der eigentlich mit dem Taster key5 schon belegt ist.

I (923) DISPLAYD_SSD1306_I2C: u8g2_InitDisplay
I (943) u8g2_hal: sda_io_num 18
I (943) u8g2_hal: scl_io_num 22
I (963) u8g2_hal: clk_speed 50000
I (963) u8g2_hal: i2c_param_config 1
I (963) u8g2_hal: i2c_driver_install 1
I (1013) HTTPD: alive
E (1283) I2C_BUS: /home/pi/esp-adf/components/esp_peripherals/driver/i2c_bus/i2c                                                                                                                                                            _bus.c:101 (i2c_bus_write_bytes):I2C Bus WriteReg Error
E (1283) err: esp_err_t = 263
assertion "0 && "i2c_master_cmd_begin(I2C_MASTER_NUM, handle_i2c, I2C_TIMEOUT_MS                                                                                                                                                              / portTICK_RATE_MS)"" failed: file "../main/modules/display/ssd1306OLED/u8g2_es                                                                                                                                                            p32_hal.c", line 159, function: u8g2_esp32_i2c_byte_cb
abort() was called at PC 0x400d58bb on core 0

was mich zu der Frage bringt: iRadioMini wird ja bestimmt nicht an die Audio-Boards gebunden sein. Weitere Ausbaustufen (SPI-display, encoder..) verlangen weitere freie gpio's. Wie bekommt man iRadioMini auf andere hardware? Ist die Espressif Umgebung bei den Board-Definitionen flexibel genug? Auch die Servo-Erweiterung benutzt mit 18 und 23 gpio's die bereits mit key 5 und key 4 belegt sind.

PS: gpio18 und 23 kann bei meinem Board-Design eigentlich nicht auf keys liegen, weil auf denen der I2C des codec liegt.

[Bernhard45]

wie gesagt habe ich für gpio21 kaum Ausweichmöglichkeiten, weil nur ganz wenige Pin herausgeführt sind. Ich habe es jetzt mal (erfolglos) mit gpio18 versucht, der eigentlich mit dem Taster key5 schon belegt ist.

Nicht nur key5 -> auch der gpiod, gpiod_rotary nutzen diesen Pin standardmäßig auf meinem Board, siehe:

https://github.com/BM45/iRadioMini/blob/...es/gpiod.c
https://github.com/BM45/iRadioMini/blob/...d_rotary.c

Wenn da der Drehencoder dran hängt, dann darf man key5 natürlich nicht drücken!

Mein Header sieht übrigens so aus:

GND |IO0|RST|TX0|RX0|3v3|3v3
IO21|IO22|IO19|IO23|IO18|IO5|GND

Und in der Tat, I2C - displayd nutzt zur Zeit IO21|IO22. Das funktioniert bei mir aber nur störungsfrei, weil ich den Kopfhörerausgang (zur Kontrolle der Soundqualität der Softwaredecoder auf einem externen Analyzer) und nicht die Board-Endstufen nutze, denn da ist IO21 ja der Pin, der die Endstufen muted. Diese Belegung geht also nur problemlos, wenn man das Audio vom Kopfhöreranschluß holt!

Die ganzen Bedieneinheiten (gpiods) sind defaultmäßig auf auf IO5 und IO18, bleibt also IO23 und IO19. Dann darf man aber nicht zusätzlich zu einem I2C-Display und Drehencoder/Taster einen Servo zum Skalentrieb laufen lassen.

IO0 - Dazu sagt https://github.com/BM45/iRadioMini/blob/...cation.pdf auf Seite 3:

"Must be hanging when using internal codec".

Und auf Seite 4, gleiches Dokument -> Normal operation -> NC

TX0/RX0 -> sind zwar normale GPIOs, aber -> Seite 3 -> Download Serial Port.

Wir sehen (und wussten es vorher), die Anschlußmöglichkeiten an diesen Audioboards sind begrenzt. Wenn Du ein Display betreibst, solltest Du auf ein servo-getriebenes Skalenblatt verzichten und umgekehrt. Auf diesen Boards müssen wir uns (ohne Lötarbeiten) einschränken und auch darauf achten (wie beim iRadio auf Raspberry auch), daß unseren ganzen Daemonen keinen Ressourcenkonflikt untereinander verursachen.

Wie sieht denn die Headerbelegung bei Dir aus Jupp?

In meinem Github ist für das "neue" LyraT4.3/AI-Design folgendes eingepflegt:

esp_err_t get_i2c_pins(i2c_port_t port, i2c_config_t *i2c_config)
{
    AUDIO_NULL_CHECK(TAG, i2c_config, return ESP_FAIL);
    if (port == I2C_NUM_0 || port == I2C_NUM_1) {
        i2c_config->sda_io_num = GPIO_NUM_33; //GPIO_NUM_18;
        i2c_config->scl_io_num = GPIO_NUM_32; //GPIO_NUM_23;
    } else {
        i2c_config->sda_io_num = -1;
        i2c_config->scl_io_num = -1;
        ESP_LOGE(TAG, "i2c port %d is not supported", port);
        return ESP_FAIL;
    }
    return ESP_OK;
}

esp_err_t get_i2s_pins(i2s_port_t port, i2s_pin_config_t *i2s_config)
{
    AUDIO_NULL_CHECK(TAG, i2s_config, return ESP_FAIL);
    if (port == I2S_NUM_0 || port == I2S_NUM_1) {
        i2s_config->bck_io_num = GPIO_NUM_27; //GPIO_NUM_5;
        i2s_config->ws_io_num = GPIO_NUM_25;
        i2s_config->data_out_num = GPIO_NUM_26;
        i2s_config->data_in_num = GPIO_NUM_35;

Das "alte" Design hatte die auskommentierten Nummern. Dann liegen auf dem Pin-Header doch bestimmt andere freie IOs? Irgendwo wirst Du doch sicher noch einen freien Pin mopsen können, oder? Natürlich kannst Du da auf dem Eval-Board dennoch nicht alles an Hardware und Daemonen parallel betreiben. 

Da auf diesem Board generell die Frage der nur knapp verfügbaren und herausgeführten Pins aufkommt, möchte ich nochmal ein paar Sparvorschläge zeigen.

Gerade wenn man mehr als einen Encoder anschließen will, bieten sich solche Sachen an:

https://www.amazon.de/Duppa-I2C-Encoder-...B07P5FFRZG
https://learn.adafruit.com/adafruit-i2c-...r?view=all

Design + Firmware ist auch frei verfügbar: https://github.com/Fattoresaimon/I2CEncoderV2.1

Das erinnert an mein I2C-Analogpotentiometer aus dem Umbaubericht RFT/Philips 634 wird zum Digitalradio https://radio-bastler.de/forum/showthread.php?tid=11449





So einen Arduino kann man auch mit mehreren Encodern, Display-I2Cs, ... bestücken und alles mittels SDL/SDA, also zwei Leitungen, zum Audio-Board übertragen.

Die Sache muss, kann und soll aber nicht nur auf Drehencoder begrenzt sein, man google nach "i2c io expander" -> Da gibt es für wenig Geld soetwas schon fertig umgesetzt. Mehrere solche "Expander" kann man leicht durch unterschiedliche Slave-Adressen an einen I2C-Bus hängen.

Mehrere Taster könnte man auch über einen Analogpin auslesbar machen, siehe Datenblatt des Audio Boards (!) und auch

https://aws1.discourse-cdn.com/arduino/o...e01a95.png

was mich zu der Frage bringt: iRadioMini wird ja bestimmt nicht an die Audio-Boards gebunden sein.

Das iRadioMini für ESP32 läuft auf allem, was das ESP-ADF/IDF unterstützt. Wie ich schon geschrieben habe, kann man sein eigenes  Audio-Board, also auch ESP32 Modul + angeschlossenes SD-Karteninterface + DAC (kann auch der interne vom ESP32 sein) , ... hinzufügen. 

Weitere Ausbaustufen (SPI-display, encoder..) verlangen weitere freie gpio's.

Ja, aber im iRadioMini werden diese Displays und Encoder die IOs nutzen, die auf dem Header vorgeben sind, einfach damit der iRadioMini-Nachbauer so ein Board kaufen und mit der Software experimentieren kann und nicht erst ein eigenes Design anlegen muss. Gleich mit einer eigenen Board-Definition einzusteigen überfordert Ihn und Uns bei der Beantwortung der dann auftretenden Fragen hier im Forum. Du siehst ja selbst, das die eigentlich einfache Installation des ADF/IDF für Umsteiger schon herausfordernd sein kann.

Wie bekommt man iRadioMini auf andere hardware?

Halt Du die Festlegung eines eigenen Boad-Designs im ADF. Ich werde das später mal zeigen wie das geht, aber ein Schritt nach dem anderen.

Ist die Espressif Umgebung bei den Board-Definitionen flexibel genug?

Absolut!


Gruß
Bernhard

[saarfranzose]

Mein Header sieht übrigens so aus:

GND |IO0|RST|TX0|RX0|3v3|3v3
IO21|IO22|IO19|IO23|IO18|IO5|GND
..
Wie sieht denn die Headerbelegung bei Dir aus Jupp?

der Header ist bei meinen boards identisch. Ich hatte mal mit Hilfe von Norbert eine Tabelle erstellt, weil wir ja schon mal mit Testprogrammen experimentiert hatten. Norbert müsste die gleiche Revision haben wie du. Hier ein Auszug:


  tabelle.JPG (Größe: 59,38 KB / Downloads: 239)

Irgendwo wirst Du doch sicher noch einen freien Pin mopsen können, oder?

keine Chance. 18 hatte ich getestet und 5 brauche ich für I2S. Ich habe ja nicht mal einen externen I2C-Bus für Expansionen. Beim Lyrat-Board sieht es auch nicht besser aus.

Halt Du die Festlegung eines eigenen Boad-Designs im ADF. Ich werde das später mal zeigen wie das geht, aber ein Schritt nach dem anderen

das ist schön. Es wäre wichtig damit ich weitere Ausbaustufen von iRadioMini nachvollziehen kann.

[Bernhard45]

Na warte mal, beim Display kann bei dir SCL ja auf der 22 bleiben. SDL auf 21 geht nur, wenn man Kopfhörer nimmt, weil PA Stummschaltung.
Auf 18 geht nicht, weil dort key5 ist bzw. der gpiod, zusammen mit der 5. Servo muss ausbleiben, dann kann SDA vom Display ja auch auf 19.
Verzichtest Du fürs Testen erstmal auf gpiod und steuerst nur über den Webbrowser, dann kannst Du den GPIO dafür benutzen.

Die passenden Dienste musst du natürlich in der iRadioMini.c zu/ab-schalten.

[norbert_w]

PHP-Code:

AUDIO_NULL_CHECK(TAG, i2c_config, return ESP_FAIL);
    if (port == I2C_NUM_0 || port == I2C_NUM_1) {
        i2c_config->sda_io_num = GPIO_NUM_33; //GPIO_NUM_18;
        i2c_config->scl_io_num = GPIO_NUM_32; //GPIO_NUM_23; 


Die I2C Pinbelegung (32 -33) war für mich das Argument, den I2C Bus beiseite zu legen, da
- die Pins auf dem Board nicht zugänglich sind (sie liegen unter dem Abschirmblech des ESP32)
- ich nicht in der Lage war/bin den I2C_NUM_1 entsprechend zu konfigurieren.
IC2_NUM_0 wird benötigt um den ES8288 zu parametrieren.
GPIO 21 schaltet die Endstufen frei, die ich ja auch bei einem Audio Board benutzen möchte.

Bernhard und ich scheinen den gleichen Typ Board zu haben.

[Bernhard45]

- ich nicht in der Lage war/bin den I2C_NUM_1 entsprechend zu konfigurieren.

Wie Du den zweiten I2C-Controller benutzen kannst, findest Du ja in unserem Quelltext zum Display.

https://github.com/BM45/iRadioMini/blob/...sp32_hal.c

Dort steht auch drin wie SPI angeworfen wird.

Ebenso einfach beschrieben hier in der Doku zu ESP32 IDF https://docs.espressif.com/projects/esp-...s/i2c.html ,
jeweils getrennt ob der ESP32 ein Master oder Slave sein soll.

Die zu füllenden Datenstrukturen und möglichen Werte auch nochmal hier: https://github.com/espressif/esp-idf/blo...iver/i2c.h

Und nicht zuletzt, besteht die Möglichkeit einen Software-I2C aufzumachen. Das zeige ich in einem weiteren Schritt im iRadioMini-Hauptthread.

Dann könnte man Szenarien wie:

I2C0->Audiocodec (2 Leitungen im A1S-Modul)
I2C1->Display only (2 GPIOs)
Soft_I2C-> I2C Tastaturen / I2C Encoder / Gestensensoren / Potis ( 2 GPIOs )

, also mit 4 externen GPIOs, realisieren. Ja Norbert, wir scheinen die gleiche PCB-Version zu haben.

[norbert_w]

Ich danke Dir für die Informationen zum I2C Bus, Bernhard.
Da liegt noch ein Stückchen Arbeit vor mir!

[Bernhard45]

was mich zu der Frage bringt: iRadioMini wird ja bestimmt nicht an die Audio-Boards gebunden sein

Ich habe das jetzt noch mal auf der Github-Seite des iRadioMini etwas deutlicher geschrieben.

   

Auch wenn ich hier https://radio-bastler.de/forum/showthrea...#pid219800 geschrieben habe:

"Als Basis für das iRadioMini soll dieses schon beschriebene Board dienen."

bedeutet das natürlich nicht, daß nicht auch andere "stinknormale" ESP32-Boards genutzt werden können. Wenn das rüber gekommen ist, dann möchte ich mich dafür bei den Lesern entschuldigen. Natürlich ist es für den Einsteiger einfacher, so ein fertiges ESP32 Audio Kit zu nehmen, was out-of-box vom ESP-ADF unterstützt wird. 
Es ist aber kein Unterschied, ob ich dieses fertige Board nehme oder einen ESP32 (in einer seinen Ausführungen) und den Rest (SD-Karte, DAC, Endstufe , ...) mit HATs drum herum baue.  Ich fand diese ESP32 Audio Eval-Boards zusammen mit dem ADF eben einsteigerfreundlich und das war der Urknall für das iRadioMini auf ESP32.

Übrigens gibt es auch ein iRadioMini für STM32 ...  , aber das ist eine andere Geschichte und ich will jetzt hier nicht noch mehr Verwirrung mit zusätzlichen Plattformen stiften.

Wir merken uns: Praktisch da wo bisher Edzelf oder KA-Radio32 läuft, kann im Prinzip auch ein iRadioMini laufen und umgekehrt (man muss diese Audioboards hier natürlich auch nicht mit dem ADF programmieren). Das geht mit dem Arduino-Framework genauso, aber ich persönlich finde das ADF/IDF leistungsfähiger und eleganter als das Arduino-Framework. Es kommt dem, was wir mit Linux auf Raspberry kennen, sehr nahe - von daher ist das System iRadio auch ziemlich gut, schnell und einfach auf ESP32 übertragbar.

Gruß
Bernhard

[saarfranzose]

ich war schon versucht mir eine hardware zusammenzustecken. Aber SD-Card Reader habe ich nur auf SPI-Displays.

[Bernhard45]

Hallo Jupp,

ich war schon versucht mir eine hardware zusammenzustecken. Aber SD-Card Reader habe ich nur auf SPI-Displays.

Und wo ist da das Problem? Solche Displays mit "angeklebtem" SD-Card Reader, also so etwas hier



   



sind ja in der Regel so aufgebaut, daß Display und SD-Card Fassung zwei völlig getrennt Sachen sind.

Links ist alles für SD, Rechts für Display, einzig VCC/GND teilen sich beide.



Zumindest bei mir machen solche Kombinationen mit dem ADF/IDF und damit auch mit dem iRadioMini keinerlei Probleme.



Im iRadioMini initialisieren wir den SD-Karten "Service" mit audio_board_sdcard_init(set, SD_MODE_1_LINE);



Also SD_MODE_1_LINE. Was bedeutet das genau? Das kannst Du hier sehen:



   



https://www.fpga4fun.com/SD1.html



Zu den Pull-UPs in den Datenleitungen lässt sich auch Espressif nochmal aus: https://docs.espressif.com/projects/esp-...ments.html



Du kannst also mit solchen SD-Karten Fassungen (Reader finde ich zu hoch gegriffen), problemlos arbeiten. Entweder baust Du das nach dem Schaltplan deines Audio Boards 1 zu 1 nach, oder Du hängst die SD-Karte an ein normales ESP32 Modul (NodeMCU und wie sie alle heißen) beliebig ran. Musst halt nur bei Modulen wie solchen hier







darauf achten, das Du da nicht Ressourcenkonflikte mit aufgebrachter Peripherie, Flash-Speicher, ... hast. Diese Boards führen ja in der Regel alles an GPIOs raus, im Gegensatz zu unserem ESP32 Audio Kit.



In der Boarddefinition zum AI/LyraT siehst Du hier https://github.com/BM45/esp-adf/blob/mas...oard_def.h



wo der "Kartenerkennungspin" ist  -> #define SDCARD_INTR_GPIO          GPIO_NUM_34


Kannst Du bei Bedarf umlegen.

Die restlichen Pins hat das ADF hier festgelegt: https://github.com/BM45/esp-adf/blob/mas...d/sdcard.c



Kann man ändern, wenn man will und die eigene Hardware es unterstützt, unter Umständen muss man es sogar, wenn das 0815-Board diese GPIOs selbst mit irgendetwas belegt hat.



So das wäre der Teil mit der SD-Karte.



Display, Servo etc. an eigene HW anzuschließen ist sicher nicht das Problem. Aber auch hier: Achte auf Ressourcenkonflikte.



Nun zum ES8388-Chip: Wenn Du so einen als HAT/Shield hast, schließt Du Ihn so an, wie auf deinem LyraT-Board. Du kannst natürlich auch alle anderen DACs nehmen, die das ADF als Treiber dabei hat.



https://github.com/BM45/esp-adf/tree/mas...hal/driver



Musst das aber - wenn Du weiter LyraT4.3 ausgewählt hast - aufwendig im Buildprozess umbauen, damit dieser andere Chip auch benutzt wird. Wenn man da noch kein Durchblick hat, zerschießt man sich das ganze ADF! Ich würde daher davon abraten und lieber zur eigenen sauberen Board-Definition tendieren.


Aus diesem Grund will ich hier gleich sagen: Support für ein geändertes ADF / Standardboard gebe ich nicht! Bei den 0815-Modulen gibt es zig Exemplare mit teilweise chaotischen Belegungen und Nummerierungen (die sogar nicht immer stimmen) -> da Support zu geben ist mir nicht möglich!

Was aber weniger problematisch ist: Du kannst erst einmal auf dem ES8388-Chip verzichten und den ESP32 mit "internen I2S-DAC" benutzen. Ich wollte das erst später zeigen, aber schiebe es mal provisorisch ein:



Wenn in der player.c, also dem Quellcode unseres miniVLC folgendes abgeändert wird:

PHP-Code:

  ESP_LOGI(TAG, "[ 2.2 ] Create i2s stream to write data to codec chip");
    i2s_stream_cfg_t i2s_cfg = I2S_STREAM_INTERNAL_DAC_CFG_DEFAULT(); //I2S_STREAM_CFG_DEFAULT();
  


kannst Du direkt das Audio am ESP32 so abgreifen und brauchst gar keinen dieser Codec-Chips mehr:




  EarphoneESP32.jpg (Größe: 9,25 KB / Downloads: 185)







Siehe dazu auch die ADF-Doku: https://docs.espressif.com/projects/esp-...index.html

I2S Stream¶
When the I2S stream type is “writer”, the data may be sent either to a codec chip or to the internal DAC of ESP32. To simplify configuration, two macros are provided to cover each case:

• Code:

  I2S_STREAM_CFG_DEFAULT
  - the I2S stream is communicating with a codec chip
  
• Code:

  I2S_STREAM_INTERNAL_DAC_CFG_DEFAULT
  - the stream data are sent to the DAC
  

Each macro configures several other stream parameters such as sample rate, bits per sample, DMA buffer length, etc.

Da hier aber auch nicht das ADF oder eine bestehende Boarddefinition abgeändert wird, sondern die Sache in unserer iRadioMini-Software geschieht, habe ich keine Probleme diese "Funktion" gleich einzuschieben.


Gruß

Bernhard

[Bernhard45]

Hallo nochmals,

ich habe die Sache mit dem internen Audio DAC mal jetzt auch im Quellcode es iRadioMini vorgezogen.

   

In der globals.h gibt es das Define USE_INTERNAL_AUDIODAC . Wenn dieses gesetzt (auskommentiert) ist, wird bei allen Audioboards auf den externen DAC verzichtet und der ESP32 interne DAC für die Audioausgabe genutzt.

Man braucht also nicht mehr im player.c Änderungen an dem Quellcode vorzunehmen.

Wer will kann damit ja sofort auf minimalsten ESP32-Systemen (selbst ohne gpiod, displayd) das iRadioMini laufen lassen.


Gruß
Berhard

[saarfranzose]

ich habe jetzt einen Aufbau mit diesem Board:

ESP32 DevKit ESP32-WROOM

sowie dem Kombi-Display auf deinem obigen Bild.

ich fasse mal zusammen wo ich überall was geändert/kontrolliert habe. Dabei habe ich mich an den Edzelf-Belegungen und dem o.a. Belegungsbild orientiert:

~/iRadioMini/main/modules/display/ssd1306OLED/displayd_i2c.c

SCL (für Display) = 22
SDA (für Display) = 21

/home/pi/esp-adf/components/audio_board/lyrat_v4_3/board_pins_config.c

SDA (für I2S) = 33
SCL (für I2S) = 32

I2S: bck = 5
I2S: lrc = 25
I2S: dout = 26

~/esp-adf/components/esp_peripherals/lib/sdcard/sdcard.c

MISO = 19
MOSI = 23
CS = 27
SCK = 18

~/esp-adf/components/audio_board/lyrat_v4_3/board_def.h

SCK = 18

Die Version mit den defines ist noch nicht eingeflossen. Ich habe einen MAX98357A angeklemmt welcher sich als ES8388-codec ansprechen lassen sollte.

Der Monitor zeigt dass er keine SD findet, danach folgt eine Reihe I2C-Meldungen. Natürlich habe ich das Display auch mit 3,3V versorgt.

Code:

I (320) IRADIOMINI: call startup procedures (aka rc.local)
E (350) PERIPH_SDCARD: no sdcard detect
E (2850) AUDIO_BOARD: Sdcard mount failed
I (2850) SDCARD: Try read wifi.txt from sdcard
E (2850) SDCARD: No wifi.txt on sdcard!
I (2850) SDCARD: Try read channel list from sdcard
E (2850) SDCARD: No playlist.m3u on sdcard!
I (2860) IRADIOMINI: prepare to start the player process
I (2860) IRADIOMINI: start IPC
I (2870) IRADIOMINI: Heartbeat
I (2870) PLAYER: [ 1 ] startup Audio Player
I (2880) gpio: GPIO[19]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:3
E (2890) gpio: gpio_install_isr_service(412): GPIO isr service already installed
E (2920) I2C_BUS: /home/pi/esp-adf/components/esp_peripherals/driver/i2c_bus/i2c_bus.c:101 (i2c_bus_write_bytes                                                                                                                              ):I2C Bus WriteReg Error
E (2920) I2C_BUS: /home/pi/esp-adf/components/esp_peripherals/driver/i2c_bus/i2c_bus.c:101 (i2c_bus_write_bytes                                                                                                                              ):I2C Bus WriteReg Error
E (2950) I2C_BUS: /home/pi/esp-adf/components/esp_peripherals/driver/i2c_bus/i2c_bus.c:101 (i2c_bus_write_bytes

[norbert_w]

Hallo Jupp,

in der o. g.  Datei    ~/esp-adf/components/esp_peripherals/lib/sdcard/sdcard.c
wird der Pin card_detect abgefragt:
esp_err_t sdcard_init(int card_detect_pin, void (*detect_intr_handler)(void *), void *isr_context)

Wenn der nicht das entsprechende Signal für SD-Card gesteckt liefert, wird die Karte nicht erkannt.
Fehlermeldung: E (350) PERIPH_SDCARD: no sdcard detect

[Bernhard45]

Siehe auch #70

[saarfranzose]

es gibt doch keine extra Leitung über die der reader ein "SD-Card gesteckt" melden könnte. Es gibt nur die Chip-Select, über die der Prozessor den Reader aktiviert. Das wäre doch diese Definition:

~/esp-adf/components/esp_peripherals/lib/sdcard/sdcard.c
#define PIN_NUM_CS 27

aber was trage ich hier ein?

~/esp-adf/components/audio_board/lyrat_v4_3/board_def.h
#define SDCARD_INTR_GPIO GPIO_NUM_34 // 27

muss ich lt. hier wirklich auf dem DevKit rumlöten?

[saarfranzose]

hier gibt es noch Konfliktpunkte.

~/esp-adf/components/audio_board/lyrat_v4_3/board_def.h

#define AUXIN_DETECT_GPIO GPIO_NUM_12
#define HEADPHONE_DETECT GPIO_NUM_19
#define PA_ENABLE_GPIO GPIO_NUM_21

#define GREEN_LED_GPIO GPIO_NUM_22

kann man die Abfragen mit -1 deaktivieren?

#define AUXIN_DETECT_GPIO -1 //GPIO_NUM_12
#define HEADPHONE_DETECT -1 //GPIO_NUM_19
#define PA_ENABLE_GPIO -1 //GPIO_NUM_21

#define GREEN_LED_GPIO -1 //GPIO_NUM_22

[norbert_w]

Jupp,
laut Schaltplan und Beitrag #70 ist der "Kartenerkennungspin"  -> #define SDCARD_INTR_GPIO          GPIO_NUM_34
Den würde ich, genau wie die anderen nicht benötigten Pins
#define AUXIN_DETECT_GPIO -1 //GPIO_NUM_12
#define HEADPHONE_DETECT -1 //GPIO_NUM_19
#define PA_ENABLE_GPIO -1 //GPIO_NUM_21

#define GREEN_LED_GPIO -1 //GPIO_NUM_22
testweise auf -1 definieren.
Wenn es mit dem Kartenerkennungspin -1 nicht funktioniert, dann nimm doch einen unbenutzten Eingang vom Header und lege den auf 3,3V.
Übrigens Jupp, das 2,8 Zoll TFT-Display mit dem ILI_9341 Controller hat einen SD-Card Erkennungsanschluss, der aber nicht auf den Headern verdrahtet ist...

[Bernhard45]

Hallo zusammen,

ich habe mal eine Frage. Warum baut Ihr das LyraT4.3 Board im ersten Schritt nicht nach, sondern ändert alle möglichen Belegungen, sowohl in der Boarddefinition und noch schlimmer im ADF? Damit seid Ihr jetzt an einem Punkt, wo ihr mit dem ADF für kein Referenzboard mehr eine funktionierende Firmware bauen könnt. 


Ich kenne dein verwendetes Board nicht Jupp, aber gibt es nach dem Schaltplan dieses Boards und seinen technischen Beschreibungen nach für so etwas einen Grund?

~/esp-adf/components/esp_peripherals/lib/sdcard/sdcard.c

MISO = 19
MOSI = 23
CS = 27
SCK = 18

Das sind Änderungen direkt im "Herzen" des ADF, nicht nur in den Board-def, siehe #70!!! Es gibt wahnsinnig viele ESP32 Boards zum Beispiel mit SD-Karteninterface, die sich genau an die Vorgaben des SDKs halten.

   

Das hat einen Grund -> Kompatibilität erhalten. Mit deinen gemachten Änderungen kannst Du für keines dieser Boards mehr eine funktionierende Firmware bauen! Weder vom iRadioMini noch von anderem Beispielcode.
Wenn bei deinem gewählten ESP32-Modul, auch Bootstrapping-seitig, nichts gegen ein Nachbau des LyraT-Boards spricht, warum machst Du das nicht erstmal so?

SD_Card gesteckt hat Dir Norbert ja schon gesagt wo die Kontakte dafür sind. Aber das kannst Du auf deinem Dev-Board ja auch mit einem Jumperkabel schnell simulieren.


Gruß
Bernhard

[saarfranzose]

Hallo Bernhard,

nun das ist das Board welches ich seit Jahren benutze und auch Platinen dazu habe. Mit AI-Board und LyraT bin ich am Ende. Es gibt die Entscheidung Display oder Endstufe. Beides zusammen geht nicht. Weitere Peripherie erst recht nicht. Es war noch nie die Rede dass ein LyraT nachgebaut werden soll. Es war angedacht dass iRadioMini auf allen ESP32 Boards läuft. Du hast selbst die Konfigurationsstellen abgegeben. Und damit war für mich klar dass man auf diesem Weg alle Boards anpassen kann.
Alles was ich hier habe, ob Lolin, Lolin32 oder ESPlay, jedes Board verlangt andere Zuweisungen.
Okay, dann schau ich mal ob es mir gelingt mit einem Lyrat-kompatiblen Dev-Board weiter zu arbeiten.

[saarfranzose]

..Wenn es mit dem Kartenerkennungspin -1 nicht funktioniert, dann nimm doch einen unbenutzten Eingang vom Header und lege den auf 3,3V..

auch mit einem simulierten Erkennungspin wird die Karte nicht gefunden.

#define SDCARD_INTR_GPIO GPIO_NUM_15

ich breche an der Stelle ab, baue mir wieder eine saubere Umgebung und gehe auf Einkaufstour.

Das wird der beste Weg sein. Erst mal kompatibel bleiben, bis wir irgendwann mal eigene Hardware definieren können und vielleicht sogar mit menuconfig switchen können. iRadioMini ist ja noch in einer frühen Entwicklungsstufe.

Danke Bernhard für die Unterstützung bei der toolchain! Das war für mich allein eine unüberwindbare Hürde!