Silicon Valley Redneck

A quick note to peripheral designers

The "TX DONE" interrupt on a UART should happen when the transmit FIFO is empty and the transmitter is idle.

Like, just after the final stop bit has been sent.  Not after the last character is transferred from the FIFO to the transmitter's shift register.

If it happens too soon, it's useless for turning a half-duplex line around.  And some of us still have to worry about such things.

A reminder

POTUS is not the Commander-in-Chief of the Militia.  Not until it's called forth by Congress in time of war or insurrection, he isn't.

He's CinC of the National Guard, because that's a wholly-owned subsidiary of the U.S. Army that happens to be mostly on loan to the various States.  The Militia is a different entity, with governing authority divided between Congress and the States.

Any speculation that The Orange One will do something dramatically wonderful, or terrible, by way of his authority over the Militia can be quickly dismissed by recalling that he has no such authority.

Congress does, however, have the power to provide for arming and disciplining the Militia.  On that topic, speculate as you will.

That ID-check thing

Yeah, that one.  Border cops checking the IDs of passengers getting off a domestic airline flight.

A few things:

• Wait, how is this legal?
• If they were looking for a specific person, and one who had recently(?) been in court at that, shouldn't they have had a description?
• If they didn't have a description, what good does an ID check do?  Couldn't he have a new set of fake papers?  This makes as much sense as a "no-fly" list based on names.
• Is San Francisco technically "domestic" anymore?  Sanctuary cities have basically placed themselves outside the U.S. in matters of immigration and identification.  If we tolerate that crap, we have to expect this crap.

Addendum: Wait, was the name they were looking for on the manifest?  That ought to have been a pretty good clue as to whether or not someone had boarded using the ID they were trying to match.

How quickly we forget

Spotted here:

Six months or a year from now, they will have to flip from calling Trump an anti-American traitor and Russian plant to calling him a dangerous, fascistic ultranationalist whose relentless hawkishness is bringing us closer to World War Three.

Why flip sometime in the future?  The Democrats were saying both things about Trump, at the same time, during the campaign, and their true believers never batted an eye.

Never underestimate the power of Doublethink.

Afterthought: A story making the rounds the past week or so was that the Russians were - the horror! - compiling a psych dossier on Trump.  What, they don't have one already?  How incompetent do we think they are?

More UI lossage

Yes, the wonderful world of user interfaces is dominated by those who assume that everyone in the world is already up to speed.  Kind of like group ballroom dance lessons.

This time?  Google Hangouts.  Apparently it's got something to do with video calls.  So... I plug in my webcam (with microphone), and look for... er... some way to check my configuration?  Make sure the camera works, and the audio is coming from the camera's microphone and not from one of the on-board audio-input ports on the motherboard, or perhaps from some other potential audio input?

Anything?  Hello?

Come ON, guys.  At least Skype has (if memory serves) an obvious way of making a dummy call, to allow fiddling with the settings.  As far as I can tell, in Hangouts the settings are only accessible during a call, and the help page doesn't seem to have anything about making a dummy call for test purposes.

Well, maybe I need to log onto an alternative Google ID - hm, there's one for the company whose Hangouts conference is coming up, and my name is spelled wrong and can't be changed - and try video-calling my cellphone.  Which is lame, but might just work.

Branding: how does it work?

Well, we take the red-hot... no, not that kind.  The trademark kind.

Some companies seem to be unclear on the concept.

A while back, my parents decided that Bounty paper towels were suddenly crap, after having been perfectly serviceable paper towels for many years.  Turns out my father had bought a pack of Bounty Basics, which looked (in content and in packaging) very much like the standard product, but were slightly cheaper.  And were crap.

And then there's Kleenex.  Used to be, you bought a box of genuine Kleenex-brand kleenices, and you could count on them being suitable for blowing noses, cleaning eyeglasses, and all the other stuff you normally use them for.  But now?

There are several variants, and it's not at all clear how they differ.  But I recently bought some that had an "Ultra Soft!" splash.  Just a marketing slogan, you think?  Nope.  It's different.  They're kind of dusty, and kind of greasy, and kind of flimsy.  Soft, yes.  Not properly sturdy for the blowing of noses, and entirely unsuitable for the cleaning of eyeglasses.  Note that there's another variant that says "Lotion!" on the box, and this isn't (apparently) that.

And... toilet paper!  I usually buy Quilted Northern these days.  There are two types, with confusingly similar names; one is good, while the other has a certain, ah, institutional quality to it.  Not as bad as the stuff in state parks, but not at all up to household standards.  The good stuff has the purple label.  Except that last year there was a (fortunately temporary) change of packaging, the color scheme for both products changed, and I ended up buying the wrong kind.

Didn't these companies learn anything from New Coke?  Or was the lesson they learned that a product change should be done quietly, without clear differentiation?

(And model numbers.  I look for a replacement air filter for my chainsaw, and I find plenty of sources for one that's entirely the wrong shape; not so many for the right one.  The manufacturer apparently made two different saws, with two different engines from different suppliers, under the same model number.  Hurray!  Come right down to it, some car companies have made significant changes mid-model-year.  If memory serves, my agèd Jeep has some bits of the front suspension that don't match the nominal model year, and I've heard of cars that, as shipped from the factory, varied wildly from what the manual said went into them.)

I think the hills are saturated.

Out walkies at Rancho San Antonio this morning (after having missed Friday and Monday due to rain, and Tuesday due to a schedule conflict), I noted significant flood damage on some of the trails.

On a trail right near the entrance, the flood was still present: a little seasonal drainage ditch of a creek was going partway across the trail, turning left, and running along the trail for a considerable distance, gradually eroding away the trail surface.  (I have the notion that the creeklet normally crosses under the trail through a small culvert, but no upstream end of a culvert was in evidence; if there is one, it was well and truly buried under the gravel and mud*.  I didn't look for a downstream end, because there were bushes in the way.)

Somewhat past the point where the creeklet turned back off the trail and found the main creek, there was a long stretch of trail with major signs of recent erosion and relocation of large gravel.

Some of the upper trails were closed due to storm damage, but I wouldn't have had time to venture onto them anyway.

The pond was about as high as I've ever seen it, though there's still plenty of capacity in its drain pipe (if not in the creek below).

But the consequences to me just involved muddy feet.  As the latest storm was finishing up?  Turns out Coyote Creek and the Gudalupe River were getting awfully high, leading to serious flooding in San Jose.  Gah!

No significant rain in the forecast for a couple more days, but then Saturday's supposed to be somewhat rainy, with another big storm Sunday.  Think the hills will have time to de-saturate before then?

* Update: By the next morning, the rangers had dug out the mud, silt, rocks, etc., revealing the entrance to, indeed, the culvert that ought to have been there.  The pond is a tad higher than yesterday morning, and the creek below the pond is at, or slightly above, normal capacity.

Also, word is that the flooding in San Jose wasn't so much creek overflow, but more like sewage.  Sounds like a serious municipal infrastructure problem.  Which (as with any other problem) obviously calls for federal assistance, because cities are incapable of maintaining their own infrastructure.  Maybe we should try electing local politicians who'll put boring maintenance ahead of glamorous ego projects?  Nah.  Who wants to see signs for the J. Arthur Smurdley Absence of Potholes?

Is someone here playing 4-dimensional chess?

Item: For the past several years, elements within the ruling elite have been working at normalizing pædophilia.

Item: It is currently unacceptable to normalize the existence of any member of the Trump family, including a 4-year-old kid.

Item: Milo Yiannopoulos is considered entirely beyond the pale by the Left, for reasons entirely unrelated to pædophilia.

Item: Now that Milo has been unmasked as (perhaps†) an apologist for pædophilia (or rather ephebophilia, which really isn't the same thing*), Saloon** has apparently memory-holed all the articles by a fashionable pædophile-apologist***.

So!  Was this all part of a grand plan?  Someone you are required to hate thinks this might be borderline OK, therefore you are required to reject it and all who support it?

What else can we get the Institutional Left to reject?

 

* Disclaimer: I have neither condition.  My little reptile brain thinks anyone under about thirtyish is too young to be sexy.

** I can never remember which is Saloon and which is Stale.  One fashionable corporate e-zine is much like another.

*** Who apparently was merely taking the sensible position that a mental illness (pædophilia) and a related crime (child molestation) are not the same thing, and that it's preferable to treat the mental illness as such, before it manifests itself as crime.

† Update: It's becoming quite clear that Milo was not in fact suggesting that kiddy-diddling was in any way acceptable, nor is there any credible suggestion that he condones such things.  This whole foofaraw is the result of some small group (possibly involving Egg McMuffin) releasing a deceptively-edited video and applying Lefty outrage-mob tactics - to what overall purpose is not apparent.

Rainy semi-holiday Monday

I did venture out during a less-fierce period of the morning rain in search of some computer odds & ends and a roastable chicken.

Chicken's in the oven now, goobered with tarragon, thyme, red pepper, salt, olive oil, and balsamic vinegar.  It'd been too long since the last roast chicken.

A quick test with the A10-OLinuXino-LIME board reveals that its USB OTG port is no substitute for a real EHCI host port.  It runs into the same endpoint-exhaustion issue as the AM3352, with the same lack of error reporting.  But!  It does have two gen-u-wine EHCI ports.  Thing is, they're both at the same end of the board as the Ethernet connector, and they're not meant to power the board.  So, my kludge cabling is back to being an awkward USB A cable plus a 5V power cable (probably to the OTG connector).

That also scuttles an idea I had for using the LIME board in a particular role that involves the Ethernet connector (and the two USB A connectors) poking through the back panel of an enclosure, while the USB port on the other end (the OTG port) talks to a bunch of devices.  Won't work.

But I guess I can (when there's an occasion to do this sort of thing) put the board entirely inside the box, and run Ethernet and OTG cables out to bulkhead connectors, while using one of the host ports to talk to the devices.  After all, that's what I'll be doing to get the current batch of prototypes running.

And maybe eventually I'll do a custom embedded-Linux board, with at least one USB host port on the stacking header, and with a layout conducive to poking the Ethernet jack through a panel.  Unless I find a proper off-the-shelf solution before then.

Eep?

Got something in the pipeline that might call for a bunch of shortish patch cables with USB mini-B plugs on both ends.

A quick search turns up this:

Now, just a minute!

Twelve bucks for a little cable is mighty steep - and way too much for what I have in mind! - but financing?  Really?

Well, should the requirement materialize, I'll just have to get in touch with some furrin cable vendor and inquire about quantity pricing.  Should be under two bucks if ordered by the hundred, right?

Oy. Monday.

Been awake, on and off, since about 0200: headachey and vaguely fevery (but no actual fever, according to the thermometer), plus Huckleberry being rambunctious.

Actual sleep time was punctuated by weird dreams.  The only one I can remember was a fragment of a pseudo-documentary on some innovation in large reciprocating engines, and it wasn't even clear whether the engines in question were steam or diesel.

Now it's Presidents' Day.  And it's a very special Presidents' (note plural) day, because we have three Presidents!  There's President-For-Life Zaphod Hussein Beeblebrox, Not-My-President Donald Beeblebrox*, and Rightfully-President Bubba Yaga!  (Should we count President-In-Waiting Slinging Bull?)

Ugh.  There's stuff I need to do, but not with a headache.  And I really should get out for walkies, but it's raining - not a lot, at the moment, but the forecast calls for some heavy rain today, there's a flood watch, and the rain was certainly quite heavy a couple of hours ago.

Nap time?  Or go for walkies, weather and all?

 

* I'm trying to visualize "Don Beeblebrox", but can't quite figure out how a double-breasted suit works on a guy with three arms and two combovers.

A light bulb comes on.

There seems to be one residual Issue on the USB-dingus front: sometimes communication with the ACM device (which handles various management functions) malfunctions in colorful ways.

The dingus is, alas, High-Speed only, for good and sufficient reasons, and I can't really justify buying a high-speed USB protocol analyzer.

But!  The ACM device is Full-Speed; I do have an analyzer for that; and... well, I could intercept USBD+ and USBD- between the hub and the MCU, but, since the problem doesn't appear to be dependent on any of the other stuff on the board?

All's I need to do is load the MCU's firmware onto any of the other boards I have around here based on near-enough the same MCU.  Then plug that into the SBC via the USB analyzer, with its "computer" port plugged into the workstation.

I think that works, anyway.  Have to dig out the USB analyzer, which has been gathering dust for a few years now.

Off to do my laundry while it's not stormy.  USB later.

Update: D'OH!

En route to laundry, the other light bulb came on:

    -echo

Ayup, that was it.

It wasn't obvious, because most of the echoed (because, duh, /dev/ttymumble) characters weren't getting through to the device.  On the faster / multicore CPU, it seems none of them were getting through (this despite the flow control which is supposed to be inherent in USB; that's a question for another time, but maybe the lowest levels of the device's USB stack are accepting data faster than my application layers are keeping up).  On the slower / single-core platform, some of the echoed characters were sometimes getting through, causing havoc.

So, gotta see what's up with the flow control on the device side.  But, for the moment, I can just throttle the transmission of commands and all will be well.

Update 2: Found the flow-control problem, I think.  I used an example program as a starting point, what with the underlying library being very poorly documented, and the program was just an example, not a good example.  Basically, it was dumping incoming data into a global buffer from the event handler, and relying on the main task to come around and hoover it up.  This works in a demo setting, but for serious work I need to restructure it.  Probably taking the code that moves data from the buffer into a proper queue and moving that into the event handler, eliminating the global buffer, should make it robust.

But not this evening.  What's there now works well enough for the moment, so fixing the structure goes on the change list.

And, really, I need to do even more restructuring, with my queue-ified transparentization layer being tidily atop the vendor-supplied CDC-ACM stack and the actual application code being in entirely separate files.

Which has to happen on my time, not the client's.  (The ACM adaptation code is adapted from an adaptation I'd done for my own purposes, early last year, and never quite tidied up, nor entirely tested.)

Update 3: Headache, mental fuzz, and all, it only took a couple of minutes Monday afternoon to change the handling of inbound data on the MCU.  Seems to be working.

That didn't go as well as it might.

Tinga's been preening my face with an excessively sharp beak.  Time for some blunting!

So I flip her over on her back (which she hates), restrain her (which she hates), and commence application of the hoof file to her beak (which she really hates).

This was Southmoon's cue to come along and start sniffing at Tinga's tail feathers.

I didn't get much beak-filing done.

Stock accusation doesn't make sense.

From Weakly Entertaining, quoted at Instapundit:

Yet Yiannopoulos made blatant sexist comments during the interview, criticizing Amy Schumer and Sarah Silverman as people who “used to be funny before they contracted feminism.”

Excuse me?  That's blatantly sexist, is it?

There's nothing whatsoever sexist about it.  He's saying that they were funny before they went all in on a humorless ideology.

That's like me saying that MAD was funny while Bill Gaines was there to maintain balance, and stopped being funny once Gaines was out of the picture and the magazine's perspective swung hard left.

Branding such remarks as sexist / racist / anti-Semitic / otherwise deviationist simply reinforces the point that those who embrace bleak, humorless totalitarianism, and whose repertoire devolves to insulting stereotypes of the designated out-group, are just not funny.

Taxing robots: how does that work?

A recently fashionable proclamation is that we need to tax those robots that are taking people's jobs away!

Which, um.  Sounds, superficially, like it ought to make sense, in an almost-literally Luddite sort of way.  But does it?

The Encyclopædia Galactica defines a robot as a mechanical apparatus designed to do the work of a man.  The marketing division of the Sirius Cybernetics Corporation defines a robot as your plastic pal who's fun to be with.  Which definition are we using here?  It sounds more like the cutesy, anthropomorphic definition: think Star Wars, or Futurama.  All those vaguely-human-shaped robots with personalities, toiling in the spice mines, saving for their retirement at the Old Robots' Home.

But the reality is that any productivity-enhancing tool will make some workers redundant.  Levers, wheels, weaving looms, combine harvesters, ditch-digging machines, software for filling out tax forms, automated direct-dial telephone systems: all put puny humans out of work.

So what we're really talking about is taxing capital.  If it increases worker productivity, enabling one human to do the work of many, tax it!

Question for the alert student: what effect do we expect this to have on the pace of technological progress?

Especially if it's a tax on capital equipment that's legally classified as robots, vs. all other forms of capital.  Think there'll be a lot of resources put into lobbying for tweaks to the definition?  How about carefully adjusting products and marketing literature to avoid incurring the tax?*

But the rhetoric fits the current outbreak of populism.  When the rich and powerful start sounding populist, we need to take a careful look at what, exactly, they're proposing, and what it really means.

 

* See also: "assault weapon" bans, the legal definitions of what's banned, and the persistent ability of gun companies to redesign their products to comply with the laws instead of just going out of business as intended.  Also, this tax-avoidance game in Mexico.  And this case, in the U.S.

With one panic resolved for the moment...

I now have time to resume work on a project that isn't a panic, but that is nonetheless considerably behind the planned schedule.

This afternoon's task: documentation.  I have CPLD code, MCU code, Ruby code, and a schematic, but no overall document describing how the pieces fit together and what they do.

And, funny thing.  When I get busy word-processing up a master document, and digging into the code to refresh my memory of what's going on?  Turns out that some of the features are out of sync.

Well, we won't have actual hardware for a few weeks yet, so there's still time to fix the inconsistencies and omissions in the code, and make the code and documentation match each other.  It's harder to do that once it's loose in the lab, never mind the field.

Next time I need a bunch of serial ports...

I think I won't go the USB route.

Yes, it's convenient, and it works fine if there's a full-spec PC in the middle of it all.

But, with a little embedded SBC/SOM, with a lesser processor?  Too much overhead.

Better to use a processor solution with an old-school system bus of some sort - do they make those anymore? - and multi-UARTs with a regular bus interface.  Even if interrupt management does get Interesting.

Last time, many years ago, I used an octal a quad UART chip from, if memory serves, TI*.  That seems to have gone obsolete.  There are still quad UARTs from other chip vendors, in inconveniently bulky packages, starting at around $7 in modest quantities.  I think this is part of why I went the USB route: anything with a regular system-bus connection was just going to take up too much space (in addition to requiring some fiddling with drivers, to handle large numbers of them, which I didn't expect to be an issue with USB).

The alternative, maybe, is to stuff multiple UARTs into a cheap small FPGA / large CPLD.  Hey, I have a known-good UART cell in Verilog.  That means writing a new device driver for Linux, if it's not made 8250-compatible (which would eat up an awful lot of logic, to no good purpose), but maybe that's not such a big deal.

The FPGA route looks like it comes out cheaper, too.

The USB approach looked like a good solution, and it did save a bunch of development time.  If we throw enough processor power at it, it'll meet the performance requirements, and processor power is getting cheap.  But for the next generation?  Using UARTs-in-FPGAs might be best.  Also, it opens interesting possibilities for embedding certain special features right at the edge of the system, where the CPU wouldn't have to be bothered all the time.

 

* Yup, TI.  Part number was TLC16C554.  Came in a 12mm square, 80-lead SQFP.  Which wouldn't have worked for the current project anyway.  I was misremembering it as octal, and getting 8 ports in that size package might have worked.

Good news Thursday

As noted in the update-to-yesterday, it looks like there's an interim solution to the ferschlugginer USB problem that's been plaguing me for the past week-and-a-bit.

While using a TI AM3352 processor as a USB host doesn't work right for a large number of peripheral devices, nor for some particular devices all by themselves, the Allwinner A20 seems to be getting the job done.  And, now that the job is getting done, it turns out to be a good thing that the A20 is a dual-core critter, as the USB protocol stack is eating quite a large percentage of the available cycles.

I've got a cute little A10-based board on order (cheap); if that turns out to work (I'm guessing its CPU will be overworked, but I ordered it before running the test at full load), it's a Solution.  If it works except for the CPU being overloaded, well, there's a slightly pricey A20 version of it available.

And there may (details are fuzzy) even be a fully industrial spec version available.  And the board is open-source hardware, so a customized version is an option.

This got me looking at what Allwinner is up to.  They also have a thing called an H8 (not to be confused with the Hitachi H8 family), which is an 8-core beastie, with the necessary Ethernet and USB features (plus a bunch of stuff I don't need, like video).  Someone's using it on a cheap little board.  Maybe the Far Eastern assembly houses have a supply?  As far as I can tell, though, it's a commercial-temperature item, and I can seldom get away with such things.  Wonder if it's available in I-temp at all.

(Yeah, I tend to insist on industrial-temperature components for just about everything, when I'm not demanding automotive- or even military-temperature parts.  The application at hand actually needs to be I-temp when it goes to production, because it could be deployed anywhere from Anchorage to Death Valley, not to mention Foreign Parts.)

So, anyway.  Immediate problem solved.  Long-term solution in sight, and apparently not too expensive.  Also, there are some awesome little chips out there.

Meanwhile, at work

That USB issue?  Works fine with the gadget's USB hub connected to a PC running Linux, but not when I plug in the SOM, also running Linux, that it's supposed to work with?

Well!

One of those things we just don't think about, most of the time, is how many devices we can plug into the bus.  Mainly because it's nominally 127-including-hub-chips, and who among us gets anywhere close to that?

And, typically, the USB on something small, like a RasPi, will be used for a keyboard and mouse and maybe a WiFi dongle and a thumb drive.

Turns out there are limitations.  Sometimes.

Like, some of Intel's USB 3.0 controllers have hard limits on the total number of endpoints in a system, which is just not something you expect.

And, as it turns out, a fair number of ARM-based SOCs are using the Mentor USB on-the-go core, which supports the control endpoint plus 15 each of in and out endpoints.  Which is enough for your keyboard, mouse, WiFi dongle, and thumb drive, but if you're planning on controlling a multitude of peripherals?  Maybe not.

The documentation seems to say that the host controller's endpoints can be shared among multiple devices on the bus, which is what you'd expect, isn't it?  But then I look in the Linux musb driver, and I see this:

 *      * Control and bulk use dedicated endpoints, and there's as
 *        yet no mechanism to either (a) reclaim the hardware when
 *        peripherals are NAKing, which gets complicated with bulk
 *        endpoints, or (b) use more than a single bulk endpoint in
 *        each direction.
 *
 *        RESULT:  one device may be perceived as blocking another one.
 *
 *      * Interrupt and isochronous will dynamically allocate endpoint
 *        hardware, but (a) there's no record keeping for bandwidth;
 *        (b) in the common case that few endpoints are available, there
 *        is no mechanism to reuse endpoints to talk to multiple devices.

Hm.  Clearly there's some reuse of endpoints, because I can send data to the entire Imperial-bargeload of peripherals.  But I can't receive data from more than the first 8-or-so that I open, so I'm guessing that getting the incoming data from an FTDI UART involves assigning a dedicated endpoint in the host controller, and that the assignment is made at open time.

It's awfully late in the project to be discovering that the SOM, which seemed to work just fine on a subset of the target hardware during the engineering-lashup phase, has the non-obvious inadequacy.  And that it seems to be shared by rather a lot of the alternatives.

It doesn't help that Linux isn't reporting any sort of error when I open /dev/ttyUSBn, for some higher value of n, and the resource needed to receive data isn't available.

Well, I'll be getting my hands on a couple of different SOM/SBC things in the next day or so.  Maybe one of them will work.  Then there are the details of mounting, mechanical integrity, environmental specs, and all that fiddly stuff.

I really don't want to go diving into the Somebody Else's Code of the Linux USB stack to try to upgrade the host controller driver.

Update: Looks like the Allwinner A20 may be, well, a winner.  I retrieved the A20 SOM and eval board from the client, hooked up the serial console and Ethernet, applied power, waited for Linux to boot, plugged in the dingus, sent the magic commands to the ACM0 device, waited for the Imperial bargeload of ttyUSB* devices to enumerate, copied over the test program, compiled and ran the test program, and... well, initial testing went well, and it appears, so far, that all the ports are actually working.

Curiously, the behavior of the modem-control lines when the port is opened appears to be different with this CPU / Linux distro.  Well, that just means I need to make sure my middleware code initializes them to the expected state before enabling power.

My RasPi 3 also arrived, but I think that goes on the shelf for now.  It may be cheap, but it's not even close to industrial spec, so it was never really an option for this application.  Maybe for future stuff, though.

Lefty tighty, righty loosey

In among all the other crazy, Joy's mini food processor died.

So, order another one from Amazon, reasonably cheap and with next-day delivery.  The old one was long since discontinued, but its successor is a tad larger and somewhat more featureful.

On unboxing, it turns out to have the new feature of bits locking together: the bowl locks to the base, and the lid locks to the bowl.

Rather counterintuitively, one turns the lid or bowl clockwise to open. What for they used left-hand interrupted threads?  Was it made in Australia or something?

Ah... looking at where the sharp bits are, the whirly-go-chopper must run counterclockwise.  Ergo, the bowl must needs be counterclockwise-to-tighten.

From a user-experience perspective, wouldn't it make sense to have it open with a standard unscrewing motion, and reverse the blades and motor accordingly?

(It doesn't help that, as received, the locking bits were very tight, so application of a reasonable amount of force in either direction failed to budge either bowl or lid.  It took an unreasonable amount of force to unlock it the first time, and a few lock/unlock cycles to wear it in so just a little force will get 'er done.)