LinuxFlight connecting to CleanFlight Configurator

Just finished updating github LinuxFlight.  CleanFlight Configurator, is not able to connect and start sending MSP packets; but something is hanging up in getting data messages.  Work on that next week.

How to build LinuxFlight (Linux only):

• Need to build boost C++ libraries and install them 
• make
• ./PC
• open another terminal 
•  socat -d -d pty,raw,echo=0 tcp:localhost:56000
• This will create a pty, the output from socat show which pty to connect configurator
• i.e /dev/pts/9

There is a lot to do to improve the IPC speed, i.e not to copy std::vector, but to use std::move, so there is no copy.  Also, move the IPC queue struct from std::queue to boost::lockfree::queue with a semaphore to wake up the FC thread.  

The heart of the IPC is a send-reply via std::function<void (void)> type function.  So, how can a void function be able to process arguments and do process callbacks?  

• Use std::bind, this arguments.   For example, in  mspSerialTCPPort.h,  function: handle_read creates a std::function<void (void)> 

                  msgPost_t _msg;
                  mspCallback_t _callback = std::bind(&mspSerialTCPClient::postHandleWrite,                                                                                            shared_from_this(),                                                                                                                                std::placeholders::_1);

                  _msg.m_in = std::bind(&callToMSPFromTCP, _pkt, _callback);

So, msgPost_t is created with a function callback.  The std::bind takes the packet and places it in one of the arguments.  Along with a call back function.  It is important to use shared_ptr, so the class does not disappear until all callbacks are completed. So, when the function is invoked the arguments are unpacked and the MSP function is call.

This is a simple way, to keep a callback IPC API and allow any type of arguments.  Yes, it is confusing, but look at the code, run it and debug it. 

So, the current design is to move most of the I/O from the flight controller main thread, this way I2C. serial, etc are processed out side of the thread.  All data will be posted to the FC thread, this way, this should minimize jitter.