Silicon Valley Redneck

Ah, the computer age!

I kind of wanted to watch something on Amazon Video.  It's free with my Prime subscription!  There's a PLAY button!  OK....

It doesn't like Firefox ESR 45.4.0 on Linux, and suggests Chrome.  OK....

Under Chrome, I get an error involving "Widevine Content Decryption Module", which seems to be installed and enabled, but with no way to update it.  Hm?

Well, this is an outdated version of Chrome.  I try replacing it with the latest.  It doesn't install, because I don't have the latest libstdc++ installed (and it's not available for this rather dated Linux installation).  Well... dpkg says it didn't install correctly, but it seems to run, for a first approximation, and shows the latest version number... but Amazon still gives the same ferschlugginer Widevine error.  Foo.

So!  Fire up a virtual machine with a recent version of Linux Mint.  Update everything (except that one of the configured Ubuntu archives isn't working).  Install Chromium, from the repository, and Chrome, as downloaded.  Neither of them works: a window comes up, but it shows random corruption and bleed-through from the host's display.  Something strange with the VirtualBox support?

Maybe I'll try to sort this out later, perchance after the delayed dist-upgrade of this system.  Meanwhile, launch the Win7 VM, Firefox under Windows, Amazon... it wants Silverlight.  So I install that.  I get a message that Firefox 47 or later would support HTML5 playback, and a Silverlight playback window that has no video and no sound.  Grrr.

I seem to be running Firefox 35 or so.  As I check, it's downloading an update.  It asks permission to restart.  OK.  Gee, now it's version 38 or something, and updating.  Rinse, repeat, how many times?

Download the Firefox installer.  Run it.  It upgrades my installation to the latest (49 or something).  Now, at last, Amazon works, using the HTML5 playback.

This stuff is never as easy as one might expect.

Oh, and now it's past my bedtime, and much too late to start watching a movie.

Update: The HTML5 player, like so many others, occasionally receives a wedgie.  It seems particularly sensitive to being put on pause for a while, being told to back up a minute, etc.  The wedgie having happened, it's necessary to reload the page and relaunch the player.

Save your work!

And don't go plugging in strange USB devices.

Joy's iPhone wasn't charging.  To narrow down the problem, I plugged it into the self-powered, many-port USB hub that's stuck to the side of my desk.

The eval boards that I currently have plugged into that hub promptly lost power.  Oopsie!  Must be the tattered Apple-specific cable has shorted out (and of course there's no spare handy; the only other Apple USB cable around here is for an old iPod Touch, and that's the old-model proprietary Apple cable).

Aside from which, my workstation (into which the upstream port of said hub is plugged) was unceremoniously turned off.  Eh?

Just a reminder that a disconcerting number of PC motherboards (and this wasn't a bargain-basement model) don't have proper protection on the USB ports.  I'd had trouble with an earlier motherboard when a self-powered hub fed voltage back on the upstream port and it ended up feeding into the motherboard's 5V rail when the PC was turned off; this one apparently doesn't have any sort of current limiting, so a downstream short can shut down the system.

(I think this particular port may be powered from the 5V Standby rail, to allow for keyboard wake-up buttons and suchlike.  That supply doesn't have a lot of current available, and is also the supply that's used to turn the main supply on, so shorting it out will cause the main power to turn off.)

Anyway... pressing the power button and waiting restored normal operation, and I had in fact saved my work, so no real harm done.

Side effect?

I think this started, at a low level, Tuesday morning: Southmoon has been behaving very aggressively toward Huckleberry.  Hissing, growling, chasing him around the house, that sort of thing.  This is entirely out of character; Huckleberry has occasionally been aggressive toward Southmoon in the past, but this week he hasn't been doing anything to provoke her.

Last night, it got intense.  This morning, she seemed perfectly normal, right up until Huckleberry jumped down from my desk and landed sort of near her - and then she went into evil mode.

I just checked the package insert for the Revolution, and I see nothing about causing hallucinations in cats.  And yet, she's acting like she found the special glasses and can now see that her brother is actually a pod creature from Neptune.

I'd suspect that the flea treatment made him smell different, except that she's also been doing the "who are you and what have you done with my brother" thing from the far end of the hallway.

May have to call the vet this morning.

Update: I'm guessing it's psychological, not pharmacological, and that it's a side effect of Sunday afternoon's flea bombing - or, rather, of the frightful two and a half hours spent in the back yard.

Top Hat (who spent most of that afternoon cowering between shed and fence) remains happy to bound out the door and explore the yard.  Huckleberry, normally the bold one, takes a while to venture beyond the patio, and (uncharacteristically) comes scampering back in at the first suggestion that the door might be about to close.  Southmoon, who's always been quick to dart through an open door, now seems afraid to get near the door when it's open.

So, maybe she's getting territorial because she was dispossessed (along with the rest of us) for an afternoon?

Update 2: ... Or maybe it was the Revolution?  Thursday night, Southmoon slept in the bedrooms-guarding spot on the hallway floor, the better to keep the back of the house safe from the forces of Huckleberry.  In the morning, I found on that spot a slightly-chewed cardboard box - I don't know where she found it - which had once contained 6.5x55mm ammunition.  Well, at least she didn't have live ammunition, nor a Swedish Mauser to use it in.

Twelve and a half pounds of unpredictable cat with PTSD.  Great.  But she seemed fine this (Friday) morning (beginning sometime in the middle of the night, when she came bounding into the bedroom), up until she caught sight of Huckleberry, and the growling and aggressive behavior started up again.

Update 3: Later Friday morning.  Got home from walkies and errands; Southmoon came bounding up to greet me like a little golden retriever (and not armed for moose).  I unpacked a new toy from the shopping bag and commenced waving it around; Southmoon and Huckleberry seemed to be OK in close proximity, even when he waved a paw in her face while swatting at the toy.  But then she started sniffing his neck, and the growling started up again.  Hm?

O-kay, then.  Moisten a paper towel, and give Huckleberry's neck a good scrub (after consulting the Revolution instructions and confirming that it's fine to give the critter a bath after a couple of hours).  Southmoon seems calmer now.  Interesting.

Flea bombin'

So today was the day to kill the household fleas (the cats' onboard fleas get poisoned tomorrow afternoon).

Cover food and utensils; close windows; don't worry about pilot burners with this particular type of fogger.  Set up chairs on the patio.  Move the cats' food and water bowls out.  Move Tinga out.  Coax the cats out (they're starting to suspect that Something Is Up).  Set the flea bombs: garage, hallway among bedrooms, dining area.  Exit via the front door, and return to the patio.

The cats are worried, and make it abundantly clear that they know where home is, and that indoors is where safety is.  At one point, Huckleberry and Southmoon manage to get into the front yard - and make a beeline for the front door, hoping to get in that way.

Then, just as we seem to have everyone settled, Autumn Weather Event Adrienne arrives, bringing sprinkles and a slight breeze.  Hmmm.  Put a little rain shelter atop Tinga's cage.  For everyone else?  I think I saw a beach umbrella in the shed.

Yup, beach umbrella.  At one point I had a stand for it, but I may have discarded that.  Oh, well: hammer it into the dirt, using a field-expedient hammer.  Now the cats are worried about the umbrella: is it a jellyfish?  Is it going to sting us?  Southmoon and Huckleberry eventually decide it's kinda-sorta-almost safe, but Top Hat runs off to the side yard to hide, eventually ending up wedged between the shed and the fence for the remainder of the adventure.

It doesn't help that Joy is sheltering from the cold with a weird shirt with a sort of hood thing.  The cats seem even more worried about that than about the beach umbrella.

On various occasions, Southmoon starts crying and scratching at the garage door.  She knows where home is!

Eventually, the appointed time comes around, and I go around via the front door (cats carefully kept on the patio, except for Top Hat, who's still hiding) and go around opening windows, turning on the blower over the stove, and so on.

After a bit of airing-out time, I open the door from patio to garage.  Zoom!  Southmoon, who had been out of sight for a while and presumed hiding in the side yard with the others, dashes in.  Huckleberry follows.

With two cats, their bowls, and Tinga all indoors, I take the treat jar to the side yard and eventually coax Top Hat out of her hiding place.  Meanwhile, Huckleberry has gotten bored with all this, and has gone back out to patrol the blackberry thicket, so now he needs coaxing.

The day did get to be quite an adventure.  And now my ankles itch (probably minor scratches from blackberries and such).

Such a day it's been (so far)

And it started so early!  0030-ish: Southmoon comes bounding into the bedroom, which is normal enough, but she's making peculiar little sneezing/wheezing/coughing/spitting noises.  Hm?  Oh, crap: she's frothing at the mouth!  WTF?  Bad reaction to the flea powder (which she, in particular, wants to get away from)?  Ack!

Well, she's not exhibiting any of the orthodox symptoms of pyrethrin poisoning in cats, and it's not like she was exposed to a concentrated dog product; the can says it's for use on kittens and contains 0.1% pyrethrins.  Also, she's starting to seem a lot more normal now.  Give her (and the other two) a good wipe-down with a damp towel.  She wants to sit on the table, so give her a bowl of water and a small one of their favorite wet food there (with a bigger bowl of the special food on the floor for the others).  She drinks, and eats, and generally doesn't seem to be in continuing distress; by morning, she's back to her usual self.

Best guess, she'd been licking the powder off and gotten a nose-full (hence the sneezing) and a mouth-full (hence the spitting and general salivary sloppiness).

After that, morning gets to be kind of late.  Definitely a day for sleeping in.  In among usual Saturday-morning stuff, continue poking at that Kinetis KEA project I'd mentioned.  Yesterday, I'd gotten the I²C and UART drivers working usefully, so now I can communicate with the CPLD (via jumper wires between the two eval boards) and use printf (ported from my personal library) to send messages via UART2 and the debug port on the board.

Except: during the night, my test program had stopped running.  The test program buzzes in a loop, blinking LEDs, reading from the CPLD, and printing CPLD register dumps via the UART.  After running for quite a while, it died with an unhandled exception.

After much fiddling, I found that it was encountering a hard fault of some sort.  Certainly appears to have been executing in hyperspace.  Enlarging the interrupt stack doesn't fix it.  Fiddling with timing moves the problem around.  For any given combination of message lengths and programmed delays, the time to failure seems to be consistent, being somewhere between a minute and a few hours.  Stopping on the hard-fault handler, I examine the stack, and the top three words are "katskatskats" (0x7374616b three times, corresponding to R0..R2 at, presumably, the time of the trap).  The trap address seems to have been 0x90000, which is indeed nowhere.  I wonder if the magic value is really meant to be "stak", perhaps marking the region where the stack has not yet pushed?  There's a largish area below that which is indeed filled with that value.  All of which doesn't immediately help me.  What I need is a trace of the last few instruction cycles before the trap, but I don't think the Cortex M0 is going to give me that.  In any case, it doesn't seem to have been a stack overflow.

Lunch break!  Time to let the critters out back while I grill something on the patio.  Defrost a hot-dog bun.  Light the grill.  Grab a hot dog and toss it on.  Um.  That flame looks awfully feeble.  Try turning it off and back on: no flame at all.  Foo.  Stick the bun in the toaster and the dog in a pan on the stove.

After lunch, take another load of Old Stuff to e-waste drop-off, and a propane tank to tank exchange.  As I get in the car, there's a blur to my right.  Cobweb in my hair?  Oopsie!  My glasses have come unscrewed.  Grab the right lens and the corresponding tiny screw before either of them can get lost; go back indoors and re-assemble the seeing-pieces.

Now it's 1308, and there's a lot of day left.  Will my continuing attempts to debug the hard-fault thing lead to some new chaos?  Will the front door fall off its hinges?  Will the cats find some new way to take revenge for the flea powder?  Stay tuned!

Update: The day ended with a family gathering - always stressful, but nothing went horribly wrong.  The cats are OK.  The kats are still infesting RAM and registers, but... well, there's something bizarre going on, especially seeing as how the failure shifts shape if I fiddle with the main loop, but it seems to favor happening when the number of iterations is a power of sixteen - as in, the last message reports a loop count of 0x10000, where the number of trailing zeros varies depending on exactly what I'm doing in the main loop, and there's generally a partial data dump after the loop count before it's cut short by some inappropriate exception.

Update 2: The wedgie happened again during a Sunday-overnight test run with the loop time shortened.  Last iteration had a loop count of 0x00100000.  Hitting Pause on the debugger revealed that it was in the UART handler.  A bit of stepping showed that it was getting the transmit interrupt, but not actually handling it because somehow the software status that shows that interrupt being enabled had gotten cleared (and the driver checks its own idea of the enable status, not the UART bit that actually enables the interrupt).

So... aside from the question of why the driver was written that way (and if I want to change it, I'll have to find the template and fix that), why the heck is the enable flag in the status structure getting cleared inappropriately, and at such oddly consistent times?

TFIL

The cats have been playing The Floor Is Lava lately, especially with regard to the carpet.

Methinks flea-bombing had better be a priority for Saturday.  And maybe I should dust the carpet with flea powder in the meantime.

Funny thing: the fleas have been leaving me alone, even as they make the critters miserable.

Kinetis library grumble

Well, I'm back to the task of getting some firmware running on a Kinetis KEA-series MCU - the automotive subfamily.  Because sometimes the application calls for something more than just industrial spec.

I'd already noted that the support available under KDS is annoyingly different, and that KSDK support isn't there (and isn't planned for any time soon).

Well, now I have a little blinky-lights program running on the eval board using MQXLite, and it's time to bring in some real functions (like talking to the CPLD via I²C).  And: the device-driver conventions are quite different.  So I'll be needing to make a bunch of changes to, e.g., the I²C memory driver that was sitting around, already working on a different Kinetis part via KSDK and FreeRTOS.

Oh, well: another device-driver interface to figure out and hide behind my abstraction layer.

Update: Oh, great.  This family of device drivers doesn't appear to be actually documented, aside from comments in the source files, and... oh.  There's a missing function, SelectSlaveDevice, mentioned in the comments but nowhere to be found.  Looks like, yes, it's necessary to go to the "Methods" tab for the device driver and enable that one.  Between that little discovery and what I'm digging up from support fora, perhaps I'll be able to get this turkey communicating in the next few hours.

Update 2: OK, found the documentation.  It's in Processor Expert's "Help on Component" thingy, accessible via right-click.  Even includes a "Typical usage" example of sorts.  Thing is, the scheme this device-driver model uses for initialization and whatnot is not friendly to device abstraction on buses.  Oh, well: looks like I can't use static configuration for one-or-more memory-like peripherals, or maybe a level of indirection is required.

Update 3: Bad software architect!  No pizza!  Turns out the xxx_Init functions return a magical pointer, which is supposed to be passed to the subsequent I/O functions.  If automatic initialization is turned on, the init code calls the xxx_Init functions and simply discards the returned values, rather than, say, saving them in global variables that follow some naming convention (e.g., xxx_Data) or just storing it in a static variable for future use (since xxx_Init and xxx_TweakBits live in module XXX.c and are specific to device xxx).  So, for those device drivers that actually rely on the value, automatic initialization is right out, and each Init function must be called, once, from the application's initialization code and the returned value kept somewhere safe and passed to all the TweakBits functions.

Update 4: So now I'm trying to work at the LDD (Logical Device Driver) level, and having to implement my own blocking I/O operations.  MQX Lite provides semaphores: good.  But...

So I set an event handler to post to a defined semaphore on I/O completion (per device, and maybe per general operation type).  But that means I'd bloody well better wait on completion after each operation that's expected to generate a completion event, because there's no method provided to reset a semaphore without waiting on it, and I really don't want to end up in a situation where I'm one completion event ahead and failing to wait on completion of the current operation.

Or I could just set VALUE to zero when I'm about to launch an operation and I'm not sure the semaphore is clean.

Back to work!

Well... I've been partially back to work since Monday.  There's a lot of catching up to do.

Anyway, 'tis time to dust off a ToasterCo project that's been dormant for a few months, involving one of the Lattice MachXO super-CPLD parts (almost an FPGA, but not quite).  We're using the older MachXO rather than one of the more modern variants, because it's available in automotive-grade (and a convenient package, and other such fiddly details).

Now, last time I was working on this - basically doing some feasibility testing, making sure I could attain the required timing and so on - it took some fiddling.  I remember that much.  In order for the Diamond toolchain's programmer to detect the FTDI-based programming cable under Linux, one must rmmod ftdi_sio, right?  So the software can use its own, user-space driver instead of the usual FTDI comm-port driver?

Well, that didn't work this time.

After much fiddling, I determined that I had to unplug all the other FTDI-based serial ports (there were two plugged in, for unrelated projects), then re-connect the breakout board with its programming hardware, then do the rmmod ftdi_sio again.  After that, it's working.

Looks like I can't use the programming interface and have any FTDI-based serial dongles plugged in at the same time.  (Couldn't the FT2232 on the board be programmed with a distinctive VID/PID to mark it as a bit-bashing interface and not a serial port?  Seems like FTDI could designate an alternative PID or two for that sort of thing.)

It's never simple, is it?  And this isn't even the part they pay me for.

Update: Now things are together, and I can do some testing....

I'm trying to use Lattice's I²C slave peripheral module (RD1054).  The documentation, such as it is, seems to imply that sequential reads ought to work, and that data_vld should be asserted per byte.  Only... that's not what's happening.  I routed some signals out to test points, and hooked up a scope on the big, deep memory setting.  I see data_vld happening for the first byte, only.  Guess I need to dig into their code.

Foo.  I'm only trying to use the vendor's module because it seemed like it ought to be easier than coding my own.  I may end up dumping it and doing my own anyway (most likely using a state machine and a high-frequency sampling clock, just because I find synchronous designs easier to deal with than these weird things that try to create clock pulses using implied logic delays).

Update 2: Bleah.  The signals actually coming out of that module, as routed to pins and observed on the oscilloscope, bear little or no resemblance to those shown in the documentation.  (Also, the handling of the data0 state is clearly wrong, though I'm not sure what the right handling would be.)  Presumably it works in the simulation, but I'm not inclined to get up to speed on the simulation environment.  Um.  Maybe it works in simulation because those #1 thingies scattered through the code actually have an effect in simulation, while synthesis ignores them and lets the delays fall where they may?

Time to look on OpenCores.  Actually, I'm quite certain I did that before, and rejected all projects listed there.  Why?  Dunno; that would have been long ago.  Looks like there are some candidates, with BSD licensing (so OK for this project).  Have to review their documentation, and see if there's one with a decent interface and that isn't too resource-hungry when configured as a slave.

Update 3: Yeah, looks like the known-good-and-BSD-licensed one on OpenCores is designed to work with a processor, which is something I definitely don't have in this design.  Or, rather, there is one, but it's in a different chip, and the I²C is for it to communicate with the CPLD.

So, gotta write my own.  Or use SPI, maybe.  SPI is easy.

And furthermore: Southmoon has been trying to help all day.  Right now, she's lying on the Aardvark pod I was using to exercise the I²C (and will be, again, once I get my implementation done).  Maybe she thinks she can hatch it.

Hmph. Seemed like a good idea at the time.

Well... I had a go at using the EAGLE v7 hierarchical design feature.

As matters currently stand, it falls considerably short of being useful.

Yes, it's a handy way of organizing the schematic, and handling replicated structures (I need to deal with eight copies of one module, each of which has four copies of a sub-module).

But....

It doesn't help the least friggin' bit with replicated layout.  I'm thinking it actually makes the layout process even more awkward.

The resulting reference designators are appalling (QUAD2:CELL1:R34, for example).  They can't be re-sequenced into geographical order, but I guess that's OK, because there's no way they could be included on the silkscreen, and putting them on an assembly drawing would require some serious miniaturization.

Trying to debug a board...?  This could get very annoying, very fast.

Then there's the question of whether the assembly house will accept that refdes format.  And whether the BOM and pick-and-place export utilities I've been using will deal with it... or indeed with a hierarchical design.

Also, there doesn't appear to be any way of selecting a hierarchy object per se, so that its components can be moved apart from the mass and onto a layout template.  Highlighting in the schematic and alt-tabbing (the switch view button would remove the highlight!) to the layout gets a somewhat useful indication of what's what, but the moment you select the move tool, the highlight goes bye-bye.

So, nope.  Not useful for what I'm trying to accomplish.  Back to the old flat schematic, with eight copies of probably a B-size sheet with a complete four-cell cluster plus the common stuff.  That'll be enough of a headache, but at least the reference designators will be a sane length.

This also means that the next phase of the project will be more laborious than I'd hoped, but, hey, it's hourly.

(Maybe I'll rummage around the 'net a bit later, and see if there are any useful tips for actually using the hierarchical features.  Should I find anything to change my mind, I'll post an update here.)

Update: Seems the hierarchical thing was half-implemented, not to the point of actual usability, at the time Cadsoft was acquired by its previous corporate overlords, but Marketing decided to declare it a feature anyway.  I did, however, find a useful tip on how to do what I actually need to do: lay out the cell as a separate design, then import it into the overall design 32 times.

Know what'd really be helpful here?  The ability to select a group in the layout editor, and lock all the elements in it together until further notice.  That way, each cell layout could be moved around as a unit.  This would be especially useful if the lock persisted when the cell design was imported into the greater design.

Update 2: I promptly find two annoyances with the "save cell as its own design, then import repeatedly" approach.

First, there doesn't seem to be a way to auto-sequence a selection of nets, so that, e.g., IN, CONTROL, and OUT would have "1" appended on first importation, "2" on the second, and so on.  There's the opportunity to rename nets during importation, but it's annoyingly manual.

Second, each imported design starts on a brand-new schematic sheet, which, when we're importing little cells, brings us back to the classic annoyance of trying to move schematic fragments from one sheet to another, so we don't wind up with a 50-page schematic.

I have the feeling I'll end up importing four cells, merging the schematics into one B-sized sheet, combining the layouts into a quad-cell, grafting in the per-quad circuitry, then importing the quad eight times into the overall design.

I'm also getting the feeling that this may end up being a six-layer design.  I'd better get a handle on how much space I really have for the stuff that goes between the cells, to see if I can loosen things up a bit and get back to four layers.

...Oh.  I'd made the cell layout 0.4" wide, because it uses 4 pins on a 0.1" pitch stacking header.  But the actual pitch required is closer to 1".  [Edit: Sorry; the final connector row is on 1" pitch, but there are two staggered rows, so the cells are on 0.5" pitch, overall.  Still works with all the cells being on the same side of the board.]  That do free up some space; I can maybe use a single-row stacking header, and putting all the cells on one side of the board might make life easier.  Or, I can get away with using a components-both-sides layout for each cell.  Anyway, it should be easy, but I need to get my strategy in order first.

Software: threat or menace?

So the next phase of this big non-toaster project pretty much calls for EAGLE v7, on account of hierarchical designs.

I'd already observed that v7 doesn't play nice with the older version of Debian on my desktop, what with the libraries being out of date; I need to force use of some futuristic library to make it run at all, and then trying to use the print dialog kills it, but otherwise it seems pretty much OK.

My laptop, now, is already updated to the current Debian-stable (Wheezy Jessie, or Debian 8).  And EAGLE 7 runs on it.  Well... apart from the fiddly detail that (presumably because of some library API instability) the text lengths seem to be calculated wrong, or perhaps not at all, so that xref-style labels enclose about half the last (or first) letter of the label, vertical text seems to be variously not displayed at all or displayed in bottom-to-top order, and other wonkiness.

Either my Google-Fu is weak this evening, or nobody else has had this problem...?

...Do I need to fire up ldd and see what it's using?  Would that even work?  Should I try something silly like spinning up an Ubuntu VM?  This is most vexing.

Oh, and it seems Cadsoft has been acquired by Autodesk or some such thing.  They seem to have ambitious plans, some of which sound potentially useful.

Update: Turns out the vertical text was bottom-to-top because the Options->User Interface->Vertical text option had somehow gotten set wrong.  But even deleting .eaglerc doesn't address the issue with text dimensions being miscalculated.  Sooo... probably not some local configuration problem, but a shared-library thing... but, in that case, why am I not seeing any indication of others having the problem?  Maybe a library is misbehaving because of its local configuration?

Update 2: I installed Kubuntu in a VM.  Plasma crashes every so often.  Also, I'm reminded of why I don't like the Ubuntu family: it's pretty much a world of its own, and things like package management need to be re-learned (either that, or just do sudo apt-get install synaptic as one of the first steps after installation).

Anyway, EAGLE handles text correctly under Kubuntu 16.04, but not on my installation of Debian 8.  I don't think I want to be messing around with running it in a VM on the laptop (awkwardness with shared directories; other annoyances of running CAD software on a VM on a normal-sized laptop).

So I still gotta figure out what's wonky here.

Update 3: Oho!  Now - I can't remember for sure whether it was like this a month ago - EAGLE v6 is also having the wonkiness.  So, something that's always worked fine under Debian 7, and seems to be OK under Kubuntu.  Maybe I should try it as a different user, and see if it's something in my settings?

Also, the Kubuntu VM seems to have Issues with forgetting settings, deciding that my personal account (UID 1001) shouldn't be presented on the post-boot login screen, and other nonsense.  I don't think I'll be keeping it.

Update 4: Whatever the font issue is, it happens with the 32-bit version (and 32-bit libraries) too.  Forcing vector fonts works fine, but the schematic is ugly with vector fonts.  Vector fonts are for silkscreen, or for pen plotters!  (Or radarscopes, or other vintage tech.)

Come right down to it, isn't it time to take the Gerber photoplotter files out of the equation and use something SVG-derived for transmitting PCB layers?  It gets rendered to raster form anyway these days, doesn't it?  And a modern format could include all manner of metadata, all layers in a single file, and all that kind of good stuff.  The silkscreen text could be prettier, too.  Win?

Update 5: So I did a clean install of Debian 8.5 in a virtual machine, and installed EAGLE on that, and it seems to be fine.  Ergo, there's a problem related to the specific configuration on the laptop.  Is it related to having dist-upgraded from Wheezy?  Will my desktop develop the same problem when I dist-upgrade that?  Why does this spellchecker think dist-upgrade is a legitimate word?  How many more drunks will flee to Canada without waiting to see who gets elected?

Post-relocation, I plan to have enough desk space and budget for a humongous high-res monitor, so having things run in their own VMs (and having remote desktops for the various lab machines) should be less problematic.  But that's some time off yet.

Update 6: Just to make life even more weirderer, I opened someone else's EAGLE file, made some changes, added a couple of xref-style labels... and text (proportional) is working normally.  Re-open one of my files, or create a new schematic, and text is messed up. ????????

Demo!

I packed up the dog and pony again this afternoon (after confirming that the gremlin was, if not banished, at least propitiated) and headed off to the client site.

This time everything worked!  In front of the client, even!

And now I have a bit of slack in that project's schedule, since the guy who'll be doing the application software is currently tied up working on hardware (with wrenches and whatnot), so I get to hang onto the test platform for a while yet.

Next priority is some documentation, then some patching-up of hacks made to the hardware.  Then... well, there's a fair long list of stuff I really should get done in the next three weeks.  Not to mention stuff for other clients.

Oh, and two new gremlins turned up this morning.  One I bypassed temporarily; the fix seems to involve adding bulk capacitance (and I sure hope I can avoid electrolytics; this thing is supposed to be reliable).  The other is yet another oddity in the Linux USB stack, cured by a reboot.  (The long-running oddity is a tendency to decide that, for example, an ACM device should appear as /dev/ttyACM17 instead of the more obvious /dev/ttyACM0; the one that bit today was a sudden belief that the USB port didn't have enough current available to power the same dang collection of peripherals it had been powering all week.)

For now, though: I'm tired, frazzled, and chronically overcaffeinated.  Also, it's 90 degrees horribly Fahrenheit.  Time to vegetate for a couple of hours, while guzzling ice water.

Ground loops!

Can be exciting!

Or, as in this case, merely frustrating.  I think the gremlin I've spent the last week chasing was actually a ground loop, of the electrical variety.

See, there's this engineering lash-up, prototyping the various subsystems of a product under development.  Being as how it's a lash-up, with each subsystem on its own board, there are wires everywhere.

There are four boards in this lash-up: one of type A, one of type B, and two of type C.  Various boards of type D (or D', D'', etc.) may or may not be connected to the type C boards.

There's been a Heisenbug afflicting board C0, and not board C1.  Replacing C0 changes the problem, but doesn't actually fix it.  So... are all the type C boards faulty, except for the enchanted C1?  Or...

The type C board has a power connection (power and ground), and a data connection (USB).  There's a quad UART on the board, powered from the bus (the power connection is for some medium-power drivers).

Certain sorts of activity cause the UART to drop off the bus, and then re-enumerate.  This only happens with the power supply at or near rated voltage; running at half voltage, there's no problem.

For the past few days, I've been chasing the notion that the UART (or the Linux FTDI driver) freaked out if certain modem-control inputs (in particular, DCD) changed too often; some of the early type C boards had interesting problems that led to, e.g., 1.4 MHz square waves on all four DCD lines once a certain voltage threshold was crossed.

But, this hypothesis really wasn't consistent with what I was seeing this afternoon.  It really seemed to be position-related.  And... um.

The one thing different about the C0 location?  The power wiring is longer than C1.

So I added a second, shorter ground wire to C0.  Now... it seems to be behaving itself.

Still gotta do more testing.  A bunch more.  But it looks like certain switching events, with the supply at full voltage, created big enough current spikes to cause disruptive ground bounce on the USB cable, leading to bus errors.

In the production item, of course, the USB will all be on the one unified board, running down the center, with a nice quiet digital ground plane under it, and the power for the drivers will be routed around the periphery, with strategic plane cuts to avoid this sort of thing (as well as ground offsets when there's a lot of current flowing).

Update: As currently wired, the problem reappears if I crank the voltage up to 15% above nominal.  Action plan for Monday involves re-wiring, using heavier wire for the ground, and adding some inductance in the supply paths.  The gadget is designed to operate from 60% below, to 25% above, nominal supply, and I'd really like to see the lash-up perform over the full range.

Update 2: Oho!  This would also explain why it was sometimes bombing when I connected a ground lead to one of the ground test points.

The pony kicks his heels up while the doggy does his trick...

Yeah, had to put on a show this afternoon.  On a Monday.  At the client site, so it meant moving the test program from my workstation to my laptop, and packing up the test-bed hardware.

First oopsie: the control MCU enumerates correctly as /dev/ttyACM0, and I can open a PuTTY session connected to it, but pounding on the keyboard has no effect.  WTF???

After much power-cycling of the testbed, cable plugging and unplugging, and so on, I realize that I'd been pounding on the wrong keyboard.  Putting the laptop on my desk for the process was maybe not the best move; I kept getting mice and keyboards mixed up.

That having been sorted out, I proceeded to box up the hardware.  Second oopsie!  I left the mini-USB cable plugged into the hub board.  It had enough leverage against the edge of the box to pop the little SMT connector right off the board.

Well, that's why we make the boards in threes.  One for the client, one for me, and one for Murphy, right?

So I grab USB Hub Board S/N 2 and swap it in, then quickly power up the unit, plug it into my lab PC, and confirm that everything still enumerates correctly.  Off to the client site!

Discussion, display of hardware, setting-up of laptop, connecting of cables!  Send the first few commands to the control MCU: all appears well.  Run the test program.  Issue a few commands....

Third oopsie: the power LEDs on the remotes go out after a couple of commands.  Everything that goes through the UARTs (comm or modem control) seems to have stopped working.

Much fussing and fiddling.  Eventually discover that, shortly after I started doing things with the UARTS, there was a flurry of USB errors, and the UARTS disconnected and re-enumerated, which didn't exactly preserve my program's connections to them.

After much further fiddling, I dug a compact USB 2.0 High-Speed hub out of my laptop case - good thing I had one in there, and good thing it was of the High Speed persuasion! - and used that to connect everything.

Still strangeness, but eventually I managed to get it working well enough to demonstrate basic operations.

Now I gotta figure out what was going on with the USB: is there something wrong with the second USB hub board, is it something to do with the laptop, or was it just the built-in crisis detector at work?

It is actually rather important that the USB hub work properly, as that and the UARTS have to end up on the same grand unified board with the control MCU and the power circuitry, comes the time to turn this into a product.

Oh, well.  The client got to see something working, anyway, and there's a pretty good chance I'll have the glitches fixed by the end of the week.

Update: It appears that the hub is fine.  The UARTs may or may not have a problem, and the Linux driver for the FTDI UARTs may or may not have a problem.  There's some issue with the modem-control signals, and some sorts of activity on those signals triggering error status, which doesn't particularly make sense.

Also, there may have been a mechanical Heisenbug in the data path to one of the UART chips: a poor solder joint may have made it sensitive to vibration.

It's now Friday morning, and I'm still bashing my head against this... though I now have seven out of eight ports in the test setup apparently working (port 0 goes to permanent error status if I turn on RTS, though it seems to be OK if I exercise the modem-control signals from GtkTerm).

Growf.

I mentioned setting up the lab for some power-electronics tests?

Feeling a fair bit better today (but stressed, what with my to-do-soon list getting more longer than shorter, and a nasty problem having cropped up with regard to a bog-standard switching voltage regulator), I took a bunch of clutter to electronics recycling, dug out the big honkin' lab power supply, and rounded up a pile of power resistors that, suitably connected, should present the requisite load while safely dissipating an Imperial smegload of waste heat (while I check the teeny-tiny unit under test for signs of overheating; the math says all should be cool).

Gotta organize the things, and 'tis best they should be bolted to a hefty slab of aluminum.  So: mark positions, and drill and tap twenty mounting holes.

Well... around the fifteenth hole, my #4-40 tap snapped.  And why did I have only one #4-40 taper tap in my toolbox, anyway?  There's a matching bottoming tap, but I don't really want to use that.

Ah, there's a spiral tap.  Or, as one might say, this is spiral tap.  Not really meant for handheld use... and it snaps on the second hole.  Foo.

Guess it's off to the hardware store.  And, later, I'll have to find the bottle of Tap-B-Gon.

Update: The dreadfully Searsified OSH no longer carries a nice selection of taps in little bags.  There's a rack of overpriced American Vermin threading products, but individual taps start at #8-32; for #4-40, the only option is an even more overpriced tap-and-drill set.

Oh, well.  It got the last few holes done, with much more effort than a proper Greenfield (or even generic industrial) tap would have taken.

Note for next time: do all tap breaking in the morning, and make an MSC run while (a) they're open and (b) it isn't rush hour.

Low-grade crud

Started Tuesday morning, with a headache, vague queasiness, and a slight fever.  A dose of naproxen got the fever under control, more or less, and helped a bit with the headache.

Wednesday morning: I was feeling mostly better, and went for gentle-edition morning walkies.  Not the right thing to do.  After about 4 miles, I had the dreadfuls again, and still had to run some errands on the way home.  Reminder: exercising when almost-but-not-quite over the crud makes the crud come back.

This morning started out worse than Tuesday, except that the fever was minimal (the feeling of feverishness is still there, but not much actual fever).

Much idly sitting in front of the computer, not accomplishing much.  I did get some actual work done the past couple of days, and will get a bit more done today, but there's quite a lot of stuff that needs doing Real Soon Now that involves physical exertion (household chores, and setting up the lab for some power-electronics tests), and that's not happening right now.

Guess I'll rework a few more boards, then go watch some U-Toobz or something.  (Two notes to self: don't use super-tiny-footprint chips unless absolutely necessary, and if you're getting mostly-assembled boards with some SMT parts missing, and assembly is lead-free, ask to have the pads for the missing parts kept free of solder.  'Cause removing the standard tin-silver-copper lead-free solder is a royal pain, especially where delicate tiny feature sizes are involved.)

Oh, fer...

Once again dealing with the FreeRTOS/KDS/KSDK combination.

I just tested that new configuration, whereby one task receives commands and another does the processing.

There seem to be multiple things wrong, but here's the biggie:

I set out to use binary semaphores.  One task waits on the command-has-been-received semaphore, and the other sets the semaphore when a command comes in.  There's a second semaphore involved, for dealing with likely future complications.

For good and sufficient reasons, these should be binary semaphores, or counting semaphores that can't count above 1.

Well... the KSDK OS Abstraction doesn't do that.  It does, however, do mutexes*... which, according to the FreeRTOS documentation, are close enough for my purposes.  So I write it to use mutexes.

It doesn't work.  The processing loop waits once, then buzzes around.

The abstraction layer is being helpful.  If the calling task already owns the mutex, it returns immediately with error status.

Great.  Looks like I need to bypass the abstraction layer and call the FreeRTOS binary-semaphore functions directly.  Or the mutex functions, even.

What I need is a binary semaphore, such that if it's currently zero, the calling task will always wait for someone else to come along and set it.  This Should Just Work.

(Yeah, maybe if I'm very careful I can get away with using all-purpose counting semaphores.  Binary semaphores are safer in this context, and more conceptually appropriate given that they're associated with single message buffers.)

 

* Not to be confused with mutoids.

Oopsie.

Continuing with the firmware for that itty-bitty board....

Suddenly this morning it wasn't working anymore.

I'd made some changes last night, in preparation for a restructuring of how commands get processed (breaking command execution out into a separate thread from command reception, for reasons related to the communication protocol), but hadn't actually done anything that should break the program just yet.

And yet: it was hitting DefaultISR during launch of the initial task.  WTF????

So I commented out all the new code.  Still DefaultISR.

Something to do with the new task I'd added?

Ah... here we go.  I'd fiddled the task priorities.  Using FreeRTOS, developing with KDS, and using Processor Expert to configure the tasks, it seems that the RTOS main task must have the highest (numerically lowest) priority, or critical system initialization doesn't happen.

Which is annoying, since I'd meant to have the main task do background stuff.

Guess I need to rearrange things again.  Actually: I might just turn the main task into a debug/monitor thing, and add a fourth task to handle application background activities.  That eats RAM, but I still have a fair amount available at this point.

Or maybe just have the main task nice itself after initialization.

A quadrupedal absence

Back during the winter, I had that sewer line replaced, with much excavation of the front yard.

In the process, the workers dug up the sprinkler nearest the front porch (where they started digging); they re-installed it all nice and neat before they left.

Comes the hot & dry season, it's time to turn the front-yard section of the watering system back on.  Test run first: energize valve, hear water running, go out front to have a look:  Hm.

The last two sprinklers in the chain aren't working at all.  The antepenultimate one is very weak.  The pipe between "weak" and "nothing" runs along the inside edge of the front fence, a few inches below the surface.  Got broken during the sewer proceedings, maybe?

So I get out the narrow spade.  Then the pickaxe.  Ferschlugginer nasty dry hard heavy clay landfill with tree roots in!

Run some water on it, turning it into ferschlugginer nasty sticky heavy clay landfill with tree roots in.

The recently-disturbed area (where one might expect a break to be) is easier to dig.  I'm not finding the pipe.  C'mon, it can't be that far down!  I'm lazy; I would have buried it maybe 4" to 6" below the surface (which is good enough, here).

Finally, at the far downstream edge of the disturbed area: the severed end of a PVC pipe!  Buried about 4" down.

Looks like there's about a 4-foot segment of pipe missing.  I haven't managed to excavate the other end yet (nasty soil and roots, awkward angle, and muscles that haven't been getting enough use lately). I gave that area another soaking, and will dig some more later.  Also, somewhere along the line, turning the system on and seeing where water comes out may be helpful.  Probably during the heat of the day, when I won't mind so much standing in the spray pattern of the sprinklers that are still working.

Update: A bit more digging, a bit more hydraulic mining, and now I'm hot and tired but both ends are now exposed.  The downstream end looks fairly tidy, but is resting on a bunch of roots; the upstream end is jagged.  Repair promises to be fun, for sufficiently not-fun-at-all values of fun.

Might want some implement for cutting PWC pipe at the bottom of a trench.  What's a sozzle cost, anyway?  OK, so a genuine sozzle-brand sozzle is a bit pricey for current requirements (and I don't really know what post-reboot requirements will be), but there are some not-too-pricey, brand-nameish corded reciprocating saws that look plausible.  Hm.  Or maybe I do want something a notch better, since I'm already thinking of home & garden tasks that call for more than a handsaw and less than a chainsaw.

Stuff to ponder.  Meanwhile, I guess I'd better disable the front sprinklers again, what with the broken end of the pipe no longer being obstructed by clay.

Update 2: Arriving Tuesday (darn holiday weekend): one entry-level Porter-Cable brand sozzle what gets good reviews on Amazon, one blade assortment, and one package of tree-pruning blades, which I figure will be appropriate for use on the dead branches of the avocado tree, while up a ladder.  (There's one big dead branch that really does call for a chainsaw, but that one is accessible from ground level.)

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.

Meanwhile, on the other work front...

One thing about spending most of my time in the embedded-MCU world: I don't use floating point a lot.

But, what with the $2 MCU in one of the current projects having hardware floating point built right in at no extra cost... I figure, well, I might as well use floating-point calculations for stuff like calibration factors, because it's easier than mucking about with scaled integers, innit?

And besides, I'm using the KSDK implementation of printf, which never heard of my %p scaled-integer format.  I miss my printf.  I should port it to this platform.  Anyway!

I enabled the floating-point formats in the print_scan module, and soon discovered that I was getting wildly wrong answers.  Like, 10.0/65535 was coming out 1.000153, and (10.0/65535)*16985 was coming out 3.5917.  Eh?

Well, it's pretty obvious that the actual arithmetic is right, but the formatting is wrong.  Like, the integer part of the output is high by 1.  But not always.  Feed printf a nice clean constant 2.47, for example, and it comes out 2.47.

So I end up digging into mkfloatnumstr, where the actual conversion happens.  There's some code that doesn't quite make sense, that's obviously the thing that's incrementing the integer part.  Disregarding Chesterton, I boldly comment it out!

At this point, everything I throw at it works... except that 5.000 comes out as 4.000, and 10.000 becomes 9.000.  Oh.  Right.

[Added: These weren't actually exact numbers to begin with; the input was, e.g., 5, and the output being sent to printf was the nearest approximation the hardware was prepared to attempt.  Which was probably 4.999something.]

Some rather common numbers, like 5 and 10, don't represent exactly as binary floating point.  Thus, some fiddling is needed to make the binary version of 9.999999whatever come out as 10.

The original code having been rather less than useful, I just throw in a quick hack to check for fractpart > 0.9995, and figure that's good enough for the current application.

But methinks that module may need a rewrite... or at least that one function.

Somewhere around here I should have my totally portable floating-point formatting functions that I wrote back in the 1980s, for use on targets such as the 68000 and DG NOVA.  Might just be time to look for them... and I hope they exist somewhere other than a 9-track tape.

Update: My first hack didn't work right, either; 2.75 plus quantization came out 3.75.  Next try was waiting until after the fractional part had been converted, and checking for carry (leftover fraction >= almost 1).