How does SPI work internally?

This is moved from the I2C thread, which is not the subject.

it does 32 bit internally.
Example:
10 bytes => write 3 times (4 bytes + 4 bytes + 2 bytes)

@Dat_Tran : Interesting…

Could you please detail how this is handled under the hood, please ?
What if I send 1 byte, 2 bytes or 3 bytes ?
Are they padded to Int32 size ?
How are you splitting the data sent ?
Are you really sending Int32 on the bus ? If yes, what would be the issue with allowing the API to send shorts ?

1 byte => 1 time 1 byte
2 byte => 1 time 2 byte
3 byte => 2 time (2 bytes + 1 bytes)
4 bytes => 1 time 4 bytes
5 bytes => 2 time (4 bytes + 1 bytes)
10 bytes => 3 time (4 + 4 + 2)

Are you really sending Int32 on the bus ?

Depend on the size as above.

1 Like

I have answered this multiple times. You do not trust me do you? :grin: Yes we do and you never have to worry about updating display speed because the speed is as fast as it can be. Can we put this to rest or you will come back in a week and ask one more time? :grin:

1 Like

let change place of words of title
internally does work how spi :rofl: :rofl: :rofl:

1 Like

Gus,

Speed is not the only concern, as you may remember. I was also talking about 16bit data coming from (or being sent to) a device.
For the clarity of my purpose below, I will only talk about “sending data” (and a short), but the reasoning is the same when receiving data and integers.

Many sensors or devices can accept (or even request, sometimes) data in 10/12/14/16 bit format. Padding needed for 10/12/14 bit, of course.

Sending a short or an int as a serie of consecutive bytes is not the same as really sending a short or an int. In the first case, I have to deal myself with endianness, while in the other case it’s the firmware that does it when it receives a short to send to a device.

But so far, you don’t talk about endianness so what are you assuming when I send { 0x10, 0x20 } ?

  • Am I sending two bytes ? (Perhaps a register and its value)
  • Am I sending a short because the underlying data is 10 or 12 bit long ? And in this case, am I sending 0x1020 (4128) or 0x2010 (8208) ?

The MCU has endianness registers for the SPI transfers (and frame format as well). And they are taken into account when you send something different than multiple/consecutive bytes.

Had you said you were only sending consecutive bytes, I would not have even replied because it would have meant that I had to deal myself with endianness and do not bother with data size.
But you said that you were sending bigger data at once, which is not the same.

So yes, I may come back later again on the subject, as it is not as simple as you seem to believe…
Or I may give up at some time as well.

And I will even have other questions regarding SPI, related to (real) clock frequencies. But since I’m currently testing our drivers on the dev board, it’s not time yet. You lucky :wink:

Let’s leave this at we only support bytes on SPI bus. Right now, there is no SPI device we can think of that can’t be used with TinyCLR OS. If you find such incompatible device, please bring it up so we can study the need further. After all, TinyCLR is made for you all. We are here just to make it happen.

Back to work on more serious features, like supporting external flash without compromising security… Coming this month. By the way, this one was not easy at all.

2 Likes