Writing an eCos HAL
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.
- 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.
- 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.
- 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
- 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.
- 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.
ZY1000 JTAG Debugger
ARM7/9/11, XScale, Cortex-M3
Fast. No drivers!