Getting the main idea.

HALFRED is a short from Hardware Abstraction Layer For Real-time Embedded Designs. It is indeed a piece of software - a software layer. The main purpose of creating HALFRED was to provide better portability to the embedded applications, that are based on popular, low-cost microcontrollers. Nowadays we're facing a situation, where a designer has a wide variety of such hardware to choose from. Not all of the decisions taken will last long. The market changes along with user demands, silicon chips capabilities and pricing. On the other hand you always want to have a reusable software. A reusable piece of code is something you can trust and base upon, because it has proved correctness in more than one application. It is probably well tested too. You don't want to throw that away just because your microcontroller changes.

To allow your software to adapt to a new hardware you need a way of translating it to a new microcontroller. HALFRED is such a way. It translates the demands from your application to the hardware it works on. In other terms, it actually mimics the microcontroler in a standard way, so your software can always use the same virtual hardware interfaces, while HALFRED translates it to execute on a particular silicon chip. This way your software doesn't change, while microcontroller changes. It is portable.

By using HALFRED, your application draws a clear line between the hardware-independent and hardware-dependent parts of the code. This line is actually set inside the HALFRED, meaning that HALFRED itself is divided into portable code and the "port" itself. This "port" can be viewed as a driver, for a particular microcontroller.

More benefits.

If you're not interested in writing portable code, there is still an issue that might convince you to consider using HALFRED. Developing an embedded application is generally considered to be more difficult and demanding than "standard" PC software. The main reason is the usual unfriendliness of embedded debuggers and tools, when compared to will-do-it-all-for-you integrated development environments on PC. It is then attractive to develop, debug and test code with a more capable tools. on the PC platform HALFRED gives you this opportunity by providing ports for PC, that emulate virtual hardware peripherals. These modules are especially suited for developing an testing pieces of code, that are hardware-independent, but eventually must run on some hardware (in this case - virtual hardware). What you can do is for example: develop and test a protocol that uses UART communication as a physical layer before your actual hardware arrives. This also boosts unit-test and debugging capabilities. With some effort you can even simulate your whole application and it's interaction with the environment on a single PC.

Digging deeper into abstraction.

Abstraction usually means that some details are hidden, and more general properties are exposed. In case of the HALFRED there are several interfaces exposed, that allow you to use the most common abilities of modern microcontrollers. What is hidden is the actual microcontroller implementation.

The glitch.

All this value comes with no disadvantages, right? Well... no. We won't lie to you. The price for abstraction is less detail, and the price for portability is less performance. We did our best to provide as much functionality as possible, based on current state of art microcontrollers, but there are always exotic peripheral capabilities that didn't fit into the interfaces. While these can still be used, by modifying/extending ports, it would probably break seriously the portability advantage. We also did our best to minimize the performance penalty, but it's fair to say that a 100% target-specific implementation has a good chance to outperform the HALFRED-based one. But we still think that the HALFRED engine is an excellent compromise between total portability (such as JAVA) and pure hardware-specific assembly.