@TGargasz sounds like you should take a step back and read about SPI a bit, especially in context of STM32 MCUs. Yes, there’s a lot of config options, but only a few of them would likely require changes to match your configuration (setup as master/slave, use uni-/bi-directional communicaton, use hardware CS or not, use correct clock/prescaler settings, etc). This should be coordinated with the ESP chip settings on other end.
Next, as far as I understand you’re doing this with a bare Daisy Seed. Effectively this means you’re creating custom board. So what you should do is fork libDaisy, add a file for configuring it including SPI with correct settings. You should look at daisy_patch.* as example, since it contains configuration for SPI display. Except that it’s not terribly useful, because SPI settings in libDaisy are hardcoded for current peripherals.
You could add an extra method in per/spi.cpp to pass HAL handle with SPI config, so that you’ll be able to configure it correctly.
And you’d need a “driver” that would handle all logic for communication with your device. In case of OLED display, this is hid/oled_display.*, but in your case it would be less complicated (probably it would do parsing/serialization for data and store IO in buffers used for DMA)
So your best bet is to understand how SPI code works and try to replicate it. This is far from trivial and goes beyond how libDaisy is intended to be used without modifying library code. If that’s too challenging, maybe you could use I2C or UART instead of SPI. At least the configuration part would be simpler.