alexhornung.com

Logitech diNovo Edge

2011-01-11T00:00:00+00:00

Since May 2009 I'm a proud owner of a Logitech diNovo Edge keyboard. It's really a great keyboard if you are anything like me and can't be bothered with even more cables. What I also love about it is the fact that it doesn't have a numpad. Never in my life have I used it, and I just don't think I ever will. But all good things come to an end, or so it seems. A few months ago it started to behave strangely.

Initially the charging light would flash like crazy when charging it instead of just blinking normally. Some time after that it started disconnecting / turning off randomly and linux wouldn't recognize it (or rather it wouldn't pair with the dongle). Very annoying.

So I decided to have a go at it and see if it was anything fixable. At a first glance there are no screws anywhere. So how do you open this cute keyboard up?

Yes... you essentially need to peel the orange surface off, which is not an easy task, since the glue is quite strong. It also makes you wonder how it'll fit back together... Once the orange surfae is removed, you finally see the screws!

Not a good sign, all those glue remnants... But now it is finally open:

On this photo the problem is already solved. It seems like the cable that goes from the battery (the white block on the bottom right part) to the board on the left, the black one, is way too stretched. It was hooked into another hook further down, stretching it out completely. This is quite the disappointment; such a nice design but nobody thought about adding a centimetre more of that cable... My guess is that, since the keyboard is so thin, that it flexes quite easily during normal use and the cable eventually ruptured. If you are lucky you can just pull the cable out of the hooks that hold it in place; otherwise you have to completely replace that cable.

Putting the keyboard back together was probably the hardest part... especially aligning the orange surface correctly. But, as it turns out, the glue is strong enough to be reused without any major problems.

Overall I'm a bit disappointed that such a simple design flaw made it into an otherwise outstanding design, but at least it's fixable.

Cheap Multimeters

2010-10-09T00:00:00+01:00

Many people buy their multimeters on eBay or similar sites, usually because they are much cheaper there. It is understandable that someone doesn't want to spend over 100 EUR/GBP for a multimeter when there are 20 EUR/GBP multimeters and even cheaper on eBay with, supposedly, the same features. Many years ago I bought one of these cheap eBay multimeters, too: a HoldPeak HP-6870; it has all the features one could hope for, including capacitance and inductance measurement. So why am I saying you shouldn't go for similar items?

First off, here is a photo of the multimeter in question. As can be seen it's a manual range multimeter with tons of 'features', and according to the top cover, it's even rated 'CAT II'.

Since I finally decided to recycle the multimeter, I opened it up to get a closer look at what I was throwing away. Below is a picture of the front side of the PCB. The first thing that I noticed were all those little trimpots. Trimpots are a poor choice to calibrate a multimeter, they are definitely not accurate and don't maintain their exact position if the multimeter is moved, shocked (i.e. dropped) or similar abrupt movements.

See that piece of metal just above the inner two input jacks? That's the shunt resistor. In principle there's nothing wrong with bare shunt resistors, except that if you take a closer look, you'll see that it seems broken and soldered together. No, that's not a sign of quality. The input jacks themselves also don't look very sturdy; just some pieces of metal that insert themselves onto some plastic on the top side.

There's no input protection to see on the top side, so one would think it's on the back side of the PCB, right? Right...?

Well, no. On the back side of the PCB there's nothing except a cheap buzzer (top left), some very bad solder joints on the through-hole components on the other side, a dodgy wire going from the top to the bottom, some burn marks which clearly show that the board was hand-soldered (and assembled) and glass fuses.

Glass fuses in a multimeter? Really? Glass fuses are only rated to interrupt a current of about 3 - 10 times their rated current value, so in this case somewhere between 30A and 100A. Sounds good? It's not. You can easily exceed that if you work on mains, circuit breakers, etc, yet the meter is supposedly rated CAT II according to IEC 61010 as we've seen on the first photo. CAT II means that it's safe to work on a circuit directly connected to the mains. Usually multimeters use HRC fuses (high rupture capacity) which are rated to interrupt a current in excess of 6kA (6000A), and for good reason.

On top of that comes the fact that there is no input protection whatsoever. Any decent multimeter will have a range of input protection, but first and foremost Metal Oxide Varistors, commonly called MOVs. MOVs are there to absorb part of a voltage surge/transient by directing it away from the circuit it protects, since MOVs have a very low resistance at very high voltages and an extremely high resistance at normal voltages. If a critical threshold is reached, they melt and/or vaporize, but in doing so they protect the rest of the circuit and especially the user of the device. Yet there's not a single MOV in this multimeter. This one will simply blow up in your hands instead of just dying, there's not a chance on earth that this multimeter is actually in accordance with IEC 61010 CAT II.

I've mainly mentioned safety reasons not to use this kind of multimeter as it can be really dangerous to the user. If you still don't believe me, take a look at the video below.

You might argue that you don't really care about the safety of the meter if you only work on low voltage electronics. While I disagree with that statement, last but not least because even low currents and voltages can be deadly, I can understand that attitude. But there are more reasons why you'd want to spend more money on a decent multimeter. You want a multimeter that you can trust. One that gives you the same reading time and time again, so there is a way of comparing measurements. Well, it definitely isn't the case with these cheap ones. You want a multimeter with a decent accuracy. Don't be fooled by the supposed specifications mentioned on the websites of these products, they are no way near reality. The accuracy on these cheapos tends to be quite bad.

To sum it up, there are plenty of reasons not to buy one of these very cheap multimeters, first and foremost your safety. If you don't want to spend the money on a better one, then just don't buy any multimeter at all. If you want a good multimeter, you don't need to go all the way up to Fluke, probably the most expensive multimeters. There are plenty of other good brands that give you a high degree of safety, accuracy and features at a lower price: BK Precision, Extech, Agilent, ... Personally I have an Agilent U1242A with which I'm very happy:

Serialization and Synchronization (2)

2010-09-24T00:00:00+01:00

In the previous post I discussed the basic ideas behind serialization and synchronization on multiprocessor systems and introduced critical sections as one possible per-CPU approach. In this post I'll present the first real multiprocessor serialization/synchronization mechanism: the spinlock.

Spinlocks

Spinlocks are in principle the simplest locking method. The concept behind them is to actively wait (spin) for a lock to become available, then acquire, hold it while doing the processing and finally release it so the next thread can acquire it. They are suitable only for (very) short and non-blocking code sections, though. A typical usage example would be access, insertion and deletion from a list. After all you wouldn't want someone else to change your list while you are iterating through it.

A main keyword before was the active wait, or spinning. This means that the acquisition routine actually loops until it can acquire the lock, so the thread will (possibly) remain scheduled. The typical spinlock implementation on common desktop systems (x86, x86_64/amd64) will use the highly efficient cmpxchg instruction. It allows to atomically compare a value and if it fulfills a certain condition (refer to some CPU programming manual) exchange it for some other. More generically, without using the cmpxchg instruction, the acquisition routine could look like this:

int lock_acquired = 0;

void spin_lock() {
	while(lock_acquired == 1);
	lock_acquired = 1;
}

void spin_unlock() {
	lock_acquired = 0;
}

Actual implementations are somewhat more complicated and can allow for a shared access model. In this model both exclusive and shared locks exist. The concept is that a lock can be shared/held by multiple threads at once if they requested shared locking and only perform read operations. Whenever another thread requests an exclusive lock, this will only be granted once all shared lock holders have released it.

Some implementations also refrain from simply actively looping until the lock becomes available and instead use what is called 'adaptive spinlocks'. This variation will use a hybrid approach: it will loop for some time, then sleep for some time; repeatedly, until the lock becomes available. This is clearly more efficient than just actively looping all the time, but also complicates the code.

It is important to note that spinlocks should only be used for short code sections and are not suitable to be held across blocking conditions. If these conditions are met, spinlocks offer a simple, fast and low overhead locking mechanism.

Serialization and Synchronization (1)

2010-09-07T00:00:00+01:00

Since multiprocessor systems became ubiquitous many years ago, software developers have found many solutions to take advantage of them without compromising stability, functionality, etc. The problem that arises with true multiprocessing is that several threads can execute at the same time, possibly accessing the same data structures at the same time or otherwise interact in an unwanted manner. Locking will hide intermediate states that are not supposed to exist and allow safe operation. Since I mostly work on kernel development, the focus here will be on solutions used in operating systems development.

In the early days of multiprocessor systems, operating systems were quickly made MPsafe (multiprocessor safe) by wrapping most if not all the code into one big mutex lock (on FreeBSD and DragonFly BSD: BGL = big giant lock; on Linux: BKL = big kernel lock). While this allowed safe operation on these systems, it didn't offer any performance improvements, actually it ended up decreasing performance since it would still only run one thread at each time but would also have the synchronization overhead. Since a mutex can only be held (exclusively) by one executing thread, while this thread was running, no other thread could. Over time, operating systems have been breaking down this giant lock into more fine-grained locking mechanisms, often per driver and/or per subsystem locks, but this process is still happening as making systems mpsafe is not an easy task. Many problems tend to crop up and some of them, in particular some race conditions are really hard to track down when they just slowly corrupt memory here and there and don't cause any instant panic.

Now let's have a look at some of the possibilities to serialize and synchronize access to resources. In this post I'll introduce critical sections. Later posts will handle other possibilities such as spinlocks, adaptive mutexes, serializing tokens, message passing, conditional variables, per-cpu structures, etc.

Critical Sections

Critical sections are strictly per-CPU and will actually disallow preemption of a certain block of code. This will make any operation appear atomic. The syntax is usually along the lines of:

crit_enter();
....
crit_exit();

The actual implementation behind this is usually along the lines of either bumping the priority of the executing thread on crit_enter() above all normal priority levels or handle a count of critical sections being held in the thread information and let the scheduler check if there are critical sections held before trying to preempt any thread. They also tend to disable interrupts, so they are only intended to lock rather short sections of code.

The limitation of critical sections should be clear: They are strictly per-CPU. They won't protect data structures from concurrent access from other CPUs or, more generally other execution units. They are only intended to avoid preemption by, for example, interrupt handlers, or if kernel threads preempt each other by other kernel threads.

Alignment

2010-09-01T00:00:00+01:00

Too many software developers these days don't know enough about the underlying hardware to appreciate some of the design considerations that should be taken into account. It usually works out just fine because of some magic occurring at some lower level (i.e. virtual machine, compiler, OS, hardware, ...) but it is still worth knowing about some of these. One of them is alignment.

So what do I mean when I say 'alignment'? I'm in particular referring to variable alignment in structures and on the stack, but this does also apply to alignment of blocks on disks, especially those with a non-512 byte block size.

A variable is said to be N-byte aligned when its location (memory address) is (integer-)divisible by N. Formally this can be expressed as:

ADDR(var) % N == 0

The next question usually is: Why would I care? Why is it important? You often don't need to care about it directly, since it happens automatically most of the time; the compiler does the magic. Nonetheless, if you aren't aligning stuff properly you can get everything from slow performance to memory corruption and general protection faults.

Sometimes you'll see/use something like #pragma pack(1) or __attribute__((__packed__)) which effectively disables the automatic alignment done by the compiler on structures. This can be desirable if you want to know that a structure will look exactly the same in memory as you intended, without any padding added by the compiler. It is usually used for transmitting structures as a whole over a network, over files, etc. As a nice side effect, your structure will also have a smaller memory footprint. But be aware that if you use packed structures you'll have to deal with alignment yourself in case you do need it for a particular variable, meaning you'll have to add the padding yourself.

Now on to some examples of what can happen with misaligned variables/structures.

Recently I've been writing a PHY and a MAC layer for an ARM SoC. The structure representing the MAC Header looked something like this:

struct MACHdr {
  uint8_t  id;
  uint32_t data[32]
} __attribute__((__packed__));

During the initial testing, I did, without much thinking, something along the lines of:

*(uint32_t)hdr->data = 0xffff;

ARM CPUs will only allow 32-bit access on addresses aligned on a 4-byte boundary, which is clearly not the case here. This effectively corrupted the 'id' in the packet. Not a nice thing to happen, so be aware of your architectures limitations. Especially RISC architectures tend to be very picky about unaligned memory accesses.

Another example of a more picky system is VIA's Padlock. Padlock is a security engine on some VIA CPUs proving an RNG, as well as cryptographic acceleration (for AES and some hashes). To use the AES instructions, you'd use something like this gcc inline assembly:

		__asm __volatile(
		"pushf				\n\t"
		"popf				\n\t"
		"rep xcrypt-cbc			\n\t"
			: "+a" (iv), "+c" (count), "+D" (out), "+S" (in)
			: "b" (key), "d" (cw)
			: "cc", "memory"
		);

I've come across a similar code segment a year ago, where a careless developer just passed in the iv, out, key and cw without paying any attention to the alignment. This ended up in all sorts of general protection faults for a customer. The VIA Padlock Programming Guide is very clear about this: in the normal case the iv, output buffer, input buffer, key and control word (cw) must be aligned on a 16-byte boundary. Otherwise a general protection fault will occur, and if this happens in the privileged mode, you'll have a kernel panic.

While there is a bit that can be set to avoid this strict alignment requirement, setting it and actually making use of it will incur a significant loss in performance.

This leads me to my last example: The x86 and x86_64 (amd64) architecture. On this architecture you won't end up with corruption or general protection faults (at least not usually) but you will incur a performance loss when using misaligned data accesses. This is especially significant for double precision floating point data, but also affects integer performance.

A misaligned access on these architectures will require two memory accesses instead of one. While keeping such data in registers and the cache will mitigate the performance hit in some cases, you still don't want to waste your CPU time with memory fetches or have cache-line splits if you can easily avoid it.

For more details on the issues on the x86 and x86_64 architectures you can take a look at the Intel Guide for Preparing Applications for the Intel Core Microarchitecture.

Introduction

2010-08-25T00:00:00+01:00

Welcome to my new page and blog. I'm an Electronic Engineer but currently do more Software than Hardware. The blog is mainly intended to be a space where I can place all my thoughts and rumblings, as well as share my experience on certain, mostly technical subjects. As you can see from the 'About' page or the 'DragonFly' page, I'm a DragonFly BSD committer as well as a Freelance software developer.

DragonFly BSD is of course more of a hobby, but it's definitely a worthwhile one. It was forked back in the day from FreeBSD 4.X and has since developed its own personality. I enjoy working on it as I like to stick to low level software if anything.... the DragonFly kernel is my playground and I really try to stay away from most of the userland, except for some kernel <-> userland interfaces. Expect the occasional post about recent DragonFly development!

In my free time I also enjoy doing Electronics, usually involving microcontrollers (PICmicro or Atmel) and nowadays FPGAs, too. I'll hopefully be posting some of my designs as well as other ideas on this page soon.