I2C and SPI on SAMD10D14A

[anvoice]

I'm trying to figure out the SPI and I2C interfaces on the SAMD10 chip, but my limited (Atmel 328P) experience is no help in determining some of the signals. From my understanding, SERCOM 0 and 1 are the I2C and SPI pins on the device, but I can't figure out which signal is clock, which is data for pads 0 and 1 for I2C, and similarly for the SDI, SDO, CLK and chip select for the SPI. Could anyone help with this, or point me to the place in the datasheet I need to read to figure that out?

Depending on whether those coincide with the I2C, I was hoping to be able to talk to two slave devices, one using I2C and one using SPI, while sharing the clock and data pins and switching modes when needed. Specifically, I only need to configure one of the devices using SPI at startup, and then need to switch to I2C to continuously talk to the second device (an encoder).

Finally, my uC will talk to an outside master controller via I2C: is it reasonable to use the same I2C pins as the ones I'm using to talk to the encoder to do that, or do I need to use the other SERCOM pins?

[ataradov]

I'm trying to figure out the SPI and I2C interfaces on the SAMD10 chip, but my limited (Atmel 328P) experience is no help in determining some of the signals. From my understanding, SERCOM 0 and 1 are the I2C and SPI pins on the device, but I can't figure out which signal is clock, which is data for pads 0 and 1 for I2C, and similarly for the SDI, SDO, CLK and chip select for the SPI. Could anyone help with this, or point me to the place in the datasheet I need to read to figure that out?

SPI pins are configurable to a certain extent. Search for DIPO and DOPO in the datasheet and you will see additional mapping of pads to corresponding pins. I2C pins are fixed to PAD0 and PAD1.

You can find bare-metal examples of SPI and I2C masters here https://github.com/ataradov/dgw/tree/master/embedded

Depending on whether those coincide with the I2C, I was hoping to be able to talk to two slave devices, one using I2C and one using SPI, while sharing the clock and data pins and switching modes when needed. Specifically, I only need to configure one of the devices using SPI at startup, and then need to switch to I2C to continuously talk to the second device (an encoder).

There are too many possible permutations to tell if it is going to work or not. You will need a pen and a piece of paper for that

Finally, my uC will talk to an outside master controller via I2C: is it reasonable to use the same I2C pins as the ones I'm using to talk to the encoder to do that, or do I need to use the other SERCOM pins?

Yes, sure. As long as you keep speed and length of the wires in check, you should be fine.

[anvoice]

SPI pins are configurable to a certain extent. Search for DIPO and DOPO in the datasheet and you will see additional mapping of pads to corresponding pins. I2C pins are fixed to PAD0 and PAD1.

You can find bare-metal examples of SPI and I2C masters here https://github.com/ataradov/dgw/tree/master/embedded

Thanks, much appreciated! The examples are extremely helpful.

There are too many possible permutations to tell if it is going to work or not. You will need a pen and a piece of paper for that

Shouldn't it be as simple as using PAD0 for SDA and PAD1 for SCL in I2C, then turning around and using the PAD0 for MOSI, PAD1 for SCL, and pads 2-3 for MISO and chip enable in SPI? Assuming the SPI are configurable to that extent of course.

Yes, sure. As long as you keep speed and length of the wires in check, you should be fine.

My main source of confusion is what happens when the uC is, say, talking to the encoder (it has constantly do that to maintain motor position) when the external controller decides to send a command of its own (e.g. move to a different position). How would the chip detect that event? Interrupt?
My encoder actually has a PWM output for position as well as I2C interface: I'm now wondering whether it may be wise to use that instead, using up an extra pin and measuring the duty cycle of the PWM to see where the rotor is, but simplifying the overall I2C communication procedure.

[ataradov]

Shouldn't it be as simple as using PAD0 for SDA and PAD1 for SCL in I2C, then turning around and using the PAD0 for MOSI, PAD1 for SCL, and pads 2-3 for MISO and chip enable in SPI? Assuming the SPI are configurable to that extent of course.

Well, I wrote this before I remembered that I2C is not all that configurable. Yes, this configuration is possible with DOPO=0, DIPO=2. And SS can be any pin at all, just use it as a GPIO. Don't use SERCOM's SS, it is a pain and not worth it.

My main source of confusion is what happens when the uC is, say, talking to the encoder (it has constantly do that to maintain motor position) when the external controller decides to send a command of its own (e.g. move to a different position). How would the chip detect that event? Interrupt?

In both I2C and SPI mater always initiates the transaction, so device can't accidentally start anything. The rest depends on the type of your devices and their capabilities.

My encoder actually has a PWM output for position as well as I2C interface: I'm now wondering whether it may be wise to use that instead, using up an extra pin and measuring the duty cycle of the PWM to see where the rotor is, but simplifying the overall I2C communication procedure.

I2C will probably be more accurate.

[anvoice]

In both I2C and SPI mater always initiates the transaction, so device can't accidentally start anything. The rest depends on the type of your devices and their capabilities.

Right, but the uC would be both slave and master depending on whether it's being talked to by the external controller (uC is slave) or talking to the encoder (uC is master). So don't I need a way to switch the uC from master mode during normal operation to slave mode when the external controller contacts it?

[ataradov]

Right, but the uC would be both slave and master depending on whether it's being talked to by the external controller (uC is slave) or talking to the encoder (uC is master).

I missed that part. No, you can't do this with one SERCOM. You need to be a master or a slave, unless you have some clearly defined way to share the time between the two. But it will be a huge pain to debug, I would not even try to attempt it.

[anvoice]

I missed that part. No, you can't do this with one SERCOM. You need to be a master or a slave, unless you have some clearly defined way to share the time between the two. But it will be a huge pain to debug, I would not even try to attempt it.

Ok, this might mean I'll have to use the SAMD21 instead, as I'm running out of pins for all the connections. But assuming I'm using 2 SERCOMs, it should be no problem to use one for I2C master with the encoder and the other as I2C slave with external controller at the same time, correct?

[ataradov]

Ok, this might mean I'll have to use the SAMD21 instead, as I'm running out of pins for all the connections.

DigiKey is selling some real cheap D21s at the moment, but it looks like they mostly have QFN packages left, all cheap TQFPs are gone.

But assuming I'm using 2 SERCOMs, it should be no problem to use one for I2C master with the encoder and the other as I2C slave with external controller at the same time, correct?

Correct. SERCOMs are absolutely independent.

[anvoice]

DigiKey is selling some real cheap D21s at the moment, but it looks like they mostly have QFN packages left, all cheap TQFPs are gone.

My motor gate driver is actually QFN, so I'll have to figure out a way to solder QFN packages onto my board anyway... For the prototype at least, if I ever do production runs I'd do reflow of course. Now on to figuring out how many total pins I'll need. 
Thanks for the clear explanations!
Edit: ok, so I'd have to somehow solder the ground plane to, well, ground on the QFN version. So it looks like I need to either get the TQFP or use some amazingly creative trick to get that ground plane connected.

[anvoice]

Does anyone know if there is any functional difference between the SAMD21 with a ground plane thermal pad and the one without? Both of the versions I'm looking at seem to operate at up to 125C. The one without the thermal pads will certainly be easier to solder on, so I was thinking of going with that. Any issues to look out for though?

[ataradov]

No difference whatsoever. Those things can't dissipate enough heat to worry about that kind of stuff. I think the pad is mostly for mechanical purposes.

[anvoice]

Sounds good, I can get the QFN no-pad version then, should be possible to solder that on with a fine tip.

[ataradov]

Sounds good, I can get the QFN no-pad version then, should be possible to solder that on with a fine tip.

But QFN chips always have a pad. And it loos like TQFP never has a pad in case of D21.

Although there is a note in the datasheet "Note:  The exposed die attach pad is not connected electrically inside the device.". So it should be fine to not solder it.

[anvoice]

But QFN chips always have a pad. And it loos like TQFP never has a pad in case of D21.

https://www.mouser.com/ProductDetail/556-ATSAMD21E16L-MF
That one has no pad in the picture. Could be wrong of course, there are errors on that website occasionally, but that it definitely looks like a genuine picture of a QFN package.
Edit: Ok, looked at that photo more closely and it looks like they edited out the pad for some reason. So you're right, they always have a pad.

I realized that it was my gate driver that has the thermal pad that must be connected to ground, so I'll have to figure out how to solder that on anyway.

Although there is a note in the datasheet "Note:  The exposed die attach pad is not connected electrically inside the device.". So it should be fine to not solder it.

Where did you find that note? I don't seem to see it in the Packaging Information section of the datasheet no matter how hard I look.

[ataradov]

That one has no pad in the picture. Could be wrong of course, there are errors on that website occasionally, but that it definitely looks like a genuine picture of a QFN package.
Edit: Ok, looked at that photo more closely and it looks like they edited out the pad for some reason. So you're right, they always have a pad.

They often just match package name to a corresponding picture in the database without actually checking all the features of a specific device.

Where did you find that note? I don't seem to see it in the Packaging Information section of the datasheet no matter how hard I look.

It is in the Microchip version of the D21 datasheet, for example in the section "38.2.2 64 pin QFN".