bspi problems

ive been working with the bspi interface to integrate more sensors to my machines and i think ive found a few issues, im tracking my work in github.com/sleepybishop/linuxcnc/tree/bspi_work.

• the address of the fifo counter register is wrong in bspi.c, it should be "md->base_address + 2 * md->register_stride + i * md->instance_stride"
• the value in val wanst actually sent in bspi_write_chan()
• in mesa_7i65.comp reduce module 16 -> 4 since hostmot2 supports a max of 4 bspi modules (each with 16 channels), i believe this was just a mixup between channel/module nomenclature

i also added a few things like

• fetching the values of the fifo counter registers via tram read
• adding a function to write to the fifo counter to clear it
• added support for the samplelate flag in the channel descriptor

however im still unclear on a few things and im still having some problems integrating some devices when using multiple channels.

questions:

1. is the bspi fifo counter for the entire module? (eg. address 0x5700 has counts for all 16 channels in bspi 0, and address space 0x5704<-->0x573c doest have meaningful data?


2. if (1) is true and if the bspi fifo counter says there are 5 values in the fifo, where should a read from the fifo begin and how do i know which values belong to which channel?

i thought this was handled automatically and all i had to do was assign a single 32bit word via hm2_tram_add_bspi_frame() for each channel to get updated values.


for a simple test between 3xmax31855 channels but only one chip connected, im seeing incoming values jump between the channel pins, for example correct values will start on the pins for channel 0, but over time they might jump to
the other channel pins and back, when using only one channel things work fine.

i thought this might be due to overflow on the bspi fifo so its why i added the code to clear the counter, it didnt seem to have any effect.
i thought i might have to do with the sample late flag so i added that as well also to no effect
i attached a logic analyzer on the pins of the active chip when it had shifted to another channel and it was sending data correctly when its cs pin was triggered, so i am at a bit of loss

im using the following code
github.com/sleepybishop/linuxcnc/blob/fi...s/max31855_bspi.comp

my end goal is to integrate 6xtmc2660 stepper drivers and 6xams5047p encoders and other misc sensors for vision tasks for a few robot arms but it all hinges on being able to talk to many devices via the bspi interface

There is a single 16 deep 32 bit wide FIFO so a maximum of 16 32 bit or narrower transactions
are allowed without waiting for TX FIFO to empty or emptying the RX FIFO


If the RX FIFO says five items, it means 5 SPI transactions (with RX data capture enabled)
have taken place

So if you did transactions to channels 6 3 1 5 8, the first FIFO read would be channel
6, then 3 then 1 etc all this assuming 32 bit or smaller transactions.

You should never have to clear the RX or TX FIFO except at driver startup
that is the TX FIFO will got to 0 when all SPI TX data has been shifted out of the FIFO
(the TX may still be active in this case however)

And you should read all RX data out of the RX FIFO (needing to clear the FIFO is an indication that something has lost count)

hi andy, im still trying to sort all this out in my dev environment. however maybe ill split my work into actual fixes and work still in progress and submit a pr with just the fixes for now.

im still trying to better understand the bspi interface, seems like hm2_tram_add_bspi_frame() always uses hm2_register_tram_read_region() to read from the start of the fifo, (addr[0]), not sure if thats a bug but im assuming since RX data reads dont care about the read address it just pops data from the RX fifo into each frame address.

when i integrated the counter to help with debugging i noticed that if i create X transactions via hm2_tram_add_bspi_frame(), the counter would differ from X in hm2_bspi_process_tram_read()

in which case if its less than X im not sure each frame got a valid read, if its more im not sure that each frame is going to get the proper data.

also if its more than X for a few cyles the counter will continue to grow to a maximum of 16, which is where i got the idea that maybe i should be clearing the fifo, but peter said the better alternative would be to read all data out of the rx fifo instead, im not sure how to do that in the current framework since each bspi_frame does a tram read for only one 32bit value.

ive considered refactoring the bspi module to do a full tram read for all 16 values and depending on the counter value assigning the data values to the proper sensor pin, but im not sure what pitfalls lie in that approach.

im not 100% sure this is the root cause of my problem with multiple sensors getting incorrect data, buts its my leading theory.

Actually this should be pretty simple, if you do 5 independent SPI read transactions (or writes with echo enabled)
you should expect (and wait for) 5 items in the RX FIFO, you should then read all 5 items out of the RX FIFO
and the FIFO count should now be (and stay) 0

The data in the RX FIFO will match the transactions requested in the TX FIFO

thanks peter, that makes perfect sense, though im not sure how to implement in the current driver as each bspi frame registers a single 32 bit tram read region and the tram reads are executed without regard to the counter value.

i expect ill have to refactor the driver and maybe ditch tram maps for direct reads and writes

hi andy, ill take a look at absencoder for guidance, thanks.

i noticed that the pktuart driver eschews tram maps and uses low level io exclusively

what are the performance implications of that? would that be acceptable in the bspi driver?