Before you start

When writing a HAL for your hardware there are a couple of things you should keep in mind:

• You'll want to keep your HAL and any changes to eCos changes under your own source control system. The community will only be interested in a HAL if it is for some reference hardware platform that is readily available.
• The eCos license is GPL w/exception, which allows you to keep your HAL closed source and stored together with your application.
• You'll want to be able to update eCos without having lots of your own changes mixed into the eCos repository making merging hard
• There are no eCos releases. The "releases" on the official eCos web sites are hopelessly(years) out of date. Pull down the latest version from CVS HEAD.

Steps

1. Is there a GCC toolchain available for your CPU? If not you'll need to build a toolchain. This can be anything from relatively straightforward to a black art depending on your luck.
2. Get the latest version of eCos from CVS HEAD, zip up the entire repository including the CVS folders and commit the resulting file under your own source control system. This allows you to control when eCos is updated. The eCos core is mature and has changed very little in the last couple of years, so there is a good chance that you won't need to update it during the development of your product, but occasionally you'll need some bugfix/feature/driver that has been added recently.
3. Duplicate the HAL that most closely resembles the hardware you have and create an eCos repository containing only your HAL. Place the resulting files under your own source control system. You will be writing an ecos.db that describes the layout of the files in your HAL. The files you have under your own source control system is a seperate eCos repository.
4. Your processor architecture will almost certainly be supported by eCos, but if it is not, then don't despair. If you are familiar with the processor architecture and you have a GCC compiler, then writing an eCos hal is relatively straightforward. eCos has a bare minimum of formalities that need to be in place to support a new processor architecture.
5. Either place drivers in your application code(access hardware directly without any drivers) or place them into your own eCos repository under your source control system. It is not "bad" to access hardware directly from an eCos app, you only need to do so if you want eCos to interact with your hardware. A common driver model only makes sense for standard hardware(ethernet, usb, serial, etc.). If you have an FPGA with some highly application specific hardware registers, then the interaction with that hardware belongs in your eCos application and not in eCos.

Resources

• eCos porting guide