Re: FreeBSD's embedded agenda

Poul-Henning Kamp sez...

[snip; getting into this late due to some weird mailing list delays]

> FreeBSD is a great operating system for embedded use and people all over
> the world use this to their advantage.

Judging on what I have heard over my career in embedded development,
*BSD (let alone FreeBSD) is almost completely unknown in the embedded market.
WindRiver, GreenHills, QNX, ... and possibly some Linuxs are the owners
of that marketplace.  [Maybe the notable exception is Juniper Networks;
I've heard they're a big BSD shop]

> At the developer summit in Ottawa this month (right before the
> wonderful BSDcan conference) we spent a lot of time talking about
> what we as developers can do to further this market segment.

It's got to be as simple and well-supported as the OSs mentioned above.
It's got to have success stories, PR, etc.
It's got to have a base of experts that *know* embedded.

There must be a commonality between the "embedded edition" and the
"desktop edition" -- self-hosted development is ORDERS of magnitude
more efficient than cross platform development, so the "desktop"
version should present itself as a really "fat" embedded system...

[snip]

> Overall Focus
> -------------
> 
> I think we found three main areas where we need to do some work:
> platforms, packaging and evangelism.

Agree 100%; I'd also seriously add:

d) port kits

What I mean by that is creating a set of libraries, tools, documentation,
whatever it takes, that will help someone coming from a VxWorks or QNX or
whatever environment to get started and become productive in a FreeBSD
environment ASAP.

[snip]

> What can you do ?
> 
> If you work with embedded FreeBSD, I think the best you can do is to
> chime in to small_at_freebsd.org, tell us what you are doing (as far as
> company policy will allow you), and if you have any ideas, wishes,
> problems, let us hear about them.

Well, my current project is QNX-based, but I've been asking myself, "why
can't we use FreeBSD on this one?"  Apart from the fact that it's a medical
device, and we are 2 years into it :-)

Let me describe it briefly -- it's a 500MHz Celeron processor, 16 MB
CF, 64MB RAM, VGA, Ethernet, and a 48 digital I/O card + serial ports.
The OS and all applications are on the order of 3MB.  The CF is used
for logging of "interesting internal software events" as well as a
database of irradiated products.

The software controls two motors, monitors a dozen inputs, and communicates
with the user via a 4 x 20 Vacuum Fluorescent Display and a 14 button keypad
over a weird Datapac 3201-like serial protocol (ETX/STX/ACK/NAK/ENQ type of
stuff).  It accepts an IBM-PC/AT compatible keyboard, with a barcode scanner.

There is 50kLOC divided into half a dozen major processes, all communicating
via IPC.  I'm not going to take up more list space with details, see the
top entry of my resume at www.parse.com/resume.html for more info.  There
you'll also see the kind of stuff I've been working on for the last 20
years.

What if we were to port this to FreeBSD, or if we were to have started the
project in FreeBSD in the beginning?

Well, the following things are "critical" for our system -- FreeBSD
addresses some of them, and is "at the edge" for others:
	a) fast boot time -- there's a stupidly-designed microcontroller on one
	   of the systems (legacy; can't change) that needs to be tickled within
	   13s of power up.
	   Using the current Celeron processor, with a special "fast boot" bios
	   from the manufacturer, and having customized the kernel, and hacked
	   the OS bootloader, we're down to 10s.
	b) small sizes -- this is less of a constraint than it used to be, but
	   the size of everything affects bootup time.
	c) realtime response
	d) certified for use in medical devices

The last requirement is peculiar to this device and can probably be omitted
from the "general list" of embedded requirements.

There's been a lot of discussion on this list about filesystems and flash
adaptation layers and all that.  The CF cards that we're using are M-Systems
32 MB EIDE "plugs" (they plug right into the motherboard's EIDE connector)
and we did extensive life-cycle testing on them with no apparent degradation.
(This could be a misleading statement -- we don't write to the flash that
often, so our simulation of "5 years worth of life cycle" consisted of on
the order of 1 million open/write/close cycles on a few files).

Since it's almost impossible to get any "real" answers from M-systems (or
any other vendor, most likely) about what they do for wear-leveling etc,
we simply said "Fine, how does a representative sample of their devices
compare over our expected lifecycle?"

Another serious issue to consider with wear-leveling is that some of the
algorithms are patented, so there's a whole nasty IP issue to contend with.

In another life, I did data acquisition for an aluminium smelter, worked
on a control system for a chlorine plant, conveyor controls, embedded
telecoms work, etc, etc.

An "embedded edition" of FreeBSD is definitely required...

[snip]

As far as PR goes, maybe what someone needs to do is make a checklist
against the other market leaders in the embedded marketplace.  Something
that PHB types could look at and go "Golly, this has everything!" -- POSIX
compliance, realtime support, drivers, protocols, development tools,
support, etc.

Someone should look at the other embedded players and see how they handle
BSPs -- Board Support Packages.  These are the "take these ten things
and mix them together and voila, you have a working reference board".

[snip]

> It would be great if we could park a couple of developers full time
> on embedded FreeBSD in the future, but that would take some serious
> financial support from the user community, if you think your company
> could be persuaded to help with this, get in touch with the FreeBSD
> foundation.

I would love to work on embedding FreeBSD; unfortunately, doing what I
do, I have a money-driven scheduling algorithm.  This means I'd either
need to convince a "sugar daddy" employer that this would be a "Good Thing(TM)"
or there'd have to be a sufficient infrastructure in place that it would
be a no brainer, or someone would have to pay for development...

Anyway, just sharing some random thoughts :-)

Cheers,
-RK
--
Robert Krten, PARSE Software Devices
Realtime Systems Architecture, Consulting, Books and Training at www.parse.com
Looking for Digital Equipment Corp. PDP-1 through PDP-15 minicomputers!