Subject: Re: Summary so far...
To: Bucky Katz <firstname.lastname@example.org>
From: =?UTF-8?Q?Karl_Sj=C3=B6dahl_-_dunceor?= <email@example.com>
Date: 06/14/2007 13:14:49
On 6/14/07, Bucky Katz <firstname.lastname@example.org> wrote:
> Allen Briggs <email@example.com> writes:
> > I've been trying to keep track of the various topics discussed so
> > far and a few more things that came to my mind while assembling
> > the notes.
> > Comments are, of course, still welcome.
> > -allen
> > ---+ Embedded NetBSD
> > There are several classes of embedded systems that we look at here,
> > knowing that many devices may not fit neatly into each category:
> > * Handheld/kiosk devices
> > * Have more complex and interactive user interface than others
> > * May have limited networking needs
> > * Probably limited ROM / RAM resources
> Note that cell phones are different than traditional handheld devices.
In what way are they so different? Only thing that is different is the
close work with RF antenna. Otherwise it's pretty much the same with a
decent size flash, decent size ram.
> > * Flash support
> > * Support for NOR devices (CFI, et al.)
> > * Support for NAND devices
> > * Flash filesystem
> > * wear leveling
> > * makefs support
> There is a large body of experience that suggests that treating NOR
> and NAND devices as similar and lumping them all together as "Flash"
> tends to lead to poor designs with respect to NAND.
> > ---+++ Debug / optimization
> > * Power management (conserve power when idle / semi-idle)
> > * powertop-like functionality?
> > * power usage logging / reporting facilities
> Power management on handheld devices is not an optimization. Battery
> life often determines the market acceptance of a handheld device.
Well it is optimization, see so different time consuming functions run
as little as possible and see that when it goes down in power save,
everything is turned off that does not need to be on. Hardest part is
that a lot of the power saving work is done by hardware guys but
software guys is good support in chasing current.
> > * Remote debugging (via firewire or ip? gdb w/ kdp?, ssh-to-ddb? esp?)
> If you do USB client then CDC ethernet ip debugging is prefered.