Generic clocked serial protocol on STM32?

[Bassman59]

On the one hand you say there is no official spec on the other you differentiate between actual and SPI like chips. Which one is it?

You should have noticed that I put "SPI" in quotation marks.

There seems to be a de facto (look that up) standard for SPI that has four "modes," and the differentiation between those "modes" is in the state at which the clock idles and whether the first data bit is driven out on MOSI prior to the first falling clock edge or whether it goes out on that first falling clock edge. Silicon Labs, among others, seems to like this definition, and it describes how their parts actually work.

I have never seen any documentation about SPI other than the blurbs people put together online and what the micro controller datasheets tell me. If the micro can do it and it's beneficial great but another may not. Some micros may have bigger shift registers other are limited to the common and therefore deemed to be official 8 or 9 bits. The SAMC has address recognition on it's "SPI" interface, can they still call it SPI with this non standard feature - oh wait there is no standard and why is that feature not available for the actual usart? Why does the lin mode of the USART have auto baud syncing, why can't I use that on RS485/UART mode? oh wait nothing really stops me sticking an RS485 transciver on a lin interface providing i write my code to handle the direction which is why you do on RS485 anyway when the MCU does not "officially" support RS485 by which they mean saving you one line of code to assert the receive or transmit mode in the application code.

And that's why I put "SPI" in quotes -- anyone can call something "SPI."

I think most engineers understand that "SPI" is nothing more than a shift register. All of the other stuff, like address recognition, is built on top of the shift register.

Autobaud is not really interesting in a synchronous protocol (like "SPI"). There is no reason why a receiving device needs to figure out the baud rate -- the clock is there!

Anyways, I think you doth protest too much.

Every chip has various options covering a minimum that everyone else does with some more bells and whistles. The data input on the master is often an option to be enabled because often like in this case or little LCD's there is no data to come back so you save a pin rather than be forced to not use it for SPI but not as GPIO either.

So what? So you figure out what features the USART (or as NXP calls them, "FLEXCOMM" which makes sense to me) has or doesn't have and you use them or you don't.

What we colloquially call "SPI" is just one variant on the synchronous "serial" port implemented with a couple of shift registers and some logic.

I mean, what's a SERDES? Is there a standard?

Now if you REALLY want to till at windmills, complain when someone says, "UART transmit" or "OSERDES." Ask yourself why those are stupid.