Silicon Valley Redneck

The smoke alarms work.

Yes, I conducted the Thanksgiving smoke alarm test.

In preparation for Day 2 of family Thanksgiving, I baked a pecan pie yesterday evening.

I used a cheater crust.

It dribbled grease on the bottom of the oven.

This morning, I set the oven to preheat to cornbread temperature, and settled in to read the morning internets.

After a while, things started smelling a bit smokey.

Then things started sounding decidedly loud.

Back out to the kitchen: much smoke, but any actual fire was confined to the interior of the oven, so no big deal.

Turn on vent fan, take down smoke detectors and remove batteries, open some windows....

Things are back to normal-ish now.  Got to run a proper cleaning cycle on that oven some day soon.

Oh, and put the smoke detectors back up, just in case the next one is for real.

Eek!  That smoke has got to be full of trans fats!  I feel my bronchi clogging!

 

I, too, am on the Not Flying list this holiday weekend

Of course, none of the place I'm going would be reasonable air-travel destinations from where I am; it's quicker to drive.

Still...

I've been increasingly reluctant to travel by air these last many years; part of that is the undersized seats (my hips fit just fine, thank you very much; it's my shoulders that slop over, and the travel agents look at you funny if you try to reserve "one seat for me and one for my sword arm"), but the airport security theater has been a big factor.

Thirty years ago, the security theater was stupid and annoying, but not too much of a hassle, and sometimes amusing (like the time I was forced to check my LED bow tie, which spent the next few days flying up and down the state on a variety of wrong flights, but had no trouble with my briefcase, which contained a variety of tools and electronics, and, as I later realized, some forgotten, er, energetic devices).

It had gotten seriously annoying (and still stupid) the last time I had to travel by air, what with taking shoes off, and having the special rules for laptops and such.

Now... deal with the Blue-Hand Dudes?

Naw.

And it's not like I could pull off the Gay Scotsman act (though I keep thinking I should have a Utilikilt for summer wear).

And, if I really wanted to blow up an airplane?  I came up with a search-proof method years ago.  No, I'm not going to publish it, just in case the terrorists haven't thought of it yet.

I might be tempted to use Lex's hypothetical air-taxi service, except for the minor detail that his back-of-the-envelope calculations show that there's no way he could make a profit at it.

And now, of course, there's a proposal to expand the intrusive searches to those who avoid air travel.  Got to have security checkpoints at train stations, bus stops... perhaps any place crowds gather?

And if this comes to pass, The Bureaucrats Will Have Won.

 

Ferschlugginer Acrobelfry!

Earlier today, I'd been looking at the specs for some plastic enclosures, in PDF form.

Some of them had animated 3-D views.

When I tried to close one of them, Acrobat commenced to consume 99.8% of a CPU.  (Isn't it nice to have a dual-core system?)

Anyway, I killed it off, and decided it was time to install 9.4, which had been pending for quite a while.  (I don't like exiting Acrobat, as I usually have a couple of dozen datasheets and such open at any given time.)

The update having been duly installed, I launched it.

Yeah, it seems to be working... but the file-switching bar (whatever that's called in Adobe-land) had for some reason migrated from the bottom of the screen to the top, and I can't find a way to move it.

Maybe it's in preferences?  Last time I tried to call forth the preference menu, I got a stupid error message.  Let's see what I get this time, with a fresh launch of a fresh install and nothing open yet.

This dialog sets preferences and cannot be shown while another PDF document is showing a dialog that also sets preferences.  Please close that dialog and try again.

Yeah, that's the same stupid error message I'd gotten before, on the previous version with a bunch of files open.  Only this time I'm quite sure there's no such other document open.  On this machine, at any rate.  Perhaps no such document may be open anywhere in the universe?

Hokaaaaay....

Rename ~/.adobe/Acrobat/9.0/ to something else.  Launch the program again.  Get the license agreement.  Agree.  Try to set preferences.

Yup.  Same stupid monolog box pops up.

Oh, well... I wonder if 9.4 improves the printing any, or if it's even more broken.  (Printing from Acrobat Reader to Postscript printers has been problematic for years, on both Linux and Windows platforms, even when the printer speaks Genuine Adobe Postscript.  It's been getting worse lately, with a great many recent-ish datasheets needing to be printed from an alternative reader.  Of course, my current printer speaks off-brand BR-Script, but still: you'd think the Adobe's PDF reader could emit valid, printer-friendly Postscript.)

 Update: printing is at least as b0rked as it was before.  And I continue to bump into the limit on how many tabs I can have open, and now sometimes having the file load or save window open will cause obscene CPU usage for perhaps a minute at a time, which hadn't been a problem with the previous version.

 

Well, maybe I need to fix the old one.

I've had the same mouse for many years.

It's a Logitech cordless, old-school (49 MHz or some such).  Eats AA batteries kinda fast, but it's been getting the job done.

Lately, the right button has developed a severe bounce, causing unintended double-right-clicks.

So, off to Fry's in search of a replacement.  My needs are simple: a decent-quality cordless mouse that I can plug into the PS/2 port on my KVM switch.

All the cordless mice are USB-only.  OK....

Back home, check Newegg.  No dice.

Well, then: surely there are USB-to-PS/2 keyboard/mouse converters, no?  I mean, I've seen such things, haven't I?

Well... sort of.  As in: they'll convert PS/2 inputs to USB, so you can use your old keyboard and mouse with your new PC that only has USB ports.

Nothing, it seems, to adapt a USB mouse to a PS/2-only host.

Meanwhile, I picked up a cheap corded mouse; those are still available in dual-interface models with the green plug adapters.  And, owing to the odd configuration of my desk, the cord keeps rearranging my clutter.

Maybe a cable staple or two will help.  And I suppose I can take the cover off the old Logitech and see if the switch is fixable or replaceable.

 

I2C strikes again

Once again, I'm looking at an interesting little design involving a bunch of little chips...

...all of which have I²C interfaces, so it ought to be pretty straightforward, assuming they don't have conflicting bus addresses (and some of the datasheets don't seem to have the bus addresses listed, which makes life gratuitously difficult)...

...and they all run at different supply voltages...

...and they all follow the I²C standard, which specifies CMOS thresholds, with HIGH being 0.7*Vcc to Vcc+0.5V.  OK, so one of them (which runs at 3.3V) will accept 0.6*Vcc, so it'll work with the 2.5V logic... but not with the 1.8V part.

Grrrr.

It's a freaking open-drain bus.  It should be standardized to be reasonably independent of individual chips' supply voltages!

Anyway, looks like I need at least one level shifter.  And level shifters introduce their own exciting opportunities, such as the pullup resistor values shown in the datasheet not actually working over the rated temperature range.

Of course, if there are address conflicts I'll need a bus switch, and maybe I can find one that also does the required level translation.  Maybe.

 

Getting LPCXpresso to work under Debian-Stable

Yes, it's possible!

And it doesn't involve rebooting, either (though I changed the launch incantation to get around that... and this system does need rebooting one of these months).

I installed the evaluation version of the LPCXpresso software on both Linux and Windows... the latter to make sure the problem wasn't with the board.  On Windows, I needed to futz around in the Device Manager to make sure the driver got installed, but that's Windows for ya.

On the Debian front, I kept getting the messages about the emulator not being found.  The software found it, reconfigured it as a Code Red LPC-Link Probe, and then couldn't find it again.  Much tinkering on three different machines didn't turn up anything informative... until....

I couldn't remember the correct incantation, so I tried "crt_emu_lpc11_13_nxp -wire=winusb" and ENTER... and got

Et: Failed emulator initialization: E(xx). WinUSB driver load/install error: libLPC_Link.so. /lib/i686/cmov/libc.so.6: version `GLIBC_2.8' not found (required by /usr/lib/libusb-1.0.so.0)

Uhhh...

Well, yeah.  Lenny has glibc 2.7, not 2.8.  So why do I have a mismatched libusb in /usr/bin?

Anyway: install the official Debian libusb-1.0-0, and try again.

Success!

I can now talk to the 1114 stick from Linux.  Probably also the 1343 stick, but that's out on the dining table with one of the laptops at the moment.  After that, a 1768 stick, but those are currently on backorder.

Now if only I could get the STM32VL Discovery board working on similar terms... 'twas a freebie at the trade show, and it works with the Keil software (eval version) on Windows, but I'd really like to have the debugger available on Linux.

Heck, if the chip vendors would just release open-source GDB servers that worked with their USB debug bridges, that'd be useful.

And, while we're wishing for ponies, I'd like a straight-up GUI debugger, not tightly bound to an IDE, that would let me load my own smegging binaries from my own build process, and debug them... in disassembly view, if necessary.  (Yeah, there may be some way to configure this LPCXpresso thing to work with my preferred toolchain, but it seems to be seriously project-oriented, and I have my own configuration and my own build process, which I don't want messed with.  Oh, well.  I think I'll just use the debugger to get my low-level support code working.  Once I've got printf going and task switching working, the debugger becomes much less important.)

 

Appending an 'x' to the file extension can only make it worse

Just when we've all more or less come to grips with the pesky .docx/.xlsx formats that came out a few years ago....

Now there's this new .zipx format.  Which, apparently, the latest WinZip generates by default.  Yup, when people package up files to send to others, let's make 'em work extra hard to do so in the old familiar fomat that the recipient will actually be able to open!

I guess they had to do that, 'cause Windows has a built-in unzipper these days, and people were only buying WinZip for packing, not for unpacking.  Throw in a little default incompatibility, and they'll be having to buy it for unpacking again!

Well, to the extent that people buy WinZip, anyway.  Way I understand it, most of the users are just running the evaluation version long past the evaluation period... or that's how it was back when I worked in a Windows shop.  And it's not like here are no free-as-in-beer alternatives, at least for the traditional .zip format.

Oh, and the boss started downloading WinZip so he could examine a file.  He stopped when he found out it was an 18 MByte download.  What????  I remember when PKZIP fit on a floppy!  I'm guessing he wouldn't have been able to run it on his old PC anyway; the graphics card wouldn't be up to the 3-D animated bunny, or whatever's the distinguishing feature that justifies paying for an 18 MByte package to do a free 67 kByte job.

(67 kBytes?  Yes, that's the size of /usr/bin/zip, which gets the job done quite adequately, even if it doesn't show an animated 3-D bunny compressing the files into neat little pellets.)

 

Needs a celebrity endorsement by Bernie Kopell

CDR Salamander has a post about this "Club K" thing people have been chattering about.  Or, rather, about the latest public-service announcement from the Russians, but whatever.

Anyway, with a name like that, it really oughtta be advertised by this guy:

Join Club K now - Und! - get four cruise missiles at no extra charge!

Here's a picture of the dingus:

See, it's not so much a club, as a wonderful new gadget to allow the peaceful Reds, with no investment in military vehicles and vessels, to use their civilian transportation infrastructure to launch a preëmptive cruise-missile strike against the warlike Blues.

'Course, if the Blues decide to get all pre-preëmptive, they'll have to clobber anything that can carry a cargo container, 'cause they can't tell what's military and what isn't.

And has anyone noticed any cargo containers arriving in Cuba?

 

Sergio Leone tribute: it's what's for lunch

So it's getting to be a long time since breakfast, and I haven't gotten to the grocery store.

Look in the refrigerator.

Hmmm.

Small bucket of previously-cooked spaghetti.

Little dab of leftover chili.  About enough to flavor a chili burger, if I had a burger to flavor.

Various sorts of cheese.

OK: spaghetti with chili and shredded jack cheese.  Nuke until the cheese melts, stir, and serve.

Tex-Mex spaghetti?  Er... Spaghetti Western!

I think a nap is going to take precedence over the work I should be doing this afternoon.  I seem to be goofier than usual today, and that bodes ill for productivity.

 

Putting the squeeze on 8 bits

I did find a couple of hours to go to the ARM Techwhatsis Conference last week.  A couple of hours was all it took, 'cause the show has gotten a lot smaller than it used to be.

Not a lot of exciting new stuff, though ST was pushing the new STM32 Value Line, to the extent of handing out free STM32VL Discovery boards - cute enough little gadgets, though in the month or so since the board first came out, they're rearranged the website and all the pages mentioned in early-adopter blog posts (and on the packaging) are now 404.  I did eventually find the necessary software to talk to the thing, though.

Had a brief talk with the Code Sourcery guy, as usual.  He pointed out that there's a free, ready-built, easy-to-install version of the command-line tools (GCC, binutils, and such), and (with some questioning) that it's a good fit for building AGROS applications.  So, this time I downloaded it, and installed it on both Linux and Windows, and it seems to work fine, once I added a few lines to my ldscript template to deal with the fool .ARM.exidx segment.  And!  It supports Cortex M0, M1, M3, and M4, which is one reason I'd been looking at a GCC update (having a common toolchain so customers can compile my code is also good).

Anyway: shortly after the show, I encountered an application that's currently using an AVR part... and running out of space, so the next step is an ATmega2560.  Which is, like, pricey.

And then I take another look at the STM32 and LPC1700 families, and I'm seeing parts that can compete with that AVR on peripherals, and have much more memory and zippy-fast 32-bit processors... for a bunch less money.  And, though the running-flat-out power consumption is quite a bit higher, the power consumption at a given clock speed is just about comparable.  Maybe even a bit lower.

Awww, but they don't have the on-chip EEPROM.  And they positively require regulated 3.3V.  Apart from that, though....

That particular gadget probably doesn't get converted over, because there's an existing code base, all tied up in this Aard-Wino thing.  (So, if I get involved in the project, I'll have to get somewhat up to speed on Arduino, which I've never had occasion to play with.)

I think I need to look closely at the LPC1700 series, especially since, if I'm reading the signs aright, my LPC21xx/23xx device drivers should carry right over, though I'd probably want to toss in some conditionally-compiled sections to handle new features of the old devices.

And that means getting up to speed on the M3 architecture, which actually looks to be friendlier than ARM (or any of the other typical-RISC architectures).  Code up a new init module, task switcher, semaphore functions, and exception-handler wrapper generator, and AGROS should be good to go.  IMCFT, of course.

(Yes, wrappers around interrupt handlers are required, at least in some cases... because an interrupt might trigger rescheduling, and for that to happen, the handler needs to jump to the scheduler instead of returning.)