hm2 BSPI documentation, examples?

You can use larger than 32 bit SPI frames by setting
the Dont_Clear_Frame bit in a descriptor:

Bit 30        = Dont_Clear_Frame. If set, leave frame asserted at EOT.
                This is for SPI devices that send or recv more than 32 bits
                of data. for example a 48 bit SPI access can be built from
                access via a descriptor setup for 32 bits and
                Dont_Clear_Frame set, followed  by access via a descriptor
                setup for 16 bit access with Dont_Clear_Frame cleared.
 

andypugh wrote:

I think that the 32 bit sizes come from the width of the FPGA registers as described in the low-level docs (ie, the regmap)
github.com/LinuxCNC/hostmot2-firmware/bl...ster/src/regmap#L925

Personally I would have used 2 x 24-bit packets or 4 x 12-bt packets depending on what the ADC chip works with. Just because the FPGA code can handle "up to 32 bits" doesn't mean that there is any real benefit in using all the bits.
 

I'm not using a ADC IC, I'm using an Attiny Microcontroller. I'm using one with 4 12bit ADC channels so how the SPI data is sent across the SPI pipe isn't set in stone. For that I was planning on using a 48bit packet as it seems possible on the SPI side.

Main reason for that is there is another Attiny Microcontroller on the board, this one configures 6 TMC stepper drivers over UART.  Both Microcontrollers are on the same SPI interface. The MCU for the steppers will have HAL pins for setting configuration registers.

So it was my idea that since the SPI side of it seemed to support upto 64bits (was looking at an error thrown in the bspi code), I figured it would be better to shuffle all the data from the analog MCU across in a single transaction rather than split it across 2 transactions because the other MCU will have a transaction in between. So basically if I can get a 48bit transaction across in 1 shot the ADCs should have a full update every other transaction vs using 2 24bit transactions per 2 of the ADCs which would take 4 transactions to update a set with the other MCU in between.

Since you pointed out the regmap (and PCW verified) looks like it can be done....
Whether it actually matters if running the SPI bitrate @ say 4mhz,  I'm not really sure. I didn't do the math vs a 1khz (or better) servo thread.

I was mostly curious about what we're doing with the bspi functions as they seem to have to be called twice to read the frame longer than 32bits.
 

PCW wrote:

You can use larger than 32 bit SPI frames by setting
the Dont_Clear_Frame bit in a descriptor:

Bit 30        = Dont_Clear_Frame. If set, leave frame asserted at EOT.
                This is for SPI devices that send or recv more than 32 bits
                of data. for example a 48 bit SPI access can be built from
                access via a descriptor setup for 32 bits and
                Dont_Clear_Frame set, followed  by access via a descriptor
                setup for 16 bit access with Dont_Clear_Frame cleared.
 

 
So does that mean it would be setup like this:
r = hm2_bspi_setup_chan(name, 1, 1, 32, 4, 0, 1, 0, 1, 0, 0);
r = hm2_bspi_setup_chan(name, 1, 1, 16, 4, 0, 1, 0, 0, 0, 0);

As opposed to what I have now
r = hm2_bspi_setup_chan(name, 1, 1, 48, 4, 0, 1, 0, 1, 0, 0);

 

Well a 48 bit frame is guaranteed to not work (the per descriptor limit is 32 bits)
with 32 +16, you will get separate 32 bit and 16 bit data chunks that the upper
levels will need to deal with

andypugh wrote:

Seems plausible.
Does it work?
 

Still waiting for a new 7i92 to arrive, then I have to modify it.