Can the (MC9S08DZ) MSCAN be used without a driver for local MCU intercommunication?

[tonyp]

Hello all,

The title pretty much says it all.

I'm wondering (at the theoretical level at this time, for an upcoming project) if the MSCAN module can be used 'locally' (for example between three or more processors on the same board) without the use of driver ICs?  Can it handle message arbitration at the hardware level or is this a function solely achieved by the driver IC?

The advantage for this would be to create an array of MCUs that can all talk to one-another using the benefits of CAN (about all-or-none message delivery, multiple concurrent recipients, etc.)   In other words, I'm interested in getting the behavior of CAN between multiple MCUs on a single board, but without necessarily the electrical noise tolerant characteristics needed when dealing with cables and longer distances.

CAN the MSCAN support this directly?  Has anyone tried something similar?

TIA

[tonyp]

A small update:

I happened to find this document, which provides a more official response (not from Freescale, but still valid and probably tested) showing how this idea (using CAN with no transceiver for single board MCU interconnections) is indeed possible, and using only one wire, by the way.

So, I will have to try it with the DZ when I get a chance, and let everyone know how well it works (or not)!

[bigmac]

Hello Tony P,

I have not had direct experience with MSCAN.  However, from examination of a typical transceiver datasheet, it might appear that you could utilize non-inverting buffers with open collector (or open drain) transistors for each TxD circuit.  The buffered outputs, and all RxD inputs would be then simply paralleled, in conjunction with a pullup resistor.  This should achieve the dominant/recessive characteristic, but with a "single ended" arrangement.

Since the buffers require to be non-inverting, one method of simply achieving this would be to use analog comparators, such as LM339 for a quad comparator package, with each inverting input set to a voltage of Vdd/2, or thereabouts.  I am not sure whether this particular device would be suitable for a 3.3 volt system.

Regards,

Mac

[Lundin]

We pondered doing similar things here, but tossed those plans away. Because one ends up doing something similar to what Bigmac describes: building a CAN tranceiver with various digital+analog ICs, minus all the rugged protection that the "single-chip" CAN tranceiver circuits contain for free. So it will not only be much more expensive, bur also more error prone.

I suppose reduced power consumption could be a benefit with it, but since I doubt you can get a sensible solution that's as robust as "real" CAN, why not simply go with SPI or similar?

[rocco]

I think the diodes are a great idea. Actually, the whole "CAN as an inter-MCU link" is a great idea.

If the diodes are Schottky, the low voltage at the common bus would be raised by less than .2 volts. However, even ordinary diodes, with a drop of .7v, would give you a low that is well below the maximum valid low voltage for the CAN inputs (1.75v with Vdd=5v). I don't think noise will be an issue if the bus is limited to the PCB.

---

Lundin wrote:

. . . why not simply go with SPI or similar?

---

I have a number of boards with multiple MCUs on them, and I usually hook them together with the SPI. I can safely testify that it sucks.

The problem is that, at the higher baud-rates, you can get a byte, and its associated interrupt, quicker than every two microseconds. That is difficult to manage using interrupts, and can be even more difficult without interrupts. The slower baud-rates can allow reliable transfers with interrupts, but with limited throughput. And then there is all of the code involved in creating a reliable multi-master, message-based protocol.

Using CAN can offload a lot of the work, and allow you to code at the "message" level instead of at the "byte" level.

When I get the time, I'm going to have to experiment with this. Probably toward the end of 2017.

[Lundin]

The reason it sucks is likely because you are using Freescale MCUs that have no hardware buffers for the received data. But that merely means that Freescale's implementation of SPI "sucks" (and SCI too for that matter), not the SPI bus in itself. If they had a hardware buffer/shift register on-chip with lets say 20 bytes, the interrupt spam & jitter wouldn't be such a big issue.

So the big difference for your case seems to be that MSCAN has its 5 input buffers of 8 bytes each, while SPI has only 1 byte?

As for the wired-OR I remember our hardware folks discussing that too. I'm not quite sure why we decided against it, possibly because of a 3V system where the Schottky would munch up a considerable amount of the logic level. Otherwise I suppose I would work, yet it is still not as safe as a CAN tranceiver: no transient protection, no ESD protection etc etc. You'd have to design all those things manually. And then, depending on your requirements, squeeze in some EMI filters in there too.

I don't quite see what you would gain with this... what's next, implementing the CAN controller with logic gates and bit-banging?

[rocco]

Hi Lundin,

---

Lundin wrote:

The reason it sucks is likely because you are using Freescale MCUs that have no hardware buffers for the received data. But that merely means that Freescale's implementation of SPI "sucks" (and SCI too for that matter), not the SPI bus in itself. If they had a hardware buffer/shift register on-chip with lets say 20 bytes, the interrupt spam & jitter wouldn't be such a big issue.

---

Absolutely. I like the SPI, and prefer it over IIC for peripherals like EEProms, ADCs, DACs and I/O expansion, but as a communications medium, it lives at too low a level. I am using HC08s and S08s, so I don't have the benefits that a S12 would offer.

---

Lundin wrote:

As for the wired-OR I remember our hardware folks discussing that too. I'm not quite sure why we decided against it, possibly because of a 3V system where the Schottky would munch up a considerable amount of the logic level.

---

That was my original thought, but then a looked closely at the DZ datasheet.

Whereas it used to be that a logic level would need to be below/above a hard-coded value, like .4 volts for low and 2 volts for high, the S08DZ does something more sophisticated. A low needs to be below (Vdd x .35), which is 1.75 volts at Vdd=5v and 1 volt at Vdd=3v. This leaves more legroom for even standard diodes. To improve noise immunity, all inputs now have hysteresis.

I suspect that it was the .4 volt low-input requirement that scuttled your original investigation.

It appears to me that a CAN transceiver's ESD and transient protection would not be necessary if the CAN bus is not leaving the PCB. Those specs are meant for running through the wiring-harness of an automobile. The protection inherent in the MCU would be adequate on the PCB, as the CAN signals are no different than the other MCU signals wondering around the PCB. The same would be true for EMI filters.

Now - Bit-banging CAN - that is a scary thought.    ;8)

[celsoken]

I agree with Lundin, it will be reinventing the driver with some pitfalls. Mac's solution e.g. probably wouldn't work over 20Kbps. The awesome darl PNP diff input of the LM339 wich is excellent for noise in automotive apps (for being slow) will limit the freq response.

If you can deal with EMI generated from long lines maybe you could use a HC30 octal nand with an inverter with CAN TXDs connected to the inputs and all CAN RXDs connected to the non-inverted output.

Regards,

Celso

[bigmac]

Hello,

Here is an even simpler solution, in the "wired-OR" category -

Connect a series diode in each TxD lead, with the cathode to the output pin, and with all anodes joined and connected to the paralleled RxD inputs.  Fit a pullup resistor, say 1k, at the junction of the anodes.

Assuming a 5 volt system, and with the use of small signal Schottky diodes, the noise margin at the inputs should remain quite adequate.

In the event that an external CAN bus connection is also needed, this should then requre only a single transceiver device.  The diode anodes (and pullup) would connect to the sender, and the receiver output would connect to the paralleled RxD connections.

Regards,

Mac