0
\$\begingroup\$

I want to replace the CAN with SPI to communicate with two microcontrollers within the same board.

The current solution is with CAN protocol:

  • uc1: at Init, it sends 1 message (msg1) to uc2. After that uc2 receives it and does some actions.

  • uc2: before shutdown, it sends 1 message (msg2) to uc1. After that uc1 receives it and does some actions.

My question:

Can I replace CAN with SPI to communicate with these two uCs? if yes, then should I implement both Slave and Master SPI drivers in both uCs?

\$\endgroup\$
1
  • 1
    \$\begingroup\$ What is the reason CAN is used for on-board communication in this case? That's an unusual case, which suggests that there are very high requirements regarding immunity or reliability. Is it part of some high integrity system, automotive/industrial etc? \$\endgroup\$
    – Lundin
    Commented Dec 9, 2020 at 12:15

2 Answers 2

Reset to default
1
\$\begingroup\$

I came to say a big "no" because I thought you want to replace long-distant CAN with SPI when I first read the title. But then ...

I want to replace the CAN with SPI to communicate with two microcontrollers within the same board.

Anyway...

CAN is designed as a noise-proof hi-speed communication for relatively high distances. So it's unusual and unnecessary to use CAN for the MCUs on the same board. And SPI is well suited for that purpose. Another good option is the UART.

should I implement both Slave and Master SPI drivers in both uCs?

Normally, when it comes to the communication between the two MCUs through SPI, there'll be no strictly master or slave implementation as master or slave tag can dynamically change for either node (i.e. the sender node can be master and thus the receiver node can be slave momentarily). Implementation is quite simple and easy even for a software SPI.

\$\endgroup\$
2
  • \$\begingroup\$ As mentionned in the main Post, both uCs can intiate the communication. So if I understand well, the best option is to implement a dynamic configuration (Master <->Slave) since the slave can not initiate the communication. \$\endgroup\$
    – Berlin
    Commented Dec 9, 2020 at 12:56
  • \$\begingroup\$ @Berlin yes, that is a solution: Both nodes stay in slave mode on idle. The sender makes itself a master before transmitting, then reverts itself to a slave again (as a listener) after transmitting. Another option could be using two extra pins: one as input and one as output. Connect one's input to the other's output and vice versa. And use them to trigger the other before transmitting. This could be useful when a software SPI is implemented (i.e. for an MCU with no SPI support) \$\endgroup\$
    – Rohat Kılıç
    Commented Dec 9, 2020 at 13:03
0
\$\begingroup\$

If you wish to perform communications between two microcontrollers then you can assign one to be master and the other to be slave. If that is too limiting then you can reassign master/slave status on-the-fly with some high level protocol command.

should I implement both Slave and Master SPI drivers in both uCs?

If devices are always fixed master/slave then you only need to implement master in one and slave in the other. If you want more flexibility (and I'm not saying you do) then implement both. However, it makes sense to always boot-up in a pre-defined direction with one as master and the other as slave.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.