Silicon Valley Redneck

Geblinkenlights

The current software project doth progress... a couple of days ago I got "Hello, world!" working, and now the lights on the eval board are going blinky-blinky!

That's less trivial than it sounds, really.  "Hello, world!" is of course a trivial program under UN*X, but I'm programming on the bare metal here, and not using cheap workarounds like having putchar() just do polled I/O on the console port.  It's testing not only my printf() implementation (originally written for a 16-bit mini, then adapted to RISC targets using varargs, and now modified for an arbitrary target using stdarg), but also the I/O subsystem and the UART driver.

The current blinky function is exercising the system timer, the event notification subsystem, and task synchronization: there's a task waiting on a semaphore and then updating the lights, and a registered system-timer handler to poke the semaphore every 4 milliseconds.

(Helpful hint: a timer-event mask of 0x0FFFFFFC and match value of 0 gets the first four 1-millisecond timer ticks, and then a 268.4 kilosecond delay.  A mask of 0x00000003 gets a tick every four milliseconds, which is more likely to be useful.)

Anyway: system timer, UART, and GPIO are working.  Project for today: get I2C master support working (this means switching over to the business-card beetleweight battlebot brain board, which has an I2C EEPROM to talk to), and probably also basic SPI master support (that should be a trivial driver).  Then worry about cooked-mode TTY support, and, after that, a little monitor (which can run as an independent task).

Oh, yes: and the embedded operating system (the part of the software project that I've been working on so far) has acquired a name!  Every OS needs a name, right?  Something cute?  Well, since this one nominally ties in with my "Army of Giant Robots" project, it's now officially AGROS.  (And, yes, there seems to have been a giant non-robot named Agros once upon a time.  And AGROS could, in principle, be put to use in farm equipment... but then you'd need a protocol droid to talk to your moisture evaporators, wouldn't you?)  While it was originally meant for the beetlebot board, the first actual use will be in a client project for a vaguely military application.  The beetlebot board probably comes second, followed by some manner of modular test equipment.

Forget the flag - burn a politician!

So, once again the clowns in Washington have nothing better to do than try to amend the Constitution to prohibit desecration of the flag.

If they don't have anything more important to so, can't we just send 'em home and stop paying their salaries?  Or should we regard this as a welcome distraction from the worse mischief that they would otherwise get up to?

I don't really get the whole flag-worship thing anyway; it's always struck me as idolatrous, but then I've never had any formal instruction in this religion stuff, so maybe there's some special dispensation for worshiping colored bits of cloth, as opposed to golden calves and such.

Anyway, some folks whose patriotism can't reasonably be questioned have come out in opposition to the nonsense.  On the other hand, looking at the vote, I see Feinstein voted in favor.  This should be a good whack upside the head to anyone who still believes that she's in any meaningful sense a liberal; it's been obvious to me, as long as I've been paying attention, that she's a completely illiberal authoritarian who happens to take the party line on selected "liberal issues."

Now, just for the sake of argument... suppose the Constitution did allow laws forbidding flag desecration.  This inevitably leads to trouble: how, after all, do you define desecration, or for that matter flag?

Does the category flag include all representations thereof?  Including postage stamps with pictures of flags?  Is licking the back of a flag-themed stamp desecration?  What about cancelling such a  stamp?  Must a used, flag-themed postage stamp be disposed of in accordance with the rules for worn-out flags?

If burning (other than for respectful disposal) is desecration, what about Fourth of July fireworks with red-white-and-blue, starry-and-stripey wrappers?  Those wrappers are sure to get a mite singed at best.

For that matter... what about display fireworks that, when lit, create a blazing image of the flag, in red, white, and blue fire?

Clearly, flag desecration, like Witchcraft and Magic, is a matter of symbolism and intent.  This puts it firmly in the realm of religion, and the flag-protecting crowd are, in effect, attempting to establish a state mini-religion centered around the flag.  Is this really a can of worms we want to open?

Update: CDR Salamander also notes the idolatrous aspect.

Oh, and there's more over at Castle Argghhh!

What the world needs now...

Much as I dislike multifunction gadgets in general, I can think of one that'd be great for outdoor adventurers, if it were properly integrated.

Start with a modern smallish digital camera, with TV-quality video capability, including sound.

Now make it waterproof.  Doing this while including one or more microphones is left as an exercise for the student.  If you can retain a 3X zoom lens, that's great, but not essential.

Multifunction add-on #1: voice notes.  Stick a microphone on the back, and a button to toggle voice recording.  Allow the user to take pictures while narrating.  Keep everything time-stamped so that photos and commentary can be correlated.

Multifunction add-on #2: GPS.  Add in a little GPS receiver.  When it's powered up, capture the coordinates on events (take picture, start/stop audio recording, start/stop video recording).  Store the coordinates with time stamps, so they can be correlated with photos, video, and commentary.

Now you've got something for the hard-core vacationer who insists on recording for posterity his rambling holiday through the diesel decks, and inflicting the slide show on any available audience!

It'd also be handy for mapping trips with the intention of returning later, or just sharing with the world the details of how to get there, and where things are along the way.

Oh, heck, this'll probably be on the market soon anyway.  Only it'll claim to be a cellphone, and it won't be waterproof, and the camera function will be sub-megapixel at best.  But you'll be able to call for directions on it....

What... is the space-speed velocity of an unladen Skylark?

OK, we've all read the sci-fi tales of great ships of the void zipping hither and yon at extreme speeds, whether it's Doc Smith or David Weber.

Often, the ships must accelerate to some large fraction of lightspeed using some form of conventional propulsion, before being able to zap into hyperspace. Or, they just go Really Fast in normal space.

So... just what are the energy requirements here?  How much of the ship has to be fuel, and how fast can it go?

For simplicity, I'll examine the as-built Skylark, in which Richard Seaton went gallivanting off to Osnome.  (This is based on the heavily-revised 1958 Pyramid edition of The Skylark of Space, 'cause that's the one I've got in front of me.)  This is a fairly simple one, for various reasons:

• Relativistic effects don't apply, for reasons that are hand-waved away.
• The propulsion system uses total conversion of matter to energy, which saves me the trouble of looking up the energy yield of fusion reactions.
• The propulsion system is also, presumably, perfectly efficient, and apparently reactionless.
• The mass of fuel is stated in the book.

So, let's see now: “It was a spherical shell of hardened steel of great thickness, some forty feet in diameter.”  Weight, “thousands of tons.”  The energy source is total conversion of copper: four-hundred-pound bars thereof; with four bars aboard, the energy of one is available for outbound acceleration, so we'll use that.  When the Skylark is rebuilt with an arenak hull, the “great thickness” of the original is revealed to be four feet.

OK, now, we've got some numbers we can work with.  Converting to real units, we have a steel spherical shell of outside radius 610 cm, and inside radius 488 cm, for a volume of 464 million cm³; taking the density of steel to be 7.86 g/cm³, that works out to 3.65E+6 kg, or 3650 (metric) tons, for the hull, disregarding portholes and the massive internal structures.

To accelerate this, we have the energy a 400-pound copper bar, converted entirely to usable energy; 1.814E+2 kg converts, using the famous formula, to 1.63E+19 Joules.

So, when a 3.65E+6 kg object has a kinetic energy of 1.63E+19 J, how fast is it going?  Last I heard, E=½mv², so v=sqrt(2E/m) = sqrt(8.96E+12 J/kg) = 2.989E+6 m/s.

Just about 0.01c.  Well, I guess we didn't have to worry about those relativistic effects after all.

And so much for gallivanting around the galaxy.

Note that none of this applies if the hero has some sort of inertialess, or low-inertia, drive, such as a Bergenholm; with those, the mass of the ship is eliminated or reduced, so that kinetic energy ceases to be a consideration (or at least is scaled down).

Update, a few minutes later: Corrected a couple of numbers; I forgot to apply the 2 in sqrt(2E/m) the first time around.

Ahhhh, that's better!

Not only has the weather cooled down a bit from Oven Wednesday, but I found the opportunity this morning to get a much-overdue summer haircut.

Much cooler.

As Arnold Rimmer's father always said, "Shiny clean boots and a spanking short haircut and you can cope with anything."

 

Now, if you'll excuse me, I have to go shine my Tevas.

What the...?

This project I'm trying to get running on the LPC2148 eval board is being uncooperative.  The processor keeps bounding off to strange places at arbitrary and unpredictable times.

Only having two breakpoints available, I'm kinda limited in how fast I can debug stuff like this - I can't just set breakpoints everywhere and wait for one to  trip.  Besides, it seems to be highly timing-sensitive, and setting a breakpoint in the right place will make the problem not happen.   ("Ship it with the scope attached!")

Eventually, I catch it at the data-abort vector; examining the registers, I find that it was executing perfectly ordinary code with some entirely wonky values in the registers.  Being as how this sometimes happens, and sometimes doesn't, without an intervening power cycle or any such thing, I rather suspect it's not an uninitalized-data problem, but rather something related to an asynchronous event, like the UART interrupt.

So, I take a look at the generated code for the UART interrupt routine:

my_irq:
.LFB4:
    .loc 1 157 0
    @ Interrupt Service Routine.
    @ args = 0, pretend = 0, frame = 0
    @ frame_needed = 0, uses_anonymous_args = 0
    sub lr, lr, #4
    stmfd   sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, ip, lr}
.LCFI1:
    .loc 1 164 0
    mov sl, #0
    ldr r9, .L43
    ldr r7, .L43+4
    .loc 1 157 0
    sub sp, sp, #24

[my code]

    add sp, sp, #24
    ldmfd   sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, ip, lr}
    subs    pc, lr, #4

Now, is it just me, or is the return address getting decremented by 4 twice, once before pushing and once after popping?

Let's try compiling an utterly trivial interrupt routine.  Well, not utterly trivial; we'll include a function call to force at least a little bit of overhead:

my_irq:
.LFB2:
    .file 1 "foo.c"
    .loc 1 7 0
    @ Interrupt Service Routine.
    @ args = 0, pretend = 0, frame = 0
    @ frame_needed = 0, uses_anonymous_args = 0
    sub lr, lr, #4
    stmfd   sp!, {r0, r1, r2, r3, ip, lr}
.LCFI0:
    .loc 1 8 0
    bl  thingy
    ldr r3, .L2
    str r0, [r3, #0]
    ldmfd   sp!, {r0, r1, r2, r3, ip, pc}^

Kinda different, huh?  Like, the return address gets decremented by 4 before being pushed, and then just gets popped on return?

Ya think maybe doing the decrement twice could, oh, I dunno, maybe cause some instruction to get executed a second time, wherever the program happened to be running when the interrupt happened?

Something is rotten in the state of gcc 3.4.3 for ARM.

Hmph.  Well, rather than debug the compiler, maybe I need to provide my own assembly-language wrappers for interrupt routines.  This is annoying.

Update:

I still don't know why the compiler was doing that, but writing the little wrapper in C appears to do the right thing, provided that the function that provides the guts isn't declared static (as a static declaration allows the compiler to optimize it).

As for the bizarre, timing-sensitive crashes: those turned out to be the result of the main task blocking on a semaphore during synchronous I/O.  Meanwhile, the background task went on testing intertask comunication by putting messages into a queue... which the main task, being blocked, wasn't reading... the queue, not having a limit set on it, just went on gobbling RAM, at 20 bytes per message... the memory allocator didn't deal nicely with an out-of-memory condition, but just returned NULL, which led to an attempt to write to low memory... low memory is flash, and normally non-writeable, but the low 64 bytes are actually vector-table RAM... so, the vectors got clobbered, and then the processor ended up in hyperspace.

"I'm for the extreme middle"

There's a new call for extreme centrists!  Armed Liberal links to a post by Bull Moose, calling for moderates with attitudes.

It does seem, these days, that the only opinions that get any attention are extreme ones.  This black-and-white attitude, at any end of the political spectrum, is not conducive to consensus nor progress; rather, it encourages activists to cluster with their own kind and reassure each other that their faction is the majority.

It poisons the information supply, too, as political news all too often consists of a press release by one extreme faction, with a token quote from an opposing extremist for "balance."  Two sets of lies, and no truth in sight....

I offer a great example of a moderate/centrist with an attitude: Walt Kelly.

Try to get your hands on some classic Pogo comics, from the 50s and 60s.  Note the funny-friendly presentation of the plain folks, despite their flaws, and the ruthless skewering of the Jack Acid Society and Mr. Pig and his goat alike.

As Pogo himself once remarked, when asked whether he was left or right: "I'm for the extreme middle."

Sumer is icumen in

Lhude sing cuccu, and all that.  Just so you don't, as Michael Flanders remarked, go around singing cuccu rather too lhudely.

It sure feels like summer around here!  We may have had unseasonable sleet on the vernal equinox, but the summer solstice has brought decidedly summery weather.  Doesn't look like a brief summery, either; it's likely to drag on for a while.

Now, dont get me wrong: hot summer weekends are fun once in a while; I like to go play in rivers, and the day of the innertubing outing is approaching.  During the week, though... it gets unpleasantly hot here at SVR Central, which decidedly impairs my productivity.  (This from the guy who shows up at the ice rink in Hawaiian shirt and shorts, and complains about the heat.)

Guess "getting a summmer haircut" should be drifting up my priority list....

"Net neutrality"

Net neutrality is one of those subjects that generate huge amounts of nonsense from both sides.

Proponents, i.e., content companies, seem determined to proscribe any form of tiered service, i.e., allowing providers to charge more for guaranteed latency times and such, and claim that network companies are trying to shut them out.

Opponents, i.e., network companies (telco and cable) like to claim that the content companies aren't paying for use of the network.  This is complete nonsense, as the content companies pay to put their data on the net, and end users pay to take it off the net.  If the network companies aren't making a profit carrying the bits, then perhaps their pricing structure is broken.

The network companies certainly have engaged in predatory business practices; about the time I got DSL, the phone company was offering "unbundled" DSL (line only, use your own ISP, pay the ISP for bandwidth) for $40/month, and, IIRC, bundled DSL (including phone-company internet services, including bandwidth) for $30/month.  That's -$10/month they were charging for their in-house internet service!  Naturally, the independent ISPs were not happy about this.

As near as I can tell, the key problem is that the network companies want the best of common carrier status, such as an absence of liability for the content of the bits they carry, but they also want the ability to discriminate among customers.  The former is important, because without it the Internet as we know it couldn't operate.  The latter is a natural side effect of the network ("we just carry bits on a wire") companies also being content ("come see all the shiny things we provide to entice you into subscribing to our broadband service!") companies.

I find the mixing of company types extremely annoying from a consumer (or prospective consumer) perspective.  Last year, I was curious about EVDO, so I surfed on over to Verizon to see what they had to offer.  Did they have a nice chart of what connectivity they offer, where it's available, and what it costs?  Nope.  What they had was pages and pages of "look at all the shiny additional content we want to sell you after you sign up for this!"  Nothing at all for someone who already knows that he wants wireless internet connectivity, and why he wants wireless internet connectivity, and just wants to know what Verizon is offering in the way of bit transport.

Now, here's my modest proposal:

Keeping in mind that the network companies aren't truly private companies - their business is dependent on government-granted powers, such as that of stringing wires through people's backyards - it makes sense to regulate them, to some extent, as public utilities.  (If they aren't public utilities, I want to start charging rent on that telephone pole in my yard.)

So, what's a reasonable regulation that's consistent with utility and common-carrier status, allows tiered service, and prevents discrimination?

Simple - and, I think, well-precedented.  Require the network companies to publish their pricing, and to charge the same to all customers for the same service, even if the customer is another division of the network company.  It makes for funny bookkeping, but would help keep the net a  fair-play zone.

GoogleNAK: "skating for engineers"

GoogleNAK: a word, phrase, or concept which is unknown to Google.  Compare Googlewhack.

GoogleNAK in this sense (i.e., that word being used to represent this concept) may have been, up to this moment, a GoogleNAK in its own right, but I'm not going to wade through 37 googillion results in Hungarian to make sure (nor even the 22 googillion Hungarian results returned by an "English only" search).

Anyway, my search for the phrase "skating for engineers" (or "skating for physicists") returned a NAK, or Negative AcKnowledge, i.e., no results.

This being the day of the last session of the beginner figure-skating class I've been taking, and me still being baffled, I thought maybe there was an explanation out there of how the skates are meant to be employed, in terms an engineer (or a physicist) could understand.  Something like a "poetry for physicists" course.  Well, not really... there's obviously a lot of physics going on in ice skating (unlike poetry).

Obviously, the "skating for engineers" lesson would start out by explaining what the different bits of the blade are for, how they're used, and the forces involved.  That's something that isn't covered anywhere in the beginner class I've been taking (unless we get it on the last night, which seems unlikely, not to mention backwards).

Oh, well... I've pretty much got the hang of "forward."  I can manage "backward" too, but without much style.  "Stop" is problematic: my snowplow stops don't work, and end up hurting my back, and my hockey stops come out as hairpin turns, i.e., I end up spinning around and going in some other direction with the same speed I started with.  This leaves crashing into something (suboptimal), or catching a toepick on the ice and doing a belly flop (double plus ungood).

The instructor, not being an engineer, explains these things in ice-skater terms, which don't seem to translate well into Engineer.  No diagrams on the blackboard showing where the force vectors are meant to go, or what the blade angles are supposed to be, or any of that stuff.  No blackboard, for that matter....

Culinary note

Blackberry ice cream with whole blackberries isn't a good idea.

The berries freeze into big, crunchy, tasteless lumps.

Either smoosh the berries before mixing and freezing, or make the ice cream separately and then add it to room-temperature blackberries.

Disturbing search request

OK, so some Romanian found one of my archive categories with a search for eeprom piercing washing machine (the words, not a phrase).

It's one of about 871 results... but... what the heck was he looking for, really?

Pesky boundary conditions.

So here I sit, bringing up a fancy new interrupt-driven I/O system for my LPC2100 microcontrollers, and of course the first device I want to support is a UART, so's I'll have a console.

There's an interesting gotcha: the interrupt logic on the UART has gone all user-friendly, and tries to avoid extraneous interrupts, especially in the "transmitter ready for data" department.

The THRE interrupt (as opposed to status) is only asserted if (if I'm grokking this properly) THRE status is active, AND the enable bit is set (fine so far), AND the THRE bit has actually made a 0-to-1 transition (so, like, you won't get the interrupt just by setting the enable on an empty transmitter), AND there have been at least two characters in the transmit FIFO at one time since the last THRE interrupt.

Whoops.  That last condition means the transmitter has to be fed at least two characters per TX interrupt - possibly three; it's not clear - or there shall be no further THRE interrupts.

Fingle fratz.  I guess I need to have a "stuff the transmitter" function which is called from both the interrupt routine and the "start I/O operation" routine, which feeds the transmitter until the FIFO is full, or the data runs out, or both.  (It doesn't help that my I/O system uses queued I/O requests, so it's not a simple matter of increment pointer, decrement count - this function has to check to see if there's another request in the queue, and grab its data - not forgetting to invoke the callback function of the just-completed request - and 'round and 'round....)

Update: Oh, this just gets more and more wonderful.  It appears that, upon the writing of a character to THR, the THRE bit in the status register goes away for an unspecified amount of time before coming back... so, in fact, there's no clear feedback as to how many characters can safely be stuffed into the FIFO, unless I can determine what's the necessary amount of time to wait (setting a breakpoint between the THR write and the LSR read seems to do the trick).

Just to be helpful, Philips has an app note, AN10369, which includea UART sample code.  The sample transmit code just dumps data into THR until it's out of data, then writes an additional LF and CR, then waits for TEMT.  Yeah, that shows how to use it in real life!

Further: Hokay, so THRE is actually "empty FIFO" status, not the more traditional "FIFO not full" status.  So, if we just happen to know it's a 16-byte FIFO, we can dump "16 bytes, or until we run out" of data into it.  Means I need another counter.

"static" is a scope! No, it's a storage class!

It's a scope and a storage class!

This is one of those things I've long found philosophically annoying about C for many years now, but this is the first time it bit me.

I've got this array of structs that needs to be accessible from outside the current module, but not by name - only as part of an aggregation of all such structs from all modules.  No problem: I apply the gcc (section("these_things")) attribute, and have the linker script sweep 'em all together.  Since there's no need for the name to be global, I simply declare the array to be static, and I can use the same name for it in all modules that do this sort of thing.

Oops.  Not so fast.  Turns out gcc apparently thinks the static storage class takes precedence over the section attribute.  Since the static scope can't be separated from the static storage class - there being no private keyword to use instead, to get just the scope - it seems I need to rethink the whole thing.

Grrrrr.

Argh.

I keep forgetting that the IRS has a funny definition of "quarterly":

First quarter is three months long.

Second quarter is two months.

Third quarter is three months.

Fourth quarter is four months.

Who comes up with this stuff, anyway?

I guess it's just another of their cute revenue-enhancement schemes, to encourage late filing and consequent penalties.

Well, ha-ha, Mr. IRS!  Thanks to my laziness in the invoicing department, I didn't have any income for April and May, so there!  (But I guess I'd better document the temporal distribution of my income this year, so I don't end up with quarterly underpayment penalties on an overall overpayment, as happened last year.)

Stupid DOD tricks

El Reg reports:

According to Paul Marks writing in the 7 January 2006 New Scientist, the US Department of Defense plans to develop a lie detector that can be used without the subject knowing they are being assessed.

The Remote Personnel Assessment (RPA) device will also be used to pinpoint fighters hiding in a combat zone, or even to spot signs of personal stress that might mark someone out as a terrorist or suicide bomber. The RPA will use microwaves or laser beams reflected off a subject's skin to assess various physiological signs without the need for wires or skin contact. The RPA will focus a beam on a moving or non-moving subject and use the reflected signal to calculate pulse, respiration, or galvanic skin response.

Hmmm...

Y'know, the current enemy has a habit of fighting all wrapped up in clothing, with their faces covered... in an area where being dressed like that isn't terribly unusual.  Little or no skin exposed to probing lasers.

Besides which, a lot of people get nervous around goups of People In Uniforms With Weapons.  Especially in places with a long history of repression, where PIUWWs have always been the beloved leader's goon squads.

Hey, they ought to try it out in San Francisco.  Send a U.S. Army patrol (or parade, whatever) around the city with one of these gadgets.  They'd probably round up half the population for being stressed at the sight of our troops.

Well, it does make sense...

Apparently, the newly-coalescing Iraqi government is planning some form of amnesty for insurgents (but not, presumably, for terrorists) as part of Prime Minister Maliki's reconciliation program.

The most concrete notion at this point is amnesty for those who've killed Coalition soldiers, but haven't harmed Iraqis.

It makes sense.  After all, shooting at our soldiers makes one an enemy of the U.S., but not necessarily an enemy of Iraq.  The insurgents who are shooting at our troops might well desist when our troops leave... notably unlike the terrorists who are blowing up markets and mosques.

So, an amnesty has the potential for quieting down one class of violent factions, and bringing them into the system, which seems much preferable to leaving them as bands of permanent outlaws.

Donald Sensing has much commentary, including a reference to the various pardons and amnesties during and after our own Late Unpleasantness, and compares Prime Minister Maliki's actions to those of one of our venerated past leaders.

Well, we shall see.

 

So here it is Thursday already

It can't be Thursday yet - the week's going away too fast - there's a bunch of stuff I need to get done by next week that's nowhere near done yet!

But Thursday it is, and my wakeup earthquake arrived at about 5:25 this morning, getting me out of bed a bit earlier than usual.

It's the anniversary of the great political earthquake of 1215 CE, but I didn't get around to planning any sort of celebration... not even to the extent of trying to arrange an evening outing at the Runnymede Sculpture Garden or anything.

No time to ramble now; there's work to be done... updating a hardware design for one client, and coding up more of the underpinnings for another client's software.  And there's a bunch of yard work to do, including dealing with a bloody great branch that fell off the avocado tree in early spring.  Oh, and adding up the numbers on my calendar and writing up a couple of invoices - one of those pesky details of business.

Bush goes to Babylon...

...meets with Prime Minister Maliki...

Next thing you know, we'll have a non-aggression treaty with the Centauri Republic.

Update:

Bush and the Prime Minister reach agreement on the Euprates Treaty.

Zere are two kinds of news in zis vorld...

...zere is good news, und zere is bad news.
</siegfried>

The good news: Google Earth is avalable for Linux!  Hooray!

The bad news: it gives my system (Debian-stable, fancy-schmancy Radeon graphics card, XFree86 4.3.0) a terminal wedgie: no response to the keyboard; no response to mouse clicks; I can push the cursor around with the mouse all I want.  Oh, and I can ssh in from the next machine over, but attempting to kill the googleearth process wedges the ssh connection.

Wedge, reboot, try again, wedge again... I think I'll discontinue the experiment on this machine.  Maybe I'll try again on a sacrificial system, IMCFT.