Support for slow (bitbanged) clocks in SPI library.

Community Suggestions for the Arduino Project
1

The new SPI api beginTransaction(SPISettings(clock,...)) is a great idea: you specify the clock speed and the library calculates the clock divider for you. This makes sketches more portable: they wil run at the same clock speed (approximately) on avr and sam, without modification or ifdefs (as opposed to the now deprecated setClockDivider() api).

But this does not work if you need a clock speed that is too slow for the sam (the clock divider can be 255 max).

Funcionally, I think it would make perfectly sense to let the SPI lib take care of this by bitbanging slow clocks. I have seen such (pure c) libs, and I found it elegant.

Looking at the SPI lib code, I think this is not an easy feature to introduce: the code is highly optimized for high speed tranfers, with lots of code that is inlined, or makes use of other compiler support to optimize things...

So I am not sure if it is worth the trouble to add a feature like this.

An alternative is to add a second Bitbanged SPI class to the SPI lib. Besides the posiibility for slower speeds, this would also give more freedom for selecting which pins dedicate to SPI.

But this is not simple either: for the same speed optimization reasons, the SPI lib is organized such that it is impossible to dynamically create an SPI object (say a regular one or a bit banged one) and let this object do the transfers (so the behavior is choosen at run time). Instead the SPI.transfer() method gets inlined (decide at compile time).

I am currenly working on ArduinoISP improvements. ArduinoISP: reliability and portability improvements. · Issue #3321 · arduino/Arduino · GitHub and I would need a slow clock on the due to be able to program slow AVR's.

I think (at least for now) I will go for a minimalistic ad hoc SPI bitbang class inside ArduinoISP, but I would like to know the opinion of the SPI lib developers. There might be implementation possibilties I did not think about. (if the compiler could know if the needed clock was it could inline the correct implementation. Problem is that the clock parameter is in a separate function (beginTransaction())

2

An alternative is to add a second Bitbanged SPI class to the SPI lib. Besides the posiibility for slower speeds, this would also give more freedom for selecting which pins dedicate to SPI.

Why not add the slow stuff to shiftOut() instead?

3

To be honest, I did not know shiftOut() (nor shiftIn()), so I learned something, thanks.

I just had a look, it is not what I am looking for: for SPI you need to shift out and at the same time shift in. The ad hoc bitbang class I talked about is actually a combination of shiftIn and shiftOut and is therefore also only a few lines of code.

So I know the problem is trivial, but I still find that a sketch should simply specify the clock and the SPI lib should deal with the rest.