Compiling mavlink for PIC or 8051

[David Brown]

Ok, so I'm still very new to mavlink.  My end goal is to use a microcontroller (either a PIC or a silabs 8051) to read in a mavlink datastream from a pixhawk, parse out a couple specific packets, and do stuff accordingly.  I'm much more of a hardware guy than software guy, so go easy on me :)

So far I have:

1.  Installed python 2.7

2.  Downloaded, then double-clicked mavgenerate.py to run it.

  2a.  Selected common.xml, C language, protocol 1.0, and generated the source headers.

3.  In MPLABx (Microchips PIC IDE), I make a new project, add #include <mavlink.h>, add the .h folders to the path, and get the following errors:

Using the XC8 PIC compiler:

other/common\common.h:28: error: (285) no identifier in declaration

other/common\common.h:28: warning: (374) missing basic type; int assumed

other/common\common.h:28: error: (285) no identifier in declaration

other/common\common.h:28: error: (314) ";" expected

Following this line:

#ifndef MAVLINK_MESSAGE_INFO

#define MAVLINK_MESSAGE_INFO {MAVLINK_MESSAGE_INFO_HEARTBEAT, <redacted for brevity>

#endif

Using the HI-TECC PICC compiler I get a different set of errors for the snippet shown below.

other\mavlink_types.h:53: error: type specifier required for prototyped argument

other\mavlink_types.h:53: error: ")" expected

other\mavlink_types.h:53: error: "," expected

other\mavlink_types.h:53: error: can't mix prototyped and non-prototyped arguments

other\mavlink_types.h:53: error: type specifier required for prototyped argument

other\mavlink_types.h:53: error: type specifier required for prototyped argument

MAVPACKED(

typedef struct param_union {

    union {

         float param_float;

              int32_t param_int32;

            uint32_t param_uint32;

          int16_t param_int16;

            uint16_t param_uint16;

          int8_t param_int8;

              uint8_t param_uint8;

            uint8_t bytes[4];

       };

      uint8_t type;

}) mavlink_param_union_t;

Oh, and both compilers give warnings about redefining preprocessor macros for every MAVLINK_MSG define.

Using the Keil C51 compiler, it has issues with the syntax around the same MAVPACKED union above.

C51 also doesn't have a native 64bit variable, so I think it's a moot point to continue.

Has anyone successfully compiled the mavlink code for a PIC or 8051?  I only need basic functionality, so at this point I may just read and parse the data stream myself to look for the packets I need, but I was hoping to do it 'the right way', so if there are any changes made later on, I can easily make the changes.

[Peter Hollands]

MatrixPilot  is using 16 bit PIC based processors and has support for MAVLink. The base protocol code generates, compiles, and tests correctly, but our project has not implemented all of the resulting messages with actions. 

Best wishes, Pete

--
Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "MAVLink" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an mavlink+u...@googlegroups.com.
Weitere Optionen finden Sie unter https://groups.google.com/d/optout.

[David Brown]

Thanks for that.  I was able to get both your mavlink subdirectory, and the auto generated header files, compiled in mplabx under the PIC XC16 compiler, but not under the 8 bit compiler.  I guess I can handle using yet another architecture on this project :)

[David Brown]

I finally got my hardware to the point where I can start testing this, but I ran into a problem.  

I generated the header files from the common.xml file.  I'm using the basic example code with this call mavlink_parse_char(MAVLINK_COMM_0, c, &msg, &status); then a switch on the messageID.

The problem: right now I am sending two different packets to the PIC from my PC through a terminal just for testing, so I can tightly control the input to check the output.  The decoder returns valid for the heartbeat message, but it doesn't return anything for the other message.

I'm assuming the generated headers should return the messageID, even if it's not in the list of known types, right?  I've verified that the other packet is valid (length/checksum/etc), and I assumed it would return the ID.  

Am I missing something, or doing something wrong?