denravonska commented 7 years ago

I know this library was written with Arduino in mind, but I think that with some smaller modifications it could be made platform agnostic. Have a look at my suggestions and let me know what you think. I can fix these in my fork and submit a pull request.

Remove Arduino.h includes.
Replace bit operations with shifts. B00000100 becomes (1 << 2).
Move debug print operations to a separate N2kDebug.h/cpp.
Replace bracket includes with quotation includes for local files (merely cosmetic, but I got a compiler warning. #include <N2kMessages.h> becomes #include "N2kMessages.h".
Replace lowByte/highByte with shift operations. highByte(v) becomes (v >> 8) & 0xFF.
Leave millis() as it is and declare it external where it's used. This and CAN would be the application requirements. On Arduino it should work as-is while other platforms can wrap their own clock inside their millis function.
Functions which just want a Stream to read from or write to could accept functors instead.

The examples would remain Arduino and no sketches would be modified. It's just the source that would need some massaging for non-Arduino users.

ttlappalainen commented 7 years ago

Hi,

Thanks for comments. I'll about them. There has been discussion about same thing within othe issue.

denravonska commented 7 years ago

I got it working on AVR32 with most of the changes above. What I haven't solved yet is how Stream should be replaced or wrapped. The debug uses could perhaps be removed and handled by the application instead. That leaves the forward stream in NMEA2000.cpp (also a debug tool?) and the SendInActisenseFormat function which only uses the write portion of Stream, unless I'm missing something. That could be replaced with a function pointer.

thomasonw commented 7 years ago

Hello - as ttlappalainen commented, I too have been working on 'normalizing' the current NMEA2000 lib - targeting the STM32 line of CPUs, presently using the MBED environment. Refer the last post in issue #28 Was not too hard to back out the Arduino specifics, and/or make compile time subs for them. But how to deal with the printing is a major issue (Currently I have simply commented them out).

So - going forward: It seems very achievable to bring the current lib into a more common C standard (And Timo, I am not aware of ANY other open-source full J1939 stack. Most the other NMEA2000 projects seems to rely on a Actisense reader, or are simple read-only - ala the Ford motor company effort). @ttlappalainen, are you interested in doing this? How should the printing be handled?

ttlappalainen commented 7 years ago

Note that denravonska is working with this. Some changes has been already published and some is on his table.

denravonska commented 7 years ago

@thomasonw I have also fixed everything but the serial I/O. I have a solution for this but I'm not too happy with it since it forces the user to implement a bridge on the Arduino end to bridge the library and an Arduino Stream class:

class ArduinoN2kStreamBridge : public N2kStream {
public:
  ArduinoN2kStreamBridge(Stream& stream)
    : stream(stream) {
  }

  int read() {
    return stream.read();
  }

  size_t write(const uint8_t* data, size_t size) {
    return stream.write(data, size);
  }

  Stream& stream;
} StreamBridge(Serial);

We might not have much of a choice though. I'll keep working on it.

denravonska commented 7 years ago

@thomasonw Could you try my branch on your platform? https://github.com/denravonska/NMEA2000/tree/portability-fixes As long as you don't use the stream functionality you don't have to implement N2kStream.

ttlappalainen commented 7 years ago

Hi,

First I can not download the library. It complains "Uploads are disabled. File uploads require push access to this repository". Second I need N2kStream, since testing everything through, I'll use ForwrdStream. So How I should implement it?

Timo

6.12.2016, 9:11, Marco Nilsson kirjoitti:

@thomasonw https://github.com/thomasonw Could you try my branch on your platform? https://github.com/denravonska/NMEA2000/tree/portability-fixes As long as you don't use the stream functionality you don't have to implement N2kStream.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ttlappalainen/NMEA2000/issues/33#issuecomment-265077790, or mute the thread https://github.com/notifications/unsubscribe-auth/AM4-ZSfXPLFHC7LrfZJcDec_LDTE6p4Hks5rFQq2gaJpZM4K5Hr9.

denravonska commented 7 years ago

@ttlappalainen You can use "Clone or download" to download a zip that can be imported to the Arduino IDE. If you want to test the lib on Arduino you do not have to implement N2kStream. It works as it does in your repo: NMEA2000.SetForwardStream(&Serial);. The interface just "happens" to look the same as the Arduino Stream interface ;)

thomasonw commented 7 years ago

Hello - so, overall there are perhaps three of challenges here to bring the current NMEA2000 lib into a more portable 'ANSI C' styles:

Using more common 'C99' conventions. Ala, u8int_t vs. byte, 0x01<<3 vs B00000100, lowByte()... - this is somewhat simple and I think Danravonska you have many of them.
Backing out the AVR specifics. Mostly macros for PROGMEM, and the associated _P() funcitons. I think some are covered, but a few more are needed. Again, rather achievable.
Deal with printing.

This last one is tough. The issue is fundamentally: Arduino IDE uses print() and println() for their streams, while more common C used printf()...

For my testing I have been using the MBED environment, which I believe targets a C99 variant. And it is the print() and println() that is the show-stopper and what needs the most thought.

@denravonska : I downloaded your edits, but there are still several items in points 1 & 2 above to be addressed. Rather then create yet-another-forlk of the NMEA2000 lib, the attached .ZIP file is my current edits inside the MBED environment. (Note that I have simply commented out all printing..) I still do not have a clean compile (there are a few warnings), and still need to do work around the basic CAN support for the STM32F0 line of CPUs. But maybe this will give another idea of some of the other issues.

But more so: How to address print() and println() vs. printf()... THAT is the big issue here I think.

NMEA2000-ANSI_C-12-6-2016.zip

denravonska commented 7 years ago

I have print and println covered in my branch, at least from the testing I've done. My idea was to get the portability stuff out of the way now and do minimal changes to the lib itself to get a stable foundation. Then we could focus on the internals. My idea was to tweak the N2kStream interface into maybe an N2kIO containing the following functions:

read
write
log

That way you can have the read and write handle the actual data while log takes care of debug logging. The logger could do printf syntax (log(const char* fmt, ...);). If your app does not need logging you could simply discard the log data.

Anyway, that was my idea. Minimal changes now to avoid modifications in the applications, restructuring later.

Edit: Actually, the lib builds for AVR32 and Arduino now. As soon as someone with hardware could test it on Arduino we could merge it. I haven't fixed any warnings though.

thomasonw commented 7 years ago

So you did! (Sorry, had not even finished the 1st cup of coffee yet). Still some things with PROGMEM (And a few other small details), but they can be simply addressed. Later today / tomorrow I will see that the MBED compiler does with your edits, and also check them against my current ATmega64M1 port. Will let all know what happens.

denravonska commented 7 years ago

@thomasonw The progmem thingys should be fixed in https://github.com/denravonska/NMEA2000/commit/6cf0e290d47f84c28eafa88e9c4f79eb0b2ab43e :) I'm all for fixing the rest. Once @ttlappalainen gives the PR a go, could you add your change requests to it?

denravonska commented 7 years ago

Wait, the progmem is not fixed at all. I'll get right to it.

Edit: Well, it will work for Arduino but not for AVR in general.

denravonska commented 7 years ago

I have pushed some additional fixes to my branch covering missing itoa implementations and additional PROGMEM support. I'm not too keen on this whole #ifdef situation, but it's inevitable to keep compatibility with Arduino, stray AVR8 and the rest. I have no solution for it in mind though.

thomasonw commented 7 years ago

Hello. Thanks for the work! Quick scan, did notice a few #ifdef AVR, as well as abstraction of the avr type capabilities (e.g., PROGRAM being redefined as CDATA.) Think a different way might be to simple define the AVR specifics to null out on non AVR machines, ala:

define PGM_P const char *

#define PSTR(str) (str)
#define memcpy_P(dest, src, num) memcpy((dest), (src), (num))
. . . .

Then the main code can remain clean, as well as keep the historical 'Arduino/AVR' names for things like PROGMEM in place.

Just an idea.

Will play some with the latest edits and see what happens.

denravonska commented 7 years ago

@thomasonw Ah, that could be an option. My approach was to be able to use the same capabilities on non-AVR platforms. It could be that it's too much of an AVR thing as I haven't seen it elsewhere. I'll try your suggestion out and see how she rolls.

denravonska commented 7 years ago

@thomasonw Fixed now. I don't like how it enforces the paradigms of one platform on the rest, but you are right that it is a whole lot cleaner and easier.

I couldn't get away from the ifdef in N2kStream since we will want to print constant strings on non-Arduino (but still AVR) targets.

thomasonw commented 7 years ago

@denravonska -- Today I was able to get a clean compile of your edits mocking up an ActisenseReader demo function under the MBED environment with only these changes: 1) Adding functions for millis() and delay() using MBED calls. 2) Replacing round() with floor()

It seems round() is not well supported, even in C99 'compatible' compilers/libs – I am thinking switching to floor() will not cause that many issues?

I have not yet finished a full working example of the reader demo under MBED using the STM32F07, but perhaps it is close. (FWIW, I am not at all impress with the web based MBED – no debug, VERY limited editor, on-line linked error ‘help’ tends to simply say “Fix It”. Plus, I have been locked out more than once with their online tools being not available or malfunctioning. ) If I have time the rest of the week I will work to get something functional, but we are looking to head out of town Saturday for the rest of the month – so not sure how much time I will have. But I will also try the modified lib under a Keil uVision, using its compiler and libs to see if any other portability issues come up - at least to the point of a clean compile...

@ttlappalainen - At this point where do you want to go with all this. It seems there is a proof here of the ability to have a bit more portability. Is this something you would like to move the main lib towards? If so, I think there are some coding style selections that you should look at - and perhaps if you want to look over everything and decide on a way to go that would be best?

Also - I think the NMEA2000_CAN.h file could get very messy quickly. Even now there seems to be two different directions for STM32 support, one using the stm32duino.com approach (the include.) And myself looking at MBED libs for the STM32F0. I might suggest: perhaps it is best to reserve the NMEA2000_CAN.h file only for true Arduino ports, or very-close ones like the stm32duino effort. For ports like my MBED, or Danravonska's targeting the basic Atmel AVR environment (I am assuming that is what you are doing). Maybe it is best to make us use the NEMA2000 libs the old way, without the NMEA2000_CAN.h file.

OK, tt - what all do you think of this..

thomasonw commented 7 years ago

denravonska commented: My approach was to be able to use the same capabilities on non-AVR platforms. It could be that it's too much of an AVR thing as I haven't seen it elsewhere. I'll try your suggestion out and see how she rolls.

Ya, I know the AVR uCs need things like PROGMEM as they use totally different address spaces / access methods for FLASH/RAM. While with the ARM CPUs the address space is unified, and I think simple compiler clues such as const are sufficient to keep from repeating data in RAM..

denravonska commented 7 years ago

@thomasonw Oh, yeah, round seems to be a thing of the past. We can change it to floor(val + 0.5f); for the same result. I'll push a fix for it today, or will you after the PR?

Regarding NMEA2000_CAN, I don't use it in AVR32 at all and it doesn't get in the way (by sheer luck?). My setup is:

class Nmea2000Reader : public tNMEA2000 {
   IO::ICanBusPtr m_Can; // My CAN driver
   ...
};

I suppose the NMEA2000_CAN is to allow the user to switch boards without having to change drivers, correct?

thomasonw commented 7 years ago

@denravonska NMEA2000_CAN.h: Yes, idea is to do auto-select. The 'Old Way' is how you are doing it.

So, some more news Good and Bad. Just now I did some testing on my existing ATmega64M1 project. Using you lib I was able to compile, and the code size was reduced by around 10 bytes! (Always good). However, I was testing with debug enabled and no CAN connection - so I should be seeing error messages in the serial stream along the lines of: PGN 131069 send failed PGN 131068 send failed

However, I do not... So, there is something amiss with the serial out handling... Program does not hang, and other serial functions continue to work - just am not seeing the error messages from the NMEA2000 lib when placed into debug mode via:

     _NMEA2000.SetForwardType(tNMEA2000::fwdt_Text);                                // Send error and status messages to the Serial port._

Sorry, and turning in for the night now. If I get time tomorrow I will see if I can figure out anything - or maybe you will find something before then.

ttlappalainen commented 7 years ago

I definetely like portability!

I see the Arduino system is meant for simple startup for almost with no programming skills. So this is also why I made NMEA2000_CAN.h to keep startup simple and independent what board one uses. So I do not see it as problem to have different method for more embedding systems. So for Arduinos I would like to keep compatibility.

ttlappalainen commented 7 years ago

The inherited class CANSendFrame should return false, if it can not send frame and the send buffer becomes full.

ttlappalainen commented 7 years ago

Hopefully you did not use NMEA2000.SetDebugMode(tNMEA2000::dm_ClearText); or .. dm_Actisense); since with that it never tries to use CANSendFrame

thomasonw commented 7 years ago

Here is my startup code. DEBUG is defined, and I am able to see status / error messages in the serial stream with the original lib. Do you see anything wrong here?


bool initialize_CAN(void) {

        NMEA2000.SetProductInformation(&AltRegProductInformation );                     // Define Product information

        NMEA2000.SetDeviceInformation(1,                                                // Unique number. Use e.g. Serial number.
                                      141,                                              // Device function=Alternator. See codes on http://www.nmea.org/Assets/20120726%20nmea%202000%20class%20&%20function%20codes%20v%202.00.pdf
                                       50,                                              // Device class=Propulsion.    See codes on  http://www.nmea.org/Assets/20120726%20nmea%202000%20class%20&%20function%20codes%20v%202.00.pdf
                                     1401                                               // Manuf Code: Just chose free from code list on http://www.nmea.org/Assets/20121020%20nmea%202000%20registration%20list.pdf
                                     );

        // NMEA2000.SetSingleFrameMessages(SingleFrameMessages);                           // Register our extended list of messages we will accept.
        // NMEA2000.ForwardOnlyKnownMessages(false);                                       // Have the NMEA2000 lib send us ALL non-system messages, we will sort out which ones we want to deal with.
                                                                                        //  WAIT, This is the DEFAULT setting!  So - - -  Do not really need to call this. 
        #ifdef DEBUG
          NMEA2000.SetForwardType(tNMEA2000::fwdt_Text);                                // Send error and status messages to the Serial port.
          #endif

        NMEA2000.SetMode(tNMEA2000::N2km_NodeOnly,128);                                 // Configure for normal node, start looking for dynamic addresses @ 128 (Preferred "Power Components" range in RV-C spec)
        NMEA2000.EnableForward(false);                                                  // Do not forward CAN messages to the Serial port.
        NMEA2000.SetN2kCANMsgBufSize(2);                                                // Define only 2x reception buffers - should be sufficient.
        NMEA2000.SetMsgHandler(handle_CAN_Messages);                                    // Callback function NMEA2000.ParseMessages() uses when a CAN message is received.
        NMEA2000.SetISORqstHandler(handle_CAN_Requests);                                // Callback function NMEA2000.ParseMessages() uses when an ISO Request is received.
        NMEA2000.Open();                                                                // And start up the CAN controller.

        return(true);
}

ttlappalainen commented 7 years ago

Looks OK.

So with same code you get errors from my current master lib, but not from the "portable" lib under development?

Could it be something with new N2kStream implementation?

denravonska commented 7 years ago

@thomasonw Serial is no longer the default forward stream. I had to remove that in order to remove the Arduino dependency. You can set it using NMEA2000.SetForwardStream(&Serial);.

thomasonw commented 7 years ago

@denravonska ok! (Still up, but not for long). That solved it. Portable lib now sending out messages. Will leave it between you and ttlappalainen on the change to the API : - )

Overall good job! Looking forward to getting things polished up and into the main lib.

denravonska commented 7 years ago

I pushed a fix regarding the non standard round() function (or macro on Arduino). It compiles for me on AVR32 and in the Arduino IDE but it could be good if someone else gave it a shot.

@ttlappalainen Are you ok with dropping Serial as the default forward stream?

ttlappalainen commented 7 years ago

I'll test it later - maybe goes tomorrow.

It is ok dropping serial. We just need to mention it on changes.

thomasonw commented 7 years ago

@denravonska : Just a question, if one does NOT initialize the serial stream using MEA2000.SetForwardStream(&Serial); will the code behave nicely? Is there a check for non-initialization before trying to priny (I know, I know, I could look myself - but figure you would have the answer right away!)

denravonska commented 7 years ago

@thomasonw It's initialized to NULL in the constructor and checked before being used, but I'll double check all the usage locations.

thomasonw commented 7 years ago

@denravonska on NULL printing, great.

This morning I did a trial compile of the portable lib - the version from perhaps two hours ago - under Keil's uVision IDE ver 5, and had good results. A few notes:

In N2kCANMsg.h changed #include to #include "N2kMsg.h"
In N2kMsg.h added: #include

This left only one compile error:

..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000.h(79): error: #3093: anonymous structs are only supported in --gnu mode, or when enabled with #pragma anon_unions

When I added the following to NMEA2000.h, I was able to get a clean compile

pragma anon_unions

However, this I think becomes somewhat target specific : - )

================================ As near as I can tell, the Keil v5 environment uses C99 / C++2003, and the 'libs' I uses were the STM32 standard 'Cube' HAL-libs. Outside of the two small edits it seems only the anonymous union is a problem for this 'portable' target. (And again, this is ONLY a clean compile - still not to the point to testing the actual code..)

denravonska commented 7 years ago

@thomasonw Interesting. We better de-anonymize that struct. What happens if you change NMEA.cpp:79 from }; to } details; and remove the pragma? Does the build go through now that the struct is named?

thomasonw commented 7 years ago

It no longer objects to the tUnionDeviceInformation definition (as expected), but of course almost everything else blows up! (again, as expected).

thomasonw commented 7 years ago

OK, could use some help here - continuing to create a functional port, I am having issues with the 'bridge' files to provide support for:

bool CANSendFrame(unsigned long id, unsigned char len, const unsigned char *buf, bool wait_sent);
bool CANOpen();
bool CANGetFrame(unsigned long &id, unsigned char &len, unsigned char *buf);

The two attached files are modeled after the other code, ala the due and the one I have working for the ATmega64M1. At this point I have just commented out much of it, as I am having issues just compiling the basic framework. Here are the error messages from the Keil compiler:

compiling NMEA2000_stm32.cpp... ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.h(42): warning: #1300-D: CANSendFrame inherits implicit virtual bool CANSendFrame(unsigned long id, unsigned char len, const unsigned char *buf, bool wait_sent); ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.h(43): warning: #1300-D: CANOpen inherits implicit virtual bool CANOpen(); ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.h(44): warning: #1300-D: CANGetFrame inherits implicit virtual bool CANGetFrame(unsigned long &id, unsigned char &len, unsigned char *buf); ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.cpp(38): error: #276: name followed by "::" must be a class or namespace name tNMEA2000_smt32::tNMEA2000_smt32() : tNMEA2000() { ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.cpp(38): error: #260-D: explicit type is missing ("int" assumed) tNMEA2000_smt32::tNMEA2000_smt32() : tNMEA2000() { ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.cpp(38): error: #130: expected a "{" tNMEA2000_smt32::tNMEA2000_smt32() : tNMEA2000() { ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.cpp(39): warning: #940-D: missing return statement at end of non-void function "tNMEA2000_smt32" } ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.cpp: 4 warnings, 3 errors

I also get like complaints from MBED. Any ideas / hints here?

NMEA2000_stm32.zip

denravonska commented 7 years ago

@thomasonw You have a very picky compiler. It requires the functions to be declared virtual when they are virtual in the parent. That should probably fix the rest of the errors as well.

thomasonw commented 7 years ago

@denravonska Thanks, that took care of the implicit victuals. Any idea about:

tNMEA2000_smt32::tNMEA2000_smt32() : tNMEA2000() { }

I am still getting compiler errors:

..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.cpp(38): error: #276: name followed by "::" must be a class or namespace name tNMEA2000_smt32::tNMEA2000_smt32() : tNMEA2000() { ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.cpp(38): error: #260-D: explicit type is missing ("int" assumed) tNMEA2000_smt32::tNMEA2000_smt32() : tNMEA2000() { ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.cpp(38): error: #130: expected a "{" tNMEA2000_smt32::tNMEA2000_smt32() : tNMEA2000() { ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.cpp(38): warning: #940-D: missing return statement at end of non-void function "tNMEA2000_smt32" } ..\..\..\..\Desktop\NMEA2000-portability-fixes\NMEA2000_stm32.cpp: 1 warning, 3 errors

If I comment out that line, I am able to get a clean compile/link - have to admit, I am not fully sure what that line is trying to do... @ttlappalainen can you help?

denravonska commented 7 years ago

That one calls the constructor of the parent, but it's called anyway so you can remove it.

thomasonw commented 7 years ago

Well, that did not work - caused linking errors. However, making sure I had the correct spelling did solve all! have compiled / linked / uploaded in MBED. Compiled/linked in Keil. Still more to do, ActisenseReader demo is not running yet. But closer...

(BTW, I think doing a test for Raspberry Pie would be worthwhile to verify the 'portability' of this..)

ttlappalainen commented 7 years ago

Have you tried to have just on NMEA2000_stm32.h: public: tNMEA2000_smt32() : tNMEA2000() { }

And what about name is it really tNMEA2000_smt32() not tNMEA2000_stm32 as you .ccp is named?

denravonska commented 7 years ago

@thomasonw I think this is a minor typo or error in the code, not in the portability so we can take the tracking off-thread. Can you mail your current code to med and I'll try to help you.

thomasonw commented 7 years ago

It was the typo ttlap noted. As mentioned above, correcting that allowed compile and linking. Traveling for a few day, so not much will happen. But right now am at the point of being able to create binary and do debugging on hardware, figure most will be cpu specific for the can and serial. Maybe will have more news in a week or so...

thomasonw commented 7 years ago

@denravonska @ttlappalainen Hello. I am back focusing on the STM32F072 porting using the mbed dev environment - and am getting close, but still a couple of issues:

1) I had to make one fix, the removal of " tN2kPGNList::" and just use the constants directly. You can see the changes here (I am holding off doing a push until things are confirmed).
https://github.com/thomasonw/NMEA2000/commit/6a15824530ddc4abef242fbc03aec74fdea1c76e

2) I am having issues bridging the mbed serial into what the NMEA2000 lib wants. Here is the test code:

#include "mbed.h"
#include "NMEA2000_stm32.h"

Serial pc(SERIAL_TX, SERIAL_RX, 115200);

DigitalOut myled(LED1);

tNMEA2000_stm32 NMEA2000;

int main()
{
    pc.printf("\r\n\nAbout to start\r\n");
    pc.print("Will this work??\r\n");
    pc.println("No sure");

    NMEA2000.SetForwardStream(&pc);                                 // PC output on due native port
    NMEA2000.SetDebugMode(tNMEA2000::dm_ClearText);                 // Lets us see the debug mesages on the terminal
    NMEA2000.SetForwardType(tNMEA2000::fwdt_Text);                  // Show in clear text
    NMEA2000.Open();

    while(1) {
        NMEA2000.ParseMessages();
        myled = 1; // LED is ON
        wait(0.2); // 200 ms
        myled = 0; // LED is OFF
        wait(1.0); // 1 sec
    }
}

and here are the error messages I get:

Warning: List initialization syntax is a C++11 feature in "NMEA2000-master/N2kMsg.cpp", Line: 370, Col: 7
Warning: Dynamic initialization in unreachable code in "NMEA2000-master/NMEA2000.cpp", Line: 916, Col: 8
Error: Class "mbed::Serial" has no member "print" in "main.cpp", Line: 13, Col: 9
Error: Class "mbed::Serial" has no member "println" in "main.cpp", Line: 14, Col: 9
Error: Argument of type "mbed::Serial *" is incompatible with parameter of type "N2kStream *" in "main.cpp", Line: 17, Col: 32

The largest one being the last one: incompatible parameter of N2Kstream with mbed::Serial - if I cast I am able to get it to compile, but of course it does not function. The other two Error:'s are to simply show that the mbed::Serial does not support print nor printf

I am a pre-objects kind of guy, so these issues are tough for me to overcome. Help? If you need to see the rest of the code, I can figure out how to place it somewhere. On a plus side, if I pass in NULL for the stream - the code will compile, load, and flash the LED. I have not been able to test it yet with another CAN device, soon.

denravonska commented 7 years ago

@thomasonw You need to make your own class which derives from N2kStream and wraps an mbed Stream. Something like (not tested):

class mbedStream : public N2kStream {
   mbedStream()
      : pc(SERIAL_TX, SERIAL_RX, 115200) {
   }

   int read() {
      return pc.getc();
   }

   size_t write(const uint8_t* data, size_t size) {
      return pc.write(data, size);
   }

   Serial pc;
};

mbedStream serStream;
NMEA2000.SetForwardStream(&serStream);

The NMEA200 library implements the missing print functions in N2kStream so your serStream will have them.

thomasonw commented 7 years ago

@denravonska THANKS!

With that starting point I was able to get wrappers working, The NMEA2000 lib is now complaining loudly it is unable to send any CAN messages (Mostly because there is no transceiver connected at this point!) - So: Printing works! Will be a week or so until I can test the actual CAN code, but have not too many concerns there.

Thanks again! Will post up somewhere the final code for your review after I get the rest working.

thomasonw commented 7 years ago

@denravonska @ttlappalainen All, wanted to pass on I have been working on a RPi bridge and just today posted my 1st cut here: https://github.com/thomasonw/NMEA2000_socketCAN

I have it working with a simple read demo, still need to verify the write.

It used socketCAN for this RPi bridge so it should be very portable to any linux system which has socketCAN enabled hardware.

Timo: Should this be added to the 'automatic' selections - thinking as socketCAN is a very common 'portable' system might be worthwhile to do so?

denravonska commented 7 years ago

@thomasonw That's pretty neat. We've discussing using the Pi for one of our projects so we might give it a go.

thomasonw commented 7 years ago

Nice - of course pass on anything you might find : - ) I am looking to use it for a signal-K provider from J1939 based protocols (Primary RV-C, but some NMEA2000 might come along as well)

olesenrl commented 7 years ago

If anybody is interested my online store at www.beaconwatch.com has the iKommunicate from Digital Yachts. Send me a note and I can give you a 25% discount.

Thanks,

Bob

On Mar 4, 2017, 5:27 PM -0500, Al Thomason notifications@github.com, wrote:

Nice - of course pass on anything you might find : - ) I am looking to use it for a signal-K provider from J1939 based protocols (Primary RV-C, but some NMEA2000 might come along as well) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

ttlappalainen / NMEA2000

Remove Arduino dependencies #33

define PGM_P const char *

pragma anon_unions