Silicon Valley Redneck

Where did that come from?

When I went for my morning walkies at Rancho San Antonio on Monday, something was different.  There... in the big meadow in the county park... by the picnic area...

It wasn't there on Friday.  So what happened?  Did somebody plant a monolith seed on the solstice, and it took a week to sprout?  How big is it gonna get?

I have an urge to dance around it, waving a bone.  Or, perhaps, to invite a bunch of people to show up in monkey suits....

There's no inscription.  Yet.  Will one appear tomorrow?  Is this destined to be California's headstone, when the absolute drop-dead must-have-a-budget date can't be put off any longer?

First chipmunks, now unexpected standing stones.  What next, crop circles in the oak trees?

Just what the world needs!

A blog dedicated to the greengrocer's apo'strophe.  (Via Insty.)

RAM. We gots RAM.

Box from Newegg arrived this morning.  Oh, goody!  Unpack 2x 2GByte Corsair RAM modules.  Plug into workstation, on top of the 2 x 1GByte modules that were already in there.  Reboot.  BIOS sees 6G.  Linux sees 2.7G.  Er...

OK, rebuild the kernel with the "more than 4G of physical memory" option set and reboot again.  Re-install the Nvidia driver to go with it.  And...

Yep.  Six flippin' gigabytes of RAM.

Well, I tend to leave the system running for months at a time, with many programs spread across 14 virtual desktops, and some of those (Firefox, Acrobat, and such) are cumulative memory hogs.  And here I am getting ready to route some fine-pitch, multi-layer boards with EAGLE, which gets memory-hungry in a hurry when you start using a 0.001" grid for the autorouter.

And, after all, the extra 4 gig cost me less than I paid for my first kilobyte of RAM, back in the day.  (Eight 2102s, at many dollars each - I had to mow a lot of lawns to pay for that.)

Now to see how long it takes for this system to go into paging again....

Update: well, after a busy afternoon, memory usage stands at 2.2G, so it would have been paging by now without the upgrade.  (And the screen-blanker is the first thing to get paged out, and it doesn't get paged back in, so once paging starts, my monitor stays lit up unless I turn it off manually.)

What a difference 21,290 miles make

About $1300, in this particular instance.

A couple of times in the past, the Prius had exhibited a Known Issue: the engine would start up a bit too slowly on a cold morning, and the computer would declare a timeout and light up all the panic alerts.

On those occasions, the code somehow always cleared before I got it to the dealership.

Well, this warm morning, with the engine warm from earlier driving, it happened again, and it didn't clear.  So, time to get it fixed....

Now, all it really needs is a parameter tweaked, to accommodate the slower-than-expected startup of a cold or aging engine.  Alas, the ECU in the NHW11 doesn't accommodate field firmware upgrades, so the solution to error code P0300 ("random multiple misfire") is to replace the entire freakin' engine ECU with one that has the new version of the firmware.

And it couldn't, naturally, have done this repeatably while it was under warranty.  Oh, no.  It had to wait until the warranty had unmistakably expired before it would do that trick for the service department.

Oh, well.  It's back to normal operation now, and I expect to keep it for another few years.  I don't think there are any further Known Issues with the NHW11, aside from early failure of the auxiliary battery... which hasn't happened to me yet, in the 7 years I've had the car.

More parts bite the dust

I just came up with a totally cute use for an LM3900.

Alas, the 3900, along with its I-temp sibling the 2900, was discontinued a decade ago.  Besides which, what I'd really want would be an LM1900, which, as far as I can tell, never existed in the first place.

Well, maybe an LM159 would do the trick.  Except, er, only the LM359 is still around, and C-temp parts just don't cut it.  And it's not like the quantity is large enough to get National to make (or qualify, or whatever) a run of 159s.  And I don't want to design in a part whose future availability is suspect, anyway.

Oh, well... I wanted it for, basically, a cuteness feature (with some practical application in troubleshooting).  A little more looking around for suitable parts may yet be in order, but it's not a disaster if I have to drop the feature.

Well, isn't that special.

The One is trying to take unofficial credit for inspiring the protests in Iran?

And now, of course, the protesters, having supposedly been motivated by his noble rhetoric, are on their own.

Bay of Pigs?  '91 Shia uprising?

Projecting weakness, anyone?

Yes, by all means, rise up against your rulers who are our enemies.  Just don't expect us to stand by you in any meaningful way when you do it.

Or, this time, even in symbolic ways.  Cultivating good relations with the tyrants is so much more important, you understand.  They're people who matter, and who serve caviar.

Verrrry interesting

It seems that a pair of Columbia U. students have analyzed the Iranian election results and found evidence of human-generated random numbers.

A study at MIT back in the 70s (OK, so it was a few students chatting in a hallway) determined that 17 is the most random number, 137 is also a highly random number, and that, in general, numbers consisting of odd digits and ending in 7 are random.

And what did this new analysis find?  Yes, a disproportionate percentage of the vote counts ended in 7.  In fact, 17% of the results ended in 7... which suggests meta-randomness.  Further, only 4% of the counts ended in 5; it is well known that numbers ending in 5 are not random.

So, too many 7s and not enough 5s could be an indication that the numbers were chosen to look random rather than made up... as opposed to actually being random down at the last digit.

Back to buyin' stuff on eBay

After a considerable interval, I'm back to eBay for some odds and ends, and finding some pretty good deals.

Last week, I got an old HP 8111A pulse generator, so I can stop borrowing from a client when I need one.  (My old analog pulse generator doesn't do small duty cycles, and Project Egbert will need testing with duty cycles from a few ppm up to 3% or so, at various rates.)  It's slightly out of calibration, but I'd ordinarily have a reasonably-calibrated oscilloscope hooked up for measurement purposes anyway.

I also bought one of those $10-with-free-shipping green laser pointers.  It's chunky (the size of the red laser pointers of 15 years ago), puts out a lot of IR (rated output power is 5 mW, but my laser power meter says 15 mW or so), and temperature-sensitive (only puts out green at room temperature, and starts out Very Bright when it's turned on, falling off to merely Bright over half a second or so, starting from summer room temperature).  But, c'mon now: $10 for a pocket-sized green laser?  Heck of a deal.

Now I'm looking at those bargain-basement laser modules based on Blu-Ray lasers.  Hmmmm... and, mayhap, appropriate goggles to go with them, given the rather dangerous power levels they can put out.  Funsies!

The components I want never seem to exist

As I get further into Project Egbert, I fail to find some components that would be terribly useful if they existed.  Well, useful for me, at the moment, anyway.

Component #1: a diode array consisting of, e.g., 8 independent diodes connected from side to side of a 16-lead TSSOP, or other itty-bitty package.  Preferably Schottky diodes, rated at least 30V and 10 mA.  How is it that nothing even remotely similar to this seems to exist?

Component #2: a configuration register.  Take, say, yer basic I²C I/O expander, with 16 output pins, and put an EEPROM bit in each output cell.  So, once it's been set at the factory, it'll power up the same way every time, without having to wait for the processor.

Component #3: an I²C I/O expander with high-voltage outputs, or at least high-voltage-tolerant open-drain outputs.  With the I²C interface compatible with my 3.3V system, please.  By high-voltage, I mean at least B-series CMOS levels (up to 18V).  Doesn't need 250V drive or anything like that.  It does need to come in a fiddly little fine-pitch package.

And, y'know, if #2 and #3 were to be combined, it'd be ever so handy for making Egbert's interfaces wake up in the right state, without using huge amounts of scarce board space nor resorting to (ugh) stuffing options.

Update: I guess #2 is called an EEPROM DIP switch.  And they do exist, kinda-sorta.  Just haven't found one yet that's just that function, without fiddly MUXing in of external switch inputs (which I don't need, and it eats pins and, thus, board space).

Dumb reporting, dumb branding

Heading out for walkies this morning, I caught an announcement on the radio that the FDA was advising consumers not to use some Zicam products, as they could damage the olfactory faculties.

One of the announcers remarked that the products weren't regulated by the FDA, because they're homeopathic.

Wrong.

The products in question contain zinc, which is the problem.

The homeopathic products contain no actual zinc, and thus can have no side effects (and no primary effects either, but that's another matter).

Which brings us to the dumb-branding thing.  I'd noticed before that Zicam-branded products come in two basic types: with and without active ingredients.  Why, exactly, you'd want to have similarly labeled product lines that are so utterly different escapes me.

Well, maybe it's a good wheeze.  Cold remedy with unproven ingredients, $10!  Cold remedy with no active ingredients and no side effects, $15!  Hey, maybe I should get into that business.  I'm sure I could come up with an impressive-sounding list of ingredients not to include.  (Outgredients?)

Hey, something convenient!

If you're like me, and occasionally design something with an Ethernet port, you've probably found yourself scrounging around the network-card bonepile for MAC addresses to use on your prototypes... and wondering how best to handle the addresses for the pilot run, when maybe plunking down $1650 for your own OUI seems like overkill, even if it does work out to a measly $0.0001 per address.

Well, it seems the IEEE has kinda-sorta taken this into account, and will now sell a block of 4096 addresses for only $550, which works out to about $0.135 per address.

Surely there's a better way?

Well, yes.  Turns out Microchip will now sell you a one-each MAC address on a chip for $0.36 (Digi-Key pricing), or $0.24 each in hundreds.  That comes bundled with 128 bytes of EEPROM, and a convenient SOIC or SOT-23-5 to carry it around in!

The part number is 24AA02E48.  Worth a look.

(I'd heard rumors of MAC addresses being sold as rolls of preprinted barcode labels, but haven't managed to find a vendor.  The chip approach seems better suited to my purposes anyway.)

Update: well, not quite as convenient as it might have been.  It's based on the 24AA02, which... oog... responds to all eight of the I2C EEPROM addresses, 0xA*.  The three address-select pins present on the SOIC are not connected, and the low three address bits on the bus are simply ignored.

Why couldn't they have based it on a housebroken part?

The reward for a job well done...

...is another job.

Well, I guess I shouldn't complain; there are plenty of people out there with no jobs at all.

Still, I've had very busy days all week, and I still haven't gotten to the work I had planned for Monday afternoon.

I had that work scheduled for this afternoon.  Definitely.  But, then, just as I was finishing up the semi-definitive answer to yesterday afternoon's panic, someone dropped another urgent item in my lap... relating to yet another Egbert spinoff, which I suppose must be... let's see, now... Ethelbald is the one with the Ethernet requirement, so this must be Ethelbert.  This points to yet more work a few months out.

Then, being done for the day with high-priority revenue stuff, it was time to do some writing for a new venture.  By that time, though, my brain was fried.  Well, I got something written, anyway, and it's a starting point for further discussion (which is kinda the phase the venture is in now).

And now it's time to plunk myself down on the sofa with a book.

Maybe tomorrow I can get some real work done on Egbert, before I completely forget where I was on it.

Not the Collapsing Hrung Disaster we were expecting

The Great Collapsing Hrung Disaster supposedly wiped out the Praxibetel colonies on Betelgeuse Seven.

The Great Collapsing Betelgeuse Disaster has presumably wiped out all the planets in the vicinity of Betelgeuse by now.

Zaphod Beeblebrox, however, escaped the disaster.  Have you spotted him yet?  Hint:

“If there's anything more important than my ego around, I want it caught and shot now.”

And:

Only six people in the Galaxy knew that the job of the Galactic President was not to wield power but to attract attention away from it.

Zaphod Beeblebrox was amazingly good at his job.

Hmmm... does this match anyone you know?

Busy times

Well, it looks like I'll be kept occupied the rest of the year.

AGROS is now almost ready for Project Egbert, and the anticipated follow-on / co-project, Ethelwulf.  (I still need to add an improved inter-task communication feature, and support for task-based state machines.)  This means that Monday is time to get back on the clock for most of the day, and work on the actual client project... and probably stay in that mode for the next week or so before the next digression.

Last week brought an inquiry about Project Ethelbald, which - surprise! - requires Ethernet.  I'd anticipated someone, eventually, having such a requirement, but figured it was a couple of years off.  Anyway, from a hardware perspective, I was now able to give the right answer, i.e., "Sure, we can do that, and here's how," rather than the more traditional, "Um, let me get back to you on that."

So, there's now a customer-driven need to add Ethernet (and TCP/IP) support to AGROS for the LPC23xx.  Shouldn't be too much trouble, especially since there's BSD-licensed code out there that's quickly adaptable in a pinch.  (I should probably write a wrapper for it, to cover both technical and licensing aspects.)

And, also last week, one of my other associates came up with a new business opportunity, involving a product rather like one that I've contemplated on and off over the past 15 years or so... and he's identified a readily-targetable market, with the window of opportunity being right now.  And the initial version of the product will require low-power design, and, yes, Ethernet.

Funny how things converge.  And this shows that there are indeed two reasons for AGROS development happening on my own time: it helps fit the projects into the client's budget, and I can then proceed to use the code for other things that come along (even if none of them, so far, have involved actual armies of giant robots).

That much?

Created by Recipe Star

Via Breda

Progress, of a sort.

This morning, I started trying to bring up my little AGROS test program on the LPC2387.

It took a while to get the clock initialization right, and I discovered something cute: if your initialization code messes up the clocking (like, by switching to the crystal without first enabling the oscillator), the JTAG debugger can no longer talk to the chip.  Fortunately, the errant program can be erased via ISP, after which the JTAG works again.

Now various things are still FUBAR; I suspect one of them is that I'm not initializing the divider control registers for all the peripherals, so probably the UARTs are running at altogether the wrong speed.  (I guess I'll just fill in arbitrarily usable values for now, and worry about how the config program should handle them later.)

Meanwhile, it looks like Project Egbert (barely begun) has already aquired a fun follow-on, using a latent capability that I planned into the hardware design on the notion that it might be needed someday.  AGROS doesn't support that capability yet, but adding that was on my personal to-do list anyway.  So, I guess I'll be usefully busy the rest of the year, assuming that deal goes through.

Update: two clocking-related problems.  The PCLKSEL0/1 registers did indeed need filling in... and it says in the fine print that the M and N values in PLLCFG are actually M-1 and N-1.  Now the monitor signs on, at the correct Baud rate.

Something else isn't working, possibly in the area of I/O initialization, but that shouldn't be too much of a pain to sort out, now that the CPU and peripheral clocks are getting initialized properly.

Update 2: D'OH!  The LPC23xx vectored interrupt controller is different.  Better, I think... but definitely different.  Gotta add some family-specific #ifdefs to the header file and the code that deals with the VIC.  (Maybe not family-specific.  Maybe add a definition for ENHANCED_VIC or something, to be set in the config file.)

Anyway, not bad progress for a day when I took an early-afternoon nap and then went to a movie, generally not spending much time on actual work.  (Tomorrow, now... tomorrow had better be a solid work day.  Which means I'd better get a good night's sleep.)

Update 3: Glermf!  Turns out the 32-vector VIC has some rather basic differences in how it works.  In particular, the 16 vector control registers, used to map some subset of 32 interrupt sources onto the 16 possible priority levels with associated vectors, have been replaced by 32 vector priority registers, starting at the same address, which (if I'm reading this correctly) merely prioritize the 32 requests, which have a fixed mapping onto the 32 vectors.

Well, that's a much more sensible way to do it, but it means I'll need to put pretty much the entire VIC initialization routine under conditional compilation.  I kinda wish NXP's migration document had made this clear; it could saved me a couple of hours.

Update 4: Finally!  The monitor signs on and responds to commands, so the UART interrupt must be working... along with the scheduler and whatnot.  (I assume the timer interrupt is also getting through.)

Time to set this aside for the moment and do some billable work.

Update 5: One last (?) flippin' headache.  The low byte of P2?  The bits that are connected to the LED drivers on the MCB2300 board?

They don't work unless you pull the ETM jumper.

I just spent an hour or so bashing my head against this, thinking I wasn't using the FIO port correctly.

Blintzkrieg

Once again, North Korea is being troublesome, and there's much speculation as to what to do about it.

One thing I don't see suggested is this: what with the population being chronically starved, how about cranking up the B-52s and carpet-bombing the place with food?

OK, so blintzes probably wouldn't be the right thing to drop.  You'd need something culturally appropriate, so the recipients would recognize it as food once they opened the packages.  It'd need a respectable shelf life, and durable packaging... think Korean-cuisine MREs.  Maybe with a bit of food smell on the outside, as a hint.

Print the identity of the food clearly on the wrappers, in the local language, along with a U.S. of A. flag and some propaganda, attach little parachutes or streamers (so they won't fall fast enough to do any damage on impact), and start bombin'.

The local tyrant will of course announce that it's poison, but I'm guessing that enough desperate peasants would try it anyway (or try it before the official announcement got out) to put the lie to that.

Meanwhile, back at the workbench...

I'm still busying myself with upgrading the AGROS configuration utility to handle the LPC2300 series, starting with the 2387.

Getting the pin-configuration management right has been troublesome, as some of the pins have sparse option lists, and the pin modes are sparse... and GTK's combo boxes aren't set up to handle option lists that need to get mapped to and from non-contiguous numeric values.  So, I had to extend my Ruby class that wraps the Gtk::ComboBox class, to keep track of what options are present, and allow setting the active option by text value, not just by numeric index.

...And somewhere along the line I'll have to make sure I'm not using the combo box's numeric index where I need the numeric value of the option.

It's getting close; another few hours on the configuration program, and I'll be ready to start working on the actual code for the target machine... which shouldn't take too long; most of it's there already, just waiting to have the proper values plugged in.

Gosh. How helpful.

So here it is the first of June, 2009, and time to start worrying about second-"quarter" estimated taxes, and....

I get an important tax document reminding me of how much money I put in my IRA for 2008.  Y'know, one of those pieces of information that those of us who file our paperwork on time need sometime before the fifteenth of April.

Well, I'm pretty sure the number on this notice is the same as the number I told the IRS.

Oooh... sore feets.

I took a shorter-than-usual morning hike, partly because I figured I should get back to my desk on the early side and partly because I'd been on my feet all afternoon yesterday.

Yes, it was Maker Faire time again, with much slow-paced walking.  I've got a memory card full of photos that I might get around to developing eventually.  It was big, and noisy, and crowded... and the layout was highly irregular.  I had the notion that I'd missed a few things, and sure enough: I somehow managed to miss the Candyfab 6000, despite having an eye out for evil mad scientists in the expo hall.

Well, it was a fun afternoon, anyway, with lots of strange contraptions and odd people.  I may post photos later.  For now, back to work.