Compiling on Teensy4.0

[slick-wille]

I have been using the Teensy 3.6 with this library and have had no problems. Now I decided to upgrade to the Teensy 4.0, but I am having an error when compiling with the new one. When compiling on the 4.0, I get this error.

... src/NMEA2000_Can.h:122:26: fatal error: NMEA2000_mcp.h: No such file or directory compilation terminated.

Why would the same code not compile on a different board? Thanks.

[ttlappalainen]

There is no support for Teensy 4 yet.

[ovni32]

As the Teensy 4 is an interesting new platform I want to ask if there are plans to support Teensy 4 in upcoming versions?

[ttlappalainen]

Yes, there will be as soon as I have time.

[ovni32]

These are good news - thanks!

[hobiseven]

HI there. Did you manage to progress a bit on Teensy 4.X port please? Thank you from France.

[ttlappalainen]

I have started it, but unfortunately have not worked so actively.

[ovni32]

Dear Olivier,

I solved this topic in the following way by using a 3.2 and 4.0 Teensy in cooperation: I use a Teensy 3.2 to handle the NMEA200 bus. This Teensy 3.2 also uses sensors on an I2C bus (like environmental data pressure, temperature, wind) and forward the data to the NMEA 2000 bus. A LIN-bus is used to read out the IBS-sensors of my

batteries. The Teensy 3.2 also pushes these values to the NMEA2000 bus. Actually I am buying an heading sensor on an NMEA1830 basis, that will also operated by the Teensy 3.2.

I use the Teensy 4.0 to display the data on a 4” touch screen. This Teensy 4.0 gets the data via a serial port on its demand from the Teensy 3.2.

What is the advantage: The Teensy 3.2 has a significant lower power consumption than the 4.0 so that it runs all the time 7/24 and collects all data. I operate it further at low 24 MHz (less power, less heat). The Teensy 4.0 runs only when it is needed - and if it I runs it runs at full speed to get the needed graphical performance.

I tested this dual setup the last weeks on my ship and it works very fine. Probably this is also a solution for you. You only have to spend money for two Teensy.

Best Regards,

Markus

Von: Olivier Briand notifications@github.com Gesendet: Montag, 20. Juli 2020 21:36 An: ttlappalainen/NMEA2000 NMEA2000@noreply.github.com Cc: ovni32 markus@stommel.nrw; Comment comment@noreply.github.com Betreff: Re: [ttlappalainen/NMEA2000] Compiling on Teensy4.0 (#152)

HI there. Did you manage to progress a bit on Teensy 4.X port please? Thank you from France.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ttlappalainen/NMEA2000/issues/152#issuecomment-661291668 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AN7SRGCQCRIW4YQQDLLV223R4SMCRANCNFSM4I73LHHQ .

[ttlappalainen]

I have also looked in to the FlexCAN4 library and have thought that I have to clean it totally and include it to the new NMEA2000_Teensyx "driver". The FlexCAN4 has same issue as all CAN libraries they are not usable with NMEA2000, since they have only one output buffer, which destroys fastpacket sending. Other option is to send them with specific mailbox, which unfortunately stops system to wait until send has been done - and who in earth would like stop this great MCU to just wait. Also they forget message prioritizing totally. So I have clear plan and test device ready, just matter of time.

[ttlappalainen]

Does anyone have Teensy 4.x? I hope I'll have first driver version on next week. So I prefer other testers too.

[pk1965]

@ttlappalainen I do.. its a 4.1 I've got transceivers for can0 and can1 and I'm currently sourcing canfd transcievers for can3. I've also have multiple other devices including a rpi4b with the 2 Channel CAN BUS FD shield we can test with

[pk1965]

Successfully complied the new NMEA2000_Teensyx and updated NMEA2000 libraries on the following devices

• Teensy 3.5 with a SN65HVD230DTI Can Bus transceiver connected to Expedition Navigation software 11.2.7 via the USB port

  1. appears to be receiving all bus data and successfully transmits ISO request PGN59904 packets
  2. successfully transmitted all other selected PGN's

• Teensy 4.1 with SN65HVD230DTI Can Bus transceivers connected to can1, can2 and can3 connected to NMEA Simulator 1.7.1.210 application via the USB port. Individual ports where selected by defining "#define NMEA2000_TEENSYX_CAN_BUS tNMEA2000_Teensyx::CAN1"

  1. appears to successfully transmit and receive data to ports can1 and can2
  2. appears to successfully receive data on can3. It fails to transmit data on can3. Im assuming this as can3 is CANFD port and the installed transceiver is not compatible. currently sourcing TCAN330G transceivers before retesting

Other Devices upgrade to the new NMEA2000 library only

• Arduino Mega2560 with CAN BUS duo v2 connected to Actisence NMEA Reader 2.102
  1. initially failed to compile, "#include \<cstring>" in N2kGroupFunction.h was causing an unknow file error. Commented out line 29 and was able to successfully compile
  2. the mega appeared to work correctly connected to the NMEA Reader
  3. connected the Mega to the NMEA Simulator and it also appeared to work correctly receiving and transmitting data
• Raspberry Pi 3B+ (RPI3-1) with a CAN Bus Duo V2 used to monitor can bus during testing
  1. using "canbusload can1@250000" bus did not excess 5% utilisation
• Raspberry Pi 4B 2Meg (RPI4-1) with a RS485 CAN HAT was used to monitor raw NMEA2000 data on the bus using the NMEAActisenceListener application
  1. it appeared that all packets where seen on the bus when log file was analyzed
• Raspberry Pi 4B 8meg (RPI4-2) with a 2 Channel CAN BUS FD Hat transmitting internet based sensor data onto the bus.
  1. appears to work correctly against the teensy3.5. Expedition was able to read the data and the PI responsed to the 59904 ISO request PGN.

When checking the can0 interface on RPI4-2 using the command "ip -details -statistics link show can0" i was seeing steadily increasing "bus-errors", "errer-wan" and "error-pass" counts when transmitting data on the teensy4.1. When I swapped the rolls between the Mega and 4.1 these errors stopped. Further investigation is needed to isolate the errors but i could just be my lab setup. Will advise when I have a more definitive idea whats happening.

So overall.. awesome work Timo for the first release.

[ttlappalainen]

Thaks a lot for good testing!

• I have only Teensy 4.0 and 3.x Teensies, which I tested. Currently I do not have working RPi.

• I updated #ifndef ARDUINO #include #endif to N2kGroupFunction.h. I read NMEA2000 shield forum people having problem with missing strcmp when compiling for RPi. I wonder why they do not have for Mega.

• Have you checked cpu usage with NMEA2000 library on RPi? I added usleep(100); for loop, which dropped cpu usage dramatically on RPi see https://github.com/ttlappalainen/NMEA2000/blob/master/Examples/NMEA2000ToNMEA0183/main.cpp

• Should have other forum for that. How familiar you are with RPi? As I wrote on forum all CAN "drivers" handles NMEA2000 fast packet wrong. Tranceivers, which has multiple mailboxes must lock same fastpacket to be sent through one mailbox. In other case it may send fastpacket frames in wrong order and receivers handles that as error. Also original Arduino mcp_can did that and RPi uses also MCP2515 tranceiver. It should be easy test by using MessageSender example on RPi and count sent messags and read with some other or check with NMEA Simulator message console message count.

• I'll try to check do I see bus or other errors on my test environment. Ensure that you have 2 termination resistors on your system. I often test with only one, but then there may be errors.

[pk1965]

Your welcome

• I've checked your your update NMEA2000 library on all of my devices and they all built without error.
• I noticed the cpu going 100% on the RPI as well. I also put a "usleep()" in but i'm curios what the optimal value would be. I suppose you could calculate it based on the wait time between packets
• I'm fairly new to the RPI hardware but I've been working with linux (kernel was v0.9 I when started) on and off for almost 30years, as an administrator/integrator. Let me reset my lab and test the fastpacket issue across all my devices. hopefully i can have I can check it out in the next couple of days
• I double checked my bus and yes there was a terminator issue.. basically can2/can3 of the T4.1 was at a T section with the terminator which I now rejigged with no errors.

[ttlappalainen]

• In ESP32 there is simple yeild(); function, which releases time to other threads. In Windows Sleep(0); does same. I did not find related function for linux (RPi) at time I tested that code. If you know one, try it. It could be also handled with even mechanism, if one could generate event from incoming frame from CAN. In Windows it would be WaitForEvent(handle,1); whcih means that it would wait event and return anyway after 1 ms, which you need for handling delayed or transport protocol messages. In this case one could do sending on other thread and use mutex locking for NMEA2000 object. Something like this:

  
  void loop() {
  WaitForCANEvent(1);
  LockNMEA2000();
  NMEA2000.ParseMessages();
  ReleaseNMEA2000();
  }

void SendTemperatureThread() { Sleep(2500); LockNMEA2000(); tN2kMsg N2kMsg; // Build message ... NMEA2000.SendMsg(N2kMsg); ReleaseNMEA2000(); }

usleep(100); is good hit, if it releases time to other threads. It drops CPU usage and has still very good timing resolution.

[pk1965]

ok.. I'll see what I can find.

[pk1965]

Sorry for the delay but my new TCAN330GD transceivers finally arrived allowing the checking with the CANFD port on the 4.1.

I've final started checking the fastpacket frames on MCP2515 controllers. It appears that the MCP2515 has the same issue on RPI devices as the Arduino mcp_can but the new "2 Channel CAN BUS FD Hat" (MCP2717FD) on for RPI doesnt. Note: The new "2 Channel CAN BUS FD Hat" is installed via a kernel module where the "CAN Bus Duo V2" uses the "SPI interface" and and overly in the /boot/config.txt"

My observations where based on the following setup;

1. ListenerSender feeding data into the Actisence NMEA Reader on my PC.

   • Teensy 4.1 - integrated can controller / SN65HVD230DTI Can Bus transceiver for CAN2.0 ports can1//can2 and TCAN330GD CAN transceiver for the CANFD port can3.
   • Mega2560 - CAN-BUS Shield V2 MCP2515 Controller / MCP2551 CAN transceiver

2. MessageSenders

   • RPI 4B - 2 Channel CAN BUS FD Hat (MCP2517FD) / MCP2557FD CAN transceiver
   • RPI3B+ - PiCAN 2 Duo MCP2515 Controller / MCP2551 CAN transceiver
   • Teensy 3.5 - integrated can controller / SN65HVD230DTI Can Bus transceiver

T4.1 listenerSender results:

1. RPI3B - 28 PGN's seen only 7 being updated every second and heartbeat was every 60min
2. RPI4B - 28PGN.s seen and all being updated every second except 127250/127488/129026 every 0.1sec and heartbeat every 60min
3. Teensy 3.5 - 28PGN.s seen and all being updated every second except 127250/127488/129026 every 0.1sec and heartbeat every 60min

Mega2560 listernerSender results;

1. RPI3B - 13PGN's seen with 7 being updated every second
2. RPI4B - 22PGN's seen with 12 being updated every second
3. Teensy 3.5 - 26PGN's seen all being updated every second except 127250/127488/129026 every 0.1sec and heartbeat every 60min

Here's a couple of snapshots below. SRC22 in the RPI4B and SRC40 is the RPI3B+ the MessagerSender app is identical and the Rasbian PI software. The first one is using the T4.1 as the ListenerSender and the second is the Mega2560.. notice the difference in the updates and the missing PGN's

[ttlappalainen]

You could run MessageSender on T4 and RPi and listen with T3.5 and see the results.

[pk1965]

done SRC22 is the RPI4B and SRC41 is the Teensy4.1 can3

[ttlappalainen]

Could you try with my NMEA Simulator and modified MessageSender http://www.kave.fi/Apps/NMEA2000/MessageSender.7z On Message sender send 'p' to pause sending messages and 'c' to clear stats and 'p' to continue sending. On NMEASimulator

• Tools-Options...-General and enable only "Received NMEA2000".
• Tools-Options...-NMEA2000 --- set "NMEA2000 Port" to your listener device. --- On Devices right click each device and uncheck "Enabled", then it will not send any more. --- Exit settings.
• On main window bottom check run
• Open Tools-Message Console...

Then

• On sender pause it ('p') and clear stats ('c').
• On Simulator message console right click and select Clear.
• On sender continue sending ('p') and let it run for a while and then stop it.
• Compare reading on sender and Simulator Message Console Total Messages count on bottom. They should match.

[pk1965]

I repeated the test as requested on all 3 can ports on the 4.1 and the result was the same... failed message count=0 and the message count was the same

[ttlappalainen]

Sorry I mean to test it with RPi.

I have Teensy 3.2 on Simulator box receiving and I have tested sending with Teensy 3.2, 3.5, 4.0 and ESP32. Also with 3 divices sending sumulatanous. But interisting is that if you send from RPi. I have not cheked how they handle frames on RPi. On CAN controller it is possibele to use multiple Mailbox, but fastpackets has to be forced to go out from same. If not frames may be mixed and my listener program skips them.

[pk1965]

Ok bare with me whilst I port it over to the RPI

[pk1965]

very interesting results. I complied and run the software on all three RPI's and using the T4.1 as the listenerSender.. There was no lost messages even when all three devices where transmitting at the same time. There was a throughput difference of about 10% when changing between the CANFD port to a CAN2.0 port on the T4.1.

[ttlappalainen]

What do you mean with "throughput difference of about 10%"? How did you measure it and which was better?