Software blues.

Just done a little light reading for relaxation - a guide to optimising x86 assembler code... it is both amazing and appalling how much hardware there is inside these poor processors to try to deal with the awful code they're given to run by compilers.

It's insane. Rather than have programmers write competent code - which, I keep having to remind myself, is actually quite easy - we've ended up in a world where nearly all programmers write complete garbage that includes masses of other complete garbage that other equally-incompetent garbage-mongers have gathered together, and all this offensively incompetent shite gets compiled to a vast swamp of instructions that are then examined by the hardware, broken up into smaller micro instructions and re-ordered into some kind of sense before actually getting executed... but no matter how impressive that hardware is - there are typically tens of billions of examples of this happening in each and every computer in every second - it doesn't make the whole ridiculous process any less inefficient... and all this hardware and furious activity burns electricity and generates waste heat.

Feel your computer - is it warm? hot? Unless you're doing something that actually needs lots of computation (3D games count) that heat is almost entirely generated by programmers being stupid.

Why is this all so inefficient? Mainly because the languages and tools programmers prefer to use are chosen *not* by any logical, rational process but by the whims of fucking fashion by programmers with no idea of what is actually going on under the hood and no interest in finding out.

And they'll tell you this doesn't matter - hell! they tell *me* it doesn't matter and I know exactly how full of shit they are - but it matters to the extent that at the present moment the IT industry accounts for about 2% of all the energy used in the world. That's about the same as the entire aviation industry.

Think about that for a second... it should be such a small fraction that it can't be bloody measured easily. Instead it's a major source of wasted energy and pollution... and this energy isn't used because it needs to be used; not at all. This energy is almost entirely wasted, and it's wasted because programmers are so fucking useless. And they're not getting more efficient either, quite the reverse. All the time they find new ways to add layers of inefficiency to everything.

Programming constantly moves away from energy efficiency towards less efficient languages and tools. Programmers actively choose not to use efficient languages and expect everyone to buy faster and faster computers to keep up with the growth of their inefficiency. But this is hardly new, it was old news thirty years ago... for most of my life I've watched them at it with a kind of shocked disbelief... knowing how to write efficient software easily leaves you wondering what the hell it is about getting things wrong that other programmers find so appealing. It's harder to do it badly.

Reading this status has probably used about a million times as much energy as it should have done, and would have done if all the programmers involved in writing the code involved were skilled... the sad fact is most programmers aren't just bad but completely fucking clueless. So monumentally incompetent that there is no way anyone outside the IT industry will ever understand how fucking thick and clueless they are - most of you just don't have any experience of anything being done as badly as programmers do things. They make cowboy builders look like paragons of efficient competence. Saying they build structures like Heath-Robinson contraptions is ridiculously understating the absurdity of their habits.

Ah, fuck it. This is pointless... It's our energy and money they're wasting, and it's our planet they're raping, but nothing I say is going to stop that or make even a single one of the lazy bastards change their ways or admit to their crimes. And make no mistake - they are crimes. I just hope that one day they're recognised as such and the software industry becomes accountable for the energy they waste.

Now, programmers will be reading this and bursting with asinine remarks in defence of bloat and crud - understand clearly that I don't give a shit what miserable justifications you present; I've heard them all, and shown them all as the tripe they are countless times... what I'm left with is the sense of utter shame that people outside the IT industry confuse what I do with what you do.

Windows 7

So, in a rare - one might even say unprecedented - moment of enthusiastic optimism I ordered a copy of Windows 7 (ultimate edition) from Amazon. After all, it couldn't possibly be as awful as Vista.

After forking out £140 and waiting a couple of days, this arrived:



Gods, it comes to something when even Microsoft can't afford a decent box... Hang on - light dawns - this is a pirate! I suppose that's what you get when you order software from:



Gah... I spend minutes of my life writing invective and telling them that if I wanted pirated software I would get it myself, not spend £140 on it. I wax lyrical. I am prepared for a long drawn out fight with some faceless corporation. And then you know what they go and do? Refund me in full. What sort of nasty, evil, twisted company does that? After Sue has gone to the trouble of finding that nice picture an' all...

Sheesh. You just can't trust some people.

Yahoo toolbar

No! I do not want to install your bastard toolbar! Stop asking me! Just bugger off with your "A new Java update is available and by the way, would you like to install the Yahoo Toolbar?" or your "A new AVG update is available and by the way, would you like to install the Yahoo Toolbar?" or your [deleted] garbage [deleted] bastard [deleted] software that installs that miserable toolbar... [deleted]

I wish there was a way to tell those [deleted] [deleted] at Yahoo to stop spamming the [deleted] universe with their accursed toolbar. Wankers...

I may have been going on a bit about this at work, because after one grump a chorus of "They fuck you with the toolbar" was heard...

Engineering

So, after much rummaging about I have got this bastard long-running project to a state where it's worth taking it to the customer and plugging it into their mass spectrometer hardware, where it's basically going to be responsible for controlling the timing, driving various electrostatic lenses and acquiring data.

The design has an FPGA containing a reduced version of the R3220 (my custom 32-bit RISC processor) and about a dozen custom peripherals, it's running a fairly complicated embedded application (written entirely in assembler) consisting of 33 source files and the damned thing is responsible for some fairly hairy real-time data acquisition in a noisy environment.

As well as the device itself there are various development tools that have been written to support the design, all in all some tens of thousands of lines of code. All of which had to work and none of which had actually been tested on the machine.

And to cut to the chase, after we'd set some parameters (there are thirty-odd interface registers to play with up) and I'd restored a couple of lines that had been accidentally edited to death, it was controlling the hardware and we were looking at mass peaks... In other words, nearly everything worked first time, and the bit that didn't just required a few seconds of editing to fix.

The thing is, a programmer would regard writing so much code, and in assembler, and having it work virtually straight away as success beyond their wildest dreams, if not as being completely impossible. Me? I'm actually slightly pissed off - if I hadn't made a tired mistake tidying up a file (unnecessarily, at that) the bloody thing would have been right first time... As usual. Bugger!

Still, given that the processor was designed in only ten days and it's lovely to use, is kicking the shit out of a Nios2 performance wise and has behaved perfectly I suppose I'm allowed a small cackle of victory.

Mu-haha! MU-ha-ha-ha-oh... Sorry. Bit carried away there.

[Update on the "kicking the shit out of a Nios2" comment.

The R3220 (clocked at 30MHz) is handling more data in 5uS than the Nios2 (clocked at 70MHz) managed to handle in 80uS, so as far as the application goes the R3220 is a factor of 36 times faster, or so.

Much of this performance margin is down to the efficiency of the code they are running, of course, thought it should be noted that the Nios2 was running highly optimised C, code that was written and tweaked over a period of months. The R3220 is running hand assembler written over a period of hours and not optimised at all - there was no need.

The Nios2 system also had a lot of hardware support for functions that the R3220 system just does in software, because it can, so the performance factor is arguably higher even than that...]

Great Myths of the IT Industry

• Abstraction is invariably a good thing

• Efficiency doesn't matter

• You can be a competent programmer without understanding hardware, low-level programming, logic, anything much

• Bugs are inevitable

Windoze

I must put on record that I was being unfair to Herve today.

I accused him of being the flying dutchman of the laptop world, forever doomed to spend his time running Windows 95 - but he quickly corrected me - he actually runs Windows 98 SE and is proud of it...

You know, I'm not entirely sure that using Windows 98, even the second editon, accurately portrays the dynamic, thrusting and forward-thinking aspects of Design Design as a high-technology design company. Bet he still uses lead in his solder...

[Furtively crem returns to the assembler source for an FPGA processor he's tweaking. It is clearly a variation on a Z80...]

Panes

I've just put the finishing touches to some demo code for an ARM-based operator interface panel we've designed, and it's sitting in front of me as I type with a few windows bouncing about at frame-rate in the foreground and a Mandelbrot being rendered in the background. Every now and then another view of the Mandelbrot drifts past in a stately fashion (frame-locked, of course) and if I touch the screen it pops up another window that follows the touch about under my finger, with a ghostly lattice of lines being drawn overlayed on the background to show the outlines of the various regions of the screen that are being rendered as the window position changes... It looks beautiful, as graphics that change at frame-rate usually do.

I'd include a picture, but a static photo really doesn't do it justice and I can't be bothered to work out how to include video at my time of life.

The hardware is a Cirrus ARM processor that has a fair number of peripherals on chip, including the LCD display driver. That single chip and a couple of SDRAMs, a FLASH and some glue is all that's involved, hardware-wise. The software - a complete graphical windows system and enough of an OS to run operator interface style applications - (in total about 12,000 lines of C) was all written from scratch by yours truly in about five weeks...

Since all of this is written in C and compiled with GCC (unusually for me there's not a line of assembler in there, aside from the device boot code) and it still runs fast enough on a 200MHz ARM to look bloody impressive I find myself wondering how the hell programmers manage to take hardware like this and make it appear as slow and crappy as all the ARM-based personal organisers out there look.

What the hell are they doing to slow them down?

It's amazing how bloody awful the demonstration code that Cirrus supply for their own device is, it makes the thing look like a CP/M machine struggling to write to a terminal.

This particular chip has blitter and line-drawing hardware that I haven't used, since I wanted the graphics code to be pretty generic. The demo code from Cirrus uses the blitter and still manages to run like a slug that has overdosed on valium. Gah...

The incompetence that's endemic in this industry depresses me, it really does :(

Ouch

So, today I'm working on a new industrial input card for our logger family. Lots of 0..20mA inputs and some switched outputs, usual sort of stuff.

For added interest it has two AVR processors. A Mega128 sitting down near ground doing most of the work (handling the comms, multplexing inputs, driving the ADC and so on) and a Mega8 sitting up near the supply positive rail watching the current drawn on the outputs and turning them off if the current exceeds preset limits. These two talk to each other through a level shifting serial link.

Doing it with two processors is both the cheapest and neatest solution to the problem, the alternative would be to have lots of level shifting hardware for the various outputs and current sensing lines, which would involve much more hardware and be less accurate with it.

But - there had to be a but - it does mean that I have to simultaneously develop software for two processors that are running at different grounds, and also one of them needs a software emulated serial port because the hardware ones are busy doing other comms jobs, hence there is some slightly awkward software and the programming requires isolated AVR programming/debugging interfaces. Well, I have those, so no problem.

Hah. The gods don't like cunning designs.

I blow the first Mega8 up when the bloody ground clip of a 'scope probe unclips itself and wanders across the PCB, managing to touch one of the AVR I/O pins. Normally this wouldn't be a problem, but it picks the AVR that has its ground up at +20V or so. It doesn't like having one of its pins dragged down to -20V (as it sees things) so bye-bye and off to silicon heaven it goes.

Much gallic muttering ensues as Herve replaces it.

A few hours later I'm busy working on the serial comms between the two processors when the 'scope probe slips out of my hand. It misses the board and I have a moment of relief until I realise it's heading for the exposed PCB of the isolated AVR programmer... It lands on it and there is a very slight, but clearly audible, click as the earthed shield of the probe makes contact with some component or other on the programmer.

Of course, it doesn't do this with the programmer that's sitting at ground, it picked the programmer that was connected to the positive rail and which was sitting with its ground at +20V or so, and that click signifies the end of that particular programmer. And, of course, the end of the bloody AVR it was connected to as well.

This happened at 10:30 pm, and at about 11:30 pm there was even more gallic muttering as Herve (dragged back into work) replaced the Mega8 again. This was accompanied by a fair bit of my own muttering as I repaired the AVR programmer.

About an hour and a half later the other AVR, which had been sitting down at ground and minding its own business, stopped talking to the debugger. After a bit of investigation it turned out that one of its I/O pins was damaged at some point in the preceeding fiasco and had quietly rotted.

Think I'll wait 'till tomorrow before I tell Herve he's got to replace the Mega128 now.

I'm starting to think the gods really don't like this design...

"It's alive!"

Finished the complete SoC (system on chip) design for this 'ere project, which I think is quite impressive in only a couple of weeks given how complicated it all turned out to be.

I can see me using verilog in preference to VHDL in future, I've found it fairly nice to use. There was always something a little counter-intuitive about VHDL as far as I was concerned...

And now onward and downward - the application software for it.

R3220 microprocessor

I've been busy designing some FPGA hardware recently, and part of it uses a lovely little 32-bit microprocessor I designed a while back. I've been meaning to publish the source for it for some time, but since the contract for this design means I have to provide the source to the customer and even [shudder] document the thing to some extent I may as well take the opportunity to publish it now.

I've called it the R3220, those of a technical nature can assume this name derives from the fact it's a 32-bit RISC with about 20 instructions (while being completely oblivious of the "saturday night special" connection, I suspect).

The performance is fairly respectable, I'm using it to replace an existing NIOS II based design because the NIOS based design wasn't anywhere near fast enough.

As a guide the R3220 CPU uses between 600 and 1700 LE's in a Cyclone II array, so a complete system with one CPU with several peripherals only takes up ~12% of a Cyclone II EP2C20.

For fun I put four of these processors in the array (quad-core, anyone?) and it took up about 30% of the available logic. Since they can share memory without losing any performance it's actually not a bad idea to think in terms of more than one CPU for some applications, though I don't think I need to do it for this one.

(To facilitate the use of dual-port memory, which is common in gate arrays, the reset vector is configurable, so you can have two processors using the same memory block but not executing the same part of it. This incurs no extra delay so both will run at full speed.)

The verilog source, an example SOC design including various peripherals, a simple SDRAM controller and the r32 assembler can be found here -http://www.desdes.com/products/r3220/index.htm - note that this is the first verilog I've written so the style across the sources is inconsistent, I'm still finding my feet with the language. I'm more used to using VHDL, though I have to say I'm finding it a lot easier to write in verilog than VHDL, there's something about the 'feel' of verilog that I prefer.

This isn't the first processor I've designed and hidden away inside a gate array, but most of them have been too dedicated to a specific task to be worth discussing. This one is a nice general-purpose device to programme (in assembler, that is. If you're stuck using C then pick one of the MIPS implementations) and given how little time it took to develop (about ten days) I have to say I'm very pleased with it - it's a shame that so many embedded designers are stuck in the whole turgid morass of the linux/gcc/c bloatware mindset and can't play about like this, they really don't know how much fun they're missing...

For those who care it's a fairly classic load/store risc with a couple of unusual features. I designed it to have lots of registers (128) so I can dedicate them to interrupt handlers, and it has a nice touch that allows for 7 or 14-bit immediate values in the single-cycle instructions but also a full 32-bit immediate value can be used for all operations with only a single cycle penalty - it achieves this by taking one of the 7-bit immediate values, (-64), and using it as a flag to request that the next instruction word be used as a 32-bit immediate instead.

It has a reasonable addressing mode set with all the usual pre and post inc/dec indexed operations. The address is formed by taking a pointer register, which can be any of the 128 registers (there is no distinction between them) and optionally adding a 7-bit signed offset value. This address can be written back to the index register if required (with no extra delay) which allows auto inc/dec modes. The fact that the memory address used can be the register address or the register+offset means that there is full support for auto inc and dec with pre inc/dec and post inc/dec addresses. So any sort of stack you like, basically.

Every instruction is conditional with an option to update the flags. Sounds like an ARM, I suppose, though I first designed a CPU that did this many years before the ARM appeared so saying I got the idea from ARM might just earn you a thick ear [grin]. In fact, the bit field layout in this instruction set is remarkably similar to one of my designs from the 70's, though I was trying to outdo the PDP-11 back then so the that design had a particularly gothic and slow addressing mode set. [shudder]

The condition codes operate by having a 4-bit field that selects individual flags in the status register and then determining if the instruction should be executed using the state of the selected flag.

Doing that uses 14 of the 16 possible condition codes to handle 7 status flag bits. Of the two remaining codes one is ALWAYS which means always execute, of course, and the last is interesting - I've called it 'LOCK' and it always executes the instruction, the same as ALWAYS, but it also prevents the instruction from being interrupted. Once the processor has been put into LOCK mode it remains in LOCK mode until it executes an instruction with the ALWAYS condition code. This allows sections of code to be made 'atomic' without any overhead, and those sections can include conditional code.

Lock mode also forces locked RMW bus cycles where the bus architecture supports them, which makes it beautiful for implementing semaphores, etc. It's all much nicer than having to either flip interrupt enable/disable flags around critical bits of code or use peculiar instructions.

Another use of LOCK is in function entry/exit code, to make the stacking/unstacking of link registers etc safe. This can be handled transparently by the development tools.

I designed it to be agile, so interrupts have to be entered and exited quickly, and to that end it supports multiple interrupt levels with priority encoding on each of those for multiple interrupt sources at each level. The CPU outputs acknowledge signals when taking an interrupt vector so there are no delays while the handler has to manage the interrupt controller.

For speed it uses dedicated link registers instead of stacking the return address/state during interrupt cycles, and cleverly uses the particular link register invoked by the 'return' instruction to signal the end of that interrupt level to the interrupt controller. This means interrupt handlers are exactly as fast as calls and yet don't require any special entry/exit instructions.

Something else that's nice, though obvious, is that because you can load/store values directly to the status register and the condition codes use single bit testing peripherals can to organise their status flags so it's meaningful for the device handler software to load the peripheral's status register directly into the CPU status register and then use conditional instruction execution to determine how the flow should proceed. ie:


ld status,uart_status[peripherals]

call s0t RxByteHandler ; The s0t means execute this if status register bit 0 is true.
call s1t TxByteHandler ; The s1t means execute this if status register bit 1 is true.

The s0t, s1t (etc) are aliases for the conditions C, Z, etc.


This process is helped by the fact that the handers can preserve the status flags (they're saved in the link register and can be loaded back or not as required when returning).

The assembler is pretty powerful, as well as all the usual stuff you'd expect it handles allocating link registers automatically so the user doesn't have to know or care what they are. Thanks are due to a certain Ste for making me do this with his damned "It can't be that difficult" and "I can't see the problem" attitude.

In summary it's a nice processor, amazingly nice considering how little time it took to design. I absolutely love being in a position where I can design stuff like this and get paid for doing it...

Another interesting problem at work today.

We make electronically controlled beds for hospitals, they have achieved a certain notoriety hereabouts for occasionally exploding (I say occasionally because they rarely do it twice. That would indeed be excessive. Once is hardly worth mentioning, I feel).

A recent batch of 25 turned out to have four failures, when moved up and down they would not remain flat, basically the actuator at the foot end of the bed was not being controlled correctly - it was not moving as far as the actuator at the head end, only about 60% of the distance. The four were so consistent (all showing nearly the same degree of tilt) that we decided it pretty well had to be a software issue, hard as that was to explain.

But it wasn't - let me digress back a few years to the start of the project:

When the first bed hardware (frame and actuators) arrived for us to design the control electronics it came with a example mattress. These medical mattresses are not as you might expect - designed with disease control in mind they are waterproof and made of materials that can survive being steam cleaned. Basically they're dense and covered with some polymer that resembles rubber. And they are supplied, as most things are, in a plastic cover.

I must stress that in the eternal war of man against mattress these may be regarded as special forces, highly trained and motivated opponents. If you are asking yourself "what war?" then you are either damned lucky or have not yet made love in an uncooperative bed. But that's another saga.

So, picture the scene - we have a dirty-great mattress standing up on end against a wall with a polythene cover that needs to be removed. Along comes an unsuspecting Leon, I guess he winds up doing this because he just happened to be tall enough to reach the top of the mattress. As the only other person involved who is tall enough to have done this I must now give thanks to the gods of laziness who were smiling upon me on this occasion, because Leon walked over to the mattress as I was getting to my feet, grabbed the polythene bag near the top of the mattress and tugged it off with a manly flourish.

It was probably the last manly flourish or tugging off he managed for some time, because as he did this the friction between the polythene and the mattress built up a massive static charge which then discharged between the centre of the mattress and the part of Leon that happened to be closest to it as he lent backwards... The flash was visible in a brightly lit room, and the crack, while not exactly thunder, certainly wasn't a tiny little "click!" either... Leon clutched at his groin, managed a strangled squeak and collapsed. The mattress then celebrated its victory over humanity by slowly collapsing on top of him, which was followed by a general collapse of everyone who'd witnessed this event...

"You... Bastards..." Leon managed to say, after some considerable time had elapsed. "Get this... this... THING... off me"

Well, actually he probably said it a few times before we noticed, we were far too busy trying to breathe. Excessive laughter can be dangerous...

Anyway, the upshot of this is that removing the bags from these bloody mattresses is deadly. You don't do it fast. Given the chance you don't do it at all, you give the mattress in its bag to some poor unsuspecting suckers and let them find out for themselves, as we did.

"Do you know what happens if you remove the bag quickly?" I asked the supplier.
"Don't" they said.

"You don't know?"
"No - don't remove the bag quickly"

[pause]

"Thanks. I'll tell Leon that."

Knowing this at the start I designed the electronics with more of an eye to static protection than is normal, and it was successful because we have built a fair number of these beds without further problems (though other equipment the beds take a dislike to has been destroyed by it, they don't always choose the kinetic energy weapon option).

So, what about these four failing beds? Well, yep - static damage. They'd been built, calibrated (to define the range of movement allowed, etc), and then the mattresses had been fitted, only this time they'd done four of them differently - someone had put the mattress on the bed before pulling the bag off and also done this in such a way (yet to be determined) that the discharge was through the same actuator of all four beds. This then overpowered and destroyed a filter component (ironically something that was only there to protect the rest of the electronics from this very static) and did so in almost the same way on all four beds. It went from looking like a ~10nF capacitance to resembling a ~25K resistance, with all four having more or less the same resistance when dead... This added resistance then loaded the actuator's position sense pot, destroying the linearity, so the bed control loop thought the beds were flat when they weren't.

This input protection laughs at human-body model static discharges, you understand. Eats them for breakfast, so gods alone know how much energy is involved with these combat mattresses.

I now suspect this is the real reason why nurses are forever warning people not to sit on the beds during hospital visits. They're trying to do us all a favour, they know the evil forces that lurk beneath that innocent looking exterior. Be afraid. Be very afraid...

Interesting, eh? What? Well I didn't say it was very interesting... Oh, well, suit yourselves...

Wrong.

This is a packet of coffee, such as we use at work...



This is a packet of instant porridge.



And this is both of them carelessly placed on the same shelf at work.



'nuff said, I think...

Uh-oh...

I've been working on a fairly complicated data capture system of late, and major parts of this system are the transceivers which are responsible for talking to sensors over a wireless link. Each transceiver can handle a couple of hundred sensors, so they're fairly busy and (trust me on this) fairly complicated...

All the parts of this system have unique serial numbers, which the various protocols use to identify them. These serial numbers are really just that - numbers - but in order to reduce the scope for confusion and detect errors I've encoded them as a set of characters. One example is JM99-K634.

"Why is he boring us with all this?" I hear you ask.

Because purely by chance, the system has just decided to use the identifier AE35 for a transceiver... Fans of 2001 will understand that this is not auspicious. I think I'll pretend that one doesn't exist...

Confused?

Silicon lifeforms

Interspersed with the general grumbling today was: "The more legs a chip has, the more like the luggage it behaves..."

Modems

A month ago I was writing software for a bloody modem that didn't want to behave and I thought I was pissed off. Hah. A month ago I didn't know what pissed off really meant...

Somehow I've let myself get talked into writing the software for a complete piece of shite, yet again involving a cellular modem that doesn't want to behave, and I'm utterly sick of the whole fucking process. This project was sold to me as being a small change to an existing product, something that would only take a couple of days to do, whereas it actually turns out to be a major change with all sorts of dire consequences and awkward problems for the software to overcome. There's no way on earth I'd have agreed to do this if I hadn't been comprehensively mislead about what was going to be involved. The hardware is horrible, the modem is horrible and I'm really not in the fucking mood to wade through this sort of unreliable crap again.

What really pisses me off is that I'm now having to turn away other designs in order to make time for this joke, and I know it's not got a cat in hell's chance of ever working properly. I feel like I'm pouring my life down the fucking drain...

Programmers (again, again...)

Quote of the day:

"In my darker moments I think I could print out some of my source code, eat the listing, digest it and then shit something which would have more programming competence than most of the programmers I've met... The rest of the time I think that any sort of roughage would do"

I wasn't in a good mood. After a week long battle with some anonymous programmer's bugs in a modem, or in the network, whatever, I find myself moving onto the next project and guess what that involves? Chasing problems with another fucking modem.




"Quick - blow your raspberry!"

"Thhhuuruurruurrrppp... ThuuUUUUuUuUURRRRRPPPP! THHHURRRRRRRRRRRRRRRRRPPPPHHH!"

Lurgy

Having just tried this 'ere winter vomiting disease out I can say without any doubt that it is not worth having - just say "NeuuurrrggGGggghh-h-h-h"

Busy as hell and two days down the drain feeling as bad as I ever have, urgh. Normal grumpyness will be resumed as soon as I can work up the energy...

Oh, speaking of energy we found out last week a certain Tokamak research reactor is currently off-line because some of our electronics failed[1], oops. And me a strong advocate of nuclear fusion. Bollocks... Not a good week, considering :(

[1] Not our fault, just a batch of shitty capacitors that fail when used well within spec. I suspect even Richard could manage to blow one of these useless bastards up.

Ah, the sweet innocence of newly stuffed boards...

... I love it. That happy and carefree feeling the first PCB's of a new project have when they arrive on the desk, populated and ready but so far unsullied by the ravages of software. I like to enjoy a moment of quiet contemplation with them, a brief interlude of peace and sanity before battle commences.

But it can't last, and - oh - how quickly they lose that innocence and acquire an air of malevolent cunning and sublime evilness when you start having to make the damned things work.

Cover me, I'm going in!

[Five processors to programme, the boards arrive after the deadline has already elapsed, estimated six weeks of software required, it's dark and I'm wearing sunglasses]

"Then take the fucking sunglasses off, crem"

"Oh. Sorry"

Crapacitance

Today Richard demonstrated he can't even blow up a capacitor properly.

"We're going to blow up a capacitor, want to watch?"

Now, anyone else would ask "why?" at this point, but experience suggests that I wouldn't like the answer, so after due consideration I downed tools and followed him. A very alert observer might have noticed the pause.

In his room he'd already attached wires to the capacitor, which was potted inside a box as part of some device or other. I suppose the idea was to see how safe the device was if this capacitor ever decided to explode in normal use, but as I say, I didn't ask.

A power supply was attached, connected backwards across the poor cap and switched on. Cue rapid exit from room... The power supply quickly ramped up to about 4 volts and about 3 amps.

"Twelve watts? It's not going to last long" I opined, from the doorway.

"About... now, I'd expect" I ventured, after several seconds had passed with no visible result.

"Any time now..."

"Soon..."

After about a minute at 12W I wandered in and wound up the supply up to full power, which was about 20W. People started to cower...

A minute or so passes, with nothing visible happening.

"Twenty watts? I don't believe it..."

I wander over to the device and feel it - it's distinctly warm... No smoke, but I do start to smell a rat - "You did disconnect the cap from the rest of the circuit, didn't you?"

"Ah..."

Gah... Bloody capacitor's probably laughing itself silly while the rest of the circuit dumps all the power.

Who watches the watches?

Richard has just, in passing, mentioned that his watch claims to have 27 jewels.

"We're paying him too much"

"We're paying him?"

[pause]

"Hang on, it can't have 27 jewels"

"Why ze 'ell not?"

"Well, they're bearings aren't they? One at each end of a shaft? How the hell does it manage to have an odd number of the damned things?"

Richard is currently attacking the poor thing with a screwdriver...

He'd be better off clicking here...