meexmachina
commented
1 year ago @alphafox02 I'm currently trying to eliminate the SUDO part altogether. using as the GPIO control provider through the "non-sudo" /dev/gpiomem and SPIDEV as the spi device (dtoverlay=spi1-3cs). it is a surgical operation to the code in /software/libcariboulite/src/io_utils/.
Originally I didn't use the spidev because its hardware CS operation was very very slow. which means - for a given spi transfer that should take ~5 usec, the CS wend low ~30 usec before and went up after another 30 usec following the transfer finish. At a time it seemed unreasonable to waste ~65 usec for a 5 usec transfer. To cope with it I used pigpio that directly controls the /dev/mem device but then the big problem of "sudo"ing started. Digging into the sudo part and trying to eliminate it through "udev" rules were unsuccessful.
It should eliminate the annoying "sudo". I modified pigpio it a little but couldn't cope with the 10k lines of code in that API and it became too complicated.
The straw that broke the camel's bag was an issue with the "lock file" (flock command) that caused the software to crash (/var/run/pigpio.pid locking).
For the community - please contact me if you want to participate more intimately together with me on the continuation of the software and firmware. There still are issues with the smi-stream-dev for instance until it is submitted to the Linux mainline code. One issue is the usage of "one-shot" dma requests rather than "cyclic" requests. If you have the expertise for digging into that or other part please tell me.
David
alphafox02
I realize this isn't very helpful, but I happen to have just been testing out the bee3ddd commit after fixing the two instances of cariboulite_get_native_mtu etc. This commit was usable on DragonOS (22.04) Pi64 on my Pi4. Meaning, I could run sudo SigDigger or sudo CubicSDR and receive local FM with only minor issues.
The latest push, compiled and ran ends in the inability to use the hat with SigDigger as there's timeouts and issues w/ SMI and with CubicSDR it'll run but there's nothing I can do to the gain or any other setting that'll change the fft/waterfall display.
I do a git checkout of bee3ddd and rebuild again and without even rebooting the Pi4 SigDigger and CubicSDR are back working. I'm just curious, how are you testing everything on your end before pushing changes? Is there a specific version of Pi OS you're using? What applications do you test with the hat? How can I better submit a ticket when I observe behavior like what I'm seeing now?