FreeBSD, NetBSD, or Minix-III?
I think there is more use of microkernels (eCos, RTEMS, Erlang, etc.) in the
embedded world. The environment is more constrained, so reducing the
footprint is useful.
There is also the new µC/OS-III (yes, three) that "provides near zero
interrupt disable time. µC/OS-III has a number of internal data
structures and variables that it needs to access atomically. These
critical regions are protected by locking the scheduler instead of
disabling interrupts. Interrupts are disabled for almost zero clock
cycles, ensuring the RTOS will be able to respond to some of the
fastest interrupt sources."
In the day job I'm designing near pager size devices, heading down to
watch size devices. Current project has a U-Blox GPS hooked up to a
AVR XMega Event System pin. Any Time Nut suggestions on what to do
with it? Has 120x32 bit LCD display,
and small speaker, also.
Lux, James P wrote:
I think there is more use of microkernels (eCos, RTEMS, Erlang, etc.) in the
embedded world. The environment is more constrained, so reducing the
footprint is useful.
That's just it, it doesn't reduce the footprint at all!
All it does is legislate that the kernel function be small,
and be the only "root" task. Everything else is pushed out
into "user" land.
You do the work in the kernel, or you do the work outside of
the kernel, but you still have to do the work, and that takes
code.
-Chuck Harris
Lux, James P wrote:
I don't believe that will be happening in a message passing microkernel
(like minix) anytime soon... unless you build all of the timekeeping
software into the kernel, and then you are in the process of becoming
a monolithic kernel ;-)
Or, do what I'm doing for a software radio that uses RTEMS, do the critical
timing stuff in hardware, and the software just manages the hardware.
That's fine, as long as the critical timing stuff never has to
pass into code space. If it does, then you are stuck with the
OS's latency issues.
-Chuck Harris
On 5/16/09 4:30 PM, "Chuck Harris" cfharris@erols.com wrote:
Lux, James P wrote:
I think there is more use of microkernels (eCos, RTEMS, Erlang, etc.) in the
embedded world. The environment is more constrained, so reducing the
footprint is useful.
That's just it, it doesn't reduce the footprint at all!
All it does is legislate that the kernel function be small,
and be the only "root" task. Everything else is pushed out
into "user" land.
You do the work in the kernel, or you do the work outside of
the kernel, but you still have to do the work, and that takes
code.
But lots of embedded applications don't need, e.g., a file system.
All they need is device drivers, a scheduler, and some sort of messaging
system. (e.g. Traditional kernel functions).
On 5/16/09 4:32 PM, "Chuck Harris" cfharris@erols.com wrote:
Lux, James P wrote:
I don't believe that will be happening in a message passing microkernel
(like minix) anytime soon... unless you build all of the timekeeping
software into the kernel, and then you are in the process of becoming
a monolithic kernel ;-)
Or, do what I'm doing for a software radio that uses RTEMS, do the critical
timing stuff in hardware, and the software just manages the hardware.
That's fine, as long as the critical timing stuff never has to
pass into code space. If it does, then you are stuck with the
OS's latency issues.
That's the whole design requirement.. Thou shalt not touch the data with
software.
Lux, James P wrote:
You do the work in the kernel, or you do the work outside of
the kernel, but you still have to do the work, and that takes
code.
But lots of embedded applications don't need, e.g., a file system.
All they need is device drivers, a scheduler, and some sort of messaging
system. (e.g. Traditional kernel functions).
Traditional monolithic kernel operating systems can be
built to include as much, or as little of these traditional
kernel functions as you want.
Size is not a factor in making the decision over whether
you want/need a message passing microkernel, or a monolithic
kernel.
-Chuck Harris
On Sat, 16 May 2009 15:09:07 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
In message 4A0EBDEE.2020703@erols.com, Chuck Harris writes:
A "watch" isn't exactly a challenge to an operating system.
Well, no.
But figuring out correct handling of time is a challenge for operating
system programmers.
Out of pure interest: what makes handling of time difficult?
From an uneducated point of view it's just updating a counter
in software from a time source in hardware.
Attila Kinali
--
If you want to walk fast, walk alone.
If you want to walk far, walk together.
-- African proverb
In message 20090519095316.1e1f4b46.attila@kinali.ch, Attila Kinali writes:
On Sat, 16 May 2009 15:09:07 +0000
Out of pure interest: what makes handling of time difficult?
That people don't think about it the right way.
I think the biggest challenge for people to wrap their head around,
is that you can and should use a binary fraction instead of a decimal
fraction.
People are so used to thinking about milli-, micro- and nanoseconds
that they simply fail to recognize those as presentation formats for
an underlying real number.
Time is, for all we know, a continuous scale, it does not come in
small countable parcels, so the correct and ideal format is a
floating point format, not a fixed point format.
Time values have about 20 significant decimal places in regular
computer operation these days: subtracting two nanosecond resolution
timestamps will get you there, because of our choice of epoch for
time_t.
That almost fits into a 64 bit integer in 32.32 format, even if
you choose to do the decimal fraction stupidity and let the fraction
count nanoseconds.
NTP does that or example.
However, we run out of seconds in slightly less than 30 years time
that way, NTP can live with that, it's packets are short lived,
but permanent records in an archive can not.
A 33.31 format would buy us a century, still allow us to get
nanoseconds right, but it be computationally inconvenient and
looks messy, so people balk at it.
It would get my vote however because it is the difference between:
int64_t t0, t1, dt;
[...]
dt = t1 - t0;
and
struct timespec t0, t1, dt;
[...]
dt = t0;
dt.tv_sec -= t1.tv_sec;
dt.tv_nsec -= t1.tv_nsec;
if (dt.tv_nsec < 0) {
dt->tv_sec--;
dt->tv_nsec += 1000000000;
}
/* XXX: still left with a two-component time difference */
The truly long term solution is IEEE 128 bit floating point format,
you can resolve 10000 years to femto-seconds and still have 7 decimal
digits of precsion to play with.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
In message: 20090519095316.1e1f4b46.attila@kinali.ch
Attila Kinali attila@kinali.ch writes:
: On Sat, 16 May 2009 15:09:07 +0000
: "Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
:
: > In message 4A0EBDEE.2020703@erols.com, Chuck Harris writes:
: >
: > >A "watch" isn't exactly a challenge to an operating system.
: >
: > Well, no.
: >
: > But figuring out correct handling of time is a challenge for operating
: > system programmers.
:
: Out of pure interest: what makes handling of time difficult?
: >From an uneducated point of view it's just updating a counter
: >From an uneducated point of view it's just updating a counter
: in software from a time source in hardware.
Simple, naive time keeping is easy. Look at all the folks that make
wrist watches.
However, when you are trying to get higher and higher accuracy for the
time, you have to talk to external folks. Doing this introduces
latency. There's variation in this latency, and that limits the
synchronization of the times. Also, there are a number of
environmental factors that affect the quality of the underlying time
keeping hardware since most crystals are sensitive to temperature.
Warner
A 33.31 format would buy us a century, still allow us to get
nanoseconds right, but it be computationally inconvenient and
looks messy, so people balk at it.
Anything wrong with TAI64NA?
"libtai is a library for storing and manipulating dates and times.
libtai supports two time scales: (1) TAI64, covering a few hundred
billion years with 1-second precision; (2) TAI64NA, covering the same
period with 1-attosecond precision. Both scales are defined in terms
of TAI, the current international real time standard. "
TAI64NA in FPGA?
--
http://www.wearablesmartsensors.com/
http://www.softwaresafety.net/
http://www.designer-iii.com/
http://www.unusualresearch.com/