The Open Source Class Library is a collection of source-code that I have written to support my vision of reusable software. Someday, the entire theory and documentation will live here.

Sometimes it is easier to say a few words about what a thing is NOT rather than what it is. The OSCL is certainly not intended for all embedded applications. It is generally not appropriate for resource constrained environments. The OSCL is not designed for "ease-of-use". The OSCL is not designed to be yet-another POSIX look-alike. 

Alright then, "What is the point?" I hear you ask. The answer to that question can be glimpsed by knowing a bit about my background. The systems, with which I have worked over the years, tend to be dynamic soft real-time telecommunications systems, which are required to have a very high reliability. Whats more, these systems tend to be rather large both in terms of features and their physical size. Sometimes they physically comprise more than a single bay. Frequently, such systems are designed to be highly configurable. For example, there may be many different circuit-pack types and combinations for a single system, with more expected in the future. Now throw in the standard 50ms restoration time (which gets quoted for everything, even if it doesn't apply) and you have some idea of the problem space complexity. These are the types of systems that hatched the OSCL.


A tarball of the OSCL is now available.


I have yet to organize the release for BENV or any of the supporting tools and example programs, but that is forthcoming. Just getting this first release of the OSCL source code out there has been a much larger undertaking than I anticipated.

You can get an idea about what's included by looking at this copy of the README.summary file.


I have struggled long and hard with the issue of licensing this software. In spite of the fact that it may be too radical for wide-spread adoption, licensing is an issue that concerns me from several points-of-view, from ego to ethical.

Ego is easy, we all have one. Like most people, I would like to feel that I have created something lasting, and the best way to have this happen is to release my source code to the public.

From an ethical point-of-view, I feel strongly that it is important, at this early stage in the development of the practice of software engineering, to allow for the free exchange of fundamental ideas and practices.

Many feel that GNU Public License (GPL) is too restrictive and some have even called it "viral". However, it is important to realize that the copyright holder may offer other licensing options. These options are themselves optional, and may not be available from some copyright holders. Those copyright holders that do offer other licensing options, are no different from any other software vendor.

Software always takes time and effort to develop. Free software developers pour much into their work, and those who offer that work to advance the state-of-the-art by using the GNU public license are offering their work gratis to those willing to do likewise. However, for those who wish to profit from the developer's work, they have a reasonable expectation of sharing in that profit.

Everyone in business knows that "there is no such thing as a free lunch."

Thus, for anyone who wishes to incorporate the OSCL in a proprietary product, I am willing to negotiate other licensing options. The terms of such an agreement may vary wildly depending on many factors, including my current state-of-mind. However, don't be shy, I can be bought.


This section is a collection of notes concerning the "current" OSCL.

There are portions of the OSCL which are not currently being maintained. These are typically the target specific parts of the library. This notes exists primarily to illuminate and "justify" this condition.


The eCos related parts of the OSCL are in an interesting state. These parts were written as a part of an attempt to demonstrate the portability of my driver code under the eCos RTOS. However, to accomplish this, I had to do some serious surgery on the interrupt handling of the eCos code base.

It seems that eCos tightly couples the interrupt controller with the kernel code. Since I had already written a very complete library for the same interrupt controller, and had used this model on which to build many other peripheral drivers, I decided to hack eCos to remove their interrupt controller code.

IMHO, the eCos MPC8xx technique for dealing with the interrupt handling was not optimally layered. It may, however, have been more efficient, but that's simply not consistent with the overal goals of the OSCL.

I have recently tried to revive the projects that I built using an ancient version of eCos, but have been thwarted by the "ecosconfig" tool. When I originally did the work, my development platform was an Apple PowerBook G3 running LinuxPPC. Thus all of the original eCos tools were built for the PowerPC Linux. After that system died, I am now running a Dell Inspiron 8500, and the original eCos tools will (obviously) not run. To exacerbate the problem, I do not have the original sources for the "ecosconfig" tool, and have been unable to re-build the eCos kernel that I used.

One day, I'll get motivated to revive this code, and perhaps argue for better separation of the interrupt controller from the eCos kernel. If anyone wishes to get a copy of that hacked code and make it work, I'll gladly supply a copy.


For similar reasons, the AVR port of the OSCL and OOOS in particular are in a rather questionable state. When I originally built GCC for the AVR, I had to do quite a bit of hacking to get the standard C++ libraries to build. During my "transition" to a new development platform, the hacked GCC libraries have been ... er ... misplaced.

I do have a few issues with the AVR and C++. This stems from the fact that the AVR is a Harvard architecture machine in a very strict sense. At the time I looked at the GCC port for AVR, constant data (including V-Tables) had to be located in RAM rather than Flash. Of course that's pretty wasteful for a micro controller that typically has far more Flash than RAM.

However, there was a time when OSCL/OOOS worked using "simulavr". Another project in need of resurection.


The H8/300 series of single chip micro controllers is a true pleasure with which to work. Especially for those of us who are accustomed to RISC machines with a "large" set of general purpose registers.

The OSCL and OOOS currently work on the H8/300H serries. The H8/300L series once worked, however I no longer have the appropriate tool-chain/motivation to resurect the port.

The 300L parts are the most resource constrained of the H8 series, and therefore probably not a good fit for OSCL and OOOS anyway. However, I once had this working with the h8300-hms target of GCC.

The h8300-hms GCC produced COFF object files, which is the biggest impediment to the porting to h8300-elf, since I will have to port the linker scripts ... and I'm lazy :-P