Any chances to have the CanFestivino on AtmegaxxM1?

[alessio31183]

Instead of having the external can controller MCP2515, it seems to be more convenient using the AtmegaxxM1 uC that has the internal can controller. https://github.com/thomasonw/ATmegaxxM1-C1 I've attached the link to an Arduino Core for ATmegaxxM1/C1 CPUs in order to be able to program that uC family with the Arduino IDE. Further, the same guy posted the Object oriented canbus library. He ported from the existing due_can library and follows those APIs. https://github.com/thomasonw/avr_can

I was wondering if there is any chance to make your CANFestivino project compatible with this library without using the mcp2515 APIs. Or perhaps if there is a simple chance where we can create a bridge file between the mcp2515 library and the due_can library

Thanks in advance

[jgeisler0303]

Yes, using a different CAN driver should be quite easy. You need to change the implementation of the functions defined in CO_can.h (canSend and initCAN, currently implemented in CO_can_Arduino.cpp) and the calls to readMsgBuf and checkReceive in lines 71 and 72 of canfestival.h.

[alessio31183]

What do you think about to extend your project using this approach?

https://github.com/McNeight/CAN_Library

Basically the idea is to allow the can communication with multiple types of CAN controllers using a consistent API. The idea behind this is to use a similar approach to Adafruit's Unified Sensor library by standardizing CAN function calls, frame structure, filters, masks, buffers, etc to be used with a wide variety of CAN controllers

[alessio31183]

I'm trying to follow your suggestion in a previous comment Yes, using a different CAN driver should be quite easy. You need to change the implementation of the functions defined in CO_can.h (canSend and initCAN, currently implemented in CO_can_Arduino.cpp) and the calls to readMsgBuf and checkReceive in lines 71 and 72 of canfestival.h. but I'm still having some problems. It's not compilable yet. The main issue is that the CAN frame data structure is different between the mcp_can library and the avr_can library fof the ATmegaXXM1.

// for the mcp_can lib typedef struct { UNS16 cob_id; /< message's ID */ UNS8 rtr; /*< remote transmission request. (0 if not rtr message, 1 if rtr message) / UNS8 len; /< message's length (0 to 8) */ UNS8 data[8]; /*< message's datas / } Message;

// for the avr_can lib typedef union { uint64_t value; struct { uint32_t low; uint32_t high; }; struct { uint16_t s0; uint16_t s1; uint16_t s2; uint16_t s3; }; uint8_t bytes[8]; uint8_t byte[8]; //alternate name so you can omit the s if you feel it makes more sense } BytesUnion;

typedef struct { uint32_t id; // EID if ide set, SID otherwise uint8_t rtr; // Remote Transmission Request uint8_t priority; // Priority but only important for TX frames and then only for special uses. uint8_t extended; // Extended ID flag uint16_t time; // CAN timer value when mailbox message was received. uint8_t length; // Number of data bytes BytesUnion data; // 64 bits - lots of ways to access it. } CAN_FRAME;

This issue has a lot of consequences in the right compilation way. Is probably easier starting from the canFestival project as you did which has already an example for AVR uC (AT90CAN and ATmegaXXM1?

I'm starting from this easy template CANFestivino_ATmega328p.zip Look at the analogRead example. It emulates a generic I/O device with the DS401 profile that takes an analog value aon A0 from a potentiometer to emulate the sensor value.

[jgeisler0303]

What problems exactly do you have? I would write the send and receive functions of CANFestivino as wrappers to the other CAN bus driver, probably just copying the data from one struct to the other and then handing that copy the driver.