ttlappalainen / nmea2000_mcp Goto Github PK

Hi, greate Project!
While trying the libs for an ESP8266 i got an Error, that SREG is not defined in NMEA2000_mcp.ccp.

After defining uint8_t SREG; the compiler fond no errors and the connectin starts. But i´, not so deep in it, to understand, what SREG is realy for....
Using Arduino 1.6.12
Best Regards,
Christian

I use the Arduino MKR Zero (SAMD21 Cortex-M0+ based) and the MKR Can shield (MCP2515 based) with your librarys.
The hardware works, I can read NMEA2000 packets interpreted as standard can extended packets using a can library.

I used the Actisense Listener example provided with the library, and only put these lines before including anything for configuring the MCP2515 correctly:
#define USE_N2K_CAN 1
#define N2k_SPI_CS_PIN 3
#define N2k_CAN_INT_PIN 7
#define USE_MCP_CAN_CLOCK_SET 16

The compiler was not able to compile NMEA2000_mcp.cpp for the ARM, because it has no SREG, so I commented it out. I also had to replace cli() and sei() with noInterrupts() and interrupts().
Then I was able to compile it, but I did not receive any messages. I think the changes I made are not complete.

Has anyone tried it with the MKR Zero and CAN Shield yet? I think this would be the perfect hardware.

Hello,

when I try to compile for ESP8266 get

In file included from /Users/master/Documents/Arduino/libraries/NMEA2000/src/NMEA2000_CAN.h:144:0,
from /var/folders/p_/j24qpcws45d_0kzx14mtvdrm0000gn/T/arduino_modified_sketch_357838/BatteryMonitor.ino:15:
/Users/master/Documents/Arduino/libraries/NMEA2000_mcp/NMEA2000_mcp.h: In member function 'bool tNMEA2000_mcp::tFrameBuffer::AddFrame(long unsigned int, unsigned char, const unsigned char*) volatile':
/Users/master/Documents/Arduino/libraries/NMEA2000_mcp/NMEA2000_mcp.h:98:20: error: no matching function for call to 'min(unsigned char&, int)'
len=min(len,8);
^
/Users/master/Documents/Arduino/libraries/NMEA2000_mcp/NMEA2000_mcp.h:98:20: note: candidates are:
In file included from /Users/master/Library/Arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/1.20.0-26-gb404fb9-2/xtensa-lx106-elf/include/c++/4.8.2/algorithm:62:0,
from /Users/master/Library/Arduino15/packages/esp8266/hardware/esp8266/2.4.1/cores/esp8266/Arduino.h:254,
from /var/folders/p_/j24qpcws45d_0kzx14mtvdrm0000gn/T/arduino_modified_sketch_357838/BatteryMonitor.ino:11:
/Users/master/Library/Arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/1.20.0-26-gb404fb9-2/xtensa-lx106-elf/include/c++/4.8.2/bits/stl_algo.h:4226:5: note: template<class _Tp, class _Compare> _Tp std::min(std::initializer_list<_Tp>, _Compare)
min(initializer_list<_Tp> __l, _Compare _comp)
^
/Users/master/Library/Arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/1.20.0-26-gb404fb9-2/xtensa-lx106-elf/include/c++/4.8.2/bits/stl_algo.h:4226:5: note: template argument deduction/substitution failed:
In file included from /Users/master/Documents/Arduino/libraries/NMEA2000/src/NMEA2000_CAN.h:144:0,
from /var/folders/p/j24qpcws45d_0kzx14mtvdrm0000gn/T/arduino_modified_sketch_357838/BatteryMonitor.ino:15:
/Users/master/Documents/Arduino/libraries/NMEA2000_mcp/NMEA2000_mcp.h:98:20: note: mismatched types 'std::initializer_list<_Tp>' and 'unsigned char'
len=min(len,8);
^

I have a strange problem with a NMEA2000 device built with STM32F103 "blue pill" and MCP2515 board:
The device disappears from the bus when another device sends for the first time.

The device does not re-appear (start sending) when other devices disconnect or stop sending.

Code is taken from the example "MessageSender".

A dump of the NMEA2000 data looks as follows:
candump can0 | candump2analyzer | analyzer -raw

INFO 2019-07-18T09:24:53.873Z [analyzer] Assuming normal format with one line per packet
INFO 2019-07-18T09:24:53.873Z [analyzer] New PGN 60928 for device 15 (heap 10383 bytes)
2019-07-18-09:24:53.873 6  15 255  60928 ISO Address Claim:  Unique Number = 0x539; Manufacturer Code = ERROR; Device Instance Lower = 0; Device Instance Upper = 0; Device Function = 132; Device Class = Internetwork device; System Instance = 0; Industry Group = Marine
2019-07-18-09:24:53.873 6 015 255  60928 : 39 05 c0 ff 00 84 32 c0
INFO 2019-07-18T09:24:54.123Z [analyzer] New PGN 126993 for device 15 (heap 10398 bytes)
2019-07-18-09:24:54.124 7  15 255 126993 Heartbeat:  Data transmit offset = 600.00 s; Sequence Counter = 0
2019-07-18-09:24:54.124 7 015 255 126993 : 60 ea 00 ff ff ff ff ff

Now another device is switched on (here an ESP32 with WindMonitor example, but Garmin GPSmap behaves similar):

2019-07-18-09:27:45.261 2  15 255 129026 COG & SOG, Rapid Update:  SID = 1; COG Reference = True; COG = 115.6 deg; SOG = 0.10 m/s
2019-07-18-09:27:45.261 2 015 255 129026 : 01 fc d0 4e 0a 00 ff ff
INFO 2019-07-18T09:27:45.415Z [analyzer] New PGN 60928 for device 23 (heap 21163 bytes)
2019-07-18-09:27:45.415 6  23 255  60928 ISO Address Claim:  Unique Number = 0x1; Manufacturer Code = ERROR; Device Instance Lower = 0; Device Instance Upper = 0; Device Function = 130; Device Class = External Environment; System Instance = 0; Industry Group = Marine
2019-07-18-09:27:45.415 6 023 255  60928 : 01 00 c0 ff 00 82 aa c0
INFO 2019-07-18T09:27:45.665Z [analyzer] New PGN 126993 for device 23 (heap 21178 bytes)
2019-07-18-09:27:45.666 7  23 255 126993 Heartbeat:  Data transmit offset = 600.00 s; Sequence Counter = 0
2019-07-18-09:27:45.666 7 023 255 126993 : 60 ea 00 ff ff ff ff ff
INFO 2019-07-18T09:27:46.415Z [analyzer] New PGN 130306 for device 23 (heap 21193 bytes)
2019-07-18-09:27:46.416 2  23 255 130306 Wind Data:  SID = 1; Wind Speed = 10.30 m/s; Wind Angle = 50.0 deg; Reference = Apparent
2019-07-18-09:27:46.416 2 023 255 130306 : 01 06 04 17 22 02 ff ff
2019-07-18-09:27:47.417 2  23 255 130306 Wind Data:  SID = 1; Wind Speed = 10.30 m/s; Wind Angle = 50.0 deg; Reference = Apparent
2019-07-18-09:27:47.417 2 023 255 130306 : 01 06 04 17 22 02 ff ff

Transmission of the MCP2515 MultiSender device is now stopped and device is not visible to others on the bus.

Debugging the STM32 shows that the device is still live under this condition:
I have set 3 breakpoints in tNMEA2000_mcp::InterruptHandler()

1. if ( (frame=pRxBuffer->GetWriteFrame())!=0 ) {
2. if ( (status=N2kCAN.checkClearTxStatus(&tempRxTxStatus,N2kCAN.getLastTxBuffer()))!=0 ) {
3. while ( (status=N2kCAN.checkClearTxStatus(&tempRxTxStatus))!=0 && ...

As soon as another device is active on the bus, only breakpoint 1 kicks in.
Code in Breakpoints 2 and 3 are not reached any more, and no sending takes place.

I also tried with NMEA2000.EnableForward(false); , to make sure it is not a problem with blocking output of forwared data, but no change (also USB disabled).

MCP2515 and STM32F103 is an awkward combo, but I had no other STM32 laying around which is capable of both CAN and USB.

It would be great if somebody had some hints or fixes to my problem...

Hi Timo,

Maybe I am fool, rookie for sure :-)

\Arduino\libraries\NMEA2000_mcp-master\NMEA2000_mcp.cpp: In constructor 'tNMEA2000_mcp::tNMEA2000_mcp(unsigned char, unsigned char, unsigned char, uint16_t)':

\Arduino\libraries\NMEA2000_mcp-master\NMEA2000_mcp.cpp:71:20: error: cannot convert 'tNMEA2000::tCANFrame_' to 'volatile tCANFrame_' in assignment

   rx_frame_buff=new tCANFrame[rx_frame_buf_size];

                ^

Cheers

Hi. I've just been testing Longan CANBed 2040 board with integrated mcp2515. It didn't worked because https://github.com/ttlappalainen/CAN_BUS_Shield/blob/master/mcp_can.cpp -> MCP_CAN::mcp2515_read_canMsg() lacks SPI_HAS_TRANSACTION handling. All need to be done is adding SPI_BEGIN/END around:

#ifdef SPI_HAS_TRANSACTION
SPI_BEGIN();
#endif
MCP2515_SELECT();
...
MCP2515_UNSELECT();
#ifdef SPI_HAS_TRANSACTION
SPI_END();
#endif

Apparently original SeedStudion library has the same problem. But it is specifically for their board while MCP_CAN probably can handle any board with mcp2515 (I have been testing it with Arduino Nano Every + cheap MCP2515 CAN module as well as with RPi Pico + Waveshare RS485 CAN HAT).

And by the way - big thank you @ttlappalainen for the great job! It gave me a lot of inspiration and help.
I hope my comment will help somebody too ;).