search

ttlappalainen / NMEA2000

NMEA2000 library for Arduino
514 stars 211 forks source link

NMEA2000_CAN.h and STM32F1 #28

Open KimBP opened 7 years ago

KimBP commented 7 years ago

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 918c0d6ba319cde536def6bb3af8d14e4dc2a937)

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

ttlappalainen commented 7 years ago

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.

KimBP commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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:

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.....