CAN bus implementation

[matrix]

Hi Dan

That's good news.

Thanks for your support, I am interested but right now a bit running out of time..

[matrix]

@Dan

The CANfestival link is interesting, we have used AVR MCUs for
CAN applications, with external CAN controller and recently
parts with integrated controller.

Interfacing CAN controller with XMOS parts could be an interesting option too.

Do you know if the XMOS CAN implementation is still under active development ?

Cheers,
Matrix

[dan]

Hi Matrix,

Yes the CAN component is very much active and maintained, its part of our motor control platform and you can rely on it remaining so.

If you wanted to proceed with a CANopen github project based on that please get in touch via PM with the detail and we can explore some options.

Dan

[matrix]

Hi Dan,

Off-topic because the question targets more the XS1 architecture, nonetheless:

Is it possible to create a networked application (in my case based on CAN nodes on
preferably several unmodified* XC-1A boards), where the firmware can be upgraded (flashed)
via CAN ?

*except 1 additional CAN transceiver per board

Thanks
Matrix

[matrix]

@omega7

This helps a lot! What does this implementation need regarding threads and cores?
Should I reserve a core for CAN bus?

I have got the current sc_can from github and will try it as soon as
I have CAN transceivers in DIP package available.

The readme of the package might give some answers to your first part of your
question:

Key Features
============

* two threads for each of the node one for LLC & other for PHY layer.
* Baud Rates up to 500kbps (1Mbps alpha included)
* Support for extended identifier(29-bit) for PHY layer
* Support for dynamic bit rate control


Firmware Overview
=================

RX and TX are executed as functions which each run in PHY layer which in turn passes messages to & from LLC layer.

A demo appliction is included.

KNOWN ISSUES
============

The 1Mbps version will not run within the timing constraints.

Required Modules
================

xcommon

Regarding your second part of the question, I am not experienced enough to
answer that. As I understand the architecture, you should not run more than
4 threads on 1 core at the same time, if your application has tight time
contraints. Then, your CAN baud rate could also be an important factor to consider.

Matrix

[matrix]

@omega7

just forgot to mention:

I your application needs to do a lot of CAN Acceptance Filtering, then keep in
mind that you might need an extra thread for this. Noramally, Acceptance Filtering
is done directly in hardware of the CAN controller, in systems as such there is no
additional CPU load on this task.

Matrix

[matrix]

Hi all,

I am intersted about your viewpoint of the summary of the can.pdf
document, which was attached here in the topic:

.
.

6 Summary

The XMOS devices are ideal for protocols which map well into the ISO/OSI reference
model, through the mapping of different layers of the protocol into different
communicating hardware threads. Controller Area Network is such a protocol
where each layer of the ISO/OSI stack can be implemented using one thread.
More processing power can be achieved if the receive and transmit interface
could be decoupled into separate thread stack.
.
.

Isn't the IOS/OSI stack flow orientated, where on service provided by a layer depends
on onother layer next to it? If this assumtion is right, how can then a multi-threaded
solution offer advantages over a single-threaded one ?

Matrix

[dan]

Hi chaps,

The acceptance filtering would be done in the 'LLC' thread. The phy thread is doing the data link layer stuff.

In fact if you don't need complex filtering you won't need the second thread. Our motor control platform currently just uses the phy thread.

As for the question about firmware upgrade via CAN (e.g. DFU-over-CAN) I don't see why not. We're adding a DFU module to our AVB reference design which will be released shortly. You could take this module (which is agnostic about the network interface used to deliver the connectivity) and wire it up to the CAN interface.

As for threads, it depends on how fast you want that CANbus to run. If you want 1mbit you would need to just run 4 threads so the CAN thread can have 100 MIPS. However if 500kbit is OK, then you'll be fine having 8 62.5 MIPS threads running (assuming a -C5 part), so it depends really on your spec for the CAN interface.

[matrix]

hi,

As for the question about firmware upgrade via CAN (e.g. DFU-over-CAN) I don't see why not.

That's perfect, upgrading the nodes via CAN later on in the field
will save a lot of maintenance time (and the USB link via additional
connectors, which would be cumbersome).

It is a one-off project with 10 nodes, and the XC-1A board has the
right dimensions, by chance. 24V DC/DC converter is a must, but I think
it is managable.

Thanks

[matrix]

@all

BTW, this link gives an overview regarding CAN licensing issues.
http://www.actel.com/ipdocs/CANbus_lic_RS.pdf