Silicon Valley Redneck

Argh. Interrupt safety!

Been bashing my head against a fool bug, on and off, the past couple of days.

One current project is a cute little board with multiple functions, whereof one of the simpler is a port server, bridging a TCP socket and a UART.

Which works as expected, one character at a time.  But... send a burst of data into the serial-port side, and there's a reboot, often with a panic message suggestive of stack corruption, or task-control-block corruption, or something that causes the program counter to end up pointing somewhere entirely unreasonable.

Just found it.

See, AGROS uses a glorified version of counting semaphores for task synchronization (in this case, I'm using a single binary semaphore to tell the bi-directional communication loop when to run around copying data hither and thither).  So, I'm doing a P on the semaphore inside the loop, and a V when there's been an event on either port.

Um.

V potentially results in a task switch, running the scheduler and so on.  That, after all, is what it's for.

The event handler is (usually, and always in the case of the UART) called from within an interrupt handler.

Oopsie!

So I change the event handler to use Vc instead - free/increment semaphore and continue, without doing anything that doesn't belong in an interrupt handler - and now all seems well.  (I'd forgotten that there's also a Vm function, which branches to V or Vc according to the current processor state and should be safe anywhere.)

Though I still have a great big comment regarding the need for careful examination of the TCP-to-UART path, with regard to high-speed data dumps and CTS from the target.  That can wait; for now, the essential function is working, and I can proceed with other aspects of the project.

And you thought the "superdelegates" thing was bad...

The Libertarian Party didn't even wait for all the primaries to be over before holding its convention and nominating its Presidential candidate.

(Do they even participate in the California "primary" anymore?  I dunno; I switched my registration to "R" some years back, so's I could vote for Fred.  Who dropped out before California.  As did Herman.  And Ted.  Why do I bother?)

Life in the electronic age

Several years ago, my father bought himself a Saab convertible for his Monday-morning commute.  (At the time, he was actually commuting to work a few days a week, now he's down to just Monday mornings.)

Sometime last year, it started draining its battery in less than a week of standby time, so the once-a-week drive was no longer enough, and he keeps it on a trickle charger.

I was over there this morning, and the latest development was: it don't work no more.  Doesn't respond to the (electronic) key.  Everything remains locked (except for the doors, which he hasn't been in the habit of locking).

Hmmm.

Battery voltage is 13.25 while on the charger, dribbling off quite a bit faster than I'd normally expect when the charger is removed, but perhaps good enough.

Has the security computer gotten out of sync with the transponder in the key?  Or has it just temporarily misplaced its mind?  What happens if we disconnect the battery, wait a few minutes, reconnect it, and try again?

Or - happy thought! - surely there's a second key.  Does that work?  He goes off to fetch the spare key.  Voila!  We have a started car.  Now... how to re-introduce the first key, given that we have one-each working key in hand?  Apparently the local Saab dealership is long gone; who else would know how to do this?

Meanwhile, we'd both been trying to figure out how to extricate the metallic backup key (doors only, if memory serves) from the bulky plastic housing of the eKey.  I finally apply enough force to dislodge the one from the key I'm holding (the not-working one).

There's a little notch that looks like it's for prying the housing open, perhaps using the tip of the metallic key.  So I do that.

Oh.

There's a CR2032 coin cell in there.  Key's prolly just got a dead battery is all.

Ya know, in my day ya never hadda worry about your key's battery going dead!

C'mon, at least try to come up with a plausible story.

A big-city police chief up Oregon way inadvertently shot his friend while out hunting.

He initially claimed (or suggested, or something) that the friend had accidentally shot himself.

In the back.

With a rifle.

Srsly?

Another failure of comprehension

Interesting post here, regarding... well... too complex; can't summarize.  It touches on many subjects.

Among other things, it links to this example of discomprehension, which contains this:

Command lines demand that users remember the correct phrase to make the system run, rather than giving them prompts which might help them guess what the system needs them to do next.

What the system needs them to do next?  What madness is this?

The command line is for telling the computer what you need it to do next.  If the computer needs you to do something - insert installation disk #37 in drive A:, for example - the mechanism for that is indeed a prompt.  But, increasingly, computers don't require much in the way of operator intervention.  And that's nothing to do with command lines anyway.

There's also a cultural disconnect with regard to the term free, as it applies to software.  The assumption seems to be that it means free-as-in-beer.  But, within the community, it means not just that there's no fee for using the software, but that the users are free to get under the hood and tinker with it - which implies that Free Software is Open Source.

And, when you do away with command lines, and text-based programming languages, and all that "SYNTAX" stuff that Harihareswara so casually disparages?  The whole concept of source code goes bye-bye, and with it all prospect of Openness, and of Freedom.

Suppose, for example, that someone created a free (and perhaps even Free) knock-off of LabView.  You can construct test-automation processes without learning any syntax!  Just drag, drop, and draw connections!  Yay!

But in such an environment, there's not truly any source code - just a mysterious blob of data maintained by the magical graphical programming environment.  While you may have the legal right to share your creation, the prospect of any recipient being able to make sense of it is virtually nil.  (I know this from bitter experience, having been the recipient.)

And it is entirely possible to use much Free Software without learning the dreaded SYNTAX.  It is not, however, possible to contribute to a Free Software project without getting up to speed on the source code.  Because that's what programmers work with.  When, y'know, they're creating original programs, and not just hooking up building blocks in the limited ways anticipated by the block maker.

Four Collings birds...

Oh, they are still in the neighborhood.  Through today, in fact.

That explains why I've been hearing vintage engines, and occasionally catching sight of a B-24.

Two things that are equal to the same thing are never equal to each other

Especially in the wonderful world of software.

Got this chunk of code that's been through a couple of iterations before, on varying hardware.  Involves maintaining one or more large lumps of data on an SPI flash chip.

Now, the original hardware (for arcane reasons) used an AT45DF-series chip, which had a 528-byte block size.  Because the lumps of data in that case were handled differently depending on the lump in question, the code to handle it had to be block oriented, with some of the blocks being treated as 512 bytes and some using the full 528.  The driver for the chip uses block addressing, because that's pretty much how that family has to be addressed.  (The upside, apart from the aforementioned arcane reasons, is that it supports block-level erase and rewrite.)

The next adaptation of the code used bog-standard 25xx-series flash, with 512-byte blocks, period.  The driver uses byte addressing.  The erase size is inconveniently large, but some things you just have to live with.  There's a trivial translation layer to take block-addressed I/O requests and translate to byte-addressed operations (the translation-layer functions also take fewer arguments than the system-level I/O functions, because they only have to do one thing).

The current hardware uses yet a different flash part, that differs in minor details from the 25xx family but basically uses the same driver.  Write block size is 256 bytes; minimum erase block is 4K.  Not a big deal.

Except... it's not working.  I spent all afternoon yesterday trying to track down a persistent (and consistent!) failure to match up checksums (the data lumps are followed around by SHA256 hashes).  Reading the first part of a lump out of flash using a legacy read-from-the-flash-chip monitor command gave sane-looking data.

This morning, I wrote a new monitor command to read the lump out of flash and do a hex dump in a format that (with a little massaging) can be diff'ed against an od of the definitive original data.

Guess what?  It is completely wrong from beginning to end.  Well, almost.  There's a tantalizing hint of rightness, just at the beginning.  But, in general terms, gibberish.

And yet: the legacy monitor command shows the entire first 512 bytes or so matching the original, as far as a basic eyeball scan goes.

So?  Change the dump function to use the direct system call instead of the translation layer when reading from flash.  This is mathematically equivalent to using the translation function.

And, reading it that way, an initial test, dumping just the first 8K bytes, seems to work.  At least, the general patterns are right.  And the first several bytes are in fact exactly right.  Dumping it full length to a log file: again, general patterns right.  But!  Comparing in detail, it is in fact significantly wrong.  But differently wrong.

Wibble.

Maybe I need to work on something else for a while.  Or grill a steak.  Pick some blackberries.  Anything that doesn't involve bytes that play hide'n'seek.

Update: Gronk.  What's 512*FOOBASE + offset, where offset steps from 0 to something big in increments of 512?

Always some multiple of 512, right?

Unless... FOOBASE is defined to be BAZBASE+8, without parentheses.  D'OH!

And the presence of certain repeating patterns made the off-by-eight addressing not so obvious: the first several bytes were the right values; they were just the wrong instances of the same values.

Still doesn't explain why I got the entirely wrong result when I used the translation function, but... actually, maybe it does.  The expansion would have had a different effect there.

Well, this is silly.

Soon, I shall have the hardware for one of my little projects... well, a little subproject of a fairly large project, actually... a gadget involving a Kinetis MCU and some PWM.

Must be time to look seriously at the firmware aspects.  I have a KDS project configured.  The aspect I haven't looked at particularly is the PWM.  The KSDK libraries provide two levels of abstraction for generating PWM using the Flex Timer Module, so all should be peachy, no?

No.

Both abstraction levels take the duty-cycle request as a 32-bit unsigned integer, range 0..100.  A percentage.  Hello?

The FTM has 16-bit registers.  I've set it up for PWM at 1/2000 of the clock frequency, so I should be able to get PWM resolution of 1 part in 2000, right?

Right?

Looks like I gotta bypass the all-too-abstract abstraction layer, figure out which registers get set how, and just fill in the applicable registers myself when I need to set the duty cycle.

Oh, well.  At least I have the source code, so I can copy the key lines out of the applicable function, put them in a new function, and change them to take 0..divisor instead of 0..100.

Afterthought: The other nice approach would be to pass the duty cycle as a fixed-point fraction.  Special cases are 0 (full-off) and 65536 (full-on); the general case is, using 32-bit unsigned arithmetic, PWMreg = (request * divisor) >> 16.  If we postulate that the divisor is always <=65535, we maybe don't even need any special cases.  This would give nice uniform 16-bit resolution for the request, scaled to whatever the divisor is in the actual application.  (Given the availability of fast divide operations nowadays, we might even define 65535 to be "1", and use /65535 instead of >>16, thereby letting the request fit in a 16-bit unsigned field.)

...Yes, this application does require finer-grained control then 1-in-100.  That's why I'm using the large divisor and attendant large inductor and cap to handle the low frequency.

Critter sighting

Out and about this morning: a cute li'l mini wolf!

Had the form and markings of a husky, but was maybe Top Hat's size.  Or a bit smaller.

Somehow, I don't think that's a practical sled dog.  Playful little thing, though.

Malware? Yup.

Joy's laptop just got Windows 10.

It didn't bother asking.  It announced it.  "Windows 10 in 14 minutes 30 seconds!"

Wunnerful.

Then, after the reboot: Do you agree to the license?  You have to say yes.  Do you want Cortana?  You have to say yes.

No option for "Bugger all this!  Put my computer back the way I had it!"

At least my Windows lab machine hasn't done that.  Yet.  I made the registry changes to disable the GWX nonsense, and Microsoft hasn't overridden them.  So far.

And it looks like the important-but-out-of-date software Joy is using wasn't broken by the change.  Again: so far.  Given that Windows 10 doesn't have a stable API, who knows what'll break next week?

If I wanted that experience, I'd be running Sid.

Once they've tasted human blood, it's best to put them down.

My oscilloscope just bit me!

Not the new 'scope, the old one.  The one that's been on the shelf above my bench for years.

Actually, it wasn't the scope itself that did the biting.  'Twas a probe.  Or the probe's pointy hat, which I was re-installing from an awkward angle.

Still: ouch.  And I'd better keep an eye on that thing, lest it murder me in my sleep.

Some people just don't stay in their lanes

Headline:

Fed’s John Williams says election won’t stop central bank from raising rates

Fed's John Williams?

Is that anything like Royal Army cartographer Cole Porter?

Also on the agenda

Gotta gather network usage stats on eth1 (that being the outside connection).

I've been assuming that, post-move, a good landline 'net connection would be essential.  Certainly, Verizon's wireless 'net access is waaay too expensive for everyday use.

Looking at Exede's website (for my current location, and for a plausible destination), I find plans with decent bandwidth, but... well... at $150/month for a 30GB/month usage quota, it's a bit problematic.

But then I stumbled across an Exede reseller's site, and, in another plausible destination area, there's a $100/month plan with 150GB/month.  This seems plausible.

So, I gotta keep tabs on actual household usage for the next while, and get a handle on average daily usage.  Apply fudge factors up and down for various lifestyle factors, multiply by 31-ish, and I'll have a better basis for looking at Internet service plans.

And it does look like satellite might just be a viable option after all, which opens up large areas that don't yet have all the amenities.

Update: Household average over the past few days is just under 250 kbit/s, which works out to (divide by 8, multiply by 3600 and 24 and 31) around 84 Gbytes/month.  Peak is 2.8 Mbit/s on this here DSL line.  Usage would presumably increase on a 12 Mbit/s satellite connection, but I don't expect it would double.  So, a 150 Gbyte/month plan seems plausible.  As things get more specific, I'll have to inquire after details of what's available where, and the price of extra Gbytes.

Who knows... I might wind up with a 70-acre private valley after all....

Getting to be time...

...to retire the old household server.

Firstly, I need to shuffle the world-visible functions (web, mail, Subversion) onto the rented VPS, so I can be prepared to abandon the DSL line when the time comes.

Secondly, the Linux distro is stale, and no longer being updated (except for, maybe, security updates).

And, thirdly, I think the hardware is starting to go flaky.  This afternoon, it suddenly stopped responding on the LAN, didn't have any output on its VGA port, and didn't even respond usefully to the reset button - I had to power-cycle the thing.

Having been power-cycled, it now seems to be running OK.  Maybe it just needs the dust & cat hair cleaned out (a project for Memorial Day weekend, since I don't think I'll be making it to Baycon).

Hardware replacement, barring actual failure, is a later-this-year, post-move thing.  Probably put together something that runs cooler, most likely with an internal SSD plus some sort of well-ventilated RAID box for bulk storage.

Meanwhile, I'd better make sure everything important is backed up in multiple places.

Update: It happened again.  This time, I found the panic message in the system log, after opening up the machine and blowing much of the dust out, plus wiggling various connections.

NETDEV WATCHDOG: eth3 (skge): transmit queue 0 timed out

Hm.  Well, eth3 is the LAN.  Others have reported this error on oops.kernel.org, but that's not very informative.  And... I'm finding reports going back to 2008, and decidedly old kernels.  Um.  I'm running a vintage kernel on that box, amn't I?

Looks like it's a known kernel bug, in an obsolete kernel which won't be fixed.  But why did it manifest itself today, twice?  I didn't change the kernel lately, and the hardware configuration hasn't changed in years.  And the other reports don't seem to involve a total system wedgie, just loss of connectivity on the one port.

Another language to learn

Looks like I'll be getting at least somewhat up to speed on Lua.

Aside from being, apparently, the language of choice for playing with the ESP8266 WiFi chip, it's available as a handy MIT-licensed library for embedding, and there's eLua, intended for sticking on MCUs.

I've got some things coming up that call for scriptability, including a family of MCU-based gadgets.  I'd pondered JavaScript for the gadgets, but I'd have to come up with my own tiny implementation, as the existing tiny-JavaScripts out there have license terms incompatible with the intended use.  (The PC-side application that talks to them may still end up being in node.js, with a web browser for the UI... or maybe not; the structure of node.js is not so friendly to what I'm trying to do.  The original plan was Ruby and Qt, but the Ruby-to-Qt connection got broken a couple of years ago and still doesn't seem to be fixed.  Might end up being Ruby + browser.  Or Lua + browser, or even C++ + Qt + Lua.)

Anyway... book on order.  Source code downloaded.  Now I just need to find a block of useful time that isn't claimed by higher-priority things like client projects.

Update: A quick build of the eLua demo for the Kinetis platform uses around 200K of flash; I don't know what optimizations were used.  I need a configuration that's under 150K.  May turn out to be possible.

...But the Kinetis branch is 5 years out of date, so I should probably be starting from the master anyway, and doing my own port.  In My Copious Free Time.

Update 2: Got another possible use for an embeddable scripting language, but that one needs to fit in 128K, including the base application.  I think that calls for a different approach, like 8K Tiny Basic or something.

Pondering CNC stuff

Yeah, acting on it is a "much later in the year" thing, but still.

I look up the Tormach personal CNC mill line.  Looks like some pretty decent hardware... for not that much more than a CNCified Wrong Foo mill/drill thingy with the ferschlugginer round column.  Seriously, what's with those conversions?  I once had an RF-30 or thereabouts.  Made a pretty darn good drill press, but as a mill it wasn't much.  Refitting one of those with ballscrews and motors is kind of like trying to make a competition pistol out of a Bryco.

Another CNCish thing I'll probably want at some point is a 4-axis hot-wire foam cutter of moderate capacity.  Such things can be bought.  It appears that the software requires... wait for it... a 32-bit PC with a parallel port, running Windows XP.  Really?

Looks like pretty much all the DIY stepper drive units use a parallel-port interface.  Seems that LinuxCNC can run on more modern hardware... but just about every supported machine interface is via parallel port.

You can still - for now! - buy a motherboard with a parallel port on it, or a PCI or even PCIE add-on board, but for how much longer?

Maybe someone (not me, this year) should work with the LinuxCNC folks to come up with a protocol for shoving step-and-timing commands over USB, with a nice big buffer (hence having timing info included with the step commands).  It's getting easy to put mid-level motion control on an MCU with a USB interface, or Ethernet.

Either that, or look at porting the motion-control back end of LinuxCNC to embedded platforms with lots of GPIO lines.

Oh, well.  For now, I have real work to catch up on that doesn't involve motion control.

A lack of local news coverage

Coming up De Anza Blvd., crossing Stevens Creek Blvd in a northerly direction: note big gray cargo plane maneuvering dramatically ahead.  Hm?  He's kind of low, and even if there's some sort of event at Moffett, why's he putting on a show this far afield?  (Sanity check: the Collings Foundation was at Moffett... two days earlier.  And I don't think they operate anything with four turbofans.)

Leave it as a puzzlement.  Shortly, encounter backed-up traffic with twinkles ahead.  Sheriff's department vehicles on all sides of the De Anza / Homestead intersection.  No obvious indication what's going on.  No particular delay getting through the intersection at that point.

So... had there been some big incident at that intersection, and maybe the cargo-plane pilot was banking for a better look at the twinkly lights on the ground?

I don't find any sort of news report about it.  Like so much that goes on locally, it shall presumably remain a mystery.

Maker Faire

Went there yesterday.  Didn't manage to see all of it, what with getting tired early.

This was the first time I'd managed to take The Descendant along, and it turns out she's inherited my reaction to crowds, i.e., I'm tired and I need to get out for some fresh air and elbow room.  I've managed to develop a little more tolerance for such settings, though a few hours of maneuvering through a crowd, taking irregular baby steps, leads to sore hips.

We ended up taking the 'Trop... sorry, the CalTrain... which was reasonably painless, except that the signage in the parking structure was highly non-explanatory (CalTrain permit parking only: is there some permit that commuters get?  Or does it just mean that you've paid for the days parking at the vending machine?), the ticket vending machine's credit-card reader was in process of failing (I may have been the last one to get a plastic-money transaction through on the machine on the left), and the screwy UI on the vending machines that, if you select "two one-day tickets to Zone 2" and then select "pay for parking" silently cancels the tickets and only handles the parking, requiring a second transaction to go back and buy the actual tickets.

Getting into the Faire went reasonably quickly, half an hour after opening time; the line was kind of long, but moved along well.

There wasn't as much big showy outdoors stuff this year, maybe because of the weather (with thunderstorms forecast, I sure wouldn't want to be outdoors with a giant lightning rod hooked up to tanks of flammable gas).

Indoors, much of interest, though there was a lot of space devoted to kiddie crafts (NTTAWWT, but it wasn't what we'd come to see).  Lots of local-ish maker spaces had booths.  As usual, lots of Arduini and 3D printers.  One biohacking booth, with three organizations represented (The Descendant is a bio major, so the existence of such organizations is a good thing to note).  Several chip companies, some of them not exactly noted for maker-friendliness.

(Qualcomm had a booth, promoting Snapdragon processors.  I poked my head in.  There was a drawing for a dev board of some sort, but it seemed to be a "must be present to win" thing, which didn't fit my schedule.  I figured I could check out their web site, and buy a dev board if I needed one for a project.  When I got home, I checked out their web site.  Happy shiny highly-dynamic marketing fluffery.  References to what consumer products use their chips.  No technical data on their actual chips.  No budgetary pricing.  No where-to-buy.  Looks like Arrow carries some sort of dev board, but Arrow's search function appears to be broken, or else every Qualcomm-related keyword is kept out of it, so I don't know if they carry the chips.  Which is a shame, because it looks like I might actually have an application for one of them a few months out.)

Chatted with various people, including the guy at the Cadsoft booth (yes, they had a booth there, handing out CDs and encouraging people to use the freeware version for their creative projects).

Oh, and the EMSL Quasi-Visible 6502 was on display.  It suddenly occurred to me that, if this is a true and exact implementation, one could feed it the infamous Halt and Catch Fire instruction (if memory serves, that was any opcode with an even upper nybble and a lower nybble of 2), and see what internal state the processor gets into.  No, I'm not going to buy one of the boards just for that... though if it fit my budget, I'd buy one just for the cool factor.

Anyway, another fun gathering, but I think today is for resting.  And maybe doing some leg-stretchy exercises.

Added: We escaped without buying anything other than food for immediate consumption... but, then, we didn't venture into the big Maker Shed building, and, while the Barnes & Noble booth might have held temptations, it also held a densely-packed crowd, so we didn't get close enough to be seriously tempted.

I dd gather a pocketful of assorted paper pointing to vendors and products of interest.  I left it to someone else to ask the price of the modest-sized, Tormach-branded CNC mill: around $9K.  Had I been more alert (this was getting to be late in the day), I might have inquired after a fourth axis, 'cause that's one of the features I'll need on a CNC mill when I get one.

Oopsie.

You have 2 security updates...

Switch to the root-shell window.  Uparrow, return.

    apt-get dist-upgrade

Upgrades things related to libexpat1.  All fine.  But...

Deletes things related to libexpat1:i386.  Er.  Why do I have those 32-bit libraries installed?  Support for some key commercial software?  Um... does EAGLE still work?

Nope.  EAGLE v6 is b0rked: missing libfontconfig1:i386 (at least).

Oh, well... EAGLE v7 runs fine... as long as I don't try to print.  Then it crashes, 'cause I don't have the necessary latest-and-greatest version of some library it needs for printing.

Well, if the security-fixed versions of those 32-bit libraries don't materialize soon, I'll be motivated to upgrade the whole system to Debian's latest.  The laptop and lab machine are already upgraded.

And I need to switch to EAGLE v7 in a few weeks anyway.  A design coming up soon is inherently hierarchical, what with having eight identical groups of four identical cells each, so... it really is time for v7.

Update: Crisis averted.  Did an apt-get update a bit later, and now I can re-install the missing 32-bit libraries, so EAGLE v6 is back on the air.

Update 2: Had to re-install a bunch of the other ia32 libraries, too, to deb0rk ol' Acrobelfry.  Took me a while to figure this out, because the running instance was still running, but clicking on a .pdf in the file manager had stopped working.

Wait, can they do that?

News item: Pfizer forbids sale of its products for use in executions.

...Er...

Now, regardless of your position on lethal injection (which, personally, I regard as an abomination; if you're going to kill somebody, use a more straightforward approach and skip the pseudo-medical rigamarole), there's a serious issue here.

If you sell something, it thereafter belong to the buyer, right?  You no longer have any rights to it?  (Unless it's a work of art in Europe, or something.)

So how can a Big Pharma company impose post-sale restrictions on its products?  I mean, next thing you know, companies with highly lucrative out-of-patent drugs would be blocking their sale to potential competitors, making bioequivalance testing impossible and keeping cheap generics off the market.

Oh, wait.  They do that already, don't they?  How is this legal?  It violates one the the basic principles of commerce; doesn't it also violate some antitrust law?  If not, why not?

(I've run across something similar with European chip vendors, and fine print in datasheets saying "not for use in weapon systems."  If I design the chip into a weapon system, buy the parts from a distributor on the 'Net, build the thing, and sell it, I've, what, violated some contract I never signed?  But, unlike a pharma company, the chip company doesn't have the supply chain locked down.)