Monday, October 23, 2017

Paradise ponders: dogs and C edition...

Paradise ponders: dogs and C edition...  There's a morning ritual at our house that is by now burned into the brains of our five (!) dogs.  The ritual has several parts, all of which the dogs have firmly associated with canine bliss.  The first part is the morning excursion to the back yard.  We generally let them out first thing after we get up, even before we do our morning ablutions.  The dogs all know that nothing else happens until they've gone outside and done their business.  They do that quickly, and then as soon as they see activity in our kitchen (as when we've finally really gotten up), then they clamor at the door to be let in – they know what's coming next: bananas!

With five dogs I changed from one banana to two, so they each get roughly 40% of a banana.  And they go bananas!  I peel the two bananas in the kitchen sink, which causes great excitement – especially for Ipo and Mako, both of whom are able to stick their noses over the edge of the counter and slightly into the sink.  There is much leaping and wagging and doggie excitement!  Then I take the two peeled bananas and a knife, and with my back to a kitchen wall wait for the dogs to form a semi-circle around me.  Ipo always performs one little ceremony: she darts into her crate, and then back out to the semi-circle.  Once they've all settled into place, I start slicing the banana and tossing them to a particular dog, saying their name just before I do it.  This is aimed at helping them associate their name to themselves and something good.  It works. :)

Once the bananas are gone, I (and usually Debbie) settle into our morning tea, coffee, and toast or pastry routine.  We're generally talking, reading news or email, etc. during this time.  The dogs are all watching us carefully, waiting for signs that we're finished.  They are incredibly good at detecting these signs, and you can see them winding up as the end approaches – because they know that once we're done, I'm going to feed them.  And that, of course, is the best moment of the day!

We have a small laundry room adjacent to our kitchen.  In there is a cabinet with a rollout drawer that we keep our dog food container in, with a low granite counter top above it.  In the left photo below, you can see that arrangement, caught in the middle of my filling of the bowls.  The three stainless steel bowls that are full of food are for our three youngest (Mako, Cabo, and Ipo), all of whom we feed in their crate.  So the first step for the feeding ritual is always the same: pull out the food drawer, unscrew the lid of the food container, and fill the three stainless steel bowls.  The dogs watch me on every step of this stage, making sure I'm doing it right.  The second photo shows the view behind me as I'm working: dogly inspectors hard at work.  After I fill the first three bowls, I take them (stacked up as in the photo) into the kitchen.  There I fill each bowl with warm water sufficient to cover the food (this brings out the smells in the food).  Then I take them over to the crates, stacked up again – and the three who are about to be fed dart at maximum possible speed straight into their crate.  Often there's a big crashing noise as they hit then end before turning around to await the delivery of their bowl.  Then the crunching and slurping begins. :)

After the young ones are chomping on their kibble, I return to the laundry room to fill the two big blue plastic bowls, for Miki and Race.  These two, being (much) older dogs, get less food, lest they turn into fat old men.  If anything, this makes them even more eager for their morning chow.  Miki's only demonstrations of physicality come during these moments that I'm walking toward the laundry room to fill their bowls.  He knows it's his turn, and he's very excited.  Race is just as excited, but seems to know he doesn't have to work to get his food – he just has to be patient.  So he hovers nearby, emitting little whimpers occasionally, as I fill their bowls with kibble and warm water.  Finally the big moment comes for them: the bowls are put into their stands in the laundry room, and they go to work with great enthusiasm.  Those bowls, you might note, are not smooth on the inside.  As Michelle's boy A.J. likes to say, they've got obstacle courses in them.  These bowls cured Miki and Race of a bad habit: gobbling their food down so quickly that they'd often puke it right back up.  They can't do that with these bowls, as the only way they can get most of the kibble down their gullets is to worm out the individual pieces with their tongues.  They take about twice as long to eat as the younger dogs, but the problems we used to have with their gulping eating style are all gone...

After all five dogs have finished, things are much calmer in the house.  I let them all back outside again, and then they start the serious business of doggie play.  This is their way of waiting out the clock for the morrow's morning, when the doggie ritual of joy starts all over again...

I spent a lot of the day yesterday debugging my C program, and I expect to be doing a bit more this morning.  From a very high level, debugging in C is no different than debugging in any other programming language.  At a lower level, though, it's very different than debugging in Java (where most of my recent experience is) – mainly because most of the problems I encounter are things like uninitialized variables, memory allocation goofs, and pointer errors of one sort or another.  In that respect, it's much more akin to debugging in assembly language, right on the (computer) metal.  Here's one example I debugged yesterday.  The broken code:

*count = 0;

while( TC && (*count < max) ) {
    int c = readSerialChar( fdPort, charWaitNs );
    if( c > 0 ) {
        buffer[*count] = (byte) c;
return *count >= max;

See the problem?  I didn't see it until I stepped through it with a debugger!  Here's the corrected code (highlighted in orange):

*count = 0;

while( TC && (*count < max) ) {
    int c = readSerialChar( fdPort, charWaitNs );
    if( c > 0 ) {
        buffer[*count] = (byte) c;
return *count >= max;

This sort of error (referencing a pointer variable directly, instead of the object it was pointing too) just doesn't happen in Java.  There are no pointers, or so the language proponents like to claim (really, all the object instances are pointers internally, but the language does a great job of hiding that from you).

This difference in debugging is neither good nor bad, just different.  Especially, I think, for someone like me who hasn't done any “low level” debugging for a zillion years or so... :)

Sunday, October 22, 2017

I really am...

I really am ... still here.  Just heads-down on C code. :)

Wednesday, October 18, 2017

Paradise ponders: geekly gloating success!

Paradise ponders: geekly gloating success!  It took me damn near all day to do it, but I finally got remote debugging working with the toolchain I'm using.  All the difficulties turned out to be silly little things (as usual).  It's in the nature of things like this that you have total, epic failure until you nail the last problem ... and then suddenly everything works!  The main reason this was so challenging for me is that darn near everything I was working with (the parts of the toolchain) are brand new to me – so I wasn't just fighting actual problems, I was also fighting my ignorance.  I'm ever-so-slightly less ignorant now.  Here's what I had to do to make all this work:
  • I had to find the sources for a particular older version of the GNU debugger (gdb).  That turned out to be far more challenging than I expected, and led me down a blind alley learning how to clone git repositories.  Turns out GNU has a tarball of exactly the version I needed up on their anonymous FTP server.
  • I had to configure and compile that special version of gdb.  The configuration would allow gdb to execute on my Mac, but debug programs compiled for the Version 7 ARM computer that powers the Raspberry Pi 3.  This was way harder than I expected, but only because I had so much trouble locating the magic word (“armv7-unknown-linux-gnueabihf-gdb”) to use as the argument for the “—target” parameter to ./configure.  I read approximately 17 billion web pages to find that magic word.
  • I had to figure out what “symbol file” meant in the CLion run configuration screen.  I ran with the assumption that I had to tell the compiler to produce a symbol file ('cause that's how things worked in the dark ages when I last did things like this).  Turns out that's wrong.  What I had to do was to compile my source code on the target machine, then copy that object file back to my Mac – and point to that as the symbol file.  That took another 12 billion web pages skimmed to figure that one out.  I also found a way to produce a separate symbol file, though I'm not sure I actually care – the first method is easy and fast.
  • The easiest challenge turned out to be configuring CLion to automate all of the above things.  I only had to read about 5 web pages to get that! :)
The most important thing, though, is: Hooray!  I've got it working!

Paradise ponders: missing blogger edition...

Paradise ponders: missing blogger edition...  No, I haven't disappeared from the face of the earth!  I've just been heads-down on several projects, including installing a microwave, trying to figure out CLion (the C/C++ IDE from JetBrains), and generally learning the C toolchain for remote development on a Raspberry Pi.  So much stuff to learn!

Monday, October 16, 2017

Paradise ponders: C programming and compressed air edition...

Paradise ponders: C programming and compressed air edition...  Debbie and I took a beautiful drive yesterday morning up Blacksmith Fork Canyon.  We saw a dozen or so deer – all fat and healthy looking, ready for the privations of winter – and the tail end of the fall color.  It's elk season, and there were hunters all over the place.  Some of them (a minority, thankfully) park along the side of the road and set up what is basically an ambush at the side of a field where an elk might come to forage.  On one stretch of such an ambush, about 50' wide, I counted eleven hunters.  Each had their binoculars up, searching for some elk to poke its head out.  There were four other such ambushes along the edges of the same field, though the others weren't quite so large.  Still, if an elk was dumb enough to stride out onto that field, probably over a dozen rifles would be shooting at it.  I wonder how they decide whose “kill” it is in a situation like that?  We also saw some beautiful effects of the cold weather (it was 15°F where the photos below were taken), around waterfalls and rapids.  The combination of low temperatures and high humidity meant that the fine spray thrown up by the tumbling water stayed in the air as a liquid (or ice crystal) for much longer than usual.  This produced wonderful “steam” effects, and also ice-coated twigs and grasses.  A few photos of some of the better ones:

We also ran a few chores, but for much of the remaining day, and also today, I've been programming in C again.  I greatly expanded the simple little program I wrote about in my previous post, to give me all the functions I could imagine needing for my NTP server.  I've also modularized it in a way that will make it relatively easy to add new features, should I need to.  I'm finding that I quite enjoy the process of programming in C.  It's a far simpler, smaller language that the Java and JavaScript world I've spent the last twenty years in; in that sense it's easier and cleaner.  On the other hand, some things that are easy to do in Java/JavaScript (mainly because of the ubiquitous high quality, well documented libraries) are much harder to do in C.  Then there's the fact that C is fairly close to the hardware and the operating system – not quite as close as assembly, but not too darned far from it.  I like that; it plays to my hardware background and my desire to tinker with little embedded systems (like the NTP server and my irrigation supervisor).  One thing I've come to realize: it's pretty easy to meld the two languages for everything (or nearly so) that I might want to do: I can handle the low-level, close-to-the-hardware stuff in C (where Java either couldn't do it, or would have trouble doing so), and I can run those C “helpers” as a child process under Java.  That's both easy and clean.  I'm doing a test project of that general architecture right now: to let a Java program interpret the NMEA protocol output of the GPS on my NTP server.  A little C program will echo that NMEA data to stdout, and my Java program will run that as a child process and consume its output.  Simple!  But Java couldn't do it on its own...

Our sprinkler contractor showed up this morning, towing a huge air compressor behind his pickup.  He used this compressor to blow all the water out of our underground sprinkler lines, so that when they freeze this winter (as they surely shall), it won't damage any of the system.  The photo at right shows what it looked like as he blew out one zone in our back yard.  The noise as he did this was quite impressive, and full of bass notes that I wouldn't have expected from rapidly moving air...

Saturday, October 14, 2017

Paradise ponders: NTP adventures and old friends edition...

Paradise ponders: NTP adventures and old friends edition...  Debbie and I are both feeling a bit better today, but wimpy as heck.  Debbie's fever seems to have broken last night, and her voice is back.  I can tell she's feeling much better because she did the cat chores today, much to the delight of our feline contingent!

Last night our forecast called for snow, but we didn't get any.  We did get just a bit of a kind of fine-grained hail (photo at right), along with (I'm guessing) about a tenth inch of rain before the temperature dipped below freezing.

I got a real surprise yesterday: a colleague and friend, Ron N., from over ten years ago contacted me out of the blue.  I'm not quite sure how he located me, but he left a comment on my blog and then the two of us got together on email.  It's been interesting to catch up with him, though obviously we've got a lot more to do of that!  He tells me he'd like to come up here to visit sometime next year, which would be really fun...

Most of yesterday and this morning I've been consumed with trying to fix a problem with my NTP project: configuring the GPS to be in stationary mode, wherein it assumes the antenna is not moving.  This translates into more accurate time measurement (more on that below).  The problem I started out with was that the directions I was following for setting up my NTP server included a link to a program that just plain didn't work.  The specific problem was that the program hung when it tried to open the serial port for reading and writing.  I troubleshot it for several hours, but finally gave up because I didn't understand how it could ever work in the first place.

So I decided to write my own program instead.  That meant that I had to understand the rather complex communications protocol that the GPS chip manufacturer uses for the functions I needed, as they're implemented in a proprietary “UBX” protocol.  Then I had to dust off my (extremely) rusty C programming skills – the last time I wrote a complete C program was around 1983 (seriously!).  I've done lots of work since then in C++ and Java, but not in C – and if you're a C programmer, you know it's changed a lot since the '80s!  Finally, I had to learn something completely new to me: serial port programming on Linux. I did the development work on a Raspberry Pi, where the only development tools I had was gcc (the Gnu compiler) and nano (a text editor).  Somehow I managed to get my little program working, which, I have to tell you, was a very satisfying thing indeed – validation, of a sort, that I might have more than two or three little grey cells still working.  If you're geekly enough to be interested, here's my satisfying little program.

A couple of my readers wanted to know what the heck a GPS receiver has to do with keeping good time on my network.  If you don't know anything about how GPS actually works, I can imagine this is really quite puzzling!  The first thing you need to know is that each GPS satellite has an incredibly accurate atomic clock in it.  There are over 50 of these satellites in four separate systems (the US, Russia, China, and Europe each have their own independent system), so there are a lot of these awesomely precise clocks flying around.  The GPS receiver I'm using can listen to all four systems, and at any given moment it likely has 10 or 12 satellites “in view” (meaning that it can hear their signals). Once my receiver can “hear” at least four satellites, it can tell the time very precisely indeed.  In fact, its accuracy is very nearly that of an atomic clock, as if I owned one of these (very expensive!) things.  All that with a $39 GPS receiver and a $29 antenna!

With the success of my little program, I've now got my stratum 1 NTP server up and running.  It's working great, passing all the tests I can throw at it.  Now the only things left to do are to mount the antenna on my barn's roof (that might be a challenge!) and to make a case for the Raspberry Pi.  I've already got it in use on my network, though – even with the antenna just pointed out of a window in my office, it's much more accurate than any NTP server I can access over the Internet...