SPI data size reducuction to 1-bit

[JSext.1]

I have a rather strange request, but I am communicating to a Digital Potentiometer (AD5227) over SPI.  The chip has 64 available positions, but can only increment or decremement its position by 1 for each clock cycle.  To increment by 1, a 1 is placed on the MOSI, and to decrement a 0.  The issue is that to increment by 1 over SPI (8-bit) I have to send, 10101011, which is inefficient.  I hoped I could change this to 1-bit, but I am limited to a minimum option of 4-bits in STMCubeIDE.  Is it possible to change this to 1-bit?  I also then need to change it back to 8-bits for the other devices on the SPI.  I am unfortuantely limited by the number of pins available on the MCU otherwise I would use 3 more dedicated pins to communicate to this chip.  Thanks for your help   

[LCE]

The big question: is there anything else connected to that SPI?

If not, then do it as they say above: no SPI, just a function with "manual" GPIO toggling for clock and up / down.

[TDK]

> On a 'F4, tight consecutive writes can toggle a GPIO pin once every system cycle.

Did you test this? From my recollection of testing exactly this, the max speed was something like 20 MHz on a fast F4. I didn't try an F7, but I believe H7 was even slower.

Edit: Recollection was wrong, H7 was ~20MHz, F4 was 1 BSRR per clock (under heavy code optimization).

[waclawek.jan]

> Did you test this?

Yes. That was the very first thing I did on the STM32, some 11 years ago... Not in order to generate pulses, but as a vehicle to understand the bus system, its constraints, impact of waitstates etc.

One interesting corollary from that exercise was, that you can bit-bang a 1-cycle long pulse by two consecutive writes to GPIO, and then a 3-cycle long pulse by inserting some NOPs, but not a 2-cycle long pulse (the reason lies deep in the way how the AHB bus is arbitrated).

> under heavy code optimization

No point to do such test otherwise (asm, of course) ;‑)

And the 'H7 GPIO toggle speed has been discussed here ever since.

Nonetheless, I personally would probably try to solve this particular issue by generating clocks from a timer, possibly one with Repetition counter (or just chaining two timers to generate N pulses, if timer with RCR is not available). Although bit-bang is tempting, given the high accepted frequency of target chip; I may have given it a though.

JW