Upgrade for thermal imaging camera

Background

Rufilla, a software development consultancy that specialises in training, asked us to support a project for one of their clients.

The client had a thermal imaging camera, aimed at building inspectors and engineers. We were asked to carry out a mid-life upgrade on the product, which included enabling it to support high capacity SD cards (SDHC).

What we did

The camera was a Linux based design, with u-boot bootloader.

We applied the customer’s board specific modifications to a more recent Linux kernel, which supported the SDHC cards, and we made both u-boot and Linux kernel changes.  This was an important upgrade as SDHC cards were becoming more prevalent and the client wanted to give end-users greater choice.

We also made a series of minor enhancements to the camera, which responded to end-user demand. They included modifications to its video system, which reduced the delay between moving the camera and the change showing in the viewfinder. This made the camera easier to use.

The result

The project was delivered on time, and the customer was able to issue an update, which gave compatibility with a wide range of memory cards. This gave their end users more choice and enabled them to store more images.

Says Joe Nicholson MD of Rufilla, “We’ve collaborated with Humboldt many times so I knew they had a great deal of knowledge and experience of Linux video drivers.”

“They were a key component in making this project successful. Fast and flexible, they approached each element in the most appropriate way. This involved meetings, joint investigations, short milestone software delivery, as well as advice on the correct approach.”

“We worked jointly on many tasks so communication needed to be excellent. Humboldt made this very easy and seamless by using online collaboration tools.”

“I have to say, I don’t think we could have completed this project without them”.

Running Linux on a PCI Add-in Card: Hardware

Every so often I see someone attempting to run the Linux kernel on a PCI add-in card. I’ve done this myself, but there are a lot of complications. This article covers the hardware, and a second article will cover software. Don’t take this as chipset selection advice: before you commit to hardware double-check both the errata and the availability of the silicon.

Read more

SSL Handshake Overhead for Mobile Devices

If you’re designing an application where devices communicate with a server over a mobile network, there are trade-offs between implementation effort and data transfer. This may not apply to a consumer application, where the application developer doesn’t have to pay the data charges. But if the application is M2M these trade-offs matter.

Read more

Embedded Theora Video

Last year I did some experiments with the Theora video decoder on a Texas Instruments DM642 DSP. A royalty free video decoder is very attractive for embedded devices, but after some major restructuring for performance, some problems remained.

The main problem is that, unlike MPEG video, Theora video is not packed in the bitstream in the raster order that it is displayed on screen, but instead in Hilbert curve order. This is not a problem in itself, but Theora’s DC prediction and post-processing loop filter are both defined in raster order. The need to go over the data once in Hilbert curve order and once in raster order leaves Theora decode requiring higher memory bandwidth than MPEG decode.

The encoder faces a similar problem. Andrey N. Filippov describes an FPGA implementation of the Theora Encoder, and comments on the high memory bandwidth required. The solution in the article is to implement a custom SDRAM controller with knowledge of the Theora data structures, an option not available on a DSP.

There are other minor problems remaining. The DM642 has instructions to assist video encoding and decoding, but these are optimised for MPEG and may not easily apply to Theora. For example, the avg2 instruction averages two pairs of 16-bit values, but it uses the formula (x + y + 1) >> 1, whereas Theora’s half-pixel predictor uses the formula (x + y) >> 1.

Where does this leave Theora decode on DSP? The DM642 is just capable of decoding NTSC quality video (640×480, 30fps) provided that the bitrate is controlled. The good news is that the newer DaVinci architecture provides extra memory bandwidth through a DDR2 memory controller, plus the possibility of splitting the workload to place bitstream decode on the ARM processor and frame reconstruction on the DSP.

MPC107/Tsi107 I2C in Linux 2.6

As of Linux 2.6.9.1, the driver is in the kernel as i2c-mpc.c. This version of the driver has been tested on Tsi107 (formerly MPC107), and on MPC8240, MPC8540, and MPC5200 PowerPCs. Thanks to all the testers.

MPC107/Tsi107 Cache Coherency

The Tsi106 (formerly MPC106) and Tsi107 (formerly MPC107) PowerPC host bridges both contain a data cache. This note describes why it may be necessary to mark memory as SMP coherent even in a single processor system using these bridges.

Read more

MPC107 I2C Driver

The driver is supplied ready to be inserted into the linuxppc-2.4-devel tree.

The driver has so far been tested on a small number of systems and with a small number of I2C parts. Thanks to Gleb Natapov, Matthew S. McClintock, and others for testing. Further test results are welcome.
Read more

Asiliant 69030 Driver for Linux 2.2

These are experimental Linux 2.2 and 2.4 framebuffer drivers for the Asiliant 69030 graphics chip. This chip was previously available from Intel, and is descended from a Chips and Technologies part. The 2.2 driver is thus based on the Linux chipsfb.c driver, which supports the 65555 part in certain Apple Powerbooks. The 2.4 driver is also based on work by Jordan Crouse.

The driver currently leaves the flat panel as it was set up by the BIOS. In most cases this displays the same image on flat panel and VGA outputs. The goal for the driver is to support multi-head operation, and multiple 69030 chips. The driver supports operation without a VGA BIOS for embedded applications, but currently contains no flat panel setup code.

Read more

Asiliant 69030 Driver for Linux 2.4

These are experimental Linux 2.2 and 2.4 framebuffer drivers for the Asiliant 69030 graphics chip. This chip was previously available from Intel, and is descended from a Chips and Technologies part. The 2.2 driver is thus based on the Linux chipsfb.c driver, which supports the 65555 part in certain Apple Powerbooks. The 2.4 driver is also based on work by Jordan Crouse.

This driver is experimental, but is intended as a basis to merge into the mainstream kernel. Though the driver should work on the 69000, I currently have no 69000 hardware to test it on. Reports of using a panel and CRT simultaneously on 69000 are very interesting.

Read more

Machine Check Handling

Current PowerPC kernels have a number of flaws in their machine check handling. The first fault is that they raise a SIGSEGV exception if the machine check occurs during user mode code. Many causes of machine check are not directly related to the current process. For example, on some platforms a PCI parity error detected while a PCI bus master writes into memory will cause a machine check. On some platforms a parity error reading data from the L2 cache in order to write it out to memory will cause a machine check.

Read more