December 7, 2013

My fourth day with the Beaglebone

On my third day with the BBB I figured out how I wanted to deal with things and have actually been fairly busy learning JQuery and socket IO since then.

My way of doing things is to use vim to edit the source files right on the BBB, then use "node file.js" to run my server, which then dishes out file.html to a browser, which then uses JQuery and socket IO to run my GUI. This works out great and I am basically working at full speed without being hindered by some stupid buggy IDE.

Pulse width timing measurements

I run a loop in my server that emits pulses as well as doing other things. My intent is that this loop will one day be generating pulses that drive a stepper motor. The stepper controller I am using will recognize a pulse as long as it is at least 20 microseconds wide. The question is how wide the shortest pulse I can send from node will be. The fastest way I know (at this time) to send a pulse using Node.js is: 
b.digitalWrite ( bit, 1);
b.digitalWrite ( bit, 0 );
I get out my oscilloscope, wrap a loop around the above code and measure that this gives me a pules 0.7 milliseconds (700 microseconds) wide. Certainly wide enough to trigger my stepper controller, but it is a concern that this takes almost as long as the loop interval when I am running a loop every 1 ms using: 
var delay = 1;
setInterval ( ticker, delay );
Since I have the scope hooked up, I measure some other pulse widths. Lets call the following a "2 instruction" pulse: 
b.digitalWrite ( bit, 1);
b.digitalWrite ( bit, 1);
b.digitalWrite ( bit, 0 );
It is about 1.1 ms wide. So the pulse width timings look like this: 
1 instruction pulse: 0.7 ms
2 instruction pulse: 1.1 ms
3 instruction pulse: 1.8 ms
4 instruction pulse: 2.0 ms
5 instruction pulse: 2.2 ms
10 instruction pulse: 3.7 ms

Loop timing measurements

I ran a 1 Hz LED blinking loop and it seemed to be blinking at 1 Hz just eyeballing it. I used the oscilloscope to measure loop activations established by setInterval with various millisecond delay arguments. My ticker routine for this was the following: 
var delay = 1;

function ticker () {
    b.digitalWrite ( bit, 1);
    b.digitalWrite ( bit, 0 ); 
}

setInterval ( ticker, delay );
The results are as follows: 
1000 gives a 1000 ms (1 Hz) loop (good!)
100 gives a 100 ms (10 Hz) loop (good!)
50 gives a 50 ms (20 Hz) loop (good!)
20 gives a 20 ms (50 Hz) loop (decent)
10 gives a 12 ms delay (83 Hz, not 100)
5 gives a 8 ms delay (125 Hz, not 200)
2 gives a 5 ms delay (200 Hz, not 500)
1 gives a 2.4 ms delay (417 Hz, not 1000)
So, things are coming unglued at fast loop rates. This is not totally shocking, but I am glad I checked this while I had the scope out.

Running with a stepper motor

This yielded some surprises. Using the above loop for continuous pulse generation, it was curious to listen to the motor. Occasional timing issues yielded interesting "music" from the motor (when it was resting on an object that provided some acoustic coupling for the motor vibrations). Not only that, every minute or so there was an episode where the motor "sputtered" for a few seconds -- presumably because the process running "node motors.js" was not getting scheduled.

Contrast with AVR microcontrollers

Nobody ever said that linux provides a real time environment for user processes, but I didn't expect things to be this bad.

Performance using Javascript and Node.js on the BBB (as a user process running under the linux kernel) is interesting to contrast with simple code running on an AVR microcontroller (similar to an Arduino). On the AVR microcrontroler the timing was dead on and solid. The code running on the AVR was compiled C, running on a bare microprocessor (no kernel, no other processes).

Each has its strong points. The BBB provides a wonderful development environment, ethernet, and a nice path to a GUI. The AVR provides direct access to hardware, but only a USB connection in the usual configuration, making GUI development more challenging, but hardly impossible.

What the BBB really needs is a real time kernel like the Skidoo (TM) real time kernel I wrote for my thesis project.

Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org