Silicon Valley Redneck

Motivation

Now that Project Egbert is rolling, and I've got a nice shiny LPC2387 eval board sitting on my workbench, it's time to get AGROS running on the LPC23xx.

Now, that basically means modifying the initialization code to handle the different PLL and a few more details, all under conditional assembly so that init.s continues to support whatever LPC2xxx part I'm using.

And, in fact, I'd made those changes quite some time back, though I seem to have gotten some of the details wrong.  Such is life.

But!  In order to use the modified features of the little assembly-language init module, I need to change some of the definitions in the Makefile.  Which is generated by the config utility.  Which extracts all that stuff from the target/architecture definition files.  Which....

Oh, heck.  I suppose I might as well do it right, meaning that I need to create definition files for LPC2387, LPC236x, LPC23xx in 100-lead QFP, and LPC23xx.  Some of these are trivial - basically, include the more general forms and fill in a few definitions.  But I still need to fill in the dreaded pin map and pin options map.

This will take some time, but, once it's done, adding support for any other LPC23xx part in the 100-lead QFP will be easy.

And I've got other things on the drawing board using LPC236x or 2387 parts, so there should be further use for it, on beyond Egbert.

Crazy days

Yesterday afternoon was so filled with interruptions that I only managed to complete one of the half-dozen tasks on my to-do list for that time... and that was the only one that wasn't billable time.

Today... well, I'm sort of catching up.  Got several things checked off, and I'm making progress on Project Egbert as well as handling change requests on an earlier project.

And, demarcation not yet having been settled, I've been looking at aspects of Egbert that will probably be someone else's bailiwick once the lines are drawn.  This leads to my looking up the I/O connectors used on Egbert's predecessor, which I guess must, in retrospect, be Offa.

A hundred eighty dollars per*?  And there are two of them on the board, which makes the cost of my fancy high-tech chips look kind of inconsequential.

Well, I think we'll be using a different connector family for Egbert, but I don't know yet if it's more or less expensive.  (The list of ordering options suggests that it's not much less expensive, if at all.)

And I think I'll be looking more at doing it right options, as opposed to doing it on a budget, at least so far as the right way isn't hugely more expensive.

Still to be done this evening: continuing support for the project that's in bring-up mode, and some further contemplation of Egbert.  (Not real work; that requires a bigger block of time, and also clearing my workbench of the stuff I need to have there for the continuing-support task.)  Then there's a lot of stuff that should be on my personal to-do list, only I don't seem to be keeping one, so that stuff all gets lost....

*Update: apparently the client's purchasing department gets a better deal than my casual web search turned up.  They're only paying $76 each, in whatever quantities they buy.

Now, here's a head-scratcher.

Consider, if you will, the I²C interface.

It has two signals, SCL and SDA, both open-collector (or open-drain), with pullup resistors to be provided externally.

It's used in systems that run on a variety of supply voltages... frequently, a variety of supply voltages within one system.

So: how does it come about that, on every I²C I/O expander I look at, logic "1" on SCL and SDA is defined to be 0.8VCC, rather than, say, 2.0V?

(I don't have the I²C spec ready to hand; maybe it's graven there in stone.)

Would it not make more sense to have the open-collector bus use TTL thresholds, so that all logic running on 2.5V or higher could just share a bus, with pullups to the lowest VCC used on the bus?

Oh, well.  Since I need to hang one each 5V, 8-bit I/O expander on an otherwise 3.3V bus, I guess I'll be needing a level translator.  Hello, 3.3V I²C bus and separate 5V I²C bus.

Monday comes on a Tuesday this week

But, as Mondays go, this isn't too bad.

I completely missed the evening parties at Baycon, what with allergies acting up and some sort of general crud.  But!  It seems that the general crud was one of my occasional metabolic shifts, and by the time the weekend was over, I'd lost the two obstinate pounds that had been refusing to budge for the last several weeks, and one of their friends went with them - and I was another half-pound lighter this morning, despite four meals and a couple of snacks yesterday.

Up early this morning, getting in a 5.2-mile hike before work.  Maybe tomorrow I'll get going even earlier, and do the 7-mile loop with a proper hill in it!

Also, I've reinstated the "no caffeine after breakfast" rule.  I may be a bit headachey the rest of the week, but I really do need to taper off the caffeine.  It's not really effective at keeping me alert, anyway.  When I get overcaffeinated, I tend to be buzzed and falling asleep at the same time.

Ah, well - compliance work this morning (and tomorrow morning).  Project Egbert this afternoon.  Gotta rip all the marketing material out of the project plan, and turn it into a proper engineering/planning document, replacing the "what cool things shall we do?" tables with "these are the application requirements" tables.  Tomorrow, order some more stuff for component evaluation; there's a lash-up to be built.

Baycon weekend

Busy weekend ahead!  As usual for this time of year, there's a big gathering of science-fiction fans and other weird people, so it's time for socializing, including late-night partying (tonight only; let others party late Sunday, but I need to get up early Monday morning).

Tuesday, work resumes, and as I look at the scale of Project Egbert, and the list of off-the-clock stuff that needs doing in order to facilitate Egbert ending up the way I want it to, it looks like I've got a very busy three months ahead of me.  Mostly, the first few weeks will be hectic as I ensure that the hardware choices are sufficient for the eventual mission.

Well, AGROS will come out the better for it, including a new cheap-networking protocol for talking to AVRs and such.

I still think this is the wrong end of the stick.

If you're in California, and on the same mailing lists I'm on, you've probably heard something along these lines:

SB585 is currently in the Senate Appropriations Committee.  Introduced by State Senator Mark Leno (D-3), SB585 would prohibit the sale of firearms and ammunition on the property or inside the buildings that comprise the Cow  Palace.  In short, SB585 is a stepping-stone to banning gun shows on all publicly-owned property in California.

Well... I have my suspicions about this.

Yes, it could be a stepping-stone to banning gun shows in public venues.

But it could also be a stepping-stone to selling the Cow Palace to a private developer.

Apparently there's been a Plan in the works for several years to sell off the Cow Palace, and of course one of the obstacles is those pesky people who insist on holding, and attending, events there.

Closing the Cow Palace so it could be sold would draw the ire of several constituencies all at once.

Getting rid of the gun shows would draw the ire of just one of those groups - a fairly large and outspoken one.

Then the custom-car shows need to go; those people are scary.  Then the boat shows, on whatever pretext.  Then... well, before too long there's hardly anyone using the facility, and it's costing way too much to keep it open, so it might as well be demolished and the land sold off.

Project Egbert is GO!

Yes, it's official: I got the project code yesterday, and had the kickoff meeting this afternoon (with some changes to my original concept, but I'm not having to throw out any of the work I'd done ahead of time on speculation).

And - hurrah! - the first unit isn't due until November, which means we can probably start integration in September, which means I've got June, July, and August to get a moderately ambitious hardware & firmware project done.  So, I'll be comfortably busy the next three months.  (No summer vacation, but the project won't be eating my weekends either, and there'll still be time for morning exercise.)

Also, the second customer with similar requirements is almost ready to sign on the dotted line, so in addition to having just about enough time to do it right, there's a bona fide business case for doing it right, incorporating plenty of flexibility, etc.

Lessee, now: I ordered an LPC2387 eval board yesterday evening (after getting the project code), so, allowing for the holiday weekend, that should be arriving Tuesday, I guess.  A fair amount of the firmware work can be done on eval-board lashups.  There's coding to be done in C, Verilog, and Ruby; as usual, some is on my own time and some is on the client's nickel.  I need to order a couple of other eval boards for probably-useful components, now that I know the project is going.  Ahhh, and there'll be lots of coördination needed to get the hardware actually built, assuming the client is going to deal with layout and fab.

So, interesting (but remunerative) times ahead.

Stupid thought of the day

Is macular degeneration the opposite of immacular generation?

Life in the -unstable lane bites again!

This morning, I updated the Debian-unstable on my workstation (but not a dist-upgrade, this time).

Everything seemed to be OK... until... I tried to print a page from Firefox.  No soap.  Firefox would let me print to a file, but if I tried to select one of the CUPS printers, the "Print" button would be grayed out.

Firefox 3.0.10 + CUPS 1.3.10 = FAIL?

Well, a bit of googlery turned up an answer: there's something screwy involving IPv6.  Since I don't play IPv6, the solution turns out to be to add this line:

alias net-pf-10 off

to /etc/modprobe.d/aliases, and reboot.

Hey presto!  I can print!

Now if I could just figure out why Firefox keeps wanting to start in offline mode by default....

Danger! Danger!

With the State of California now officially in a desperate financial situation, what can we expect?

Well, a bailout from Uncle Sugar, of course.  With strings.  Meaning that state law and policy will henceforth be determined by the President, not by elected state officials.

And what else?

Well, one obvious fundraising measure is a vast increase in law enforcement as a profit center.  You remember the jokes about small towns in the deep South in the bad old days, with traffic lights that would turn red at the push of a button, with only the briefest flash of yellow?  Well, that sort of thing has been with us in the more sophistercated parts of the country for several years now, and we can expect it to increase.

So: expect vigorous enforcement of laws punishable by large fines.  Expect also an increase in property forfeiture action.

On the other hand, it'll be good times for serious criminals.  California is already having to dump inmates from its prisons due to overcrowding and lack of funds.  With the budget megacrisis, expect the state to give up on trying to put common criminals in prison.  This will have the added benefit of freeing up resources for collecting fines and confiscating property.

Coming soon: the national financial collapse, and China's aircraft carrier: what's the connection?

Fawns of the prelude to the afternoon

Well, morning is the prelude to the afternoon, isn't it?  And, yes, I do realize these aren't that sort of faun.

Anyway, some non-rodent, non-apocalyptic furry cuteness from this morning's exercise outing:

Rodent of the apocalypse!

Twice last week, as I was out on my morning hike at Rancho San Antonio, I saw something scamper across the trail.  It was the size of a chipmunk, and the shape of a chipmunk, and it moved like a chipmunk... and, the second time, with slightly better lighting, I got the impression it was striped like a chipmunk... but I'd never before seen a chipmunk in this area.  Our picnic areas are noted for their lack of chipmunks.  Chipmunks, when I was growing up, were critters you'd see if you went somewhere other than the Bay Area.

Well, this morning a movement caught my eye, and there was this little furry varmint perched in a bush, and this time I had my camera out:

Yup.  Chipmunk.  I guess that'd be a Merriam's Chipmunk, based on its general location and habitat, though what it's doing on the Peninsula I don't know.  Must be ManBearPig's fault.

Of Acrobats and Acrobelfries

And how Adobe seems to have an infestation....

I've had Acrobat Reader 7 and 8 both installed on my Linux workstation for a while now, and have been using version 7 because I'm used to it, and the UI in 8 is distractingly different.

Well, thanks to software rot, I'm finding it necessary to switch to version 8... many new documents (such as recent NXP datasheets) display just fine in 7, but if I try to print them, I get a blank page, and then I have to open the document in some other reader and print it from there.

And so it comes to pass that I discover that parking an instance of the reader on Desktop #10 and opening documents from file managers hither and yon doesn't work the way it used to.  With 7, the documents would open in the existing window.  With 8, they all open in new windows.  OK, so where's the setting for fixing this?

Apparently there isn't one.  Seems that feature was removed from the Linux version of acroread 8... and then from the Windows version of acroread 9.

Feh.

Do these people ever use their own products?

Well, maybe I can apply some X magic to force the new window to open on the right virtual desktop, at least.

Updates: (1) /opt/Adobe/Reader8/bin/acroread -help informs me that there's a -openInNewWindow option.  Ever so helpful, that, seeing as how it's the default, and only, behavior anyway.  (2) Apparently version 9.1 supports tabs.  Guess I should give the very latest version a try. (3) Yeah, that worked.  Get 9.1; the tabs are more useful than the old scheme... at least so far.  I haven't gotten to the dozen-files-open stage yet.  (4) Finglebatz!  The original problem, it seems, isn't in fact solved.  I tried to print a recent California Micro Devices datasheet from 9.1, and got a blank page.  It prints fine from kpdf.  Go figger. (5) Oops.  After the last reboot, is vas version 7 running, not version 9.  Guess I need to update the symlink in /usr/bin.

Now, wait a minute...

Slashdot links to this PC Authority article on disappointing technologies.

One's the Apple Lisa.  Fair enough, but...

Lisa couldn't charitably be described as an Apple invention per se, it was a straight steal of Xerox's Alto machine, which the company correctly assumed would be too expensive to sel in volume.

Er, wasn't the Lisa, like the Mac, built around a 68000?  And wasn't the Alto built around a Nova-type processor?  Back in the early 70s, before there was such a thing as a 68000?

Anyway, the Newton was a much better disappointment than the Lisa, though it does still make a fine party game.

See also: the song.

Nigerian Toyota spam from Sunnyvale!

In my inbox yesterday: a Wonderful Offer on unsold Prii, or Priusim, or whatever they're called.

Excerpts:

Due to the recent global financial crises, Toyota stuck in stock with 1200 Prius HYBRID cars, because in this stock are cars unsold for over 6 months, TOYOTA launch the Advantage Program where is 30% discount for 1200 Prius HYBRID cars.

Hmmm.  Y'know, the actual e-mails I get from Toyota generally have better grammar than that.

The third step: After the agreement, the buyer need to deposit $5,000 to TOYOTA Dealer Bank Account, necessary for delivery, completion all documents, and submission of a balance of $2,500.

Er.  Some sort of incomprehensible juggling of bank accounts.  Sounds Nigerian to me.

And where's this come from?

Domain Name.......... toyotaadvantageprogram.com
  Creation Date........ 2009-05-17
  Registration Date.... 2009-05-17
  Expiry Date.......... 2010-05-17
  Organisation Name.... [person's name removed]
  Organisation Address. PO Box 61xxx
  Organisation Address. 
  Organisation Address. Sunnyvale
  Organisation Address. 94088
  Organisation Address. CA
  Organisation Address. US
...
 Admin Email.......... [email protected]
 Admin Phone.......... +1.510595xxxx

Ah, a Sunnyvale address, but an East Bay phone number (the admin address is the same PO box as the purported registrant's address).  Registered via a proxy today, but the e-mail was sent yesterday (time zones are possibly involved).

I see, however, that by this morning the domain has been diverted, and now points to toyota.com.

What's up with the time signal?

According to my computer, my cellphone, and the Sun, it's now 0801 where I'm sitting.

My Oregon Scientific self-setting clock has somehow decided it's 1700.  And, yes, the time zone is set to "Pacific."

Seems like it was showing the right time yesterday. The little radio-tower icon is indicating a strong signal, which presumably enables it to reset itself... but it appears to have reset itself kinda wrongish.

Good idea, lousy timing

El Reg reports that Acer has a cute new netbook with an optical drive of sorts: a Vmedia reader.

Er, so what's Vmedia?

Well, it's sort of a small-form-factor version of a blurray disk.  Cute little rascal.  Apparently the idea is that you can buy movies on these little things, at approximately DVD prices, and play them on your mobile devices.

They hold - wait for it! - 1 Gbyte, with a 2 Gbyte model on the way.  A recordable version, so's you could make your own movies, use it for backup, or design it into a camera, is somewhere in the future.

Remind me now: what's a 2 GB SD card cost?  Oh, six bucks retail.  And the "drives" are dirt cheap.  And they're recordable.  The full-size ones, and even some of the micros, come with a write-protect switch to prevent accidental erasure.

If you wanted to distribute read-only movies in a small form factor, surely one of the SD card manufacturers would be happy (if the quantities were high enough) to churn out a mask-ROM version of the micro-SD card... or, for smaller quantities of each movie, perhaps a write-once product.

This sounds like one of those things that would have been a killer technology if it had come out a decade earlier, but that's just a generation too late to have a real market niche.

Another day, another weird problem

My plans for the afternoon mainly involved preparations for Project Egbert, including learning to use features like DDR inputs on the Spartan 3E (having gotten the hang of LVDS I/O yesterday).

However, the client went and handed me some boards of an older model, which the technician was having trouble programming.

Hm.  Well, Flash Magic won't talk to them through my cable, either... and it will talk to a known-good unit (of a slightly more recent model).  Autobaud fails.  Actually, it appears that the LPC2138 is sending BREAK on TXD0 (or perhaps it's just not initializing, and the line is floating low - I should check that).

Hook up the JTAG pod, and it finds the processor... and the flash appears erased... and the JTAG debugger can't load the program into flash either.  Some sort of "no response; are you sure that's flash at this address?" sort of error.

And, yes, the 3.3V supply looks healthy, and the main oscillator is humming along at the appointed frequency.  (Otherwise the JTAG wouldn't work.)  RESET is high, at least at the supervisor chip.  (Again, if RESET were low, JTAG would fail.  I think.  Maybe I'd better re-examine that.)

So, either this batch of boards has bad microcontrollers, or there's something else going on that keeps the bootloader from running and flash from being programmed.

In the former case, it raises questions about Project Egbert, as I've been planning all along to use a similar NXP part in that.  If we're having reliability issues, perhaps I need to look at alternative vendors.

Update 1: TXD0 is floating after reset.  This is also the case on the good unit; it goes from floating-low to driven-high (followed, of course, by a bit stream) when the flash-programming software starts talking to it on RXD0.  On the bad units, though, it just stays at floating-low.

RESET and P0.14 are confirmed correct at the chip: P0.14 is low when the "program" switch is on, and RESET goes low while the button is pushed.

RXD0 looked right on the first unit I examined... mayhap there's something peculiar about it.  It is 5V logic, but that's the case on all of them, and that input is supposed to be 5V tolerant.

(Oh, and the client notes that there have been quality issues with some recent boards... speckles of copper where no copper should be, and pits in copper that should be pitless.  Since we may need to go to 4 mil trace/space for Egbert (or Egbert Jr.), this may call for finding a fab house with better QA than the one they've been using.)

Update 2: It occurs to me that what ISP and JTAG flash programming have in common is the ISP/IAP code that lives in the boot block.

If I hook up the JTAG pod again, and examine memory starting at 7FFFD000, the good unit has ARM code there.  The four bad units have all ones.  Like, the boot block has somehow gotten erased, or was never programmed in the first place.

Anyway, I sent the boards back, to have their 2138s replaced.  But what happened?  Were the chips shipped sans boot code?  Were they severely X-rayed?  Did the boot blocks somehow get erased?  The manual says that's impossible, but apparently some members of the LPC2100 family can have their boot blocks rewritten.

It's all rather confusing, really.

Whatever became of pockets?

Last week,I stopped by J. C. Penney and bought three basic lightweight cotton short-sleeved shirts that were on sale at a reasonable sort of price.

This morning I put one of them on, and noticed that it lacks a pocket.

So do the other two.  Three shirts, two makers, zero pockets.

Maybe that's why they were marked down - the pockets are missing!

Well, I guess they're OK for days when I don't need my pencil, pen, PDA, and notepaper.  Which, pretty much, is hiking days.  These shirts are OK for hiking, but I was thinking more along the lines of work days when I picked them out.

And now I still need a couple of new, respectable summer workday shirts, and apparently I need to add "with pockets" to the checklist, as pockets seem no longer to be standard equipment.

In which I stop bashing my head against that particular wall

At long last, I have the LPC2148 USB driver for AGROS behaving itself... at least as my test program being recognized by Linux as /dev/ttyACM0, and writing to that device resulting in bytes showing up in the appropriate place on the test program.

Windows recognizes it as a valid USB device, but can't find a driver for it.  Guess a VID/PID of FFFF/0001 isn't good enough for Windows.

A large part of the trouble was, as it turns out, that packets were coming in too fast for my interrupt handler (at least, with the debug messages enabled).  The solution was to have a loop for each OUT endpoint: while the endpoint status shows data available, read and dispatch it.

I still need to implement the rest of the CDC-ACM layer, but there shouldn't be too much to that.  I do want to recognize commands vs. data being sent on the data interface, so the "AT+GCAP\r\n" that the Linux driver sends during initialization (apparently trying to decide whether the device is really a modem or not) doesn't get passed to the application.  Once it's all done, it should look like just another character device, and things like the TTY line discipline should just work.

Meanwhile, there's another (actually work-related) wall against which I need to bang my head a bit more.

And there's Project Egbert, which still isn't official, but I really ought to be doing some meeting prep so when the client finds time to address it, we can quickly nail down the application requirements.  That one shouldn't involve too much head-bangery.

(I think when it's official it'll need a new code name.  Egbert sounds too much like a downtrodden engineer's breakfast.)