The Paleotechnologist

Digital Is Better Than Analog. God Said So!

2010-01-30T12:31:00.004-05:00

It's true. God (at least the Christian one, as Jesus) said so Himself:

"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil."
(Matthew 5:37, King James Version)

Directory Size Management

2010-01-23T15:52:00.003-05:00

I'm in the process of organizing and backing up the rather large directory structure on my desktop box, in preparation to try out Windows 7 and Ubuntu Linux.

Until I finally buy a BD-R drive (which will probably happen sometime this year), this means backing up to DVD-R discs. My mail spool is no problem at 2.3GB or thereabouts, but the \docs directory is another story entirely. There is content in there -- probably large, unused content -- from at least as far back as the first Clinton administration. I don't mind keeping old data around if it's reasonably sized, but how to tell where the disk-hogging directories are?

Googling "directory tree size," I came across WinDirStat. It's a freeware application to scan a given directory structure and show how much is taken up by which subdirectories.

It also takes this data and maps it into pretty fractal pictures.

I'll post my thoughts on Ubuntu and Windows 7 when I get to them. I may even try out the 64-bit version of XP, depending on how much I like or dislike Win7. (With 64-bit support and newer versions of DirectX, I *want* to like it -- but I have concerns about the way the GUI has been evolving since Office 2007 and Vista.)

Data.gov

2010-01-23T15:01:00.001-05:00

This looks interesting: the US Federal Government has released some 300 data sets to the public via Data.Gov.

They say sunshine is the best disinfectant; making as much data as possible as public as possible sounds like a great idea to me.

Paleotech Transportation

2010-01-19T22:41:00.005-05:00

In other words, bipedal locomotion -- walking!

My friend DOSquatch (not his real name, but it's quite appropriate) has recently started a personal weight-loss program (and is doing quite well.) He has inspired me to get back into my routine of walking home from work (at least part of the way; it's 4.7 miles, so I only do the entire distance when it's reasonably light out.)

An interesting way to stay motivated, doing something like this, is to add up your mileage and then use a mapping program to chart your progress towards some distant goal. The "Virtual Me" is currently walking -- very slowly -- towards the Space Needle, in Seattle, WA. He's very nearly to Harrisburg now (~90 miles), having started in Philadelphia!

Some geek observations on the art of walking:
* Cool weather is your friend. There are limitations to speed, and one of them is heat dissipation. I go a lot slower when it's 80 degrees out than when it's 50.
* Uphill can be just as easy as straight and level, provided you're willing to go slower. Shorten your stride and pull it down a gear or two -- no problem.
* People generally don't walk very fast. I'm by no means athletic, but my standard cruising speed when walking tends to be a lot faster than most (~3 mph / ~5 km/hr). I'm not sure why this is, since I know many of these people could run circles around me if they cared. Weird.
* Know your neighborhoods. The nice thing about my route home is that there are plenty of options to stop and take the train along the way -- there are twelve subway/trolley stations along the way, including the two near work and where I live. Some neighborhoods (and some SEPTA stations) are nicer than others, and that factors into my planning, too.

So long, Loran; we hardly knew ye

2010-01-12T22:31:00.005-05:00

I guess it had to happen eventually. The US Coast Guard apparently intends to turn off Loran-C next month.

Just as Loran took over from Omega, GPS is now making Loran-C obsolete. Still, we dinosaurs will miss it. Loran has long been associated with marine and aircraft navigation, of course, but it also has a special place in my heart as the first navigation technology that I used.

Back in the day (mid '90s?), I found a surplus Loran-C receiver at a hamfest. I didn't really know how they worked at the time, but it was cheap ($10 or $20, I think), and it came with a book that explained what voltage and polarity it needed on the power connector, so I bought it.

After a little reading, some soldering, and some programming in TRS-80 Model 100 BASIC (an awesome little laptop -- more about it later), I actually had a functional navigation system! That is, I could tell my latitude and longitude, and calculate line-of-sight distance to various waypoints that I set. Not the most practical thing in the world to mount in a car, but it was a lot of fun.

It actually did help with navigation, too. A few days after installing it, I was driving home from a friend's house in Norfolk, and turned the wrong way onto Tidewater Drive. I'd have found this out soon enough myself, but I happened to glance down at the Loran, saw that my heading was 360ish when it should have been 180ish, and did a U-turn. That was pretty cool -- I never expected it to actually do something practical.

I got a lot of programming experience out of it, too. The Loran would output its latitude and longitude (in degrees, minutes, and seconds) once a second. Even compressed into bytes, this was three bytes for latitude and three for longitude, every second. Today, this is a ridiculously low data rate -- but on a Model 100 laptop with a whole 22k of free memory (including the logger program code), six bytes a second was WAY too much for logging a long trip -- it wouldn't even last an hour.

So I got creative. I realized that the latitude and longitude *degrees* hardly ever changed -- and that the minutes didn't change much, either. I came up with a scheme to compress the data: two bytes were normally recorded each second for the latitude and longitude, except when one or the other rolled over to the next minute and/or degree. In those cases, an "!" was inserted in the data, telling the plotting program that a full six-byte frame would follow.

With that scheme, I was able to record over eight hours' worth of data in the M100's 22k of memory -- including the recording/compression program! My friend Jason and I took the whole setup (ported to a larger Compaq Plus computer) along on a road trip to Milwaukee and back. It worked pretty well -- even when we had to shift it over onto the Great Lakes Loran chain.

I don't know how good its accuracy (repeatability) was, but its precision was sometimes pretty good. On the way back from one roadtrip, I decided to drive all the way around a cloverleaf interchange (four 270-degree turns) as a test. When I got back home and looked at the data using a quick-and-dirty plotting program I wrote, the whole cloverleaf was clearly visible, albeit squashed a bit in places due to only having one update per second. Not bad for several-decades-old technology.

I know it had to go -- but I'm still going to miss it.

Newtonian Physics Demonstration

2009-12-13T23:08:00.001-05:00

...courtesy of Mother Nature.

Guys, Joshua/WOPR said it best:
"A strange game. The only winning move is not to play."

Just -- WOW.

2009-12-04T00:05:00.004-05:00

Speaking of Bad Code, I just ran across "The Who-Knows Code".

Either someone out there has a very VERY sick sense of humor, or otherwise he or she should be tracked down (we might want to put the FBI on this) and restrained by whatever means necessary from ever using a programmable piece of technology ever again.

Don't believe me? Go see for yourself. "GOTO Considered Harmful," indeed!

Bad Code Contest!

2009-12-03T23:33:00.004-05:00

They don't know it yet, but several of my fellow geeks at Drexel are about to be the recipients of some Bad Code Offsets.

They're like carbon offsets, only for lazy geeks who take the easy (and often ugly) way out when writing code. Things like allocating a huge honkin' array at runtime instead of coding a linked list, or doing a sort in n² time instead of n*log(n), just because you couldn't be bothered to implement Quicksort.

I know I'm guilty. My code gets more maintainable as I get older, but not very quickly. If style violations were actually illegal, I'd be on a first-name basis with most of the folks at the Criminal Justice Center downtown, just on the basis of the last microcontroller project I did alone. It's part assembly (some of it autocoded by a hacked-together FreeBASIC program), part macros, and there would have been some C thrown in for good measure if I hadn't run out of time. Prior to that, I did another project where a VBasic GUI running on one machine worked alongside a QBasic program running on another, driving a microcontroller running a program written in assembly -- and none of it presentable. (I guess I'm one of those programmers that Dennis Ray warned us about, way back when!)

The best part about these offsets is that the money goes to open-source projects. (I chose Apache as the beneficiary for the offsets I bought.)

I plan on putting these offsets to good use by starting an impromptu Bad Code Contest. No rules, except that the badness has to be confined to one egregiously bad line of code in the language of your choice. Something of such horribleness that it would make Dijkstra shudder from half a world away, in the same way Obi-Wan Kenobi felt a disturbance in the Force.

Bonus points for the Bad Line Of Code being implemented in assembly!

Not just no but HELL no

2009-11-15T20:47:00.005-05:00

Some things just go together. You know, peanut butter and jelly; summertime and Beach Boys music; apple juice and Graham crackers; credit-reporting sites and Facebook...

Wait, WHAT?

I've been using CreditKarma for a while now, since it charges no fees, appears to be ad-based (which is okay by me since they're providing a service), and generally above-board.

But browsing the site today, I came across a reminder of why you have to really watch what you click on the 'Net.

I have a Facebook account (mostly to keep people from bothering me to do so, but also to keep in touch with friends and acquaintances whom I don't see very often.) I'm generally leery of linking other applications and sites to my Facebook account, though (this blog being a notable exception) -- and as of this evening, I can now point to at least one concrete example of why this is not (just) paranoia.

(Image heavily redacted, but you get the point...)

Why oh WHY would anyone want to post his or her credit score on Facebook? I know I'm over 30 and therefore at least two generations removed from being uber-cool (or so Madison Avenue would have the world believe) -- but seriously, folks: no good can possibly come of this, no matter what your credit score is. That little check box might as well read: "Check this box if you're STOOPID-spelled-with-two-Os."

If your credit score is bad, you absolutely don't want to put it on Facebook. 'Nuff said, right?

If it's good, why would you publicize that on Facebook, and invite identity theft? (I mean, they're already browsing your Facebook account -- and if you posted your credit score there, they probably already have your DOB, SSN, ZIP -- and you're SOL.)

That leaves "mediocre" (whatever that is.) Chances are that there's overlap between "good" and "bad" -- in that a score high enough to be able to qualify for some credit cards and invite identity theft could still well be low enough that you wouldn't want friends, family, and employers (potential or actual) to see it.

Such things are private for a reason, folks. Caveat emptor.

Lights-out, remotely

2009-10-29T22:40:00.002-04:00

Ever been logged in to a computer via Remote Desktop, and wanted to put said computer into Hibernate mode? Yeah, neither had I, until today. I was running an experiment in the electronics lab and wanted to put my laptop (back at my desk) into hibernation, in preparation for heading to class later.

A quick Google search later, I found the answer:
rundll32.exe powrprof.dll,SetSuspendState Hibernate

Have fun!

Well, this isn't encouraging...

2009-10-26T14:47:00.003-04:00

Just stopped by our IT department at work; our sysadmin guru was installing Windows 7 on a test PC (one of our standard configurations -- a Dell GX620.) According to him, it had already bluescreened once on him. While I was there, he was running into a bunch of other errors -- during the install process. Admittedly, he was trying to upgrade an existing XP installation, but this is still not a good sign.

Very often, Windows installation errors are due to user error; I've seen this happen many times. But this guy knows his stuff -- if he made a mistake, it's because it's there waiting to be made.

Looks like XP or Linux for the foreseeable future, for me...

Do not pass Reboot, do not collect $200...

2009-10-01T09:30:00.001-04:00

One of the annoying things about Windows XP is its tendency to keep pestering the user to reboot after updates have been installed. I'm sure I'm not the only one who's been working on a document, only to have the "Reboot Now?" dialog box pop up, accept the spacebar keypress that was meant for your document, and happily reboot the machine -- three days into that loooong simulation you're running in FreeBASIC. Grr.

At least there's a solution. If you stop the Automatic Updates service, the insipid messages go away and don't come back until after you reboot. Peace at last...

How To Lose Friends And Irritate Customers

2009-09-30T18:34:00.003-04:00

Verizon, in its eternal quest for World Domination Through Customer Annoyance, has decided that Spam Is A Problem.

Good for them, you might say -- nobody likes spammers, and doing something about it must be a Good Thing™, right?

Of course, there's a right way and a wrong way to do something like this. The right way would be to, say, traffic-shape or selectively block outbound Port 25 connections for users who were sending copious amounts of email to many different addresses (I'm sure SpamHaus and similar organizations could give them many a pointer along those lines.)

The wrong way (and unfortunately the easy way), of course, would be to decree that Port 25 is a Bad Thing™, and to block outbound Port 25 connections for all Verizon end-users.

So a few days ago, my email client could mysteriously no longer connect to the mailserver for outbound mail. Diagnosing it, I found that I was otherwise still connected to the 'Net, and that the mailserver (gotta love Linux-based hosts with shell access) was still happily accepting connections from everyone but me. In fact, it was still talking to me, too -- but only via POP.

The next step was to try from somewhere else. Being lazy, I fired up my Drexel VPN connection. Sure enough, everything started working again. HMM.

A Google search quickly fingered Verizon as the culprit -- but the problem was, what to do about it? Verizon's advice ("Just Use Port 587!") was very unhelpful, as my mailserver had no idea WTF they were talking about.

Not having many other options, I found several pieces of advice on the 'Net, including advice to forward Port 25 to 587 (a nasty hack that I didn't want to inflict on a production host), to modifying the Sendmail configuration (always scary). I ran out of other options, though, and so started playing with the Sendmail configuration.

After one attempt that didn't work so well (Sendmail started working on Port 587 but no longer bound to Port 25 -- OOPS!), I finally found a helpful site that showed how to add an entry to the sendmail.mc file to make it listen on both ports. (This involved editing the sacred "Do Not Edit This File" sendmail.mc file -- but that only added to the fun.)

The story has a more-or-less happy ending, with the usual trope of the villian skulking off to do yet more evil deeds in the sequel. My mail is working again, and I have actually managed to modify Sendmail without causing a huge mess.

I gotta get a real ISP one day.

The Sound of Silence

2009-09-25T22:21:00.003-04:00

New toys are always fun, especially when you've heard about them but never actually gotten to play with one. The hard drive in my laptop at work had taken to making slightly disconcerting clicking sounds -- nothing really ominous, but the kind of noise that makes you notice, if you're a computer geek. I mentioned this to my supervisor (also a techie). I figured he'd agree I ought to get a new hard drive. What I didn't figure on was his suggestion that we look into a solid-state drive. (It's a great idea -- but I didn't think it had a chance of being approved.)

Well, it did. I just finished cloning the drive across this afternoon, and it's amazing. These things are probably the future of storage (at least until the Next Big Thing comes along); they're fast (think NO access time to speak of and better throughput), durable (no moving parts means I don't have to worry as much about the laptop rattling around in my backpack), and efficient (running on the old HD yesterday, the batteries gave up after about 2 hours of note-taking in class; today, with the new HD, it ran for 3+ hours, with intermittent Wi-Fi use, and still had juice left when class ended. No need to put an ammeter on it -- I'm convinced. This will definitely help in my classes (one of which is in a turn-of-the-last-century building designed long before students had a need for power outlets).

Solid-state drives are also silent. Not "quiet" -- not "whisper quiet" -- SILENT. When running non-CPU-intensive tasks, it's amazing how quiet the laptop is, now. If you hold it up to your ear, you can hear the CPU fan. I never realized just how much noise the old HD made (relatively speaking).

I gotta get one of these for my desktop. Well, someday -- when I'm not broke.

Under the hood

2009-09-12T11:47:00.005-04:00

One of the most important reasons the Internet is both cool and interesting is its modularity. Different layers of the network model do their thing, without needing to care what the layers above or below them are doing. It makes writing Internet-based applications relatively straightforward, which means we get a lot of cool, shiny toys to play with. This is, of course, a Good Thing ™.

For technology geeks, though, this modularity also means that individual pieces of technology can be learned in relative isolation. You don't have to know or care how (most of) the rest of the stack works in order to teach yourself a new piece of the puzzle.

(A brief and more-or-less-correct description of how the Internet does its thing follows. Feel free to read, skim, or ignore it; the "cool stuff" is below.)

There are generally two basic approaches to learning how the stack of Internet protocols works: "bottom-up" and "top-down." At the bottom of the stack is the physical layer -- the wires, fiber optic cables, or radiofrequency links that actually move the information around. The next few layers deal with the electronics that translate the information back and forth and get it where it's going. Higher up are layers that handle authentication (where needed), and the Application Layer -- which is concerned with actually doing the task at hand. Information travels up and down these layers every time any action is initiated on the Internet (or other TCP/IP network).

For instance, suppose you click on a link to this blog. Your browser, at the Application layer, translates this into a request to the appropriate web server (www.paleotechnologist.net). It then uses knowledge of HTTP (HyperText Transfer Protocol) to formulate a request in a way the webserver can understand. Once this specific, formal request is created, the browser passes it to your computer's network protocol stack, which looks up the IP address of the webserver, packages the request into a TCP/IP packet, and sends it off to your computer's default gateway router, with its destination marked as Port 80 at the webserver's IP address. The packet passes through your computer's network adapter (or modem, if you're on dial-up), to the gateway, which starts routing it across the Internet.

Once the packet gets where it's going, the information makes its way back through the layers in reverse order. The network card on the webserver computer receives the request, strips out the relevant information, and passes it to the webserver program. This program inspects it and finds that it understands the request, gets the information requested from local memory or the hard drive, and creates a reply packet (or many reply packets) containing the requested information. These go back through the same process to your computer, where the information is processed into a web page.

The amazing part is that all of this (usually) happens in a few milliseconds' time.

The HTTP protocol is one of those things that don't always get a lot of attention. It does its thing, so most folks don't think about it. I recently came across a post on Slashdot that suggested taking a look at the HTTP headers being sent out by the Slashdot web server. It suggested running the following command in Linux:

echo -e "HEAD / HTTP/1.1\nHost: slashdot.org\n\n" | netcat slashdot.org 80

Being an inquisitive sort (and not seeing anything really harmful-looking in the command), I decided to try it out. As it turns out, the Linux box I have available doesn't have netcat installed, so I decided to take the lazy way out and try telnetting to Port 80 using Windows. ( C:\> telnet slashdot.org 80 )

Amazingly, it actually worked. Here's what I sent:

HEAD / HTTP/1.1 <enter>
Host: slashdot.org <enter>
<enter>

...and I received:

HTTP/1.1 200 OK
Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4
SLASH_LOG_DATA: shtml
X-Powered-By: Slash 2.005001
X-Bender: The laws of science be a harsh mistress.
X-XRDS-Location: http://slashdot.org/slashdot.xrds
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=iso-8859-1
Content-Length: 99945
Date: Sat, 12 Sep 2009 16:14:08 GMT
X-Varnish: 1558400757 1558400652
Age: 6
Connection: keep-alive

First of all, I just impersonated a Web browser -- and you can, too! How cool is that? You open a Telnet connection to the webserver's Port 80, send a properly-formatted request for information, and it replies.

The other interesting part -- a little wasteful but still cool -- is the "X-Bender:" header. Slashdot's webservers apparently insert interesting little quotes from Bender and other staples of geek culture into their HTTP headers. (If the Internet is the Information Superhighway, think of this sort of thing like the "wash me" and "I may be slow, but I'm ahead of you" messages you sometimes see written in the dust on the back of eighteen-wheelers. The Muggles shopping at the Wal-Marts where the trucks deliver their goods will never see these messages, but they're there if you know where to look. Geeks being geeks, the dark steam tunnels of Internet protocols are no doubt full of such things.)

Finally, a bit of philosophy. The reason it all works -- and the reason that it's so open and free -- is exactly this sort of modularity. Why is playing with the HTTP protocol cool? Not because it's particularly interesting, but because, out there, there's a document that shows the publicly-available, agreed-upon protocol for requesting information from a webserver -- and if this protocol is followed, it works no matter who wrote the webserver, what country it's in, what language the programmers used (or speak), or what information is on the server. HTTP, in turn, rests on other, similar layers, with other, similar protocols. With the proper (freely available) documentation in hand, you could build your own network from scratch -- blowing glass to make vacuum tubes and designing your own computer, and connect it to a cable or DSL modem in your house. If you did everything right, it would work. No magic, no proprietary "sorry, you don't get to see how this bit works," no smoke-and-mirrors. If you use an open-source OS like Linux, you can (in theory) literally understand every movement of every bit, all the way through the whole process. It's both a great way to learn about technology -- and a great way to show just how cool freedom is.

We need to make sure it always stays this way.

Really for the birds

2009-09-11T16:40:00.003-04:00

Now I know what my friend Leon is talking about when he complains about slow Internet speeds in Durban, South Africa.

A company in South Africa, annoyed with the slow ISP connectivity available, decided to stage a race between their ISP and a carrier pigeon, to see which was a faster method of transferring 4GB of call center data logs to their branch office 80km away.

The pigeon won.

Not only that, but it blew their ISP away. In the two hours, six minutes, 57 seconds it took to complete the data transfer (one hour eight minutes flight time, plus uploading, downloading, etc), their ISP (Telkom) managed to transfer only 4% of the data. For this particular application, that's 1/25 of a pigeonbaud, I suppose.

As Andrew S. Tanenbaum famously noted, "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway."

...Or, apparently, of a homing pigeon carrying an SD card. And this one wasn't even highly motivated!

For the birds...?

2009-09-08T22:33:00.003-04:00

Not understanding what all the fuss is about, but being both curious and bored, I decided to sign up for Twitter. Apparently I'm now officially a "Twitterer."

Now, to figure out what to tweet about. (Never mind figuring out whether anyone cares or not -- I have two followers already. Welcome, whoever you are. Good to see there's someone out there more bored than I am, I guess!)

Philosophically, I don't "get" all of this emphasis on social networks. My take on ubiquitous connectivity and IT automation is that one of the really cool benefits of all of this is the extent to which it *reduces* necessary interpersonal contact. For instance, online banking and e-commerce.

However, I may be a curmudgeon and "born old" according to several friends -- but no technologist should dismiss technologies out of hand without a good reason. Twitter seems harmless enough, providing one is careful about the information tweeted -- so why not give it a try?

Right now, though, I'm blogging about tweeting -- and have connected Twitter to this blog via the RSS feed. There's a whole lot of connectivity there -- but it's all self-referential. Is there a point? I guess I'll see.

ROMfoolery

2009-09-03T21:57:00.006-04:00

"I spy, with my little eye, a ROM address beginning with the sequence 0001010000011001..."

I've recently been playing with DS18B20 One-Wire digital temperature sensors (from Sparkfun -- big surprise there). They're fun little devices -- accurate and cheap. They're also insanely easy to wire up, having only three leads (they look just like 2N2222 transistors).

When Maxim says "one wire," they mean it (not counting ground); you can even power it using the data line if you're careful about timings and provide a strong pull-up when needed. Developing microcontroller code to drive them is nontrivial, though (various layers include bit timings, commands and ROM codes etc), but once it's working, they're very reliable.

Temperature A-to-D conversion takes up to 750ms, but you can issue a broadcast command to get all devices on the line to start a conversion at once, then read the results back at your leisure.

Here's the first interesting part.

With a one-wire interface, timing and coordination of reliable two-way communications gets tricky. There's no synchronization line -- and from the description in the datasheet, the timing accuracy of these sensors isn't all that wonderful, anyway. The scheme that Maxim worked out was that a short low pulse represents a one, and a longer low pulse represents a zero. A really long (more than 480 microseconds long) pulse resets the bus altogether.

But wait, there's more.

The interface is specified so that multiple slave devices (I.E. multiple sensors) can share the bus. This takes not only coordination, but implementing the bus with an open-drain configuration (in other words, you use a fairly weak resistor to put 5V on the bus -- and devices are only allowed to short the bus to ground, not pull it high.) This keeps communication collisions between devices on the bus from causing short circuits and burning up output transistors -- but it also complicates timings and the basic communications protocol.

Now for the really interesting part.

Each sensor has a unique 64-bit serial number, which you need to know in order to interface with it. It's not marked on the package (too small) or in the literature you get when you order the part (that would make too much sense), so Maxim provides a "Search ROM" feature, which uses a bizarre take on Manchester coding to send the address back. Two bits are read out at a time for each bit position in the 64-digit ROM code. 01 means the bit is a 0; 10 means it's a 1; 00 means a conflict (someone on the bus sent a 1 and someone else -- maybe a lot of someone elses -- sent a 0); and 11 means that nobody is listening (check the circuit?). By going through bit by bit (with a lot of backtracking, if addressing a lot of these on one line), you can eventually determine the ROM codes for all devices on the line. It's very Byzantine -- but when you think about it, that's really a result of the one-wire interface.

Here's an example of how it would work with simpler devices that only had 4-bit ROM codes.

Suppose you had three devices on the bus, with ROM codes 0110, 1110, and 0101.

The least-significant bit is sent first; this comes back in two-bit Manchester coding as an "00." (I.E. there's at least one of each variety.)

The master (microcontroller) makes a decision at this point, and sends a one or zero. Any devices which match this bit in the first position keep listening; all others go idle and wait for a bus reset. In this case, we'll default to zeros first. The master notes a conflict here, and sends a zero.

Sensor 0101 reads the zero and goes idle. Sensors 0110 and 1110 read the zero and continue, since it matches the least-significant bit in their ROM code.

The master then continues with reading the second bit. This comes back as a "10" -- apparently all remaining devices agree that there is a "1" here. The master records a "1" and continues.

The master reads a third bit, which comes back as another 10. Another "1" is recorded and transmitted.

The master reads a fourth bit, which reads "00". (Another conflict.) The master sends a zero; device 1110 goes idle, while 0110 is made active (having passed all the way through its ROM code). The master records 0110 as the ROM code of one of the devices on the bus -- and records 1110, since it can deduce that; this being the last bit, that's the only possibility.

The master then resets the bus, starts the ROM search process again, but sends a "1" this time when it reaches the conflict in the first bit. Device 0101 remains active this time while 1110 and 0110 go idle. The master then continues with the process; since 0101 is the only device left on the bus, no more conflicts occur.

Think of this process, expanded to 64 bits, and you have an idea of the situation. And not only that -- you then have to figure out which sensor is which, if they are in different positions!

The amazing part is, once the code for this is written, it's all over in a few milliseconds, and the ROM codes appear on the LCD...

PIC programming, Cadillac style!

2009-08-26T13:12:00.003-04:00

I've been working with the PIC18F4620, and am impressed by how easy it is to program, compared to the smaller PICs. I think I'm in love. Or at least in lust.

Here are some of the improvements from an embedded developer's point of view, as contrasted to the (still very cool) 16F887.

32MHz max internal clock speed instead of 8MHz
This alone would be worth it -- a PIC running at 8MIPS! It will go to 10MIPS with an external 10MHz clock, but 32MHz with no external parts needed is very cool. For us PIC16 afficionados, it's like finding out that your new car can go 400km/hr on the freeway, legally, when the old one only did 100.

MULWF and MULLW instructions
You can tell the PIC16 programmers in the audience; they just started drooling. Hardware multiply -- and not only that, but hardware multiply that executes in a single instruction cycle. I see a re-writing of some of my math libraries in the cards!

(almost) NO MORE PCLATH!
Ding, dong, the witch is (almost) dead! GOTOs and CALLs on PIC18s access the entire memory space directly. So, unless you're doing a computed GOTO, you don't have to worry anymore about the value of the high bits of the program counter. No more save-the-old-PCLATH-value-then-set-the-new-one-then-call-the-routine-then-return-then-restore-the-old-PCLATH business. Just GOTO or CALL your routine! And with PIC18s, you really don't want to do computed GOTOs anyway, because now, you have...

TBLRD* and TBLWRT* instructions
PICs are Harvard architecture parts -- meaning they have separate memory spaces for instructions and data. Before the PIC18s, there was no way to access the program memory at runtime -- lookup tables were handled by a series of RETLW statements, whether specific or produced by the assembler from "dt" statements. The TBLRD* and TBLWRT* instructions allow PIC18s to read from and write to program memory. One use of this is to use the (relatively huge) 64kB of program space Flash memory (32 kWords, but addressable as bytes for data use). Large, verbose diagnostic messages can now be programmed relatively easily, with just a little more work than calling printf() from C.

ADDWFC
Add W to F with Carry. This is a bigger deal than it sounds. It will speed up the ADD32 and SUB32 libraries quite a bit, I think.

MOVFF instruction
With MOVFF (which takes two instruction cycles), you can copy a byte directly from one memory location to another, without going through the W register. This doesn't always save time (although it's always at least as fast as the old way), but not having to go through the W register can be very helpful.

Branch instructions
Branch-if-zero. Branch-if-not-zero. Branch-if-carry. Branch-if-not-carry. Branch-if-the-moon-is-in-the-seventh-house, for all I know. Well, maybe not that last, but PICs now have more branch statements than just BTFSS and BTFSC. This doesn't quite rank up there with MULWF or TBLRD as far as I'm concerned, but I'm told it makes the compiler guys happy.

RRNCF and RLNCF
Rotates that don't go through carry. Huh. And RRF/RLF are now RRCF/RLCF, just to break older code, I suppose.

TSTFSZ
Test F, Skip if Zero. Sounds like it could be useful.

DCFSNZ and INFSNZ
Now you can increment or decrement and skip if *not* zero. I'm confused now; this is backwards from how these are normally used. This smells like something a compiler would like to have available.

CPFSEQ/CPFSGT/CPFSLT
Compare F with W, Skip if equal, greater-than, or less-than. Hmm. Equality tests sound useful.

BTG
Bit Toggle, to go with BSF and BCF. Well, I guess it was the missing option...

DAW
Decimal Adjust W. Something to do with BCD math. Sounds possibly useful.

PUSH and POP
More to the point, there's a real, honest-to-goodness stack now! This is a good thing. Low-range and mid-range 8-bit PICs have an 8-entry hardware stack. Except in simulation, it was anybody's guess just how deep into the stack a program already was when a particular subroutine was called. This made for very conservative use of the CALL statement -- and has prompted me more than once to do things with macros that I really shouldn't have.

RCALL
Relative Call. This sounds like a segfault waiting to happen. I hope it's not what I think it is...

Two NOP opcodes
To quote Bob from Frontier: First Encounters, "My, oh my, what happened here?"

RESET
There's probably a legit reason for this, but it escapes me at the moment. Why not just GOTO 0x0000?

MOVLB

Move Literal to BSR? *looks up what BSR is, anyway*

LFSR
Move Literal to FSR? *looks up what FSR is, too*

OK, now for some of the drawbacks:
Nonhomogenous instruction size
In other words, some instructions are two words long, and others are one. This means that you can't just cavalierly do a GOTO $-5 to jump back five instructions anymore, without at least thinking about which instructions are which. If you inadvertently point to a location in the middle of an instruction, the assembler will tell you. If it happens to line up on another one, it won't know anything is wrong until you run it and it doesn't work as intended. Best is to come up with a consistent labeling scheme and make liberal use of good, mnemonic labels, aiming the GOTOs at them instead of using relative jumps. This will also stop you from breaking the code when you add more lines in the middle of the loop, later. (Anyone else been bit by this one?)

They're a bit more expensive
Waah. They're worth it.

Paleotech, through the eyes of a Millenial...

2009-08-13T16:36:00.005-04:00

What happens when you give a modern teenager a Walkman? You get some interesting insights about technology. It's amazing how far technology has come -- and a reminder that yes, there really is such a thing as paleotechnology. (For us children of the 70s, the fact that cassette tapes have two sides is completely intuitive. For someone seeing a Walkman for the first time, perhaps not.) For how many other forms of technology might we forget some of the nuances, or even some of the important things?

Fellow paleotechnology expert DOSquatch writes about the subtle yet extremely important art of troubleshooting. He definitely has a point. I would also add that it's important to document technologies as they are developed, lest we end up having to reinvent them all over again to get them to work (or end up breaking them inadvertently).

Actually, the comparison between a Walkman and modern mp3 players is a good example of how technology is not only progressing, but accelerating. When my grandparents went on a trip to Japan and brought back one of the first electronic calculators, it was definitely new -- but easily understood in a few minutes. When cassettes started to take over some of the role of record players*, they too were relatively easily understood. Increasingly, though, the capabilities of new devices are breaking down old barriers and requiring new ways of thinking about things. (This isn't necessarily a Bad Thing, but it bears mentioning.)

For instance, try explaining the subtle relationship between mp3 files and playlists to someone who doesn't truly grok filesystems, shortcuts, and links. You might be able to explain it, but it will take a lot of explaining. Try a more advanced topic, like why a satellite-modem connection works fine for streaming audio but is horrible for interactive websites -- and the explanation can take much longer. Bring DRM, P2P, streaming, file sizes, bitrates, codecs, protocols, IP addresses, connectivity, lag, bandwidth, Bluetooth, AC3 and oversampling into the conversation, and suddenly you're speaking a foreign language.

Technological progress is definitely accelerating, and every year, I hear more and more people talk about the Singularity. I'm even starting to believe it myself. A lot of it does sound farfetched -- yet technical progress in many fields is starting to look asymptotic. We definitely live in interesting times: they say that by 2025, supercomputers should be sufficiently powerful to run realtime simulations of the human brain. With computer speeds doubling every year or two, we could well end up as spectators to the fastest and most profound changes in history.

As long as we can control the direction things take, though, I, for one, welcome our new robotic overlords.

* Yeah, yeah. Nobody, least of all me, is going to claim that cassettes beat LPs for audio quality. I draw the line at CDs, though. Maybe 44.1kHz/16bit isn't optimal, but it sure beats dragging a rock through a plastic groove.

Digital blasphemy?

2009-08-11T00:32:00.004-04:00

When is a 555 not a 555?

When it's really a PIC!

The design of the DrACo/Z80 computer calls for a 555 timer (a great piece of paleotech, even if it still isn't sure after 38 years whether it's really a digital or analog part.) However, for running higher-speed programs on the DrACo, I wanted to have the option to, as Emeril might say, "kick it up a notch." I figured that a PIC12F683 would do nicely, since it could be programmed to provide a nice, stable TTL clock output without any external components.

The only problem was, the PIC's ground lead is on Pin 8 and its power lead is on Pin 1; the 555 has the opposite configuration. The solution? Possibly the single ugliest soldering job I've done in a long time (and that's saying something, folks.)

Yet, it works -- and is a nice, drop-in replacement for the 555, swapping the astable oscillator mode for a much faster 2MHz clock output.

This is also the single shortest program I've ever written for a PIC:

   org 0x00
   banksel OSCCON
   movlw 0x70
   movwf OSCCON

   goto $

It sets the clock to 8MHz, then sits in a single-instruction loop and contemplates its navel. So, for that matter, when is a PIC not a PIC? When it's not doing any computing at all -- but just providing a 2MHz CLKOUT signal.

But sometimes, the smaller the MCU, the more creative the applications. I've heard of people using microcontrollers in fireworks to provide split-second timing for the pyrotechnics. At 30 cents each for something like the 10F200, it only sounds crazy until you think about it.

...and yeah, this project could have been very easily done with a less expensive PIC -- but 12F683s are so versatile that I keep a couple dozen of them on hand for various things. They're like digital LEGO...

Thatsa lotta beer!

2009-08-10T17:41:00.004-04:00

The statute of limitations is up on this by now, I think...

Back in the day, several ne'er-do-well CS students were enrolled in a certain CS150/151 class/lab, taught by a certain D. Ray with a certain M. Ghose as a lab TA. As the legend goes, they were bored in lab one day (having finished the ridiculously easy assignment in a few minutes, but not being allowed to leave early). They got the idea to put into practice their newfound knowledge of unsigned long integers (32 bits of nonnegative goodness, on those machines) by writing a technological take on the age-old "bottles of beer" song known and loathed by school-bus-drivers everywhere.

The technological take was to make the computers "sing" the verses of "Four billion bottles of beer on the wall" by writing the verses out to a disk. The code looked something* like the following:

#include <stdio.h>
int main(){
   unsigned long long beernum;
   for(beernum=4000000000;beernum>0;beernum--){
      printf("%llu bottle",beernum);
      if(beernum!=1) printf("s");
      printf(" of beer on the wall,\n");
      printf("%llu bottle",beernum);
      if(beernum!=1) printf("s");
      printf(" of beer,\n");
      printf("Take one down,\n");
      printf("Pass it around,\n");
      printf("%llu bottle",beernum-1);
      if(beernum!=2) printf("s");
      printf(" of beer on the wall...\n\n");
      }
   return(0); //Outta beer, outta here!
   }

They finished writing it, so the story goes, just before the lab period ended, and set it in motion, telling their friend in the next section that it might be a good idea to save his work. Apparently the sysadmins hadn't heard of disk quotas, because the drives rapidly filled up with the verses of what had to be the world's longest song. According to aforementioned friend, one of the sysadmins ran into the lab about halfway through the next section, asking for certain students by name.

The interesting thing is, Moore's Law being what it is, while such files might not fit in a user's disk quota, they probably wouldn't crash the server, either; at about 124 bytes per verse, the "song" would take up about 496GB (depending on whose definition of a GB you use.) This would actually fit on the free space on my 1-TB drive on my workstation at home (MSRP of just under a hundred bucks.)

Moore's Law rocks.

* OK, so this isn't the original code by a long ways -- but it gives the flavor. The original:

was written in Pascal, not C;

wrote to the disk instead of standard I/O, and

probably didn't have the fancy "bottle" / "bottles" code

Linus Has Spoken

2009-08-06T13:30:00.003-04:00

I was reading a recent article ("Real Men program in C") recently, and came across a link in the comments to Linus Torvalds' opinion on the whole C-vs-C++ thing. Let's just say he doesn't mince words. (This is an excerpt, but it captures the flavor of the original post.)

What Linus said.

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:

- infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)

- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

Random Thought Of The Day

2009-08-05T16:56:00.004-04:00

I wanna know:

Why does Windows' Task Manager list the size of the "System Idle Process" as nonzero? Also, why is it different, on different computers? My desktop apparently takes 16K of memory to do absolutely nothing, while my laptop (memory hog that it apparently is) takes 28K to do just as much nothing-per-second.

Now, I know 16K or 28K is a drop in the bucket these days -- my laptop has 2GB of memory and my desktop has 3GB* -- but honestly, why should doing nothing be anything more than a line or two of assembly?

* Yeah, 3GB. Not only does the 32-bit version of WinXP not always play nicely with 4GB of memory, but Core i7 processors have three memory pipelines, rather than the more understandable two or four. (Maybe Intel decided they liked Google's "Don't be evil" and decided to go with "Don't be normal" or something. I dunno.) At any rate, Core i7s like their memory in threes. Go figure.

A step in the right direction

2009-07-24T00:56:00.004-04:00

Well, that would explain it...

The reason that the quadruped robot was doing the "funky chicken" instead of walking smoothly was mostly due to a major bug in the gait angle calculations. The angle of the leg is the sum of the "shoulder" and "knee" joint angles -- but the angle commands to the knee servos weren't taking the shoulder angles into account. This caused a really inefficient, jerking motion, rather than the relatively smooth gait that was intended.

Oops.

It's fixed now (and has a new chassis and circuit board). The video shows it moving more-or-less in a straight line, but with a few modifications to the gait tables, it can turn, at least in shallow circles.

Next on the list:

Rubber tips for the feet

Improvements to the turning routines

Turn-in-place functionality

Reverse (basically, just run the gait tables in reverse order)

Wireless control

A second microcontroller to handle control and communications