Author Topic: CANopen on i.MXRT?  (Read 2255 times)

Offline NedK

  • Newbie
  • *
  • Posts: 3
    • View Profile
CANopen on i.MXRT?
« on: May 16, 2022, 07:34:00 PM »
I've been looking at the V2.0.0 µTasker code, and noticed that:

 (a) the version of the CANopenNode code is quite old (2015 vs. the CANopenNode 4.0 code that is the current branch)

 (b) the driver code appears to be taken from the MCF5282, but the guts of the actual driver code (in CO_driver.c) appears to be all or mostly disabled (CO_CANmodule_init, CO_CANsetConfigurationMode, CO_CANsetNormalMode, CO_CANverifyErrors, etc.).

The latest CANopenNode 4.0 branch cleans up the directory structure, and allows for using multiple object dictionaries if desired.
This can help sharing parts of the object dictionary between nodes that have to communicate but don't have identical object dictionaries.

I've been using the CANOpenEditor fork from https://github.com/frabul/CANopenEditor.git, compiled in VS 2022 Community, and it's been quite stable.

My current project is actually using the CANopenNode object dictionary and editor, but not the whole CANopen stack (yet). However, it's likely that we will want to use the whole stack (and the CAN peripheral in the i.MXRT1020) within a year or so.

So I'd like to ask:

What is the current state of the CANopenNode code? Could it be updated to the 4.0 branch?

Is there likely to be a CAN driver for the i.MXRT family any time soon that would work with CANopenNode?

Thanks!



Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: CANopen on i.MXRT?
« Reply #1 on: May 17, 2022, 01:46:42 AM »
Hi

It is correct that the driver layer used as reference was from a Coldfire reference but I don't know whether it actually worked since there were some things that didn't match the Coldfire's CAN controller. CO_driver.c is therefore mostly not used since it is HW dependent in its original from and has been made HW independent (but original content retained - commented out - as reference).

Then the interface was reworked to use the uTasker CAN driver interface instead and used in a product (probably about 4 years ago now) on a K64 of K66 .
The Kinetis has FlexCAN (as the Coldfires do/did) and the i.MX RTs also have the same FlexCAN.

If I enable CAN_INTERFACE and
Code: [Select]
SUPPORT_CANopen the project builds for i.MX RTs (although I had to disable two lines in CANopen.c due to a typedef being provided twice):

//typedef unsigned short    MAX_MALLOC;                                    // up to 64k heap chunks
//extern void *uMalloc(MAX_MALLOC);


It may be that that was never needed or became redundant and is only evident when MAX_MALLOC is typedef'ed differently in the application's types.h. My bet is that this is the case and so I will disable these since I don't see that they are needed since there is an include of "config.h" there to access it.

Theoretically this will already run on the i.MX RT since the FlexCAN driver is the only thing that is HW dependent and, since this driver is shared between Kinetis and i.MX RT and assuming it runs on the i.MX RT (which I haven't verified myself just yet - eg. a clock source could be incorrect for speed calculation or there be a register incompatibility somewhere) it will run on any Kinetis, i.MX RT or Coldfire with FlexCAN (although Coldfire is legacy and no longer worked with).

One restriction of the CANopen stack is that it only supports a single instance and so different CANopen instances can't be run on multiple CAN buses..

uCANopenApp.c is used as application interface to the CANopen stack - interfacing with the CANopen.c interface.
If a newer version of CANopenNode is used I expect uCANopenApp.c to remain the same and also CANopen.c to remain the same unless there are changes to the stack's API.
The rest of the newer CANopenNode stack would replace the previous version.

In each of the CANopenNode files I have added:

#include "config.h"

#if defined CAN_INTERFACE && defined SUPPORT_CANopen
...
#endif


which allows them to get their configuration defines from the application configuration rather than needing a configuration header which is not so easily maintained for multiple application use.

Therefore I essentially expect that the 2015 version of CANopenNode should be operational (worst case with a driver / i.MX RT specific correction).
A newer version would need to be integrated but I don't expect any real complications as long as the interface files continue to do their job of keeping the CANopenNode code itself independent to the application's / HW interface.

Regards

Mark

P.S: There is a possibility that I will shortly be using CANopenNode in an i.MX RT based product development and then I would also need to decide whether an upgrade makes sense as part of this work.