Silicon Valley Redneck

Got another purple envelope today

Containing three of my latest purple board - yes, the one that goes with the mysterious East European item - and a purple sticker.

Update: assembled the right (i.e., Eastern-facing) end of the board this afternoon, and spent an hour or so playing mad scientist with this, various bench instruments (power supply, pulse generator, scope, voltmeter), and the Mystery Item.  It works!  Next up: populate the MCU and a few other parts, and throw together the basic operating firmware.  Then, the left end (USB interface), and some rinky-dink Ruby program for demo purposes.

I expect to be turning this into a Genuine Product (actually, 2 or 3 closely-related products) sort of June-July-ish, assuming an ongoing supply of Mystery Items can be negotiated.  Watch for an announcement.

Update, Sunday afternoon: MCU is now controlling the interface section (in a rudimentary way, as I'm missing a small but important component at the moment), and taking measurements.  Another few hours should have the dingus fully operational.  When those few hours will be... well, I've got a busy week coming up.

Update, Thursday lunchtime: hardware is now fully armed and operational.  I'm sending measurements back to the host PC via the FT201X.  Just need to implement the rest of the firmware features, and it'll look remarkably like a Product (modulo packaging and suchlike details).  This afternoon, though, there's Real Work to be done.

New toy

My Beaglebone Black just arrived!

Cute li'l rascal.  And, though it sports a micro-SD socket, the OS lives in 2GB of on-board flash.  So, the add-on memory card is optional.  Looks like a good configuration for designing into custom programmable instruments, with the power, Ethernet, and USB connectors exposed to the world.

Haven't powered it up yet.  Got work to do, and here it is the end of the month, Walpurgisnacht, and all that.

But!  I now have the mechanical sample that allows me to make sense of the cape template I found in someone-or-other's library (prolly Lady Ada's).  Looks like I pretty much have to keep my tall components - in particular, things that go at the ends, such as connectors - topside, unlike the RasPi crust.

For now, back to work.  Assuming, of course, that I can get the darn furry Huckle-beastie to go take a nap someplace that isn't on top of me.

Last of the summer gadget boards

That board I ordered from OSH Park just over two weeks ago?

Here we go. Nice and shiny, if incompletely depanelized (a few seconds with pliers took care of the rails).

Continuity check shows the inner layers connecting the things they're suposed to connect.

Finish, like Kryten's final words, is ENIG.

I was going to spend the afternoon stuffing first the power section and then the processor, but a busness lead just came over the transom, so I may be chasing near-term revenue instead.

Summer gadgets: signs of life

Having to correct a few bonehead blunders along the way, but things seem to be more or less right so far.

L to R: Store-boughten STM32F4 Discovery board, being used as an SWD pod; my programming/debug/serial-port adapter; my handset board (whereof the exact nature shall, for the time being, remain shrouded in secrecy).

Few patch wires and kludges:

On the adapter board, I designed in a chip that I'd used before, and that had since gone obsolete in that footprint (SOT23-8).  Installing a TSSOP part in that footprint was tricky, but worked for the prototype.

Also on the adapter board, I connected an entirely wrong modem-control signal, which makes for a cut & patch operation.

Further, that half-pitch DIPswitch really needs to be normal-sized, maybe with protruding levers.

On the handset board, I carefully checked the pinout before using an STM32F1-series library part for the STM32F4xx that's in the actual design... but I didn't check that all the ground pins were still ground.  Oops!  Two of them are actually outputs from the core voltage regulator, and are supposed to be bypassed to ground, not shorted to it.  Fortunately, those pins are adjacent to corners, so lifting them post-installation was merely a royal pain.

Then, when I finally hooked up the debug cable: no talky.  Poke things with a scope probe.  Wiggles here, wiggles there... hey, when I probe SWCLK at the target end, the debugger signs on!  Ship it with the scope attached!  Or, perhaps, tack a 22pF, 0402 cap (what happened to be to hand) from SWCLK to GND on the target board, and make a note to terminate it properly in the future.

Anyway, I loaded the DAC_SignalsGeneration demo, and now I get waveforms on the DAC1 and DAC2 lines, so things are more or less working.

Couldn't find a handy demo program that talked to USART1 in an immediately identifiable way, so maybe I need to write one.

Then: get AGROS running on the Cortex-M family, write a driver for the STM32 UART, get it signing on, start writing drivers for other peripherals (SPI, I2C, ADCs, that sort of thing), and it'll be Application Development Time!

Warped minds think alike!

'Bout 15-20 year back, I had a dream of a multi-leggèd personal transportation apparatus, having the general character of a classic VW Bug with 6, or possibly 8, excavator arms mounted thereto and a big honkin' hydraulic pump.

Now there's Project Hexapod!

'Course, mine was supposed to have a plasma cannon, but I guess you got to have the vehicle first, and you can always bolt on doodads later.

(Sorry, guys: no Kickstarter funding from me this month.  No got spare change just now.)

That's convenient

I'm implementing another AGROS-based doodad, and once again using SCPI commands to communicate with it - not that SCPI is particularly wonderful, mind you, especially when moved outside its original HPIB context, but somebody else is going to be communicating with the gadget using LabVIEW, and I might as well make his life easier - and, inevitably, I run into some syntax I hadn't needed to handle before.

I already had handy parsing functions for numerical arguments and such, but now I need to handle channel lists: (@1, 3, 6, 12:17, 94) and like that.  And, given that the range of channel numbers can be quite large (and that the standard calls for the order being significant), I can't just set bits in a bitmap.

First go was to stick parsing code in the handler for each command or query that needed to handle such lists, but that opens a can of maintainability worms, as well as being wasteful.

I was almost thinking it was time to learn enough C++ to handle this sort of thing, and then redo the whole SCPI subsystem in C++... but that's another can of worms.  Still, the concept of handling it the way I would in Ruby, i.e.,
    cmdline.eachify_channel_list do |chan|
        relays.close_channel(chan)
    end
has a certain appeal.

Well... how about if I write an iterator with a callback?  Straightforward enough, except: C doesn't have lambda expressions, so I'll need a named top-level function for each callback case, or some sort of multi-function callback function.  Ugh.

But wait!  I go rummaging through the current GCC documentation to see what extensions are on offer (AGROS is highly GNU-toolchain-specific anyway), and I find that it now supports full-on nested function definitions!

Which is rather more than I need for the purpose at hand, but it's a convenient way of having a small function, about whose name I need not worry, to handle callbacks from the iterator function.

Wandered around the Embedded Systems Conference this afternoon

ESC seemed rather smaller and less exciting this year; that seems to be generally the case with trade shows lately.  Even combined with other shows, the expo hall (the only part I get to, 'cause it's free) was pretty much a one-afternoon thing.

There being some sort of sensors-oriented event there, I'd hoped to badger a few sensor vendors, but the sensors corner of the expo hall had something like three booths, only one of which had component-level sensors on display, and those accelerometers, on which topic I don't currently need to badger anyone.

There was some other interesting stuff, including a few companies whose products and services may suddenly become relevant to my world later this year (in one case, possibly next week).

The one thing I'm kind of excited about, and hadn't already been aware of, is something I would have totally missed in my normal pattern - but, late in the afternoon, I happened to stop by the LeCroy both to say "Hi, what's new since DesignCon?" - and the answer was, a new range of waveform generators, just arrived from the factory this week: the WaveStation.  For the price - the base model comes in at just under $1K - this thing is t3h aws0mz!  All the essential features of an arbitrary waveform generator that also does standard waveforms, modulation, pulse trains, and the like - and it's dual.  Yup.  Two output connectors.  Two channels.  Which means... well, it won't drive a 3-phase motor, but (keeping in mind I haven't read the manual yet), seems like it ought to be capable of generating a signal pulse on one channel and a gating pulse on the other... which I sometimes need, when testing features of the toaster controllers.  And so it goes in this year's capital-equipment budget, perhaps in late spring.

If there was exciting schwag this year, I missed it (but then I was never much of a schwag-hound).  Came away with a few pens, a sample heat pipe, and a little eval board for one of ST's Cortex-M0 MCUs, which has some potential utility, someday.

Iggle upgrade

My upgrade of EAGLE from 4.x to 5.3 arrived from CadSoft this morning.  Installation was straightforward.  Looks like it's going to behave itself.

I haven't started exploring the new features yet (what with there being real work to do today).  On a quick look, though, it's nice... and the bundled library collection has expanded quite a bit since version 4.1 (though a lot of them are user-contributed and contain only a few parts; a bit of central work on compiling master libraries would have been a good idea).

Update: the user interface is improved in various little ways (though I'm not sure I like the new delicate pastel look).  It has PDF export built in!  And cross-reference labels (though the mechanism is a bit awkward).  And... user-defined attributes!  Yippee!  That's a feature I'd really been missing.  I'll have to investigate just how this works in detail, but it should certainly allow me to tag passives with things like tolerance, voltage or power rating, dielectric type, and so on... normally leaving these blank, but having them available when I really need to differentiate things in the BOM.

The autorouter seems (based on a couple of quick tests) to work about the same as ever, and still doesn't deal nicely with user-defined power/ground fill (polygons may fall apart at the last minute), and still likes to route traces through the corners of SMD pads (I don't know that this is an actual problem, but it doesn't look right).  It seems to me that the overall result looks a bit cleaner than the old version's usual output.

I still need to try running some of my indispensible ULPs (slightly adapted from user-group programs) to make sure they still work... and then see how to incorporate the new attributes into the BOM program.

Slow-turn prototypes - how novel!

About 3 weeks ago, I ordered some PC boards from batchpcb.com, a division of Spark Fun Electronics that specializes in cheap, slow-turn PC boards.  Slow, as in about 3 weeks, not the 3-5 days of the quick-turn places.  Cheap, as in $2.50 per square inch for prototypes, with a $10/order setup charge.

Anyway, what with the setup charge being per-order rather than per-design, I ordered various numbers of seven different goodies.  They all arrived today, in good order.  Quality looks fine, and I was kinda pushing the limits of the .008" trace & space rules.  Misalignment between solder mask and copper is smaller than I can detect; this had been a bit of a worry, as I'd tightened up the mask clearance in hopes of getting mask between the leads of my TQFPs (which, as it turns out, worked).

I did have a bit of a problem with their DRC bot: I had, originally, a component in one design rotated 45°, which caused EAGLE to draw the Gerber with a small aperture; the DRC bot complained about this, despite the fact that no feature was actually smaller than .008".

I just assembled one of the simpler boards, and promptly discovered that I'd mis-assigned the leads of a tiny SMT switch.  Patch wires already... well, this is why we make cheap prototypes.

Sometime soon I need to swing by Anchor for some odds & ends that I didn't get around to ordering.  Teeny toggle switches and the like, cheaper from Anchor than from official sources.

And now for something completely different: back to FPGAs

In anticipation of one or more projects involving small-to-medium FPGAs, I'm setting out to learn more about the options.

I'd done some playing around with the Xilinx parts in the space of interest (Spartan 3E).  They look fairly promising.  The competition comes down to Altera (Cyclone II), and, now that I take a closer look, Actel (ProASIC3 / Igloo).

I have the Altera software installed on my office Windows box, but haven't done much with it.  For the application at hand, as it turns out, Altera is pretty much disqualified on grounds of not offering the right amount of logic in a small enough package without resorting to insanely fine-pitch design rules (there's about enough space for a 100-lead VQFP, but, for Altera, 144 leads seems to be the minimum).  [Update: The junior member of the plain-vanilla Cyclone family is available in a 100-lead TQFP; while it lacks some of the nifty features of Cyclone II/III and Spartan 3E, it seems quite adequate for the current task - which puts Altera back in the running.]  Given that I only need three inputs and one output for the application (plus five pins for the supervisory interface), even a 100-pin part is overkill in the I/O department.

I hadn't really been thinking of Actel, partly because I was remembering them from the mid-90s (antifuse FPGAs and a really expensive development environment) and partly because, the last time I'd looked at their newfangled flash-based parts, the development software was still out of my price range, unless I had a solid (and funded) requirement.

Well, now the development software is a free download, though it's even more obnoxiously encumbered than Altera's (node- and date-locked, requiring a new free license every year, in addition to the free version being Windows-only), and there's a cheap eval kit for the Igloo (the kit's called an Icicle, and Mouser has them for $108.something), so I got myself one of the kits, downloaded the software, and went through all the weirdness of getting a license.

(Setting up FlexLM manually is a nuisance.  Apart from anything else, the Windows environment-variable editor, like sundry other things in the Windows world, deals with potentially long lists of potentially long strings in a little bitty, non-resizeable window.  Talk about sucky UI design!)

Anyway: my first impression of Libero is that it'll get the job done, eventually, but that it's nowhere near as well designed as Xilinx's ISE.  It appears that each stage of the build process is meant to be invoked manually (no "make" button), and I'm not finding a nice summary of resources available vs. resources used (which is right there on the front page of an ISE project).

Determining resource usage is going to be important in evaluating parts for a given application... maybe I'll find the information I need, hidden somewhere, when I get around to wading through the manual.

The time-locked license may be an issue for the client, too; the prospective product is meant to have a 20-year support cycle, and having the ability to maintain a stable development environment is important.  This may yet push the whole thing back to the Xilinx platform.

Apart from the development-software issues, the ProASIC3 does have a certain amount of promise for the application at hand: it seems to be available from stock in the right combination of size, package, and temperature range, at a decently low price; the instant-on characteristic is a good thing; and the 1K bits of user flash could prove useful for storing model-specific parameters, leaving the actual Verilog program invariant (I'd been planning to use an external serial memory for that purpose, but the ProASIC3 could be a one-chip solution).