February 2008

Friday, 29 February 2008

Doing a bit of further debugging of AGROS on my lunch break... turns out there were a couple more problems related to the restructuring, and a problem with the architecture definition for the configuration program.

Those being fixed, I now have a sample program happily ticking away with four tasks running (main, monitor, poll manager, and idle). The lights blink, messages come out on the console port, and I can type in monitor commands and have them run. Currently compiled for ARM using gcc 4.2.2 (which didn't work with the old structure), and there's no manual futzing around to get the right version of libgcc.

Maybe I'll try compiling for thumb later (now that I've got it back to a working state, so anything that breaks can be safely blamed on thumb mode).

Thursday, 28 February 2008

The little AGROS test program was sometimes almost running, but mostly crashing in strange and exotic ways.

After much futzing around, I discovered that it all (for the moment) came down to the task-switching code having been called from a non-vectored interrupt.

That doesn't work. It has to be called from a vectored interrupt, because otherwise the task's return address will be pointing into the middle of the non-vectored interrupt handler (which loops around, calling handlers as appropriate) instead of back to the interrupted task code.

This having been revealed, I tracked it back to a bug in the configuration program, which was examining priority values such as "4" and "12" and declaring them to be non-numeric, ergo non-sortable, and thus making the associated requests non-vectored.

This is not a good thing to do to the system timer interrupt, whose wrapper exits through the scheduler instead of just doing a normal return from interrupt.

Progress! (As in, my New Improved System is gradually approaching the usability of the old crufty codebase.)

Wednesday, 27 February 2008

A bit of Real Live Work having been accomplished today, I resumed work on AGROS.

Much frustration with initialization being interrupted by a data abort in one place or another, and stack traces being inconvenient on these ARM beasties.

There was one new initialization function that I hadn't gotten around to calling, and a sentinel value that I'd moved from the assembly-language initialization file to the linker script template, putting it in the wrong place and causing all initialized data to be initialized one word off from where it should be....

Well, there's progress now. It just managed to announce that the monitor was starting... before leaping gracefully to the instruction abort handler.

Anyway, there's Progress.

Once I get it behaving itself, there'll be another round of headaches as I redefine the task structure to be more friendly to supporting multiple architectures. (Got to change the C definition, and then go through the asembly code that also uses it and update all the offsets to match... but thereafter it should be well and truly nailed down.)

Feeling the need to get away from my desk this afternoon, I wandered into TechShop to see what was new the past couple of months.

Well, various things have changed. The most conspicuous change was the disappearance of the big CNC machining center with the frozen spindle (and, if memory serves, its turning-center counterpart).

The space formerly occupied by the machining center now contained some sort of framework. Sort of cube-ish. Vaguely 10-feet-on-a-side-ish. Could it be...?

Go take a closer look. Yup. Things that go up and down and back and forth on rails, with a wire strung between them, and a big spring for tensioning the wire.

It's a humongous CNC hot-wire foam-cutting machine.

Which is kind of a nifty thing to have, I guess, if you ever find yourself wanting to carve large slabs of foam into, say, several-foot-long airfoil shapes in preparation for wrapping carbon-fiber cloth around them.

Well, I needed to get my ARM gcc cross-compiler configuration in shape for actually building AGROS. I figured I might as well work with version 4.2.2, as long as I had it installed... but it didn't have the right library variations built (I need libgcc.a with soft floating point and interworking, and preferably built for thumb mode).

So, back to reconfiguring and rebuilding and fiddling and Googling, until finally I find myself with a nice assortment of supported architecture variants under /usr/local/lib/gcc/arm-elf/4.2.2/ and the only link errors I get are related to dangling references in my source code.

Here, recorded for posterity, is the process (assuming binutils and gcc sources are already unpacked in /usr/src):

At least, I think it is. Still got a few hours of tinkering before I'll have a believed-good binary... then I'll load it onto the development board and see if it actually runs, whether my interrupt wrappers play nice with thumb mode and interworking, and all that sort of stuff.

Still need to review Makefile rules; the Makefile generated by my configuration program works, but builds the dependency list whether it needs to or not.

Update: Snazzle fratz! I got a clean build (through somewhat unclean measures, which will have to be tidied up later). Used the JTAG pod to load the image onto the LPC2148 devel board. Got a debugger malfunction.

A bit of meta-debugging later, and I find that the JTAG pod isn't working because TCK is only getting driven halfway low... which in turn is because, despite RTCK being pulled properly low during reset, on coming out of reset TCK/P1.29 gets driven high.

Moomph.

Well... hm. I suppose it could be a software problem. I surmise that, when the chip comes out of reset, it doesn't know yet that the JTAG pod plans to take over, and so it starts executing the image it finds in flash. If my initialization code has gotten goofed up, and is repurposing the JTAG port as GPIO, with P1.29 as an output driven high, then I guess that would explain the problem.

So, I guess the next thing to try is loading a different image via the serial port, given that ISP mode bypasses the installed application right out of reset.

Saturday, 23 February 2008

As the restructuring of AGROS proceeds, and I approach the moment when it'll finally build again, ever more complications arise.

The latest one has to do with the GCC support library for ARM targets.

There are several variations of the ARM architecture: little-endian vs. big-endian, hardware floating point or not, Thumb instruction set supported or not.

Accordingly, there are many versions of the support library: (little-endian vs. big-endian) times (hard-float vs. soft-float) times (pure ARM vs. pure Thumb vs. ARM with interworking support vs. Thumb with interworking support).

The default build of GCC-for-ARM only includes the library for little-endian, pure ARM, with hardware floating point.

I want to build AGROS for little-endian (for the target at hand, at least), Thumb model with interworking, and software floating point.

So, I end up rummaging around until I find, in the Cygwin version of the cross-development toolchain, something that seems to be approximately right: software FP and interworking, at least, and the only link errors now relate to my code, not to missing support functions or incorrect formats.

It does look like a minimal AGROS app, with a few device drivers and some debug features included, may come in around 12K when built for a Thumb target (I'm counting on the magic interwork feature to take care of important details... and, once I have a clean build, I'll have to see how interrupts and task switching come out). Won't fit in an LPC2101, but it'll fit in a 2102, and the 2103 ($3 in hundreds) is looking downright roomy with its 32K flash / 8K RAM.

Getting back to the subject of that support library... getting the correct version of it in the right place so the linker will use it (I'm invoking ld directly, to avoid dragging in bunches of C libraries that wouldn't work in the target environment) is sure to be a world-class headache when I unleash this thing upon an unsuspecting world. Mayhap I really should be going through gcc to get to the linker... which leaves only the problem of ensuring that the user has a toolchain that includes the library versions to support soft floating point and interworking.

Thursday, 21 February 2008

Average score for this quiz during February: 71.0%Average score since September 18, 2007: 71.0%

Young whippersnapper Lex only got 86.7%. And here I thought he was supposed to be ahead of me in the civics department!

(Yeah, I did a fair amount of guessing, but when I can eliminate three out of five options on a multiple-choice question, and one of the remaining two just doesn't sound right, the odds aren't too bad.)

Tuesday, 19 February 2008

Just keeping busy with one thing and another, and not finding time for blogging.

The massive restructuring of AGROS is proceeding, in between working on actual work. I think I've come up with a decent directory structure, and the configuration program is coming together. Still need to massage the Makefile generation a bit, and make the configuration GUI more coherent (as well as taking care of fiddly details like allowing the user to save a configuration, for future editing).

I just got bitten by another of those Ruby-is-not-C details:

if (avail_vecs & (1 << i))

...is a perfectly good test in C, with the body of the if statement being executed if the bit was set. In Ruby, though, this always evaluates as true, barring some error in the data type of avail_vecs or i.

D'oh! No wonder all the interrupt handlers were being assigned vector 0.

Thursday, 07 February 2008

Well, now Romney has dropped out, leaving only Half-a-bee running against McCain (oh, and the real fringe candidates, too).

Nothing became him in the campaign like the leaving of it. If he'd campaigned the way he conceded, he'd surely have done a lot better.

Anyway, he expressed his determination, shared with McCain, to Get Osama.

C'mon, guys! Osama's been dead for months. Finding the bones ain't much of a priority.

Earlier, in response to some of McCain's anti-business populism, Romney made some remark to the effect that McCain doesn't have the right kind of experience to run the economy. Er, Mitt? The President doesn't run the economy. The economy goes bounding off on its own. The President has some strings he can pull, but there's no Big Economic Steering Wheel in the Oval Office.

Monday, 04 February 2008

Yesterday having been SupperdishSuperdishSuperbowl Sunday, I had plans to lead the usual hike out at the coast, in search of elephant seals.

Around midweek, the weather forecast was still for rain on Saturday, clearing for Sunday.

Well, Saturday's rain waited until Sunday to show up... though, just at the time the carpools would have been gathering, there was a patch of sunshine.

Sunday turned into one of those soggy-outdoors, stay-dry-indoors sort of days. (No, I didn't spend it watching TV. What is this "feetballs" of which you speak?)

Now it's Monday, and gloriously clear and sunny. Maybe I'll try the coastal hike again on the 16th, when Pescadero Phineas comes out of the ocean, and, if he sees his shadow, we get four more weeks of winter.

Sunday, 03 February 2008

A couple of months ago, I took a vendor survey, and, unbeknownst to me, thus got my name put in the hat for a drawing. The drawing being held, I turned out to be the winner of a rather nice Newegg.com gift certificate.

Well, I dithered over what to get... a bunch of little fiddly bits, or a grand (well, medium-small, actually) indulgence?

I finally settled on A Bigger Monitor. A few years back, I'd replaced my 17" CRT with a 17" LCD, and almost immediately wished I'd spent the extra cash on a 19". Now, with the prices having come down quite a bit, and the gift certificate....

I ended up adding some of my own money, and getting a Benq FP222W H - a 22" widescreen, 1680x1050 pixels, with VGA, DVI, and HDMI inputs.

I've got it hooked up to the workstation using 506, which works pretty nicely. Good sharp display and all that. The server connects to the VGA port via the old KVM switch, and a still-hypothetical tinkerbox / Windows machine can use the HDMI port (via adapter cable), allowing me to switch among the two digital inputs and the switched analog input with the monitor's input-select button.

Minor quibbles:

Between the stand and the location of my monitor shelf, the center of this monitor ends up slightly above eye level, and the monitor only tilts forward a little way. Thus, I have a slight "looking up" angle at the top of the screen, which causes grays to come out slightly tinted toward the top. Making slight adjustments to the color in the X server setting utility gets this to a non-distracting level.

It's got "modes" - Standard, Movie, Dynamics, and Photo - which aren't actually explained in the documentation. They sure 'nuff change the appearance of the display, and Movie and Photo cause some text to look funny. I'd really like to know what these modes are doing... though in fact Standard seems to be the most generally suitable of the lot.

The control buttons are arranged inconspicuously along the left edge... as are the labels for them. The placement of my monitor allows access to the edge for a finger, but not for my head, so I have to feel for the buttons, count positions, and try to remember which one is which.

All this is minor stuff. It's a great display for the money.

Now I can, for example, display a B-size schematic on the screen, and make sense of it (though I'll typically still need to zoom in a notch for actual working), and display two letter-size pages side-by-side in Acrobat.

Many web sites still display in a scrawny little column optimized for a 640-pixel-wide screen, though.

Oh, and X-Plane seems to have a problem rendering onto a wide-format display. It loses the corners of the cockpit. (This seems to persist in the version 9 beta.) The scenery is great, but there's a little too much of it visible....