CompactPCI (cPCI) is finding new growth areas in the following:

• Avionics
• Medical
• Military

In the 90’s, cPCI’s growth was driven primarily by the telecom and industrial computing markets.  Over the years, and as a result of the downturn in the telecom industry, cPCI has evolved and found new growth sectors.

There’s been an uptick in military and aerospace because it’s superior in technology to VME, and a more proven technology as compared to OpenVPX.  This makes it ideal for markets demanding rugged, reliable, and high performance systems.
By migrating new processor technologies to cPCI, you are ready to tackle today’s most demanding compute-intensive applications.  For maximum compute and power densities, the 3U cPCI form factor offers a platform that’s easy to ruggedize, and takes up minimal footprint.  For this reason, 3U cPCI products are finding a receptive marked in military, air, and ground vehicle applications.

Hudson is run as a standalone Java application.  You launch it once in a command window, or on boot up, and then you access it via a web browser. A typical Hudson job consists of a pointer to a revision control project, a build script, instructions for what to do with the built artifacts, and optionally a pointer to another Hudson job to execute.  At the end of the build, Hudson can post the Build number as a tag to the repository.

In my Linux projects, I have used Hudson to build both the Linux Kernel, as well as the root filesystems. For the Linux Kernel, Hudson updates the source tree, executes a build, and stores away the kernel image in whatever format I specify.  This image is version numbered, and fingerprinted, so that at a later date, I can check a customer’s kernel image against my Hudson repository and find the build number, source version in the repository, as well as all console output from the build.  It’s very handy!

Hudson also provides a great way to build root filesystems.  Typically, a root filesystem is built with a utility such as buildroot which fetches packages from the network, configures them, and performs the build. I have had spotty results with buildroot, as it does not always generate reproducible results.  Hudson allows me to generate complex build scripts over which I can maintain complete control.  These scripts are customized to my individual customer’s requirements, fetching and building the packages that the customer needs, with known revisions and source locations. Furthermore, all builds are archived automatically, giving me full history of the project in one convenient location.

I have found that the best embedded software incorporates a good testing methodology from the first phases of algorithm design.  Typically algorithm design begins using high level tools such as MATLAB.  These tools allow for rapid development and characterization of the algorithm and provide a great way to analyze design tradeoffs.  This phase of algorithm development is the best time to develop a test vector set that exercises the extremes of the design.

Once the algorithm and vector set is developed and the performance characterized, the model is typically moved to a high level language for efficient operation on the embedded hardware.  The typical language of choice is C++ or C.  In this phase of the development, the original vector set is extremely important to ensure that the implemented design has not been compromised in any way.

Sometimes an embedded algorithm needs to be integerized for cost-effective fielding on a low-cost processor.  The vector set again proves to be a very effective way to make certain that performance is never compromised by moving the code to fixed point arithmetic.

Vector set testing also proves valuable once the product is fielded.  A subset of these vectors can be used to establish an automated regression test when the code base is enhanced or changed.  QC departments can also take advantage of these vector sets to automatically ensure proper functionality after build.

Finally the vector test methodology is useful in the support phase of the project.  Depending on the sophistication level of the end-user, it is often possible to capture algorithm input data from a troublesome run, and then utilize this data in conjunction with the vector infrastructure that you have built up throughout the development cycle, and quickly determine the cause of the issue.  This methodology quickly illuminates whether the problem is in the model (indicating an inherent design flaw), the C implementation (indicating a coding bug) , or the integer C code (indicating an quantization issue).