Change the libary to use a different CAN driver

[birkelbach]

Right now we are using our own MCP2515 CAN driver. There are other Arduino CAN libraries out there that would also give us the ability to use internal CAN hardware for Arduinos that have those (i.e. ESP32 or STM32) or other external controller chips if someone has done that. Also this would keep us from having to maintain that code base.

[birkelbach]

I took a quick glance at the state of the CAN libraries in the Arduino and it seems pretty haphazard. There doesn't seem to be any common interface to these libraries. Maybe I'm missing it.

If we are going to do this it'd be nice if it would work with other CAN hardware than the MCP2515 only. If this worked with the internal ESP32 CAN controller then Vern's Huvver devices would immediately be CANFiX compatible. If it worked with the internal STM32 CAN controller then this pile of Nucleo boards that I have would be compatible. I'm sure there are other boards as well.

Now the question is... what is the best library to use (there are dozens of them) and/or do we commit to that library or write a wrapper in our code? It's been a while since I messed with Arduino libraries. My instinct is that we create some wrapper functions that present a standard CAN interface and then it would use different backend libraries based on #defines that the user would put in their code. This has the added advantage that the existing CANFiX code doesn't have to change much.

This doesn't seem very Arduino'ish to me. Suggestions are welcome!

[danderflieger]

Thanks Phil.

I like the idea of abstracting the underlying library away to give the developer a simple way to interface one of several libraries. Like you said, maintaining all of that code could be tough and there's no reason to re-write it all if someone already has (provided we test our "approved" libraries thoroughly).

I'm not a hardware guy, so Arduino is my only experience with microcontrollers of any kind. I'm happy to learn more, but I don't really even know where to start. Also finding the MakerPlane projects two weeks ago started my foray into the mysterious world of CAN. So from a hardware standpoint, I'm not much help, but I'm happy to work on documentation or write object classes for CANFix parameters (if that's helpful), or whatever I can do.

Dan

[birkelbach]

What do you think about these two for starters...

This one is being maintained by Adafruit and supports the ESP32 as well as SAME5x series uCs and the MCP2515. I don't really care for the interface but my guess is that it'll work well.
https://www.arduino.cc/reference/en/libraries/can-adafruit-fork/

This is the one that was mentioned on the MakerPlane forum. I like it as well. If you only want the MCP2515 then you might be able to save some space with this.
https://www.arduino.cc/reference/en/libraries/mcp_can/

Might keep ours too since it's pretty small because it only uses the features that we need for CANFiX. No extended messages or RTRs etc.

[danderflieger]

I can confirm that the CAN Adafruit Fork library works with my 8Mhz MCP2515. Using the CANSender.ino example this is a working example of what I to set my setup() block to look like:

void setup() {
  Serial.begin(9600);
  while (!Serial);
  CAN.setPins(10, 2);
  CAN.setClockFrequency(8E6);
  CAN.setSPIFrequency(16E6);
  
  Serial.println("CAN Sender");

  // start the CAN bus at 500 kbps
  if (!CAN.begin(125E3)) {
    Serial.println("Starting CAN failed!");
    while (1);
  }
}

I was also able to set my SPI Frequency up to 20Mhz, since I'm using an Arduino Nano with an ATmega328P chip on it. It worked both ways, I was just testing out various settings.

I was also able to crank my CAN frequency all the way up to 1Mhz.

And, as you know, I already tested the mcp_can library with good results too.

Seems like the Adafruit library supports more hardware (proven now on the MCP2515), so I suggest just using that one. If someone needs a slimmer library, maybe look at adding mcp_can as an option later??

Dan

[birkelbach]

Okay that’s good info. I’ll try to carve out some time this weekend to write a quick wrapper, and test it on a few boards. I don’t think it’ll be terribly difficult to do.

[birkelbach]

I thought about this more last night. I have a similar library that I wrote in C that I use for non-Arduino projects. I had a baked in CAN driver in that one for a while and I finally removed the CAN portion altogether and used user defined callback functions for the CAN stuff. So basically the calling program would be responsible for reading and writing the CAN frames. It would simply pass the received frames to the exec() function in the CANFiX object. If the exec() function needs to send a frame it would use a callback function that the calling program would have to provide for sending the CAN frames.

I couldn't think of a way of using multiple libraries without some kind of conditional compilation mechanism. That seems like bad form for a library to me, maybe I'm missing something. We'd also still have to maintain the wrapper code. This way we get out of the CAN sending/receiving business and can concentrate on protocol issues. It would also make unit testing brainlessly easy.

We would include examples for the different CAN libraries instead of maintaining wrapper code that would have to be conditionally compiled. It's the same thing we're just moving a little bit more responsibility (and freedom) to the end user.

[danderflieger]

Yeah, that sounds like a good path forward to me. I agree: If we're relying on the user to do more, we definitely need to have several simple example snippets for "supported" CAN libraries. I would certainly appreciate that as a new user. Thanks again for taking the time on this!

[danderflieger]

I've been fiddling with the CAN Adafruit Fork library and have had good success in reproducing your joystick example with it. The data is just manually hand-jammed into a message (e.g. no callbacks) for now. If you haven't already started on it, maybe I'll take a stab at updating the callbacks this week. I'm getting more and more comfortable with the spec the more I look at it.

[birkelbach]

I refactored the library files and wrote an example. The example uses the mcp_can library. I did a little bit of testing so the exec() call works and the can_write_callback() function works but I didn't test much after that. I have not pulled the code into this repo yet. It's currently available in my fork that you can find here...

https://github.com/birkelbach/CAN-FIX-ArduinoLib

While I was fiddling with it I realized that I was using the EEPROM library internally as well. I'd like to replace this with callback functions as well so the user has control of how this information actually gets stored instead of assuming EEPROM. Not all uCs have EEPROM.

I think I'm happy with this idea. The user required interface code is pretty minimal and should be pretty easy for users to figure out, even if we don't offer examples for all of them. As always, comments are welcome. I may fiddle with it some more later.

[birkelbach]

Dan, I sent you a PM on the MakerPlane forum. Send me an email and we can coordinate on working on this library. I'd love the help.

[brightproject]

Good day @birkelbach 🙂
It would be great to add an example to transmit some aviation parameters.
For example, altitude or engine RPM.
I can't figure out the CAN-FIX-ArduinoLib yet.

[birkelbach]

There is an example in the library that reads a joystick and sends pitch and roll.

[brightproject]

There is an example in the library that reads a joystick and sends pitch and roll.

The can-fix implementation for python has a list of all possible PIDs for transmitting data on engine parameters or altitude and flight speed.
I did not find anything like this in the implementation for arduino.
Could you help me understand the can-fix protocol?

[brightproject]

Thank you @birkelbach 🙂
Found the specification of the CAN-FIX protocol

https://github.com/makerplane/FIX-Gateway/blob/master/fixgw/config/canfix/map.yaml

Probably these canid's correspond to the general ID base.
At least they correspond to this:

CAN-FIX-ArduinoLib/examples/joystick.ino

Line 43 in afcc983

p.type = 0x180;

and

CAN-FIX-ArduinoLib/examples/joystick.ino

Line 60 in afcc983

p.type = 0x181;

I have a pressure sensor, the data from which I receive using the MCU esp32 and output data to the serial port.
I want to output data from the esp32 using the example code:

https://github.com/makerplane/CAN-FIX-ArduinoLib/blob/master/examples/joystick.ino

If I transfer the altitude data, which is calculated based on the pressure from the sensor, from the serial port of the microcontroller to the serial port of pyEfis

will this altitude be displayed in the program or do I need to take other steps?

[birkelbach]

CAN-FIX is not serial port based. It is CAN Bus. The CAN-FIX specification is at https://github.com/makerplane/canfix-spec. The CAN Bus Specification is referenced in that document. You will need an adapter of some kind to convert CAN Bus into something your PC/Raspberry Pi can read.

You can download a pre-built PDF of the specification from my Dropbox. https://www.dropbox.com/scl/fi/7w9okdmhin1vlvqqfij5p/CANFiX-Draft.pdf?rlkey=18md51ulzohrmfk2dm8pkrogu&st=614cpt0m&dl=0

Also, to answer your question. PyEFIS only talks to FiXGateway. FiXGateway is a data aggregator/translator. It has plug-ins that talk to the different types of external devices (serial, CAN, BT, Ethernet, etc), simulators or other software, the keyboard etc. The idea here is that someone may want to develop their own EFIS software. With FiXGateway they don't have to worry about all these other devices / software, and they can just use the interface to FiXGateway. If you can talk to FiXGateway, then you can talk to all the devices that FiXGateway can talk to.

If you want to do serial port based communication to FiXGateway then you'd have to figure out how to talk to one of the plugins in FiXGateway or develop your own plugin that talks to your device. This library will not help you do that.