Silicon Valley Redneck

I hate big complicated software!

So there's this firmware project...

Runs on a Kinetis MCU.  Yes, it's one of those.  Firmware development happens under KDS, which mostly works pretty well.

Comes time I should have a copy on my laptop.  (Eventually the client's programmer will need a copy, too, but that's a few weeks off yet.)  Easy, right?  The working directory, containing (as far as I can tell) everything is under the working copy of the client's Subversion repository.  So: add, commit, then update on the laptop, and, ...

Um.

Well, the commit takes rather a long time, considering how small the program is.  And, once it's on the laptop?  KDS can't find any of the files.  It's looking for them using the absolute paths, which of course are wrong on the laptop, and will be even wronger for the client's programmer, who has a different username.

KDS is based on Eclipse, which is a big, well-established, widely-used open-source project.  And have none of the developers ever heard of these things called relative paths????

Yeesh.  So I grep the .metadata, and get roughly 43 gazillion references of the form

<PathName>/userdata/eric/working-copies/Clientname/trunk/Product_Name/firmware/sub_gadget_name/SDK/platform/devices/MKV30F12810/startup/gcc/startup_MKV30F12810.S</PathName>

So, no, I can't just edit one wonky line in one configuration file and make everything right.  The wrongness is scattered everywhere.

Oh, and in some places backslash is used as a path separator.  How very MS-DOS.

Sure looks to me like Eclipse is just not compatible with the basic idea of keeping all the friggin' project files together and checking them into a source-control system.  Nor, indeed, with having multiple people working on a project.

It's also not real friendly to exotic operations like, oh, copying a project to another directory, under another name, and adjusting all the metadata accordingly so it'll compile properly in its new home.

Grrrr.

Do I have to find some Big Book of Eclipse and spend many days in study, just to learn how to do should-be-simple stuff like this?

Dang IDEs.  Always having their own ideas about How Things Must Be Done, and then not exposing them in the UI.

Oog.

The matter of the garage-sink drain having risen in priority of late, I decided it was time to Deal With It.  It had been draining quite slowly for some time, and snaking it out couldn't be that much trouble, could it?

It could.

Disconnect wobbly plastic sink's wobbly plastic flexi-drain from the rigid plumbing.  Poke rigid plumbing with cheapie household snake.  Seems to be OK up to the point the snake doesn't want to go further around the bend.  Hm.

Unscrew cleanout plug* between bend and wall.  Poke snake at bend from that side.  Same thing, and between the two attempts, I'm pretty well convinced that the bend is clear, so it's not an accumulation of sand and gravel causing the problem**.

Next: poke the snake the other way, on beyond the wall.  It goes in a fair way easily, then hits some kind of squidgy obstruction.  Eureka?  Pull it back out with a glob of ick.  Repeat, with various wiggling and turning.  Stop getting ick, but the snake now hits a hard obstruction.

Oh, well.  Obstruction could be junction, no?  Put the plug back in and run some water.

Nope.  Drainage has now gone from slow to virtually nonexistent, apparently dominated by a slow leak into the bucket under the drain.

Guess I need to call a real plumber, perhaps Monday afternoon, in among all the other Stuff I Gotta Do (Monday through Wednesday have cluttered schedules already).

Plumbers are expensive, though.  Maybe I'll make a hardware-store run in search of a shorter, better-configured snake?  Don't need more'n 4 feet, and having a decent handle for turning it, and less of a tail getting underfoot, might just make enough of a difference.

Update:  Off to Home Despot; look at snakes; end up with a Kwik-Spin.  Good thing I got something fairly long; after several more probulization cycles, I stopped getting wads of ick 10 feet or so down the pipe.  Actually being able to turn the thing was a big help (the auto-feed feature, not so much in this particular case).

Put the plug back in: it drains properly now!  Good as new!

I didn't try very hard to identify the fibrous component of the ick, but feathers from cage-cleaning over the years would seem the obvious suspect.

One cool shower later, I'm feeling almost human again.  Almost.

And I haven't managed to get the smell off my hands yet.  Maybe baking soda will help.  Or bleach.  Or nitric acid.  Or maybe I should use the time machine and tell myself to have broken out the nitrile gloves.

But, hey: $30 for a snake beats $300*** for a Silicon Valley plumber.

 

* Maybe not intended as such; it could have been the place a washing-machine drain would have connected, had any inhabitant of this house ever owned a washing machine.

** Come to think of it, I believe I'd removed the bend sometime last year and removed such dense crud as had accumulated: dirt, sand, brass, swarf, and whatnot.  So it should have been obvious that the current blockage was downstream.

*** Or however much the neighbors spent having their drain pipes totally re-done, including reaming out the crawlspace to accommodate modern American plumbers.  I think bringing in a team of Cambodian plumbers on H-1B visas might have been cheaper.

"P"DF grumble

So there's yet another exploit for Acrobelfry....

Reminds me I haven't checked for updates in quite a while, what with it being a manual install.

And, look!  I go to Adobe's site, and not only has the Acrobat reader (or whatever they're calling it these days) for Linux not been updated since version 9.5.something, but it's no longer available through the regular download path.  (Version 9.5.5-1 still exists, but only if you know where to look.)

Yes, there are open-source programs for reading PDF files.  They mostly work.  In some cases, they work better than the Adobe product... especially when it comes to printing to a Postscript printer.  (Adobe Acrobat has long been notorious for emitting output that Just Won't Work on a printer that uses Adobe Postscript.  This isn't just a Linux thing; I first noticed it during my time in Corporateland when using a company-issued Windows NT system, back when NT was a thing.)

But... it seems none of them support all the funny features of the "Portable" (ha!) Document Format.

Not that I use any of the fancy unsupported features, but it's a potential work-compatibility issue.

And: none of them support having a gazillion files open in a single window, with a tab bar running along the bottom to select among them.  This is how I use it.  I tend to have quite an assortment of datasheets, manuals, client specs, and other assorted documents sitting open, all in a single window on virtual desktop #11, sandwiched between the web browser (desktop #10, typically several browser windows each with multiple tabs open) and the text editor (jEdit on desktop #12, with, at the moment, 474 files open, and a buffer-list sidebar to manage them).

So, do I need to grab the source code for one of the better open-source viewers, and write a more Adobe-like wrapper for navigation and open-document management?  Office software really isn't my thing; I'm more of a bit-basher, and find GUIs rather baffling.

Actually, that might be a good idea anyway.  Adobe's product has some weird bugs that show up when it's used the way I use it; after a while, the UI becomes horribly and inexplicably sluggish (like taking a minute or so to open a file or print dialog, while not using significant CPU time, so what's it doing?); I don't know if this is a function of time or of the number of files that have been open, but it's highly annoying.

Ferschlugginer third-party software!

Back to arguing with the open-source RTOS/TCP-IP hodgepodge, plus another third-party component which was taken proprietary a couple of years ago (I'm dealing with the last open-source release).

This particular combination is, well, ugh.  Serious case of integration being out of phase, important things not quite working right, and the inter-package interface documentation being pretty much nonexistent.  Also, all available demos are way out of date.

I'll muddle through, I guess.

I was about ready to hang up the AGROS project apart from ongoing support for existing clients, but, seeing the state of certain popular products, I'm having a rethink.

I still need to look at another branch of the open-source RTOS world, for futures, but if that turns out to be anything like what I've been dealing with, I'll consider it worthwhile to give AGROS its long-overdue makeover (much assorted cleanup, port to Cortex M architecture, re-do the configuration program using Qt and possibly a different scripting language, write some device drivers for different MCU families, and document everything - then try to recruit a user group to deal with more device drivers, porting to MIPS and whatnot, and stuff like that).

Because stuff that's dead easy under AGROS - as long as it's on an LPC2xxx platform - is a royal PITA in this other environment.

One of the hangups (other than getting out of the ARM7 world) has been UDP, but I actually did a partial implementation of UDP last summer, it looks like a full implementation will be needed for an existing client this summer, and the main sticky aspect had been the API, which, thanks to the current adventure, I can now see how to do better than what I'm dealing with.  Once UDP is there, DHCP is reasonably easy, and a useful subset of mDNS shouldn't be a big deal apart from wading through all the RFCs that define parts of it.

Update: Just to make my life more and more wonderful, Eclipse and gdbserver sometimes get somehow out of sync, resulting in breakpoints happening in places entirely other than where I set them.  So, as I try to sort through the out-of-phase components of this mess, I start regularly hitting breakpoints on frell.c line 434, when the only breakpoint I have set in frell.c is supposed to be on line 399, in the preceding function.  Growf!  And, no, shutting down Eclipse, gdbserver, the target hardware, and the pod, and then restarting everything, doesn't solve the problem.

Update 2: Optimizing linker can be confusing when debugging.  That breakpoint at line 399?  I'd commented out, for the moment, the only call to that function, in another module, so the code for it disappeared, and what would have been its start address had become that of the following function.  Maybe I need to figure out how to turn that off for debugging purposes.

Sudden drum wedgie!

Early on this fine Saturday morning, I went to print a few pages of info on connectors for a project....

The first page printed fine.

The second one was halfway out of the printer when the printer abruptly stopped and turned on an error light.

"Drum".

?

Normally, that light blinks for quite a while before things get really bad.  And the print quality gradually deteriorates.  It doesn't just shut down in the middle of a page!

So I jiggle things, and cycle power, and... as the printer runs through its startup process, it stops with a klunk and turns the light back on.

So I guess the drum unit is jammed.

Have to chase the cats out of here (later), put down paper or something, pull the drum, and see if it's something I can unwedge.

And then, presumably, it'll be Amazon Prime to the rescue.  Because even if I could find a replacement drum locally, it'd likely cost almost twice as much as ordering from Amazon.  That's the trouble with living in the hinterlands the middle of Silicon Valley.

Update: Braving the cramped space under my desk (muscles in lower back and groinal region still being troublesome), I pulled the drum & toner stack out, unstacked them, rotated the drum manually, blew dust off the corona wire (and wiggled the corona-wire cleaner back & forth), removed sundry detritus from the drum with a Kleenex^® brand kleenex, reassembled it, re-inserted in printer, turned power on, held my breath, and... no frowny light!  Seems to work OK now.

Say, you don't think the sudden error was the result of cat dander on the corona wire shorting out the HV, do you...?

Looking in my office closet, I find various used toner cartridges that I'm not really going to refill, some of which are for the previous printer of blessed memory, for which I also have a couple of used-up drum units.  Well, off to e-waste with 'em.  Had I found a used-up but not totally-defunct drum unit for this model, I might have used it temporarily while ordering a replacement, had the take-it-out-and-clean-it action failed.

Maybe the systemd foofaraw...

...will get people rethinking some other aspects of "How It's Done On UN*X".

Latest mention of the systemd thing here.

Sometimes, things get set in stone too early, for the wrong reasons... and then, despite the proliferation of libraries-that-do-similar-things in the UN*X world, the old way remains the only way.

My personal peeve here is setting the Baud rate on a serial port.  The UN*X way, formalized in the POSIX standard, involves passing the choice of rate as a small integer selected from a list in a header file.

This makes sense in the context of a PDP-11, with a serial-port card that takes a 3-bit number (or whatever it was) to select one output from a Baud-rate generator that does 110 and a few multiples of 300.  It's completely outdated in the modern era of UARTs with Baud-rate generators that divide 60 MHz by an arbitrary factor.

Heck, even Windows allows setting arbitrary Baud rates.  But Linux?  Nope.  There's a system-defined short list of allowed rates, and that's it.

And, most of the time, that's OK.  But, when you need to talk to an embedded-device UART that runs at 1000 Baud because that's the standard in Upper Whatchacallistan?  Having to use Windows just to do that sucks almost as much as writing a special-purpose Linux device driver just to get a custom Baud rate.

(OK, so there is a way of mucking about with the Baud rate using the standard driver.  Ugly!  Seriously, the API should have been fixed decades ago to take the actual requested Baud rate, with the legacy rate #defines redefined to the actual number, e.g., B9600 would be 9600.)

Oh, great.

Turning more things on that had been off for a month....

The living-room projector didn't wake up last night.  (Come to think of it, it was working Thursday night, so it's not a sitting-idle issue.)  Presumably the lamp has gone bad.  It's an expensive item, but, as it happens, I'd already bought the replacement, quite some time ago, for an impending failure that turned out to be a false alarm.  So, as long as it's just the lamp, all's well, apart from my needing to find a couple of hours and a flat surface to deal with the changing-a-light-bulb process.

Then, today: I tried to turn the lab Linux box on.  The disk-activity light flickers (once per turn-on attempt), but there's no other sign of life.  Various green lights on the motherboard are lit up, though, whether I push the button or not.  Grrrr!

Ah, well.  Tomorrow, the Prius goes in for diagnosis.  On consideration, I don't really think it's the known failure mode involving the differential; it sounds more like an electric-motor issue.  Which currently isn't getting any warning lights.  Curious.

And I can spend some portion of tomorrow fixing computers and projectors.  Today went to laundry and watering-system manifolds.

Update: Well, the computer looks to be a cheaper & easier fix than the Prius.  (Has to be; I could replace the whole computer for the cost of having the Prius diagnosed, never mind having any work done.)  More detailed observation of symptoms: when the disk-activity light flashes briefly on button press, the internal green lights blink off momentarily, as the fans twitch.  Connecting a voltmeter across the input to the internal power supply shows a big dip in the 12V at that moment.  So... the external power brick (12V, 5A) has maybe gone bad, and can't handle the startup current?  Substitute a 12V, 3A supply that's lying around: it seems to work.  So, off to Halted in search of a replacement 12V, 5A unit, 'cause I suspect the 3A one might just be a little bit light for running that PC, long-term.

Update 2: Drop-in replacement, $13.95 plus tax and travel.  Seems to be working, but Linux is running a long filesystem check.  Something about having gone 384 days without a check.  I presume it'll come up OK, having gotten to this point.

Update 3: One out of three today... I just changed the light bulb in the projector, and It Still Doesn't Work. I'm guessing the high-voltage supply, maybe the starter circuit, is out of order.  Not something I'm likely to fix, especially in the absence of a schematic, and at this point a replacement projector is not at all in the budget, so we'll be without big-screen TV for the foreseeable future.

Oh, well.  Paying work resumes tomorrow.  Meanwhile, I've got a few hours to work on the project for which I'd turned the lab Linux box back on in the first place....

The journey of a thousand miles begins with _______________

Once again, I attempted to set forth on a voyage of discovery, whereof details after it happens.  'Twas originally planned for last September, then this April, then June, and finally Today.  All the previous attempts were derailed by work and/or family events which cropped up and kept me at home.

Well, today was the day... and we got as far as Lodi* before the Prius (NHW11, 2002, a bit over 200K miles) lit up its check-engine light.

OK, so first thing in such a situation (given that it still seemed to be running fine, and that I'd fed it just a few hours earlier): pull into a parking lot, re-seat the gas cap, and try restarting the engine several times.  Nope; still get Check Engine, Master Caution, and Red Car With Exclamation Mark**.

Look up the nearest Toyota dealership: a bit under 2 miles.  Drive there.  No technicians available, but a helpful service manager (whose name I managed to forget, or I'd mention it here) grabbed his personal (non-Toyota) OBDII dongle and pulled the codes: P3125 and, if I recall correctly, P3130.  The generic tester couldn't provide any further information, so he went and looked at his computer, and I asked my Magic Elf Box, and we both came to the conclusion that It Was Bad, that the car was at least temporarily drivable (with some prospect of making it home), and that making a run for home and risking having to call AAA was a better bet than staying in Lodi until a technician was available and the car could be diagnosed and parts could be ordered and installed, i.e., Tuesday-or-so.

And thus it comes to pass that I'm writing this at my own desk; whatever was wrong didn't fail catastrophically in the hour and a half it took to get home from Lodi.

So now I'm looking at P3125, and there are many subcodes, some of which are well over $4K to fix, while some are much cheaper... and P3130 is an inverter cooling system malfunction (I did check, back in Lodi, and the inverter coolant reservoir is full).

The usual dealership has a most uninformative website, but offered me a next-available-appointment of Wednesday.  No.

The nearest dealership (not that much nearer, actually) has a live person answering the phone, longer service-department hours, and the possibility of getting it looked at Monday if I bring it in at 0700, so I guess that's the plan.

And, just in case it needs a new $4400 inverter module... I'm looking at the DIY instructions, and maybe I'll call around to some junkyards.  If there still are any in this area that haven't been bulldozed for high-density development.  I don't think eBay is an option, given my schedule constraints.

It does appear, though, that the expensive P3125 subcodes tend to be accompanied by obvious symptoms, such as rough running.  I didn't observe any such things.

It's at times like this I wish the Prius had a decent set of steam gauges - even virtual ones - instead of an ID10T light.

And it reminds me why my toaster*** controllers keep a fair amount of detail in the event log... and why I get frustrated when end-users (who commonly define the communication protocol) don't give me enough status bits to return important diagnostic information.

Update, Monday morning: Took the car to the nearest specialist.  Had some communication difficulties, of the form "phone number ended up off by one on the work order, so I didn't get a call."  Called in when I noticed this.  Problem is the inverter coolant pump, which is expensive to replace but nowhere near as expensive as the inverter itself.  Also getting the oil changed early, so it doesn't come due while on the road.

Meanwhile I have this Cool Idea for a comprehensive virtual steam gauge panel that would listen to the CANbus and present interesting parameters (in particular, any that were out of whack).  But... gotta pay big bucks to the CANbus Buyers' Club for the list of standard codes, and then negotiate with each car manufacturer for access to the secret list of vendor-specific codes and their associated data (and the normal range for each item).  So, not something I'll be doing anytime soon.

Update 2, Monday afternoon: Just to make times even more interesting, the garbage scow (being my '89 Jeep Cherokee, which is currently Joy's transportation) developed a cute new problem: apparently there had been issues with the ignition lock for some time, and suddenly it started jamming in the RUN position.  It'd turn forward, toward START, but not back toward OFF.  Turning it forward until the starter ground its teeth and then quickly back would, however, get to OFF.  Ugh.  I just spent a while poking at it, after administering a dose of cleaner & dry lube... and discovered that the problem had gotten worse, and also that it had worn all the teeth off Joy's key (which was still accepted as a starting token).  My key, when I tried it, wasn't letting go no matter what, nor would the lock allow OFF as an option.

Well, turns out that the way to stop the engine is to disconnect the negative lead from the battery and then try to crank the starter (the headlights aren't enough of a load, though I didn't try the high beams).

With electricity absent, I wiggled my key forth & back several times, and nothing jammed... though it's not clear what caused the jamming, really.

We'll be needing to run an errand or two in the Jeep this afternoon, so I'll be leaving the tools for disconnecting the battery in the back.  Just in case....

I guess the old beast will be needing a new lock cylinder Real Soon Now, but today isn't the day.

Update 3, Tuesday evening: Got as far as Elk Grove.  Check Engine, Master Caution, Red Car With Exclamation Mark.  Also, performance fell off, apparently (Joy was driving at the time), and the engine seemed to be revving much higher than usual for freeway cruise.

So, head for nearest dealership.  Can't even get the codes looked at until tomorrow at the earliest.  Ponder, discuss.  Joy heads for Cameron Park with her daughter; I call AAA and use my 100-mile long-range tow plus 8 miles to get the Prius back in front of my house.  (By this time, the fault seems to have cleared (no lights, and the car behaves normally at parking-lot speeds), but driving it a long way seems inadvisable, especially as I don't know that the fault codes were.  What's that "Multi-Function Display" for, anyway?)

Anyway: tow truck ride goes smoothly; the return trip will suck.  Driver's a nice guy.  Tip him some cash and a bag of backyard avocados.

Then call Hertz.  Got a Corolla or similar lined up for tomorrow morning, and a lift to go pick it up.  Prius fixery can wait until later; this trip is kinda now-or-never.

It's almost like the Prius has a phobia about leaving California.  I try to explain to it that there are Prii in hillbilly country, too, and that outside California it'll get Real Gas, not the oxygenated junk, and it'll be able to get 54 MPG again, but it just isn't believing me.

And, looking at the after-hours activity?  I'm glad I didn't hedge my bets by cutting another leg off the pig ahead of Intel's quarterly earnings statement.  The recent gain was based on optimism about earnings, but it seems to have outperformed even the optimism.  Up almost a buck and a half after hours, forsooth!

* Not an old Norse god.
** Not an Eastasian delicacy.
*** If plutonium is copper, I work on toasters.

I say we take off and nuke National Instruments from orbit.

It's the only way to be sure.

Grumble grumble finally got rid of the mystery error message through a simple but arcane maneuver that has no perceptible connection to the message.  Now I can duplicate the problem, under the development environment.  Except that this manifestation of the problem causes the development environment to get wedged.  And, owing to the nature of the LabVIEW "programming language", I can't bloody find the place to set a breakpoint, nor see what the connections are.  Not even with grep.

I'm reminded of why, or rather when, Linux users hate Windows.  I, for one, don't hate Windows when I'm using Linux.  It's when I'm forced to use, or interoperate with, Windows that I hate Windows.  (When I'm using Linux, I have occasional grumbles, but if I get really annoyed about something, I have the option of fixing it myself, because Open Source.)

Up until a couple of weeks ago, I was perfectly happy to ignore LabVIEW, and even to have it on my "gotta learn someday because it's what everybody uses" list.  Now that I have to deal with it, personally?  EXTERMINATE!  EXTERMINATE!

Update: Hey, guys?  Most software that deals with drawing boxes and connecting dots has this thing called "View→Zoom" to allow getting an overview in a limited space... or getting a close-up view of what yer pokin' at, so's ya can see where things connect.  Might be worth a thought for, say, the 1996 release.  'Cause when I delete a malfunctioning and useless module, and try to re-connect its inputs and outputs?  The handles are bigger'n the lines I'm trying to manipulate.  Makes it real hard to see what I'm doing.

Boopdate: Well, after I gutted the useless module what's supposed to beep or boop following user input, according as how the input was OK or not, the UI seems to be working.  Some lower-level module involved in playing the beeps and boops was throwing an error, which was causing all manner of non-obvious bogosity.  So now I can build an executable that seems to work, though it says "Student Edition" all over the place.  Back to the client site, tomorrow or the day after, where we left the Official Development System, build a fresh boopless binary (maybe even correcting for the absurd screen layout the dear departed baked into the original!), and see if it runs on the client's shiny new PC....

"The first woodpecker that came along would destroy civilization."

Still bashing my head against the horrid LabVIEW software for the Nightmare Project.

LabVIEW's uninformative error messages don't make it any easier, of course.  And telling me that a VI claims to be part of library, and that I need to disconnect it and re-add it might be more useful if (1) there were some way of learning which library it claimed to belong to, and (2) the library-adder didn't refuse to add the VI on grounds of it already being part of the project.

And this whole mess is taking on a Winchester Mystery House quality; the code was adapted from an earlier project, which was adapted from one before that, which... and a lot of outdated stuff never got removed, and there are countless dead ends, and there appear to be a couple of non-Euclidean rooms.  And it appears that, somewhere along the line, a couple of VIs were copied out of a now-long-obsolete standard library, and modified.

Almost time to dig out the Yellow Pages and have a look under "Necromancers."  (No, not "spiritualists"; I need someone who can raise the dead.  Or at least plague them in the afterlife.)

A curse on LabVIEW and all who use it!

The past week having been largely eaten by the problem of getting a simple test-automation program to run on a second machine, I feel some cursing is in order.  I'm about ready to consult a necromancer, if not to summon the author of this program then at least to disturb his rest.

We did find the source code... so far as LabVIEW can be said to use "source code".  It's all Ancient Egyptian to me*.  But!  I successfully defanged the apparent copy protection.  Only the code still doesn't run right on any but the original PC.  The failure mode has changed, but it doesn't work.

Now I'm trying to poke at it using student edition LabVIEW (don't worry, we'll compile for delivery using the fully-licensed version).  And: I can poke at the blocks, and kinda-sorta see what's going on, after a fashion... but I can't run the sucker, because the library topology has gone non-Euclidean or something.  Totally obscure error message, to which the solution might be either "keep all the source files in exactly their original locations, and don't even think about working on a copy of the project" or "re-install LabVIEW and try again."

 

* 𓀜𓂗50-46-5D-90-76-BD𓂀𓍝𓂶"X < 0 ? 2"𓁸𓂏𓃫; yeah, that makes perfect sense.

Hmmm: Looking at this page on my phone, I see only the latin-alphabet text.  If the footnote lacks hieroglyphics, you may not have a full set of Unicode on your computer.  Or something.

Aieeee!

Got back from spending bucks at Verizon to upgrade fom a 4-year-old HTC Incredible to a shiny new Droidd Maxxxx (nice big screen for my aging eyes), and was preparing to set about migrating my stuff, when I discovered...

...that my laser printer, only a couple of years old, which had been working this morning, now appears to be defunct.  As in, it shows up properly as a USB device, but then disconnects, then reconnects, ad infinitum or until the OS gets disgusted.  Tried power cycling the printer, rebooting the server (which had been prompting me for a reboot for a few days now), replacing the USB cable, plugging the USB cable into the workstation instead of the server... no soap.

Maybe if I let it rest overnight it'll feel better in the morning?

Maybe there's cat hair forming a blanket and causing a chip to overheat?

And this hasn't exactly been a good week for earning the bucks, either, what with days spent trying to deal with malfunctioning (possibly copy-protected) software on a fixed-price job.

Blrgl.

Still trying to complete the half-day task, begun last Thursday afternoon, of delivering a simple test fixture.

Which involves installing the software to make it work.

Which, I'm increasingly suspecting, was locked to a specific computer, most likely with some identifying information compiled into the binary.  And, had I a Ouija board, I might be able to get some answers....

Anyway, it's on Windows 7.  Which, coming from XP-if-you-insist, and Linux/KDE for preference, is... ugh.

Want to turn on display of hidden files, and of file extensions?  The options for that used to be in the "view" menu of the file manager.  Now, the file manager no longer has a menu.  Options are set only via the control panel.  And you're supposed to know this.  Intuitively, like.

And: want to search for files modified between last June and the beginning of this year?  In XP, you click "Search" in the file manager, and "All files and folders", and "When was it modified?", and there's an option to enter a range of dates.  Cool!  In Windows 7... there's a little search box in the file manager.  You can type in a glob-style name pattern, or get strictly kindergarten-level functions by clicking on things, but to do a date-range search you need to type in a text-based filter that's in a poorly-documented language, almost as obscure as find but much less powerful, and that doesn't bloody work.  I get just enough results to tell me my syntax wasn't wildly off, but nowhere near as many as there ought to have been (and not including files that are in plain sight and match the criteria).  I think the answer may be "boot a Linux live CD, mount the Windows filesystem, and use find."

All the bridges rusting

Got a fiddly problem, on an old project.

The correct solution... well, the really correct solution involves understanding somebody else's software, which isn't really an option in this case.  The nearly-correct solution uses a small PLD... something along the lines of a PAL16V8.

O-kaaay.  SPLDs are still around. But!  I need to program it.  I have (but have never used) WinCUPL.  (Last time I used a PAL, I used ABEL.  Am I dating myself?)  And: the chip'll need programming, which (for these little devices) doesn't happen over JTAG; they need a special programmer.

Somewhere in my lab, I have... yes!  A Xeltek SuperPro Z!  Like this!  Hm.  Needs a Windows machine with a parallel port.  And:

Warning: SuperPro Z will only work on Pentium III 1.1 Ghz. or slower computers. It may create communication problems on new PCs. Please purchase accordingly!

Um.  It needs an old Windows machine with a parallel port.

Or I could blow $500 on the new model.  Or use a fancy-schmancy modern CPLD that gets programmed over JTAG.  (Paying an extra $3 for the chip is no big deal, for a production volume of 5 pieces, tops.)  But... this needs 5V-tolerant inputs, which limits the choices.  Still, plausible.

Or, I can use an AVR, program it to handle the lame transfer function, and figure out how to deal with the startup condition: those milliseconds after power-up when the MCU hasn't actually started running yet.

I think this ends up as an AVR-as-logic-replacement situation.  I've got all the development tools, and know how to use them, and the chips will happily run on poorly-regulated 5V.

Or, just maybe, I might use a pair of HCT logic chips and some resistors.  But that takes more board space than the AVR, lacks flexibility, and probably costs more.

 

(Bonus geekpoints for recognizing the title.)

Floppy disks! Why'd it have to be floppy disks?

I needed some scope captures today.

The main scope - the vintage LeCroy - has a floppy drive.

Will it flop?  Let's find out!

Grab a New-Old-Stock floppy from the supply closet.  Pop it in the drive.

Whir, whir.  Grind, grind.  No can read.

Try formatting it on the scope: no can format.

OK, so look for... hm.  Actually, I guess the server does have a floppy drive, but it's likely full of dust.  There's a USB floppy around here somewhere.  Rummage, rummage: the USB floppy drive!  Preciousssss!

Find the utility for formatting floppies... er, no.  Find the utility for formatting USB floppies.  Format, format, grind, grind.  Now it needs a FAT filesystem.  There's a utility for putting one of those on a floppy... but I can't seem to make it work.  Maybe it doesn't work on USB drives?  (In hindsight, maybe I should have been looking under mkfs.)  Oh, well: launch the XP VM, give it the drive, and format the disk there.

So now I have a formatted floppy that works with the USB drive, and looks like a filesystem under Windows and Linux.  Off to the lab with it!

...And, the scope still can't read it.  Drive musta gone wonky.

So I used a camera.

Waaaaaah!

My pizza stone is bust!

And I'd only had it about 30 years!

Just these past few weeks I'd started using it again, and cranking the oven up to Volcano Heat (545°F, rather than the wimpy 450°F or thereabouts I'd used in the past), and on this occasion, after depositing the pizza on it, I left the oven door open for a good fraction of a minute while retrieving an errant mushroom (which process didn't do my arm hair a lot of good).  All seemed well, but when I returned a few minutes later to claim the cooked pizza, the stone was as shown here (but still topped with a small pizza, with mushrooms, olives, and prosciutto).

Oh, well.  I've come to regard the pizza stone as Essential Cookware, so it's time to fork over $30 from my already depleted treasury for a bigger, heavier model that gets good reviews on Amazon.  Might use it for various sorts of non-pizza bread, too, if I get inspired.

One of these years, I'll build myself a proper pizza oven.  The wood-fired kind.

Of planned obsolescence and trust

Well, my HTC Incredible is getting on toward 3 years old, and, while it seems like time to get a 4G phone with a bigger (more geezer-friendly) screen, the old phone is still in fine condition, not even urgently needing a new battery.

Except: the software's been increasingly unstable the past year or so, and for the last couple of weeks I've been getting a persistent "Phone storage space is getting low" alert.

Apparently the updates to the Verizon-installed, non-removable apps that I never use are piling up, leaving basically no space.  Or something; it's not clear whether the complaint is about internal flash or RAM.

There certainly does appear to be a RAM shortage, which there never was before.  Thing is: the RAM is being eaten by some combination of system services and mandatory crapware.

Of particular annoyance (though it doesn't appear to be taking up all that much RAM) is the Slacker Radio app... which, not only can I not remove it, I can't even kill the running process.  Or, rather, if I kill the process it promptly respawns.

And I have a strong suspicion that there are other immortal processes that don't even show up on the task manager.  (In fact, I'm certain a lot of processes, immortal or otherwise, aren't visible; it is, after all, a running Linux system.)

So, two points.

First, the accumulation of vendor-pushed crapware and crapware patches means that a new phone becomes mandatory rather than optional (unless of course I root the phone I've got, but it's meant to be a communication device, not a hacker toy).

Second, just how confident is anyone that none of these unkillable processes are spyware?  For all I know, one of the processes I didn't ask for and can't get rid of is gathering location data and ambient sounds, and transmitting bundles of where-I've-been and what's-been-said-in-my-presence back to Verizon and thence the NSA... and maybe to commercial competitors of my clients.

Maybe I should root the thing?

Update: apparently the warning was in regard to "application data storage", whereof a huge amount was being consumed by Google Currents, Facebook, and Firefox.  Of those three, I actually use Firefox once in a while.  By clearing the application data for those three apps, I got rid of the warning.  Sometime when things are slower, I'll go through and see what else needs its bloated app data zapped.  And, when cash is less tight, I'll look at shiny new phones.  Like maybe an unbranded Nexus... not available for Verizon's LTE network, so I'd have to switch carriers, which would mean doing another round of homework: when I switched to Verizon many years ago, it was because the other carriers' coverage around the South Bay was seriously deficient, and perhaps that's changed by now.

On top of everything else...

New water heater; medical expenses of bird, girlfriend, girlfriend's daughter's cat, and elderly Jeep; getting on scheduled-maintenance time for the Prius...

I just turned on my signal generator, an aging Higgledy-Piggledy 8111A, for the first time in a few weeks.  No Output.  Various bits had been getting flakey, and I'd been having to work around them, but a complete lack of output makes it quite useless.

For the moment, I should be able to get by with the cheapie that's been on the sidelines since I got the 8111.  Real soon now, though, I'm gonna have to scrape together the kilobuck for that new LeCroy signal generator that's been on my CAPEX roadmap since spring... and which I would have bought in June, had the money situation been favorable.

Did I mentioned sotware rot?

Going on two year back, I got the LPCXpresso software to work under Debian-stable (Lenny, at the time).

More recently, I'd installed the latest version (4.2.3) on the new workstation, which is running -testing (Wheezy, which, as I've noted before, tends alarmingly to the -unstable, but which does play nice with my Sandy Bridge hardware).

Well!  I've got a project coming up in the next week or so which actually calls for using an LPC1343, probably in the form of an LPCXpresso board - to simulate a peripheral, in a manufacturing test setup.

So, time to fire up that IDE and rummage through the example code.

IDE launches, and reports being fully licensed and good for 128K code.

Debugger does.  Not.  Work.

Grrrr....?

So, I try the funny incantations of dfu-util and crt_emu_lpc11_13_nxp, and I get pretty much the same messages as all those other poor schlubs out there, most of whom eventually solved their problems in one way or another, but none of the published solutions appear to work for me.

Figuring it's a problem with running on 64-bit Linux, I try a couple of different 32-bit installs on virtual machines, as well as the -stable (Squeeze) installation on the 32-bit mini-box in the lab.  Same results.  Likewise if I try the manual invocations of dfu-util and crt_emu_lpc11_13_nxp as root.

Hmmm.  Try running the IDE as root.  It woiks!  Goes through the "set up your workspace" bit, then I install the examples, and it finds and uses the LPC-Link.

Play with the udev permissions.  Still doesn't work for me as myself.

Hokay: maybe something's wonky with the configuration.  Run it again as myself, and switch to a fresh workspace.  Hooray!  It finds the board, and debugging works!

So, something stale in the old workspace.  Great.

(And I'm thinking that the VM and lab-machine failures, which showed exactly the same symptoms, actually were a permissions problem on  account of my not having brought over my udev script.)

But!  All's not yet well!  When I try a tiny example, it runs fine, but when I try to debug the alphabetically-first example, being adc, I get "License restriction: Flash image too large for this license".  Looks like it's a bit over 8K, which is the limit for the unregistered version.  So, WTF?

Apparently the system updates over the last few months - different kernel version, and ifconfig returning the Ethernet MAC address differently - changed my system's identity enough for the debugger to think it wasn't properly licensed, while the IDE happily reported being fully licensed.

Solution: generate a new serial number, and re-license.  Hey, it's free.

Old rusty Windows boxen

Well, I've got a couple of AVR projects coming up (beginning with one of my own, that I was planning to start on this afternoon), so it seemed time to install the latest AVR Studio, which, alas, is Windows-only.

It was, therefore, time to fire up my last remaining physical Windows machine, that being the one in the lab that USB debug pods plug into when the software that works with 'em only runs on Windows.

Said machine had been powered off since the last-but-one power flicker.

It doesn't boot.

BIOS signs on.  Then the screen goes blank, and the hard-drive light comes on.

On one attempt, I actually did (after several minutes) get the Windows logon screen... but logging on got another dose of Fail.

Booting in safe mode: no soap.

Booting the rescue CD, which I still had: it said it fixed the MBR, but then the only option it offered was to wipe the disk and do a fresh install.  No thanks.

Hokay: try some of the other CDs I've got around here.

Windows XP install CD: same behavior as booting the hard drive.

Kubuntu (Greasy Grimy Gopher Guts or Jumpin' Jerboa), or whatever old version of System Rescue CD I had lying around: doesn't have chkfs.ntfs, so not all that useful for the task at hand.

So, download the latest System Rescue CD and also something called Hiren's Boot CD, or HBCD.

HBCD finishes downloading sooner, so I burn a CD of that, boot it, select "Mini XP" or whatever, summon a shell, and run CHKDSK.

Many errors, including lotsa unreadable blocks.  (I'd seen some read errors when I tried dd if=/dev/sda of=/dev/null on Linux, so this isn't surprising.)

So start it again, with /r, in hopes of actually repairing the darn thing.  Lab's closed for the night now, so I can't check on progress without bothering Tinga.  I rather suspect that the XP installation will turn out to have some crucial files missing, and that there won't be any plausible way to get the system running again short of a full re-install (which is probably called for anyway, given that the drive has developed a flurry of bad blocks and probably ought to be replaced... which means digging up a suitably old IDE drive).

Fortunately, I don't have any actual data on that machine, just a buncha software, all of which is (I think) still sitting on the server waiting to be installed again should the need arise.

Morning update: CHKDSK claimed to have repaired the filesystem, but Windows still didn't want to look at it.  Booted latest System Rescue CD: still no fsck.ntfs (so maybe I need to pull the drive, plug it into a USB adapter, and connect it to a running computer).  Oh, well: try mounting the filesystem, which works, and doing an ls -lR, which pauses and grinds many times, with disk errors.  Foo.

So, looks like the drive is truly toast.  I could mayhap recover most of the content, but since that's mostly applications, and moving applications from one Windows installation to another basically Doesn't Work, I guess it's back to swapping in an old but serviceable IDE drive and doing a fresh Windows install... and Windows Update... and Windows Update... and Windows Update... and....