NMEA2000_CAN.h and STM32F1

[KimBP]

I'm trying to port my NMEA2000 application to an STM32F1 in order to get a little more resources.

I get a compile error due to include of MapleIntCompatibility.h in NMEA2000_CAN.h (added in commit 918c0d6)

Is this file supposed to come from another library or is it a file simply never committed to this library?

[ttlappalainen]

Newer added. I'll need to ask content of it, since it has been developed by other person.

What about your fork for my NMEA0183 library? You have there e.g. on NMEA0183.h:
};
bool SendMessage(const unsigned char *buf);
void kick();
So function definitions are after class definition has been closed. That does not compile. There were several other things, which causes error in compilation, so I had to revert your fork push.

• Please update you fork with files that are fully tested both compilation and functionality and send push request again.
• As default it is not possible to open issues for forked repositories. So please go to your forked NMEA0183 repository "Settings" and tick "Issues".
• Note that you do not need to fork libraries, if you are not going to change them ad make push request. The problem with just forking is that then you also should keep all you forks updated to master. Otherwise someone may find you fork, which may be old and have some issues fixed on master.

[KimBP]

OK - but you are committer of the issue :-)

Regarding my NMEA0183 fork. Yes it kind of died for a while. I'm working at it again now. Sorry for pushing errors. You should just have commented on the PR directly.and not merged it. In the original issue (in NMEA0183 repo) I've commented a little more.
Regarding your comments about no need to fork: I can't see how I can make pull request (you write about push request which I am not aware of) without having a repo the master can pull from.
Furthermore I see local forks as a means to actually backup my work - even though it might not always be fully working. Hopefully anyone who come across my forks will also have a look at the origins

[ttlappalainen]

The problem was that when you send PS, I thought it is OK and just merged it. This definetely will not be the way in future - I have to test code before merging. But that causes extra work to test others changes too.

If you need to do changes and PR, then you need a fork. But just for backup I am not so sure. I just some weeks a go helped someone with the case where his code worked fine on my lab but not on his device due to old versions. So it is not so sure that folks will find right version.

[thomasonw]

Hello - just a quick note, I too am interested in porting the NMEA2000 lib to the STM32 line of CPUs, am targeting the ST32F072 for now.

@KimBP I am looking to use the MBED libs as the basis, what IDE target are you using? We should perhaps coordinate efforts : - )

[KimBP]

I don't know MBED libs. Will have a look at it (developer.mbed.org I suppose).
What do you mean by IDE target? Are you just thinking IDE as in Integrated Development Environment?
The few hours I've spend so far on ST32F has been with the Arduino IDE. Got the impression the CPU was better supported than it seems to be.
I certainly would prefer to be working in Eclipse - and basically go for 'normal' builds. I.e. no fancy magic like it has been done in the Arduino domain.

[thomasonw]

@KimBP - Hello again, after a bit of digging, it seems you are targeting the mapleLeaf environment. (You are correct, IDE is the wrong word to use - it really is the underlying libs and environment).

I think mapleleaf is not a good choice, as it was EOLed last year: "...As of March 2015, the LeafLabs Maple line and the libmaple library are end-of-life and no longer supported ..." (ref: http://www.leaflabs.com/maple/, https://github.com/leaflabs/libmaple)

STM32 would be a great addition to NMEA2000, but we should think about which basic lib to target. Three prime candidates I know of include:

• STM32dinu http://www.stm32duino.com/
• MBED https://www.mbed.com/
• STMicro http://www.st.com/en/embedded-software/stm32-standard-peripheral-libraries.html

I think each has their ++ and --, and the STM32duni likely would be the simplest port. However, it does not include support for the STM32 'F0' line of CPUs, which is why I started looking at MBED. Another consideration: MBED is the official ARM environment, with full industry backing - while ST32duino has wide support - it is not in the main factory release. I have not considered the STMicro libs too much, largely because of the work needed to allow users to get that environment up and usable.

Myself, I am not really keen on the MBED online IDE, and am looking to use Keil instead - as there is a free license for the F0 CPUs, or perhaps PlatformIO - as it has wider CPU support. But in either case am thinking to use the MBED core libs. And I think the NMEA2000 port should look to support all the STM CPUs F0..F4 (as best we as can : -)

[thomasonw]

@KimBP Hey, question: Are you looking to use an STM32 CPU's with a built-in CAN controller, or an external controller (ala, the MCP2515) attached via SPI? Looking at your submission, seems to be the latter.

@ttlappalainen: I have spent a couple of hours doing a rough compile-n-see test to get an idea what might be needed to bring the NMEA2000 lib to support outside Arduino. Overall, most of what I have seen is taking out some of the Arduino 'specials' and move more to standard C. Like replacing byte with say uint8_t , and all those special PROGMEM qualifiers I had you put in! -- not too hard, mostly can be done transparently using macros. Have come to one issue though, the support of print() and println() with streams in 'standard' C... I think there might well be a bit of work,

Figured better get some conversation going before doing too much more.

[KimBP]

Yes I am aiming for an ArctiSense alike device supposed to be build using 4 cheap ebay devices: An ST32F103, a SPI MCP2515, an RS485 device and a12V to 5V converter. Initially I went for an Arduino Mini Pro.

I've also considered going for a little linux based board, like maybe Raspberry PI, but think the total price then comes too close to the ArctiSense.

If we can somehow make the library more generic from a platform point of view I think that would be very nice.

[ttlappalainen]

For you original question about missing MapleIntCompatibility.h I have not got response. I have code snipped on my mail:
class SREGemulation
{
public:
operator int () const attribute((always_inline)) {
uint32_t primask;
asm volatile("mrs %0, primask\n" : "=r" (primask)::);
if (primask) return 0;
return (1<<7);
}
inline SREGemulation & operator = (int val) attribute((always_inline)) {
if (val & (1<<7)) {
interrupts();
} else {
noInterrupts();
}
return *this;
}
};
extern SREGemulation SREG;

inline unsigned char  digitalPinToInterrupt(unsigned char Interrupt_pin) { return Interrupt_pin; }

#define sei() interrupts();
#define cli() noInterrupts();

Please try that. If it works, pull missing file. Instead of #define sei() interrupts(); I prefer inline void cli() { nointerrupts(); }

Generic platform would be interesting, since e.g. with Rapsberry you can run Open CPN so it could do a lot. On the other hand there is already converter under SignalK for Rasberry.

[thomasonw]

Generic platform: I know of a few project that are NMEA2000 listeners, some (like CANBOAT and OpenSkipper) use the Actisense NGT-1 device, another I see (VYacht) does have some NMEA2000 CAN code, but it looks to be a listen only. Do you know of another full J1939 open-source based stack out there?

I started editing a fork of this project, and have ran into a rather large issue: print() and println() from the Arduino libs seem to be non-standard, and are not supported outside Arduino. To complicate this, Arduino does not extend printf to their streams class --- so, it seems a rock and a hard place given how the serial messages are currently coded. @ttlappalainen, I think if you are interested in moving to a wider target am going to need your help here : - ) Let me know what your thoughts are.....