custom SPI pins not working on ESP32
trying to use this with a custom set of spi pins but it dosnt work on an esp32. if i change the board pin definitons for the spi pins then it works.
What EPS32 board are you using? What board are you selecting in the Arduino IDE? What version of the ESP32 Board Support Package are you using? What is an example sketch that demonstrates the issue?
- knockoff WeMos LOLIN32 Lite
- ESP32 Dev Module
- 2.0.5
- simple player
also i tried using the same actual pins but with manualy defining the same pins as stock and that still didnt work
if i change the board pin definitons for the spi pins then it works.
But it works with some changes? Where did you make these changes? In your sketch? Or to the actual library code?
i changed the pins in the arduino IDE board definitions, it changes what pins it tries to use for the hardware SPI functions
That sounds like files in the ESP32 Board Support Package?
yes, C:\Users\***\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.5\variants\esp32\pins_arduino.h
OK, if there is an issue with the board definition, please open an issue with espressif: https://github.com/espressif/arduino-esp32/issues
it is not an issue with the board definitions, the existing pins are right. the issue is that when i ask this library to use diffrent pins (eg the second set of spi pins on the esp32) it dosnt work
How are you specifying different pins in your sketch?
#define CLK 18
#define MISO 19
#define MOSI 23
#define RESET -1
#define CS 10
#define XDCS 8
#define SDCS 4
#define DREQ 3
Adafruit_VS1053_FilePlayer musicPlayer = Adafruit_VS1053_FilePlayer(MOSI, MISO, CLK, RESET, CS, XDCS, DREQ, SDCS);
those are the same spi pins defined in the pins file
if i switch to Adafruit_VS1053_FilePlayer(RESET, CS, XDCS, DREQ, SDCS); it works fine, basicaly the software spi isnt working on the esp32
Were you able to get software SPI to work at all?
not with this library but it works fine with the Adafruit library for the nokia Nokia 5110 display
It sounds like hardware SPI works as expected. But you could not get software SPI to work. So not sure what you were able to get working by updating the board definition file?
the esp32 boards can technicaly do hardware SPI on almost every pin, it works better on the standard ones but can be done on most. so changing the board definition made it use hardware SPI on the diffrent pins.
That would be required due to how Arduino works. That is not an issue with this library.
But your code snippet is setting up for software SPI:
Adafruit_VS1053_FilePlayer musicPlayer = Adafruit_VS1053_FilePlayer(MOSI, MISO, CLK, RESET, CS, XDCS, DREQ, SDCS);
And it sounds like that did not work?
It's still not clear what worked / did not work here.
so i was running the player_simple example sketch, when i use the hardware mode (dont specify spi pins) it works fine, but when i use the software mode (using the same pins but this time specifying them in the opject constructor) it says it cant find the player
OK, I think I've nominally recreated this. Not using the exact same hardware, but at least ESP32. Using a Feather ESP32 V2 with a Music Maker FeatherWing (which uses same VS1053) and running the feather_player example sketch.
This works (HW SPI):
Adafruit_VS1053_FilePlayer musicPlayer =
Adafruit_VS1053_FilePlayer(VS1053_RESET, VS1053_CS, VS1053_DCS, VS1053_DREQ, CARDCS);
This does not work (SW SPI):
Adafruit_VS1053_FilePlayer musicPlayer =
Adafruit_VS1053_FilePlayer(MOSI, MISO, SCK, VS1053_RESET, VS1053_CS, VS1053_DCS, VS1053_DREQ, CARDCS);
results in player not found:
Couldn't find VS1053, do you have the right pins defined?
For now, can use the HW SPI pins that work, or the work around you've come up with for modifying the BSP files.
Keep an eye on this issue thread: https://github.com/adafruit/Adafruit_VS1053_Library/issues/81 It'll be worth simply updating this library to use BusIO first and see if that fixes this issue.
great thanks
@TomW1605 I've done some work on this but have some follow up questions.
What SD storage are you using and how is it being attached? This library uses the SD library which is hardware SPI only - on whatever default pins have been defined in a board's BSP config. So using the same pins for software can cause a potential conflict. That's actually why my test above with the Feather setup did not work.
What is driving the need for software SPI / alternate SPI pins?
thanks for looking into this
What SD storage are you using and how is it being attached? This library uses the SD library which is hardware SPI only - on whatever default pins have been defined in a board's BSP config. So using the same pins for software can cause a potential conflict. That's actually why my test above with the Feather setup did not work.
i am using the SD card slot on the adafruit board. i had a look at the SD card library and it can be passed a pre made SPI object that would allow the pins it uses to be changed. however based ont he examples this would be outside the perview of this library as it is done in the main ino code.
What is driving the need for software SPI / alternate SPI pins?
my use case is a bit odd, i am working with a chip that does not have a pre defined breakout board in the esp32 board library. i have tried making one but without much luck. this chip (ESP32-PICO-V3) works the same as the standard dev board with 1 exception, the normal SPI pins are not avalable (used for the internal flash and not connected outside the chip) so i need to use a custom set of pins.
i had a look at the SD card library and it can be passed a pre made SPI object that would allow the pins it uses to be changed
Can you link to where you are seeing this. That would help, but wonder how universal that is? vs. limited to a specific BSP.
sorry for the delay, unfortunatly it looks like it is specific to the esp32 SD library
https://github.com/espressif/arduino-esp32/blob/a5f03a86512b270be1080d7e7cb82e4fd71c9a1a/libraries/SD/src/SD.h#L31
@TomW1605 Unfortunately, for now, software SPI will likely remain unsupported. The current way in which this library is using the SD library makes refactoring it difficult. Took a look at what it would take for that as part of #82, and it essentially requires a rewrite. So the SD aspects remain hardware SPI based.
Your approach of changing the pin definitions in the BSP is probably your best solution. In general, using hardware SPI is preferred. So hacking your local copy of the BSP to mod it for your actual board is an OK hack.
SD lib usage is kind of an issue anyway because it colides with SDFat. Maybe a little rewrite would be able to tackle both issues at once 🤔
Moving to SDFat was what was being investigated. But it starts pulling a thread. :(
ok thats fare. shame its not practical with the way the SD library works. but in that case, i think it is best to remove the options constructor from the library completly. if the full SPI pin constructor dosnt and wont work then it is just confusing to have it there at all.
Fully agree with @TomW1605 It took me a couple of days to figure out that this was the issue for my ESP32. At least a comment in the sketch would be helpful