RaspberryPi4 using an ADC, "bitbanged SPI" component?

I was working on something a ways back I kind of shelved for a while that I'm currently rethinking. I had initially started this as a Machinekit project on a daughterboard I designed for a DE10 nano running MKSOCFPGA. The DE10 Nano has an onboard 8-channel 12-bit ADC. What MKSOCFPGA did was create a hm2 firmware module that exposed the adc as a 32bit integer with 12bits shifted for each channel. It really wan't a very useful thing in hal without some external means of shifting the data and scaling it into a floating point number to represent a voltage. I was able to do this using normal hal offset and conversion components but it was a bit messy to instantiate 8 instances of 4 or 5 different components.
The DE10's ADC (LTC2308)

Me and a programmer friend came up with this component and pushed it into MK as a simpler means:
vari-bit-adc

What I'm trying to do now is something similar with a rpi4 in Linuxcnc. Debating on using a mesa 7i90, but I think I have to figure out this same thing regardless unless I want to use a Mesa analog input card too which is a bit much for this, it's a rather simple machine that I think I can get away with just using hal_pi_gpio.

I came across a post suggesting this component max31855 that "bit-bangs" the SPI bus of that chip for thermocouples. What I want to do is something similar. with an ADC, not particularly choosy about any one, I only need a couple of channels.

Curios if there is any reason this is a bad idea besides the fact that it'll probably need a hal component that does not exist. I certainly can't write it but maybe someone who knows what they're doing can get onboard, pretty sure by programmer friend is getting sick of me asking for obscure LinuxCNC stuff lol. I'm sure plenty of other people would find this useful.

andypugh wrote:

If you are using a Mesa card, then you can use a firmware with SPI channels included.

an example: github.com/LinuxCNC/linuxcnc/blob/master...ivers/mesa_7i65.comp

But why not use a built-in Pi SPI channel?

Well the thing I had this in mind for is pretty light, so no Mesa card. Looking to just use the rpi_gpio

As for the hard vs soft SPI thing, well I could probably use some guidance there. Is there a hard SPI driver exposed to hal currently? I know there is hm2_spi drivers but I'd think they are specific to interfacing Mesa cards. I also don't necessarily tie the thing to an rpi so a component that bitbangs some hal pins should work for any form of reasonably fast gpio pins. I see soft SPI used in Python projects so I'd think that a hal component implimenting soft SPI could be at least as fast.

I'm not really upto snuff on SPI in general or at least the way it's implemented in drivers and such. I understand it a little better for how it relates to other serial protocols. I guess the question is, is there a generic hard SPI interface that can be exposed to hal in the form of a driver or component as is? Depending on the answer to that the question is, would it be better to allow this separate driver/component to handle SPI itself and pushes data through hal pins? If that's the case, I already have the "vari-bit-adc" component.

The max31855 component stuffs the spi interface internally presumably because no good external means just exists in hal. If it's possible to separate hard/soft SPI interfaces directly in hal then it's alot easier to deal with data coming direcly off a couple hal pins from those components to suit the device it's connected to right?

Like the DE10-Nano I mentioned above, the way it's implimented there is a hm2 firmware module called nano_adc or something like that. then there is a hal driver for it. All of the hal pins represent a channel of the SPI ADC chip. What you see is 8 hal pins of u32 type with 12 bits shifted around for the ADC value. Is it possible to do something like that?