tech-embed archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Quick and dirty embedded OS



Allen Briggs wrote:
On Wed, Oct 20, 2004 at 10:49:08AM +0200, Werner Backes wrote:


I understand.  The clock speed is not an issue.  My early NetBSD
work was on similarly-powered mac68k systems (16MHz 68020+68851+68881).
The MMU is (68851 is the MMU above, 68030 & up have the MMU built in).

NetBSD would take a lot of work to make it run without an MMU.
Looking at higher-end PDAs/HPCs is a compromise--NetBSD already
runs to some extent on a number of them.  It all depends on where
your interest really is--are you strongly tied to that hardware,
or are you interested in leveraging the development with NetBSD?


What I am interested in is mainly the device drivers and a familiar environment for things like malloc, etc. I can't speak for all embedded developers out there, but I know that I would simply like to be able to bring up various pieces of hardware and run a single program on it. Multitheading would be nice, but if need be I can do my own task switching. The code I am working with is not terribly complex from a functional point of view, but adding new features is quite a task because I have to take care of silly little details like memory allocation and driving a device.

Currently all our code is written in assembly for a certian family of processors without an operating system. May main goal is to say "Look, by switching to a higher level language and using NetBSD, we are no longer beholden to this CPU vendor. NetBSD gives us the ability to choose from many possible CPUs, with support for many peripherals, and to be able to quickly adapt to new hardware."

As it stands now, if we want a feature, I spend a lot of time reinventing the wheel for our system. I'm looking into uCLinux, RTEMS, and NetBSD as solutions to this problem. uCLinux looks to provide the best bang for the buck as it has a very expansive device driver library, and will run on these very basic processors. RTEMS is what I functionally need, but device driver support is less than uCLinux. Being a longtime NetBSD user and an embedded developer, I was sold on NetBSD by the "Runs on more systems than anyone else". I wouldn't mind working on NetBSD to get it to this point, but I definitely lack the knowledge of the kernel and operating systems in general to effectively do this.

If anyone is interested, I can probably get an hour or two a day for this project.

--

Brian







Home | Main Index | Thread Index | Old Index