DragonBoard, an affordable 64-bit ARM single-board computer, but unfortunately it hasn't lived up to my hopes.
First of all, it shipped with one terrible problem, making it useless for headless development: The onboard wireless doesn't receive multicast traffic, including ARP requests! And their kernel doesn't provide many modular drivers, so adding any old USB wireless dongle doesn't work until you rebuild the kernel. As of this writing, there is no useful workaround.
And that's when I hit the second show-stopper problem. I planned to build kernels for this thing anyway, because the goal is to run LinuxCNC on it with rt-preempt realtime. So I stuck in a large capacity micro-sd card, obtained the kernel source, built it, and rebooted with my new kernel.
(incidentally, testing kernels is a PITA. You have two choices: one, flash the one and only boot area with your new and untested kernel and hope for the best; two, tether to a PC (losing USB keyboard and mouse on the dragonboard!) and use fastboot every time you boot. ugh)
.. but the new kernel just didn't work. It scrolled kernel messages, but got stuck partway through booting. dmesg implicated the wireless card. This one at least has a workaround: cherry-pick a certain commit from their kernel git. As I understand it, this bug is triggered by using the compiler on the dragonboard, and not encountered with the linaro cross-compiler running on a traditional x86 desktop.
Anyway, having found out about this I was briefly celebratory. I booted with my own kernel and had a working USB dongle. Unfortunately, that celebration was short-lived. The USB dongle hasn't been terribly reliable either, particularly under high CPU load.
I soldiered on and patched the linaro 4.0 kernel with the 4.0-rt5 patchset. There were a few minor conflicts which I believe I resolved correctly. Unfortunately, the LinuxCNC latency-test readily encounters latencies above 15ms (15000us). LinuxCNC really would like sub-100us max latencies.
I briefly enabled tracers, and have traces that seem to implicate a variety of subsystems: networking, usb, and video *all* figure. More experienced developers than I will have to be the ones to sort out RT on 64-bit ARM.
I won a copy of the book Hacker's Delight from John Regehr for my entry in his nibble sort contest earlier this year.
In that thread I had heard about the CBMC Bounded Model Checking software, and it gave me the idea to combine the two: a project to take implementations of the algorithms from Hacker's Delight and prove the algorithms' properties with CBMC.
I have a modest start on github, which I am calling "Proven Delights":
While it's otherwise an excellent irc client, I've been frustrated by pasting in irssi. There are two main problems:
My e-mail full text search software mailpie is now hosted at github: https://github.com/jepler/mailpie
Anders Wallin recently discussed generating graphs of server time error using a timestamp from the Date: header of an http request.
NTP servers themselves have estimates of time error, and it's possible to get the local server's idea of the error by sending SNTP packets to the local machine. You can also see the last time this NTP server successfully communicated with a peer or upstream, and see whether the server considers itself desynchronized by checking the stratum and leap second fields.
Based on my tinkering, the root_dispersion field or the derived LAMBDA value is the easiest to look at for estimating how bad the NTP time is. Between communications with a peer, root_dispersion and LAMBA increase at a rate of 15µs/s, ntp's arbitrary estimate of the accuracy of the local undisciplined clock. (YMMV and you can appaerntly tweak CLOCK_PHI in your NTP configuration file)
The attached program is a basic Python SNTP client which by default polls the local server every 5 seconds and prints some information. License: GPLv2+
12:25:58 0.06233 228.95875 ST-SYNCH LI-SYNCH 12:26:03 0.06241 233.96404 ST-SYNCH LI-SYNCH 12:26:08 0.06247 238.96745 ST-SYNCH LI-SYNCH 12:26:13 0.06255 243.97141 ST-SYNCH LI-SYNCH 12:26:18 0.06262 248.97673 ST-SYNCH LI-SYNCH 12:26:23 0.06270 253.98213 ST-SYNCH LI-SYNCH 12:26:28 0.06277 258.98746 ST-SYNCH LI-SYNCH
Files currently attached to this page:
The GNU project and the Free Software movement are two of the most important computer-related things in my life. At $DAY_JOB we depend critically on many pieces of GNU software (such as gcc). This blog is hosted on a system with a GPL kernel and a GNU userspace, and the blog software itself is covered by the GPL license. My everyday computer is a GNU/Linux system, and my cellphone and tablet have GPL-licensed major components, such as the operating system kernel.
I personally have contributed thousands of unpaid hours developing GPL-licensed software, which is my way of repaying everyone else who has developed Free software.
On the other hand, we haven't come as far as one might wish. My everyday computer doesn't function as well without proprietary drivers, and many devices that should be general purpose computers don't ship in a mode that allows their owners to install the software of their choice. Careful choices are still necessary when buying hardware, particularly if you insist on an operating system that consists only of Free software.
Here's hoping that the next 30 years bring more gains for Free software and the GNU system. Either way, we'll still be here.
Here's how to run the debugger on realtime code in the "unified-build-candidate3" branch from linuxcnc.org. This assumes you are using a run-in-place tree with a userspace realtime model, and that you understand the basics of gdb.
Chris Radek, I've been working on a visualization for his Rotary Delta Kinematics. Here's a picture of the work, which he hopes to push to git.linuxcnc.org soon. Of course the plot is of the AXIS splash screen.
All older entries
Website Copyright © 2004-2018 Jeff Epler