Sunday, July 30, 2017

General C/C++ lambda's and calling C code before main

I've been working on a few small projects, EtherCAT and QuadCopter IO board with USB EEM using STM32 micro-controllers. During this projects found couple interesting C++/C concepts:

  • Using Lambda functions for C callbacks
    • Simplifies static C++ functions to allowing C to call a C++ functions.
  • using GCC init to invoke C functions from C++ initialization.
    • One issue in creating projects is how to control or startup threads, init code etc in the proper order without #include every function.

Lambda Functions for C callbacks

lwIP has an asynchronous interface allowing the programmer not to create a thread to wait on socket events, all of the events occur within lwIP worker thread.  Using the same thread alleviates locking


err_t            tcp_connect (struct tcp_pcb *pcb, const ip_addr_t *ipaddr,
                              u16_t port, tcp_connected_fn connected);

The above function starts the TCP connection with the IP address in the function.  So, function requires a C callback function.  

 err = tcp_connect(m_conn, &ipaddr, PORT, [](void *arg, struct tcp_pcb *tpcb, err_t err) -> err_t
                                         {
                                              class *pToClass = reinterpret_cast<class *>(args));
                                              return pToClass->connect(tpcb, err);
                                         }

From the code above, a lambda is used without any capture arguments, this allows the lambda to be callable from C.  So, now the connect function can also be a protected function.  So, no static function needs to be declared. 

Using C++ constructor to invoke a C function before main


Here is a simple function:

static void _startUpUdpServices(void) __attribute__((constructor (102)));
void _startUpUdpServices(void) 
{

    regStartUpFunction(StartUpPriority::_6, "udpServices", (startUpFunctor_t)startUpUDPServices);
}




The __attribute__((constructor (102))); Puts the function in the .init section and orders it to be at 102.  So _startUpUdpServices function will be called before main.  This makes it easy to register a system without calling the function.  nothing is worse then spegitti code to debug.  Now, it is possible to order using higher numbers.  I took a little more time and create anoterh class to register function and order them.

If you have any questions let me know...


Sunday, June 25, 2017

Update ( dRonin communication to secondary board via UDP (USB EEM))

EEM USB is now working, there are some performance tweaks still needed, but, it is working.

Next start on a simple protocol to setup pins and pwm modes, ie, oneshot, or pwm out.  The goal is to use micropython and json for pin maping, and have a work task handle the I/O.  

Next week, will checkout TCP performance using iperf and Lwip netperf app.

Pushing forward.  


Thursday, May 25, 2017

dRonin communication to secondary board via UDP (USB EEM)

There is a similar project, called FlyingPI, but instead of using Raspberry PI, this project is using the OrangePI (Zero)/(Zero plus2) 

The interface between the micro-controller and flight controller will be USB (Full-Speed).  (Soon there will be STM32 high speed USB  boards out, but as of now, it is USB Full Speed).  The protocol will be EEM-USB (Ethernet-Emulation-Model), it is simple, just two bulk end-points.  At this time I have a basic STM class driver setup and some what talking to Linux.   An Ethernet interface is created and DHCP messages are streaming from the Linux. So, at-least the USB descriptors are working etc.

Why use USB?  Why use Ethernet? The goal is to make the flight controller interface generic, i.e UDP This way different boards or platforms can use standard sockets instead of SPI, Serial, etc. 

The main issue at this time is RAM space the board only has 138K of RAM, so, buffer space will be limited, but, should work.

Moving forward...

Saturday, May 20, 2017

orangePI Zero dRonin

I've been making slow progress on getting dRonin running on the orangePI Zero; work, and other spring outside activities.

Status:
Sparkfun MPU9250 and MS5611 is connected to the zero and dRonin is loading on the board.  just debugging general start up issues and now getting to testing sensors.  Need to configure starting dRonin with command line options for SPI and I2C.  Once this is done, add the microcontroller board for motor control, pwm input, etc.  Making progress.

Saturday, March 11, 2017

General update

It has been several months since the last post; several projects starting up at work, and several projects around the house keeping me busy.

Here is the plan over the next few weeks:
  1. New OrangePI Zero buildroot tutorial 
    1. Basic configuration 
    2. Patches (from Armbian) for WiFi 
    3. How to configure kernel for RT_PREEMPT 
      1. Best way to configure OS for real-time multicore response
  2. Updates on BetaFlight conversion to Linux (never ending)
    1. Issues in porting
      1.  creating a HAL (Hardware abstraction Library)
        1. SPI 
        2. Serial
        3. I2C
        4. GPIO
        5. Interrupts
        6. Timers
    2. Goal is to be able to run BetaFlight 
      1. Linux
      2. Micro-controller 
        1. Must have I2C flash or SDCard
        2. Use FreeRTOS
          1.  Zephyr RTOS is interesting more of a Linux based RTOS (ITS NOT LINUX)
    3. Also doing a for arducopter 
  3. Complete Udoo NEO M4 port OpenAMP
    1. Update MQX to use OpenAMP
      1. Did a port a while back need update this

Yes this is a large list, but there are 25 hours in a day ! ;) yes a management theorem.

If there is any questions please ask.. always looking for idea's for postings

Saturday, November 12, 2016

LinuxFlight parts list

Making progress:

  • Fixed gyro interrupt.
    • Able to single with gyro ISR callback using epoll, and GPIO.  Need to merge into the flight controller loop.
    • Started moving code for GPS parsing using C++/ boost ASIO
Here is the parts list:
Opted to use a OrangePI Zero over the Neo AIR.  The goal is to get something in the air and then move to using a camera OSD/OpenCV.

Still can use a USB camera for a simple test.  

Here is a trace of the flight controller loop at 8Khz.  What is interesting is the I2C poll for the baro/Mag.





Saturday, November 5, 2016

LinuxFlight Progress OrangePI PC

Testing barometer(MS5611) and compass (HMC5883L) with CleanFlight configurator.  The first trial will be with the OPC, then with the new OrangePI Zero.

Things to do:

  • Need to add GPIO interrupt callback to sync the gryo
  •  Merge GPS parser boost asio thread. 
  • Add blackbox logging
  • lttng logging to validate timing
Some progress, going to order quad-frame, moters,esc, etc.  Time it is all assembly board should be ready along with firmware. 

Any questions?