UNO + Ethershield + CAN bus: how do we know who is talking?

I am running an UNO with Ethershield and CAN bus adapter, however, CAN does not receive data.

My first step is to prove that the CAN bus read is giving me the data I need; this worked just fine.

pin 13 (SCK)
pin 12 (MISO)
pin 11 (MOSI)
pin 10 (SS/CS)

Then I added an Ethernet shield…
pin 13 (SCK)
pin 12 (MISO)
pin 11 (MOSI)
pin 10 (SS/CS)

and changed the CS/SS for the CAN bus:
pin 13 (SCK)
pin 12 (MISO)
pin 11 (MOSI)
pin 9 (SS/CS)

Ethernet works… CAN bus does not seem to read anything.

Then I started thinking… The SS pin makes a SPI device active. Using pin 10 for the Ethershield (and which I cannot change), and SS on pin 9 for the CAN bus board makes sense.
BUT, since only one can ‘talk’ on the SPI, who switches off 9 when 10 is required and the other way around? I have the suspicion that 10 is happily chatting, while 9 goes under. I thought that only one SS (either 9 or 10) can be active.
What does control these two pins?
Is this something that is being taken care off in some libraries?

I have seen this question, whether UNO + Ethershield + CAN bus can be stacked and or work together, but when code was shown, I could not see what makes one SS active and not the other.

Any hints appreciated.

(The attached source, shows how the basic CAN was developed first, and then Ethernet and MQTT where added; meaning the logic should work)

main.cpp (22.3 KB)

Provide a link to the CAN adaptor you are using.

How much memory is left after compilation?

Thank you for your interest... :slight_smile:

I am using this adaptor: MCP2515

DATA:    [======    ]  60.3% (used 1234 bytes from 2048 bytes)
PROGRAM: [=======   ]  72.1% (used 23268 bytes from 32256 bytes)

I have progressed with the fault finding, by going back to basics:
two UNOS, two MCP2515 boards, connect them, one transmits the other receives; sweet, all working.
Then change code on one to read data from the source device, a battery management system. Also working.

Changed publishTopicAndMessage() to serial out, rather than sendMqtt... and this produced some gibberish, indicating the program seems to work, but the coding must be wrong.

The source sends data at 4Hz, and quite a bit of data.
I reckon the sendMqtt msg bit takes to long; and another suspicion is my c-string handling, which I have to read up on. It may well be the reason for the UNO to produce gibberish, and eventually reset after a few seconds, due to buffer overflows.

I think I need to rewrite this to wait for a certain message Id, process this, send the MQTT msg, and then wait for the next msg Id. Say, every few seconds I capture another msg of interest. There are 7, one every 2 seconds, and I have the data in 15 seconds, do this every 5 minutes, this will do.

Most importantly what I forgot: the key question: Who talks on SPI? Or, what manages the different slave select pins? How does one know the other is talking? In this case the Ethernet shield uses pin 10, while the MCP2515 uses pin 9. Who orchestrates the 'traffic' so to speak? I have mot coded anything to that effect. This could be also the problem for the gibberish (as in weird characters) I get?!

The libraries control the chip select lines when your code does a
or a
For the rest of the time there is nothing driving the chip select lines.
The ethernet shield and the CAN adaptor only listen to the chip select lines, they don’t drive them.

Arduino is single threaded and I don’t see any interrupts in your code therfore the only way for both chip select lines to be active at the same time would be due to a bug in the libraries you are using.

From the #include <mcp_can.h> in your code I’m guessing that you are using a MCP2515 library from Seed Studio. You may have more success using the Cory Fowler library GitHub - coryjfowler/MCP_CAN_lib: MCP_CAN Library.

My own experience with MQTT and CAN bus together on the Mega328 is that you run into low memory problems which is why I switched to using the Mega2560.

Thanks; this makes sense...

I am using Corey's library... it has the 8MHz definitions for the cheap MCP2515 boards.

2012 Copyright (c) Seeed Technology Inc.  All right reserved.

Contributor: Cory J. Fowler

I have quite a few controllers with close to 80% memory used, and they work fine, ut I take your hint, and may well change to a MEGA or go Raspberry ;D

There are two distinct libraries, Cory was involved in both, but the one under his own name is more recent.