SPI and a synchronized Control/Data line for a display controller

[wallwhit]

I'm trying to drive a display controller and have found it trickier than I anticipated, and I hope you can kindly help. 

My microcontroller is the STM32U545. My display controller is the UltraChip UC1628c_A, as part of a custom 160x160 monochrome LCD. Our display's only data interface is the S8 4-wire interface described on page 32 of that link. It's half-duplex SPI with an additional pin called Control/Data (CD), or sometimes Command/Data. Each byte of the message that we send is either Control or Data. We tell the controller which by driving the CD pin low for Control or high for Data during that byte (the controller reads that pin in the middle of the final bit). 

Each message starts with one or more Command bytes, and most messages are followed by one or more Data bytes (up to 160 bytes in my product). I expect that the display controller requires these bytes be sent as one continuous SPI message, without stopping the clock or changing the chip-select (slave-select) line. And that is what I'm finding surprisingly difficult to do without resorting to blocking code, which would degrade the performance of other features I'm going to run on this MCU.

Earlier, I tried to achieve this by using the STM32U5’s linked-list DMA, just because its 1-step mode can generate an interrupt after every linked list item (LLI). I broke up my message so that each LLI was entirely either Control or Data. Then, in the interrupt, I would set the C/D pin to suit the next LLI before re-enabling the transmission. But being new to the STM32, I’m struggling to understand and control these rich but complex peripherals correctly, and I haven’t gotten my code to work after the first LLI. More importantly, the apparently necessary steps in the interrupt are more numerous than I expected, which makes me think that the interrupt routine won’t keep up with the SPI transmissions. Slowing the SPI baud rate could mitigate that, but it wouldn't be a good tradeoff to have to make.

My new idea is to treat the C/D pin as another data stream. Why not just prepare a buffer of Command/Data bytes to match the display-data buffer and send the two buffers in parallel? The tricky part is again synchronization, if for instance I put the C/D data on a UART. But it appears that the STM32U5’s Octo-SPI feature (intended for parallel SPI interfaces to high-speed memory chips) could do this job. I would set it for dual-SPI: two synchronized SPI MOSI lines. Octo-SPI's limitation of half-duplex is perfectly fine. 

This seems good, though preparation of the data buffer would be required. It seems I can’t give the Octo-SPI peripheral separate buffers for each of its outputs; for my dual-SPI configuration, it will process one transmit buffer, sending all the even-numbered bits out one pin and the odd-numbered bits out the other. So I would have to interleave the buffer’s bits for C/D and display data. That seems worth it for the benefit of avoiding interrupts and race conditions… but I also thought my linked-list approach was going to be good at first, so I’d appreciate your advice.

Thanks!