Update to work with latest version of Seeed_Arduino_CAN lib (544d2c8e…

[dhopf]

…eb5891f41c70c19fdce7cda85211f7ff)

Actually, it's even compatible to the head of Seeed_Arduino_CAN lib as of today: ef053846591d4bc48aabd4ad82b301fa42d8f92c

I did not do much testing!
I have a Teensy 3.2 + 2x MCP2515 CAN-Shields and I set up one as NMEA2000 sender, the other as receiver (I had to comment if (CanInUse) return false; inside CANOpen()) for this.

I successfully received NMEA2000 messages sent from the other shield.

[ttlappalainen]

The sentence "I did not do much testing!" does not promice good. Now you forget that you broke compatibility to version under my Git, which has been tested to work with NMEA2000. Have you checked that Seeed library handles NMEA2000 fast packets right? This is most common error in CAN drivers, that they do mix fast packet frames. That is the case also with with older version of Teensy FlexCAN, for which reason I prefer to use only FlexCAN from my Git.

Two main requirent for accepting pull requests are

1. It must be tested. For drivers most important is:

• Message receiving
• Message sending
• Fastpacket sending must always sent frames in order. This is a bit difficult to test and requires bus analyzing.
• Interrupt handling

2. It must be down compatible

This does not fill any of those.

[dhopf]

Thank you for the feedback and instructions. I understand that I can try basic Message receiving and sending with the examples provided with your NMEA2000 lib.
Interrupt handling should also be possible to be testetd if I decide to run the examples with interrupts enabled?

Regarding fastpacket sending you mean that I likely will not be able to test this with a limited setup I have here (3x MCP2515 CAN-Shields, 1x Teensy3.2)? In addition, I have NMEAReader and NMEASimulator on my Dev PC. Do you think I could manage to verify fast packet sending with that?

[ttlappalainen]

There is no sense to run NMEA2000 in any other than with interrupts enabled. Interrupts disabled is only for testing purposes.

For testing you need some devices.

1. Sender, which in this case must be MCP2515, since it is under tests. It must send fp and single messages and report all successfully sent fp and single messages. Test program should send at least 3 fp and 3 single different priority messages in one loop so that they will be buffered. Next send should be waited at least until all frames has been sent. Since there is no function to see, when buffer is empty, one way it so calcluate minimum time for resent. Bus can handle in max. 2500 frames/s.
2. Receiver I prefer at least Teensy 3.2. This should report received fp and single messages sent from test device.
3. Bus filler. Device, which just fills bus with messages. E.g. MessageSender.

You should also thnk how backward combatibility will be solved.