3D Vector and Matrix Utility in C

Need a simple 3D vector and 3×3 Matrix utility in C? I just published one on GitHub providing basic functionalities like orthonormalizing, transposing, multiplying (etc.) matrices and vectors. It was supposed to be used in Nuttx drivers but certainly can be used in other contexts. For Nuttx, I had to add mathematical calibration to an acceleration sensor driver, so that x y and z axes can be re-specified no matter how the sensor is built in.

3D Vector and Matrix Utility in C

Contributing LTC4151 voltage and current sensor driver to Nuttx

I recently pushed my first contribution to the official Nuttx repository on Bitbucket! Nuttx is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint.

I’m working at Robodev GmbH since June – a small Start Up getting ready to launch its new product series. In the last weeks I learned so much there and as Robodev uses Nuttx for its embedded devices I can also contribute to an open source community.

Check out my work: Driver for LTC 4151 – Example App

Contributing LTC4151 voltage and current sensor driver to Nuttx

RactJS on the BeagleBone

If you want to access a ReactJS app on the BeagleBone you will have to provided a web server. I used NodeJS for that. The idea here is to just pass every request on to the React app. You can do this after setting up the server with this command:

const app = express();

// Serve static assets; This navigates to the build folder generated by webpack
app.use(express.static(path.resolve(__dirname, '..', '..', 'build')));

// Always return the main index.html, so react-router render the route in the client
app.get('*', (req, res) => {
    // __dirname will get the directory name of the file, not the directory where React was started
    res.sendFile(path.resolve(__dirname, '..', '..', 'build', 'index.html'));
});

I am using expect here to achieve the desired effect. To finally run the app on the BeagleBone you can just launch the server. Make sure that webpack bundles only your client code, not your server side code. The index.html includes the bundle.js script generated by webpack, redirecting requests from the server to the client enables ReactJS to handle the routing itself.

As a side note, I use Babel with webpack to generate a backwards compatible bundle.js file. Here is the code: https://github.com/ordsen/gsoc-preparation/tree/master/reactjs_example/frontend

RactJS on the BeagleBone

Rest API with NodeJS

To create a rest API from an Express NodeJS app just add a new js file to the routes folder, e.g. rest.js and add a call to to the app.js file:

var express = require('express');
var app = express();

app.use("/rest", rest.js)
app.use('/rest', rest);

To create a function which is first called on all requests add the following:

/* executed on all requests */
router.use(function(req, res, next) {
    console.log("There was a new request");

    // pass request on to our api
    next();
});

To create a GET method at /rest/yourMethod add the following to your rest.js file:

router.get('/yourMethod', function(req, res, next) {
    res.send('A return value');
});

Parameters can be read with req.params.your_param and the rest call needs to be modified for this to match something like this: ‘/yourMethod/:your_param’

To create a POST method at /rest/yourMethod:

router.post('/putPayload', function(req, res, next) {
    console.log(req.body.your_post_param);
    res.json( {result: "OK"} );
});

Note that req.body.your_post_param reads the parameter named your_post_param from the POST request.

A full example can be found on GitHub: https://github.com/ordsen/gsoc-preparation/tree/master/nodejs_server_example/interface

.

Rest API with NodeJS

NodeJS to C Binding

To call methods written in C/C++ from NodeJS you need to accomplish several tasks as stated here. I am not aware of a solution to talk directly to a C library, so I will create a C++ binding which behaves like a wrapper for the C functions. I will summarize here  how this works, please see the Github repo and the provided links for more details: https://github.com/ordsen/gsoc-preparation/tree/master/nodejs_server_example/interface

Continue reading “NodeJS to C Binding”

NodeJS to C Binding

NodeJS and Express

To create a new express app with (creation of express apps with IntelliJ currently seems not to work properly) ejs use

express --ejs name_of_your_project
cd name_of_your_project && npm install

To give you a basic overview: In your Express project, the bin/www file starts everything up. The app.js file is where everything app related happens. in the “views” folder you can find your html pages (which are ejs now) and in your “routes” folder you can put the logic for each page (e.g. index.js for the index page). And last but not least, you can add publicly available resources to the “public” folder. To include a new page, add the .ejs file to views, include it in app.js and add a .js file for that page to the roots directory. See my repo for an example.

NodeJS and Express

Results of serial port tests

I tested the serial ports with non-canonical and canonical input mode as well as synchronously and asynchronously. I did not encounter any heavy problems related to FIFO overflows, but there seems to be a limitation with canonical input mode:

Synchronous Serial Port Communication

Even when writing 20000 messages all at once with the maximum baud rate supported by the temios API (B230400) to all four serial ports there were no messages dropped! Reading from the port and writing to a log file all happens synchronously, but the driver seems to take care of pretty much everything. Reading one byte or multiple bytes from the serial buffer does not seem to make a difference and both perform good. I tested this with non-canonical input mode; with canonical input mode (see other branches) I was able to separate the log into single messages devided by their time stamps. When doing this it is easy to find out the limitations of the built in buffer: The serial device can send up to 4096 characters without a line break. But if it sends more, the first messages which arrived will be dropped as the buffer fills up. That makes sense, as one page is 4096 bytes large. To overcome this issue later the user of the serial terminal server should be able to select non-canonical mode. That way the buffer can be read in time. Another possibility would be to use non-canonical mode per default and divide the logs manually after each \n character.

Asynchronous Serial Port Communication

This was tested with canonical mode and led to the same results as with synchronous serial port communication. The same limits apply, but inputs can be handled without needing to spawn a new thread for I/O tasks. This can be an improvement for the serial terminal server implementation, as I would like to avoid blocking the UI thread.

Results of serial port tests