Silicon Valley Redneck

Sometimes, it pays to pester people at trade shows.

For the last couple of years, I've been stopping by the Actel (now Microsemi) booth at trade shows to ask if they had any plans for a mil-temp version of their SmartFusion chips - the ones with the nice Cortex-M3-based MCU with canonical peripherals sharing a die with a chunk of FPGA and some other goodies.

Well!  I got an e-mail today announcing that they'd gone and done it!

'Course, at this point I don't have anything in the pipeline that requires such a thing, but it's nice to know it's available, so when a requirement does come along - and it will - for an extreme-environment, subcompact, super-smart toaster controller, there's a chip I can use.

And that's maybe an excuse to dust off the SmartFusion eval kit that's been sitting idle these past couple of years.  Well... when I have some free time again.  I need to learn how that thing and its development environment work, so that once AGROS is up on the Cortex-M platform, I can write a few device drivers for the SF platform and be ready to go when the opportunity arises.

And, even in the non-extreme space, I've thought of a couple of good uses for the SF chips, just waiting for me to do something about them.

'Tweren't the diode this time (Update: yes, it was.)

Consider, if you will, the humble peak detector.

Signal enters on left.  There's a diode in series, then a capacitor to ground.  Detected peak exits on right.

In reality, there's probably also an op amp involved, and a cunningly-fudged feedback circuit, and a resistor to bleed charge slowly off the cap to allow ongoing readings of "most-recentish-peak", but in general terms you've got a cap being charged through a diode.

Well.

I watch the input pulse go up and down.

I watch the voltage across the cap track the input pulse up... and then track it partway down, before leveling off.

I see that the amount by which the cap follows the input down decreases with pulse width: at 5μs, it's barely noticeable, while at 500ns, fully half the peak voltage is going bye-bye.

So I double-check the diode, and its capacitance is dang-well guaranteed to be far too low for the driver to be sucking that much charge out of the cap on the falling edge.

And I spend much time puzzling over this, and wondering how a ceramic cap can possibly take time to charge up.  I mean, it's not like it was an electrolytic, or a lead-acid, or any such.

And the dissipation factor for X7R dielectric is supposed to be, what, 2.5% or something?

Oh.

Maximum DF is 2.5%, for parts rated 50V and up; maybe 5% for a 10V rating.

And that's at 1 kHz.  The "typical DF vs. frequency" chart shows 1.2% @ 1 kHz, a rapid increase approaching 1 MHz, and off the 10% top of the scale at 4 MHz.

And I'm hitting it with a pulse with about a 250ns rise time.  So... lotsa energy goes into heating the dielectric during that edge, and doesn't come back out again.

If the pulse is wide enough that it starts looking like a low frequency again, the capacitor takes in a bit more energy in reversible fashion, which is what I want.

Guess I need to try substituting a C0G cap for that X7R part.  Fortunately, the footprint is big enough to accommodate the value I need.  Unfortunately, I don't have that value handy, and the local purveyor of such things is closed for the holiday weekend.

Oh, well: I can always stack up lesser values for test purposes.

Update: substituting a comparable value built up from NP0 parts has little effect.  I are re-confoozed.

Update 2: Spent a smegging lot of time on this mystery.  Finally ripped the diode out (for sufficiently delicate values of "rip" - it's a sodding SOD-323 in the midst of a 3-D sculpture on the  lab board) and replaced it with a 1N4148, and then with one of the SOD-323 Schottkies as used in the power sections.  Guess what?  It behaves itself now!  So, either the diode was faulty in a weird way, or the type that I had installed (and I don't know for sure what that was) has a bizarre property that doesn't exactly jump out of the datasheet (and, if it was what was supposed to have ended up in that spot, the manufacturer claims it's for "high-speed switching," so you'd think it could deal with 2V pulses at half-microsecond time scales).

Yipe!

Reworking a prototype toaster-controller board, I found myself about to use the last OPA365 (fast-ish op amp, SOT-23-5 package) in my inventory.

So, time for a procurement break, to get a restock in the pipeline before Digi-Key's shipping deadline for the day.

Look up OPA365.  Find the part I need: 1227 (or thereabouts) in stock as cut tape.  Click on the part number.  Add 5 pieces to my order.

What?  Back-ordered?

Yup.  Some SOB done bought 'em all out from under me - and, shortly thereafter, bought all that were available on reels, too.  POOF!

That left a few mil-temp parts, which seemed unnecessarily pricey for my purposes.

Luckily, Mouser had 74 of the I-temp parts still in stock, at a somewhat higher price than Digi-Key, but the SOB hadn't snaffled 'em all up yet.

So I guess somebody out there is actually building hardware in volume... and, once again, he's designing in the same parts as I am.

Brain fizz

The reader may have perceived, behind some of my recent posts, that I've got rather a lot of irons in the fire at the moment, and an abundance of harebrained schemes in the queue.

I'm not sure what it is - spring, gradually getting my allergies under control, an outbreak of uncertainty in the business climate, flirting with some tipping point in physical fitness, whatever - but my brain has been popping into overdrive lately, and I keep coming up with Great Product Ideas.

The idea list keeps expanding, and I anticipate getting some serious prototyping done this summer.

In the midst of designing a cute-just-because gadget (for which there may actually be some market among the HPR crowd, and perhaps elsewhere), I suddenly had an inspiration for... well... no details in public right now, but it's a highly useful electronic gadget for the occasional bread maker, and perhaps for other people.  Not exactly a concentrated market... but probably enough of a market to justify making the thing, and - here's the fun bit - selling it on Amazon, which seems to be the convenient new forum for low-intensity selling.

Of course, I don't really want to run a retail operation even at the Amazon-store level of involvement, so this probably calls for either finding someone who's already doing that sort of thing, or starting a separate business and getting some other sucker to look after operations while I develop the next dozen products.

Iggle oddities

Working on some new board designs for the New Venture.  Well, proof-of-concept boards for the Maybe-Later-This-Year Venture, anyway.

Being as how the R&D budget is kinda tight... as in, nobody's paying me for this, and parts and outside services come out of my own paltry stash of investable capital... I'm trying to do things on the cheap.  Like, where at all practical, squeeze designs into the 2-layer rules at Batch PCB, and keep any dimension from being just-a-little-over an integral number of inches.

And so I've got this design that's kinda pushing the limits for 2 layers, 8 mil trace & space, and 20 mil minimum via.

EAGLE, what's up to 6.2.0 now, has its usual problem when autorouting a board with one signal layer and polygon-defined ground plane on which violations are allowed: the ground polygon gets all carved up, and sometimes becomes discontiguous, and often it seems prudent to add staples on the signal layer to stitch areas of ground plane together across long interruptions.  Also, there doesn't seem to be a way to suggest to the autorouter that it try to reduce the via density, e.g., when there's a QFP in the middle of a big open space, and having all the vias packed close in will increase ground-plane-falling-apartness.

The new oddity, though, is that the autorouter and the DRC don't seem to agree on clearances.  (I suspect it's the autorouter being peculiar, as 6.1.0 was happily routing signals across unplated holes in the board.)  Load rules for 8/8; run DRC: happy; run autorouter; run DRC again: a few clearance violations - via to trace, via to pad, via to via.  Run the autorouter with 8.5 mil spacing, then check at 8 mil: still some clearance errors, though maybe not as many.

So, there's annoying manual cleanup work to do, that I don't recall having to do with version 5.x.  (I don't recall seeing the DRC problem on a bigger board I did earlier this year either, but I don't recall which EAGLE version that was, and that board was both a lot less dense and done with 6/6/15 design rules.)

Update: I think DRC is being kinda paranoid.  For one thing, it keeps complaining about solder-mask violations when silkscreen text is in the general vicinity of pads, even when the actual text doesn't infringe on... wait, lemme check something.  Ah!  DRC behaves itself when dealing with vector fonts.  With the nice proportional font, which won't Gerberize as such anyway, it gets paranoid about where the boundaries are.  So, I guess I should really go through my library and make sure everything on layer tNames is in vector font.

Meanwhile, though, changing the "make all the names 40 mils tall with a 14% ratio" drill to include "and vector font" takes care of the text vs. pad issue... leaving the question of why DRC and the autorouter don't seem to agree.

Update 2: Not DRC being paranoid; it's the autorouter not minding via clearances, or something.  I generated Gerbers for a little board routed with 8/8 rules, and Gerbv says the spacings that DRC was complaining about are in fact under 8 mils, by various amounts (half-mil-ish).

Browsing the Cadsoft support fora, I don't see anything about this, so perhaps nobody else who's running v6 has done a DRC after an autoroute yet.  Maybe I oughtta be posting there instead of here?

In contrast to the previous post...

I keep seeing info on Cool Parts that aren't in distribution.

In particular, a couple of MEMS sensors from ST, LSM333D (combining 3 axes each of gyro, accelerometer, and magnetometer in a single package) and LPS331AP (digital barometer, low power, tiny package).

OK, so the LSM333D shows as "Preview" on ST's site, but the LPS331AP is supposedly "Active" - so will somebody please sell me one?  (Or, more to the point, have a bunch in stock, with prices listed, and the prospect of an ongoing supply?)

As an alternative to the LSM333D, there's the MPU-9150 from Invensense, though I have the suspicion it's gonna be pricier than the ST part (Invensense doesn't show quantity pricing online, and doesn't seem to deal with the usual distributors, but the gyro+accelerometer parts are significantly pricier, in onesies, than the LSM330DLC).  But... when first I heard of it, the data sheet was promised in, IIRC, April.  Now it's "Available Q2 2012."  And as for actual parts...?

Update: Actually, Mouser does list the LPS331APY, at $7.17 in onesies... with none in stock and 430 on order, supposedly shipping at the summer solstice.  Which says I probably ought to try to shoehorn in a footprint for it alongside the known-available BMP085, in a design that probably gets prototyped sort of late-Juneish.

Hey, cool!

The past couple of years, I've been grumbling, on and off, about the lack of CANbus transceivers in anything smaller an an SO-8 package.  LIN, yes, but not CAN.

A while back, NXP semi-obligingly put the transceiver on-board in the LPC11C24, but that only helps for applications where a logically-tiny MCU will get the job done.  (Also, that part is only available in a QFP-48, which has kind of a big footprint for one application I have in mind.)

Well!  I just noticed that NXP has now come out with the TJA1042 CAN transceiver... available in a cute little 3mm square HVSON-8.

Which makes CANbus plausible in applications where its noise immunity would be really nice, but that old SO-8 is just too huge a footprint.

Also, there are now some cute multiple transistors... like how about the Zetex ZXMHC3A01T8TA, quad 30V, 2A FET, 2x N and 2x P, in a bridge configuration and a 6.7x7.3mm footprint?  Coupla simple down-pulling drivers for the high sides, drive the low sides with ordinary logic signals, and ya got a nice little motor driver in very little space.

Need to drive a smaller motor in a smaller space?  Hello!  NXP PIMC31, prebiased PNP/NPN transistor pair, 500mA, 50V, in a 6-lead SC-74.  'Course, you need two of those, plus typically a dual NPN (or dual N FET) in a third SC-74 to drive the high-side bases from your low-voltage MCU.

And there are now some dinky linear regulators.  Need 3.3V @ <100mA from a 3.4~5.5V input?  That can be had in a < 1mm² footprint these days, if you don't mind handling itty-bitty 4-bump ball-grid packages.

So, happy days.  I got a bunch of designs in the works, none of which immediately call for CANbus nor full-bridge motor drivers, but it's nice to know those parts are out there.

Having negative feelings about POSIX

So there's this new-model toaster that the apprentice is bringing up... and we've got almost everything sorted out at this point.

Last little detail is changing the Baud rate for the host interface (RS-485) to what the customer wants.

Which is not on the standard Baud rate list.  It's not 75, nor 110, nor 300×2ⁿ, nor 14400×2ⁿ.

Now, changing the toaster's Baud rate is dead easy.  In AGROS, you specify the Baud rate you want (integers only), and the driver is responsible for doing the generally simple, but device-specific, arithmetic to come up with the nearest divisor.

Thing is, we need to test that sucker.  And that calls for hooking the RS-485 up to a PC, generally using some flavor of USB serial dongle, setting the communication parameters to match, and running in ruby slippers a Ruby script that emulates the customer's toaster-hoster.

And, when I try to deal with it on Linux... well, ya see, there's the POSIX way of specifying Baud rates.  Which involves passing an opaque constant defined in a header file... which only defines the constants for standard Baud rates.

Apparently there's a way to bypass that and set arbitrary Baud rates, but that (a) requires manually calculating the divisors and (b) only works on built-in UARTs, not USB dongles.

And on Windows, well, that remains to be seen.  Once my lab XP box finishes applying several months' worth of Patch Tuesdays, I'll give it a try.  But!  It probably won't work on the laptops in ToasterCo's lab, because Microsoft.  (I'm assuming because Microsoft.  They've got a mixture of XP and 7, running mainly to 7 now, and some time ago my use of the setCommState function ceased, some of the time, to set the comm parameters correctly, even though (at last report) it still worked on my token XP machine.  So, the actual parameter setting is handled by an earlier (as in, before I open the port) invocation of the mode command, which I'm pretty sure only recognizes the standard Baud rates.)

Update: I'm provisionally astonished.  Not only does Windows (XP, with the latest FTDI driver) let me set the funky Baud rate, but it even lets me do it via the mode command!  It remains to be seen whether it'll work in the company lab.

Attack of the LLDs (or, EABI strikes again)

Wednesday evening, I added a debugging feature to the code for the old-model toaster controller: if the debug level is set above 1, prefix state-change messages with timestamps, said timestamps being hhhh:mm:ss.sss representations of time_stamp_ms, which is defined as sys_time/1000, where sys_time is a 64-bit unsigned count of microseconds (typically, as in this case, incremented by 1000 every millisecond).

Well, I hadn't tested it, but it's trivial, innit?  Do the necessary arithmetic on the arguments to printf, and format with %4lld:%02lld:%02lld:%03lld, and hey presto.

And besides, my workbench was full of new-toaster innards, so testing old-toaster firmware was inconvenient.

Well, Friday afternoon was an occasion to set the new toaster aside and do some old-toaster testing (which points to the factory's prototype of the latest version perhaps being miswired, 'cause it works fine on my test setup).

And today I had some Other Stuff, entirely unrelated to grilled bread products, to work on, and kinda wanted my workbench back.  But, as long as the hardware was set up for testing, why not do a fresh build of the firmware, and make sure my silly little addition actually works?

Oops.

Panic!  Data abort trap.  System dump.  Task list corrupted.  Awooga!

Gah.  Did one of my changes to AGROS in the last couple of months make the toaster firmware not work?  Oh, first off: check that I'm using the right ARM toolchain: yup.  So, then: check out a couple-months-old version of AGROS from the repository, and build against that.  Same problem.  Re-run the config utility, making sure I'm getting the old version.  No change.

Eep.

Much running around in headless-chicken mode.  Run diffs on everything involved: nothing makes sense.

Finally #if out my newly-added if (debug_level > 1) {mumble mumble printf(mumble);}.

Works now!

Welllll... I haven't actually diagnosed the problem, having worked around it by the simple expedient of doing all the arithmetic into temporary ints and changing the %lld formats to plain old %d, but I'm kinda guessing that there's some problem involving alignments, ARM EABI, stdarg, and a plurality of long long arguments.

 

UARTs is tricksy beasties

Back in the realm of Project Forkbeard, I've got a couple of UARTS implemented in the FPGA, and they'd apparently been working fine... right up until I started trying to implement field firmware updates, which feature involves shoving large amounts of data down one of the UARTS at full speed.

See the result: garbled data, sometimes.  On closer examination, framing errors are cropping up, so I can detect those and demand a retransmission (in addition to all the other consistency checks).

As things stand at the moment, I can successfully transmit the necessary data, in a reasonable time... but I really want to understand why the errors are happening, and make them stop.

Presumably the state machine is somehow either not getting back to IDLE during the stop-bit time, or bouncing out before the start bit shows up, neither of which really makes sense (especially when it's a sometimes thing).  Perhaps something needs another layer of synchronization, to prevent a race condition between state-variable bits?  (That makes little sense.)  Or, if the framing errors persist, maybe I need to whack 'em with the framing hammer (not a town in Massachusetts).

Update: the UART logic, per se, was fine.  Turns out there was some manner of race condition in the state-transition logic, which doesn't make sense, 'cause it should have been only one bit changing anyway - but synchronizing the RXD input fixed it.