[RPI] Refactor SPI and GPIO handling for XVF3510 initialization #213
Conversation
|
Very nice! I once started to implement the adafruit stuff for the Mark2 led, however never finished it. Good to see, you are picking those packages up. About your changes to the flash script. That scrip originally came from the XMOS guys which I once downloaded when they where openly accessible; Perhaps, they are interested in it? Although they where also not very keen on my tip for the drivers to use the dtoverlay way; Anyhow, for your convience I uploaded the full XMOS information pack with schematics, binaries, firmwares, tools and scripts here for you to have a look; It might help you understand certain things. |
|
@j1nx Does the J201-Rev10 board work for you on the latest build? On the image from Dec.12, everything works fine.
|
BohdanBuinich
force-pushed
the
xvf3510-rpi5-compatibility
branch
from
44c4f55 to
f6a2b4a
Compare
I am still in the middle of testing everything with the new 6.6.14 kernel. I ran into some podman/quadlet issues that prevented me to run the test I wanted to run, however yesterday on a rpi4-2gb with the latest build, the Did not gave me any errors. It did found all the right i2c addresses and all configuration commands ran succesfully. Above dis show the xvf-3510 card with all the right settings, however having a quick look at ncpamixer, no sound was captured on the microphone and no sound output as well. That is obviously as the xvf3510 flash script should fail because the lack of RPi.GPIO support. Guess is silently fails. Will do some more testing soon when the podman/quadlet is fixed and the device keeps running without OOMD killing it. EDIT: BTW, without loading the xvf3510 firmware, you will only see the 2f address which is the TAS5806. That is why we only use that specific address to "call it" a Mark2. Perhaps we should extend the script to check for the right XMOS addresses after loading the xvf3510 firmware and if not there, remove the dtoverlay again and report back that we do not have a mark2 but something else at that address. Anyhow, will scan the addresses on my rpi4 this evening to check if I have the same problem as you. |
|
OK, the new image was able to fully initialise again at first boot. Below some testing; |
|
|
|
|
However no sound input nor sound output signal (silence) Looks like the upload firmware indeed fails silently. Without the firmware being uploaded to the sj-201 sound will not work as the Mycroft guys did not add a SPI storage chip to hold it across boots/reboots. |
I guess/assume the above actually does not do what is should be doing. Will rebuild an image with this PR to test the new flash script. |
OK, this means that the device will only appear in the i2c list after FW flash, right? Ok, I need to figure out what I missed in my script. |
Indeed, the firmware is what should be behing those adresses. Just gave a command over ovos-cli-client and it appears I was wrong. Sound output does work without any issues, so it is only the microphone / xvf3510 chip/ input. So guess, if we can get the firmware uploading fixed it should work.
Am I correct that the firmware upload with this PR also fails for you? If so, I will leave it to you for a bit. Otherwise we have to dig into those docs I uploaded once again. |
the uploading is working, but the device does not appear in the i2c list, the problem is that we do not have any information about the update status. I'll try to experiment some more. |
|
I will do the same. there are some low level tools for the xmos chip in that zip file however never used them on the sj-201 or at all for that matter. I might as well give it a try. |
|
As pointer with something I have in the back of my mind; i2c transfer speed is involved. https://github.com/xmos/vocalfusion-rpi-setup/blob/master/setup.sh#L119 raspberrypi/linux#5653 |
|
I also see there are some changes in the dtoverlays for 6.6 https://github.com/OpenVoiceOS/VocalFusionDriver/blob/main/xvf3510.dts#L13 Should not be changed according to; |
BohdanBuinich
force-pushed
the
xvf3510-rpi5-compatibility
branch
3 times, most recently
from
c0442cc to
8f31a41
Compare
|
Confirmed working on the RPI4 |
|
Ah crap! @BohdanBuinich I screwed up by merging my gpio branch for the libgpiod changes as they where confimed working for the rpi4 however completely forgot that i merged your branch with this PR into it. So now I kind of merged this PR without really merging this PR ????? while it is still in draft. |
BohdanBuinich
force-pushed
the
xvf3510-rpi5-compatibility
branch
from
8f31a41 to
59d3088
Compare
no problem, you will be a tester now))) |
This commit significantly overhauls the script for setting the XVF3510 board to boot from SPI slave mode and for loading a binary file. The refactor not only aims at improving code readability, maintainability, and robustness but also addresses compatibility issues with the latest Raspberry Pi models, specifically the Raspberry Pi 5, which does not support the RPi.GPIO library.
Changes made:
smbustosmbus2for I2C communication, offering a more modern and robust interface.RPi.GPIOandspidevwithdigitalioandbusiofrom theadafruit_blinkalibrary, enhancing cross-platform compatibility and providing a more Pythonic API for GPIO and SPI operations.setup_direct_gpio), streamlining the main logic flow and separating concerns.setup_spi) and data transmission logic (send_data_over_spiandhandle_block_transfer), enhancing code organization and maintainability.Benefits:
smbus2andadafruit_blinkalibraries modernizes the script and may improve compatibility with a wider range of devices and future Python versions.