OSCL
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.
Download
A tarball of the OSCL is now available.
oscl-v1.0.tgz
oscl-v1.1.tgz
oscl-v1.2.tgz
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.
Licensing
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.
Notes
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.
eCos
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.
AVR
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.
H8/300
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