Embedded RTOS - features poll

On Mon, 20 Sep 2010 14:09:33 -0700, D Yuniskis
<not.going.to.be@seen.com> wrote:

>Hi Paul,
>
>Paul Keinanen wrote:
>> On Mon, 20 Sep 2010 10:33:23 -0700, Jon Kirwan
>> <jonk@infinitefactors.org> wrote:
>> 
>>> A minimally compiled system does NOT have a real-time clock,
>> 
>> An interrupt caused by the RT clock is no different from any other
>> interrupt.
>
>Some systems rely on the jiffy being "special".  <frown>

By jiffy I assume you are referring to Linux ?

Originally Unix was just an other time sharing system.

Fortunately Linux also has a purely priority based scheduling,
otherwise it would not be usable for any real work :-).

>
>>> quantums, 
>> 
>> What is that ? A feature of the 1960's time sharing systems ?
>
><grin>  Actually, I typically allow each task to have a priority
>and/or a "timeslice" (which I will assume "quantum" is intended to
>reference).  This can be a win for tuning on smaller systems.
>On larger systems, it provides a subdivision of "round robin"
>scheduling (i.e., allowing you to give a bigger piece of the
>"robin" to one task over another)

There is something wrong in an RT system design, if you put several
tasks on the same priority.

>
>>> semaphores, messages, 
>> 
>> These are syntactic sugar
>> 
>>> thread priorities, 
>> 
>> In a simple system, the priorities are defined by the order, in which
>> you declare them. 
>> 
>> There are extremely rare cases (one in a million) in which you really
>> need to change the priority at run time.
>
>Ignoring, of course, protocols to handle priority inversion?

The first time I heard the expression "priority inversion" was when
NASA had problems with it on a rover on Mars. Before that I have made
multitasking systems for decades, without similar problems. Of course,
maintaining a clear data ownership and for small data entities atomic
access helps a lot.

>I've been experimenting with dynamically altering priorities of
>tasks based on user activities.  Mainly in an attempt to anticipate
>future needs so I can have the "results" ready before the user
>asks for them.
>
>Historically, timesharing systems would use priority aging as a
>hack to improve the performance of short-lived and interactive
>tasks (processes/programs).
>
>The problem with all these scheduling parameters is that they
>are often abused by folks who haven't properly designed their
>"system" and aren't getting the behavior/performance they want.
>Akin to throwing things in an ISR because your application
>architecture doesn't address the timeliness of that particular
>"thing", adequately.
>
>Once you start *playing* with these parameters, it's easy to
>find yourself in the role of <fill-in-favorite-derogatory-ethnicity>
>Carpenter trimming the legs on the tipsy dinner table:
>"Ooops!  Too short!"

The first rule of RT system tuning is to find jobs that could be moved
to a _lower_ priority. 

Unfortunately, most people seem to intuitively try to increase the
priority of some "important" task :-(.

Hi Paul,

Paul Keinanen wrote:
> On Mon, 20 Sep 2010 14:09:33 -0700, D Yuniskis
> <not.going.to.be@seen.com> wrote:
> 
>> Paul Keinanen wrote:
>>> On Mon, 20 Sep 2010 10:33:23 -0700, Jon Kirwan
>>> <jonk@infinitefactors.org> wrote:
>>>
>>>> A minimally compiled system does NOT have a real-time clock,
>>> An interrupt caused by the RT clock is no different from any other
>>> interrupt.
>> Some systems rely on the jiffy being "special".  <frown>
> 
> By jiffy I assume you are referring to Linux ?

The "system tick" is often referred to as the "jiffy".
Since most MTOS's only support a single "clock", this
tends to also drive the scheduler.

> Originally Unix was just an other time sharing system.
> 
> Fortunately Linux also has a purely priority based scheduling,
> otherwise it would not be usable for any real work :-).

Do people actually *do* work on Linux?  Seems most folks work
on Linux *itself*!  :>

>>>> quantums, 
>>> What is that ? A feature of the 1960's time sharing systems ?
>> <grin>  Actually, I typically allow each task to have a priority
>> and/or a "timeslice" (which I will assume "quantum" is intended to
>> reference).  This can be a win for tuning on smaller systems.
>> On larger systems, it provides a subdivision of "round robin"
>> scheduling (i.e., allowing you to give a bigger piece of the
>> "robin" to one task over another)
> 
> There is something wrong in an RT system design, if you put several
> tasks on the same priority.

If there is no inherent relationship between those tasks, then
how do you prioritize them? If I have a box "running my home",
what are the *relative* priorities of the HVAC controller and
the irrigation controller and the burglar alarm?

>>>> semaphores, messages, 
>>> These are syntactic sugar
>>>
>>>> thread priorities, 
>>> In a simple system, the priorities are defined by the order, in which
>>> you declare them. 
>>>
>>> There are extremely rare cases (one in a million) in which you really
>>> need to change the priority at run time.
>> Ignoring, of course, protocols to handle priority inversion?
> 
> The first time I heard the expression "priority inversion" was when
> NASA had problems with it on a rover on Mars. Before that I have made
> multitasking systems for decades, without similar problems. Of course,
> maintaining a clear data ownership and for small data entities atomic
> access helps a lot.

Yes.  I always make sure that I remember the role of an OS is to
make my (developer) life easier by taking care of "things" for me
(that are either too boring to attend to *or* too *tedious*).  As
systems get more complex -- especially systems that *grow* -- it
gets hard to keep track of all the interactions between (shared)
objects and entities.  A good candidate for an OS service!

>> I've been experimenting with dynamically altering priorities of
>> tasks based on user activities.  Mainly in an attempt to anticipate
>> future needs so I can have the "results" ready before the user
>> asks for them.
>>
>> Historically, timesharing systems would use priority aging as a
>> hack to improve the performance of short-lived and interactive
>> tasks (processes/programs).
>>
>> The problem with all these scheduling parameters is that they
>> are often abused by folks who haven't properly designed their
>> "system" and aren't getting the behavior/performance they want.
>> Akin to throwing things in an ISR because your application
>> architecture doesn't address the timeliness of that particular
>> "thing", adequately.
>>
>> Once you start *playing* with these parameters, it's easy to
>> find yourself in the role of <fill-in-favorite-derogatory-ethnicity>
>> Carpenter trimming the legs on the tipsy dinner table:
>> "Ooops!  Too short!"
> 
> The first rule of RT system tuning is to find jobs that could be moved
> to a _lower_ priority. 
> 
> Unfortunately, most people seem to intuitively try to increase the
> priority of some "important" task :-(.

*EXACTLY*!  I recently posed a related question regarding how
people tweek things and the psychology employed.  E.g., if you
are doing N things on your workstation ("PC") and are particularly
interested in one of them,  how do you "bias" the machine to
expedite the "task" (activity) that you are focused on?  We
tend to "kill" activities that we consider least important in
the hope that this will help the *desired* activity proceed
faster.  But, we don't even consider how many resources are
being used by that "killed" activity when we make the decision
to terminate it.   Wouldn't a more meaningful interface (in
this example) be a facility that lets you *elevate* an activity's
importance (nice -1000) instead of having to *de-emphasize* everything
else?

[note that this is the exact opposite condition from what you
are describing -- sort of.  :>  In your scenario, the developer
should have been disciplined to run each task at "the lowest
possible priority".  In the workstation example I posed, the user
doesn't think in terms of how he might want to refine his priorities
ex post facto while he is "creating" those "activities"]

On Mon, 20 Sep 2010 22:06:58 -0700, D Yuniskis
<not.going.to.be@seen.com> wrote:

>Hi Paul,
>
>Paul Keinanen wrote:
>> On Mon, 20 Sep 2010 14:09:33 -0700, D Yuniskis
>> <not.going.to.be@seen.com> wrote:


>> There is something wrong in an RT system design, if you put several
>> tasks on the same priority.
>
>If there is no inherent relationship between those tasks, then
>how do you prioritize them? If I have a box "running my home",
>what are the *relative* priorities of the HVAC controller and
>the irrigation controller and the burglar alarm?

That should not be hard.

Anyway, you may have to divide each tasks into several subtasks with
different priorities. Anyway, each task should not need to run for
more than a millisecond or in the "running my home" example for more
than a minute.
 

>>>>> thread priorities, 
>>>> In a simple system, the priorities are defined by the order, in which
>>>> you declare them. 
>>>>
>>>> There are extremely rare cases (one in a million) in which you really
>>>> need to change the priority at run time.
>>> Ignoring, of course, protocols to handle priority inversion?
>> 
>> The first time I heard the expression "priority inversion" was when
>> NASA had problems with it on a rover on Mars. Before that I have made
>> multitasking systems for decades, without similar problems. Of course,
>> maintaining a clear data ownership and for small data entities atomic
>> access helps a lot.
>
>Yes.  I always make sure that I remember the role of an OS is to
>make my (developer) life easier by taking care of "things" for me
>(that are either too boring to attend to *or* too *tedious*).  As
>systems get more complex -- especially systems that *grow* -- it
>gets hard to keep track of all the interactions between (shared)
>objects and entities.  A good candidate for an OS service!

Some of these issues are really high level architectural decisions. If
done improperly, you end up with lot of locking requirements etc.

In the 1980's I was running a department making control systems based
on PDP-11/RSX-11 systems. These machines had a program addressable
space of 64 KiB and a maximum physical memory of 256 KiB or 4 MiB.

Once I got the invitation to tender, I split the problem into tasks,
decided about what data should be owned by each task and how they are
going to communicate with each other, assign preliminary priorities,
thinking about which person in my team should do each task and after
that start to think, how long it takes to make each task before
writing the tender.

We never had problems fitting each program into 64 KiB and the
projects were much better within budget than other departments working
with the "unlimited" VAX addressing space.
 

Hi,

thanks for your response

On Sep 20, 7:35=A0pm, Warren <ve3...@gmail.com> wrote:

> Stargazer expounded in news:67fc4024-eeeb-4fe5-a1cf-
> a71f9d56b...@z34g2000pro.googlegroups.com:
> ..
>
> > I want to make something that is working well and useful,
>
> I think that one of your first steps will be to determine
> the size constraints of the MCU(s) you want to support.

I think it will depend on projects. I currently have support for ARM9,
MIPS32 and x86, MIPS64 was barely seen to work on emulator; MSP430 (16-
bit) is likely to be supported, PPC 32/64 bits are possible, but I
have to understand the requirements in the field that they are used.

> What I look for in an 8-bit RTOS (if at all) is going to
> be entirely different than a 32-bit platform. =A0The 8-bit
> resource limitations can be extreme, so you need to know
> up front what limitations you are prepared to design for.

Projects that are built around 8-bit MCUs have even more "custom"
needs than stronger CPU-based. I do most of the work for 32/64 bit
CPUs, so I know many questions in their application field that current
OS offer doesn't answer (or is not known to answer). I understand 8-
bit MCUs field less (mostly evaluations and stories where projects
switched from 8-bit MCU to more capable due to increasing
requirements), it seems to me that projects based on them count every
feature against cents of cost. I think that for 8-bit MCU you may only
be interested in memory (?) / task (?) management, flash interface and
chip support library. All this is easily isolated from my OS, but I
have to do a real 8-bit project to verify what issues I may have
there.

In principle, there is nothing that prevents my OS from porting to 8-
bit MCU without MMU.

> Can you implement a file system with 1K of SRAM? =A0Its
> difficult, but I've done if for FAT16/32. =A0You have to
> play some shell games with sector buffers to make it
> possible. But this emphasizes the point that a file
> system implementation for 8-bit is going to be a lot
> different than a 32-bit platform. Resource limitations
> enforce some practical realities.

Probably I can do that, but I don't see how this implementation could
be included in common OS code. Implementation will be grossly
different between 1K, 2K and 4K of RAM, and it will probably not work
on USB disks at all. It may be used as reference code to recall ideas,
but I don't even see how this can be used for other project for
anything else than 1K requirement.

> If not 8-bit, then are you looking at small, medium or
> large footprints, or all of the above? The choices made
> here will affect your compromises and "usefulness" to
> a target audiences.

I take Linux as scalability example, it scales well from relatively
resource-limited to multiprocessor high-end systems. I believe that
the most natural application field for my OS is small to medium
resourced 32-bit and 64-bit systems (higher-end systems usually have
less performance / footprint problems with Linux, and as of now it
will be hard for me to compete in features offer due to architecture
differences - porting of open-source code from Linux to my OS is not
entirely smooth). Things may change, however.

> And, is this going to be open sourced?

Due to my own (in many cases painful) experience, developer that uses
an embedded OS must be provided with complete buildable source code.
Such an OS must help to developer with its ready features, interfaces
and frameworks, but not prevent him from understanding how it works in
details and changing it to suit his needs. I am not sure as of now if
it will be "free beer" itself or not, and what restrictions will be
suitable if customer wants to massively redistribute it (I don't want
it to absorb too much third-party perceptions).

> > The OS will have to build feature list and..
>
> I cringe whenever I see "feature list" mentioned.
> People new to software engineering tend to throw
> things in with the naive belief that "more features"
> is somehow "better".

Well, I'm not very new to engineering (almost two decades). However, I
do believe that "more features" is "better" (just that if you don't
need something it shouldn't be there for you to stumble). When I meet
with a client and they say that they want to do this and that, I first
of all evaluate what software offer exists, and what features we have
ready. Usually, if not enough features can be readily collected, the
project never leaves requirements stage.

> I prefer a design to start with the known
> bare essentials. Then analyze what is missing by
> putting it to work. What is missing becomes obvious
> when you actually try to apply something. And
> even then, resist the "because I can" temptation to
> add things. Everything that is "added" becomes a
> support burden down the road.
>
> An example of a kitchen sink item, is support for
> linked lists in the RTOS. =A0If required at all, this
> should be put in an application library. It doesn't
> belong in O/S level support. =A0But I've seen it in
> at least one RTOS, because someone thought this
> added to the "feature list". (To be fair however,
> the RTOS may have used this feature internally,
> and thus it cost little extra to export this
> service -- I didn't check on that).

Well, features that I meant are something different. Examples:

* Priority-based task scheduler
* Standard C library
* POSIX I/O
* pthreads
* TCP/IP stack
* PCI host and enumeration support
* telnet server
* HTTP server
* CPU 'x' port
* Platform 'y' support (chip1, bus2, etc.)

etc.

IMO, lists are not part of OS feature list. E.g. I use softed lists to
implement installable timers and some other things, but if you don't
use all that and don't use them yourself, then they are not in your
build and not affect your footprint. The same goes for what IMO are OS
features.

> To summarize, "less" is "more". =A0Small software projects
> that are focused on essentials are easier to build/port
> and support. =A0For example, I like the avr-threads
> package over an RTOS (for 8-bitters) because it is so
> focused on what is needed- only threads, mutexes and
> events. =A0Not the extra baggage of features I have no
> need for.

In principle, there's nothing that prevents from using my OS with
custom task manager. There are some things that need to be done,
however, as drivers, sockets, timers atc. use native task manager API
to put tasks to sleep and wake them - all that needs to be changed to
work with a different task management system. Source code will be
handy.

> I know that Mach kernels are an old idea these days, but
> perhaps a good implementation of Mach on a suitable
> range of hardware might be something better than a
> "YARTOS" (Yet Another RTOS). Just an idea.

I think that microkernels and their derivatives didn't prove
themselves. They possible designs, they are better in some theoretic
issues, but they solve real needs worse than what is currently
popular. Just my opionion, but industry seems to back it.

> You should also spend time to study what other people
> have done- this will quickly tell you what you didn't
> like about each, and what you did like about each. Learn
> from the other projects- it may save you from making
> similar mistakes.

Somebody here suggested looking at academia - as of academic
offsprings TRON got to the most developed stage, but it follows
"classic" (single-address space, single binary, monolithic kernel)
embedded OS design.

From what I know, most RTOSes, including the most well-known (VxWorks,
pSOS, LynxOS) were developed in the same way that I'm going to do. I
already put in some thought, but don't see something better. I think
that other custom OSes that people write (individuals and companies)
follow the same way, eventually stopping or settling at some point
along the way. It's hard to tell why the "well-known" guys got to the
point of extremely low quality and selling non-working features that
got the embedded OS field where it is today - they won't tell me.

Thanks,
Daniel

Vladimir Vassilevsky expounded in 
news:oeidnTWnfd1fMgrRnZ2dnUVZ_sidnZ2d@giganews.com:

> Warren wrote:
> 
>> Can you implement a file system with 1K of SRAM?  Its 
>> difficult, but I've done if for FAT16/32.
> 
> One guy showed me his very minimal FAT implementation which took less 
> then 512 bytes of RAM. There is no need to buffer a full sector. This, 
> of course, implied tremendous overhead and inconvenience.

Indeed!

>>  You have to 
>> play some shell games with sector buffers to make it 
>> possible.  But this emphasizes the point that a file
>> system implementation for 8-bit is going to be a lot 
>> different than a 32-bit platform. Resource limitations
>> enforce some practical realities.
> 
> The real point is that it is plain stupid to mount things like FAT or 
> USB host or TCP/IP on 8-bitter with 1K of RAM. It is not wothy, those 
> are be crippled implementations with lots of limitations.
> 
> VLV

Of course it is limited, but hardly stupid. You don't need
a linux kernel on a 32/64 bit platform doing data logging.

You can of course accomplish this with a little 8-bitter, 
logging to a FATFS on a stick. It simply takes a little 
planning.

Warren

Hi Paul,

Paul Keinanen wrote:
> On Mon, 20 Sep 2010 22:06:58 -0700, D Yuniskis
>>> There is something wrong in an RT system design, if you put several
>>> tasks on the same priority.
>> If there is no inherent relationship between those tasks, then
>> how do you prioritize them? If I have a box "running my home",
>> what are the *relative* priorities of the HVAC controller and
>> the irrigation controller and the burglar alarm?
> 
> That should not be hard.
> 
> Anyway, you may have to divide each tasks into several subtasks with
> different priorities. Anyway, each task should not need to run for
> more than a millisecond or in the "running my home" example for more
> than a minute.

Of course.  I wasn't posing a real problem but, rather, illustrating
that (sometimes) tasks don't have a clear relationship to each other
in terms of priorities.

>>>>>> thread priorities, 
>>>>> In a simple system, the priorities are defined by the order, in which
>>>>> you declare them. 
>>>>>
>>>>> There are extremely rare cases (one in a million) in which you really
>>>>> need to change the priority at run time.
>>>> Ignoring, of course, protocols to handle priority inversion?
>>> The first time I heard the expression "priority inversion" was when
>>> NASA had problems with it on a rover on Mars. Before that I have made
>>> multitasking systems for decades, without similar problems. Of course,
>>> maintaining a clear data ownership and for small data entities atomic
>>> access helps a lot.
>> Yes.  I always make sure that I remember the role of an OS is to
>> make my (developer) life easier by taking care of "things" for me
>> (that are either too boring to attend to *or* too *tedious*).  As
>> systems get more complex -- especially systems that *grow* -- it
>> gets hard to keep track of all the interactions between (shared)
>> objects and entities.  A good candidate for an OS service!
> 
> Some of these issues are really high level architectural decisions. If
> done improperly, you end up with lot of locking requirements etc.

The trick in most (almost all??) multithreaded applications is
data sharing (or hiding) and communications.  This is the first
thing that I look at when facing a new design or evaluating
an existing design -- if either is poorly thought out, you end
up with lots of extra "work" (i.e., code) being done to
compensate.

The real challenge is figuring out how to come up with architectures
that support growth and revision without unduly penalizing them in
their initial/current form.  And, doing this in a deterministic
manner for real-time applications is doubly so!

> In the 1980's I was running a department making control systems based
> on PDP-11/RSX-11 systems. These machines had a program addressable
> space of 64 KiB and a maximum physical memory of 256 KiB or 4 MiB.
> 
> Once I got the invitation to tender, I split the problem into tasks,
> decided about what data should be owned by each task and how they are
> going to communicate with each other, assign preliminary priorities,
> thinking about which person in my team should do each task and after
> that start to think, how long it takes to make each task before
> writing the tender.
> 
> We never had problems fitting each program into 64 KiB and the
> projects were much better within budget than other departments working
> with the "unlimited" VAX addressing space.

Smaller, generally, *is* better.  Make threads inexpensive so the
user isn't discouraged from using them liberally.  I think the
same philosophy should apply to all OS mechanisms for similar
reasons -- if something is "expensive" (architecturally), then
developers will tend to avoid it... perhaps even when they *shouldn't*.

A consequence of this (IMO) is that you should offer the minimum
set of features required to provide the needed complement of
services.  I.e., don't do the same thing three different ways;
pick one and use it exclusively (e.g., use *one* type of
synchronization primitive) so that you can optimize *that*
implementation without having to accommodate other variations.

On Sep 20, 10:53=A0am, Chris H <ch...@phaedsys.org> wrote:
> In message <4C963A7C.2040...@given.com>, FreeRTOS info
> <noem...@given.com> writes
>
> >On 19/09/2010 16:31, Stargazer wrote:
> >> Greetings,
>
> >> I am writing my own RTOS, which I intend to use in my projects and
> >> license for anyone who would like to use it. At first I will use it in
> >> my own projects, so that it achieves a certain level of real-life
> >> performance and stability, then release it.
>
> >Just what the world needs - another RTOS. =A0Line up.
> >Regards,
> >Richard.
>
> Pot, Kettle, Black?
>
> There is nothing worse than some damned engineer doing their own RTOS,
> unless it is doing two RTOS..... :-))))
>
> >+http://www.FreeRTOS.org
> >Designed for Microcontrollers. =A0More than 7000 downloads per month.
>
> >+http://www.SafeRTOS.com
> >Certified by T=DCV as meeting the requirements for safety related system=
s.
>
> --
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> \/\/\/\/\ Chris Hills =A0Staffs =A0England =A0 =A0 /\/\/\/\/
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

I wouldn't try to knock his work too much.  FreeRTOS is very widely
used and is looking a bit like a defacto standard.  The SafeRTOS is
his paycheck and I am sure it is a bit harder to use "safely", so it
is much more likely that others will need his services to help with
their application.  I can't find any real fault with what he offers or
how he offers it.  I only wish I had something of this utility to
offer the world (and make an income from).

Rick

In article <Xns9DFA61F529F79SnarkCharmedFerSure@188.40.43.230>, 
snark@cogeco.ca says...
> Vladimir Vassilevsky expounded in 
> news:oeidnTWnfd1fMgrRnZ2dnUVZ_sidnZ2d@giganews.com:
> 
> > Warren wrote:
> > 
> >> Can you implement a file system with 1K of SRAM?  Its 
> >> difficult, but I've done if for FAT16/32.
> > 
> > One guy showed me his very minimal FAT implementation which took less 
> > then 512 bytes of RAM. There is no need to buffer a full sector. This, 
> > of course, implied tremendous overhead and inconvenience.
> 
> Indeed!
> 
> >>  You have to 
> >> play some shell games with sector buffers to make it 
> >> possible.  But this emphasizes the point that a file
> >> system implementation for 8-bit is going to be a lot 
> >> different than a 32-bit platform. Resource limitations
> >> enforce some practical realities.
> > 
> > The real point is that it is plain stupid to mount things like FAT or 
> > USB host or TCP/IP on 8-bitter with 1K of RAM. It is not wothy, those 
> > are be crippled implementations with lots of limitations.
> > 
> > VLV
> 
> Of course it is limited, but hardly stupid. You don't need
> a linux kernel on a 32/64 bit platform doing data logging.
> 
> You can of course accomplish this with a little 8-bitter, 
> logging to a FATFS on a stick. It simply takes a little 
> planning.

If you mean logging to a USB memory stick, that will require
your 8-bitter to implement a USB Host interface.

My approach has been to use SD or SD micro cards with an
in-house sequential file system.  It doesn't need an
RTOS,  just an interrupt handler to collect and queue
the data and a main loop to pull from the queue and 
write to SD.  That works up to about 400 16-bit samples
per second  on an average current around 10mA using
an MSP430.   I don't think you can run linux effectively
on 10mA at 3.3V.


Mark Borgerson

Mark Borgerson wrote:

> In article <Xns9DFA61F529F79SnarkCharmedFerSure@188.40.43.230>, 
> snark@cogeco.ca says...
> 
>>Vladimir Vassilevsky expounded in 
>>news:oeidnTWnfd1fMgrRnZ2dnUVZ_sidnZ2d@giganews.com:
>>
>>
>>>Warren wrote:
>>>
>>>
>>>>Can you implement a file system with 1K of SRAM?  Its 
>>>>difficult, but I've done if for FAT16/32.
>>>
>>>One guy showed me his very minimal FAT implementation which took less 
>>>then 512 bytes of RAM. There is no need to buffer a full sector. This, 
>>>of course, implied tremendous overhead and inconvenience.
>>
>>Indeed!
>>
>>
>>>> You have to 
>>>>play some shell games with sector buffers to make it 
>>>>possible.  But this emphasizes the point that a file
>>>>system implementation for 8-bit is going to be a lot 
>>>>different than a 32-bit platform. Resource limitations
>>>>enforce some practical realities.
>>>
>>>The real point is that it is plain stupid to mount things like FAT or 
>>>USB host or TCP/IP on 8-bitter with 1K of RAM. It is not wothy, those 
>>>are be crippled implementations with lots of limitations.
>>>
>>
>>Of course it is limited, but hardly stupid. You don't need
>>a linux kernel on a 32/64 bit platform doing data logging.
>>
>>You can of course accomplish this with a little 8-bitter, 
>>logging to a FATFS on a stick. It simply takes a little 
>>planning.
> 
> 
> If you mean logging to a USB memory stick, that will require
> your 8-bitter to implement a USB Host interface.

At least a part of USB host to support for the basic read/write 
operations on the mass storage device.

> My approach has been to use SD or SD micro cards with an
> in-house sequential file system.  It doesn't need an
> RTOS,  just an interrupt handler to collect and queue
> the data and a main loop to pull from the queue and 
> write to SD.  That works up to about 400 16-bit samples
> per second  on an average current around 10mA using
> an MSP430.   I don't think you can run linux effectively
> on 10mA at 3.3V.

We used simple sequential file system also, despite of the obvious 
limitations. Later we switched to FAT with POSIX API, and it was so much 
better. There is no need for Linux; a standalone full featured 
multithreaded FAT takes ~50kb + buffers. The power consumption is 
determined by the number of transactions per second rather then the 
memory size.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Mark Borgerson expounded in
news:MPG.27028556ec82117d989c4d@news.eternal-september.org: 

> In article <Xns9DFA61F529F79SnarkCharmedFerSure@188.40.43.230>, 
> snark@cogeco.ca says...
>> Vladimir Vassilevsky expounded in 
>> news:oeidnTWnfd1fMgrRnZ2dnUVZ_sidnZ2d@giganews.com:
>> 
>> > Warren wrote:
>> > 
>> >> Can you implement a file system with 1K of SRAM?  Its 
>> >> difficult, but I've done if for FAT16/32.
>> > 
>> > One guy showed me his very minimal FAT implementation which took
>> > less then 512 bytes of RAM. There is no need to buffer a full
>> > sector. This, of course, implied tremendous overhead and
>> > inconvenience. 
>> 
>> Indeed!
>> 
>> >>  You have to 
>> >> play some shell games with sector buffers to make it 
>> >> possible.  But this emphasizes the point that a file
>> >> system implementation for 8-bit is going to be a lot 
>> >> different than a 32-bit platform. Resource limitations
>> >> enforce some practical realities.
>> > 
>> > The real point is that it is plain stupid to mount things like FAT
>> > or USB host or TCP/IP on 8-bitter with 1K of RAM. It is not wothy,
>> > those are be crippled implementations with lots of limitations.
>> > 
>> > VLV
>> 
>> Of course it is limited, but hardly stupid. You don't need
>> a linux kernel on a 32/64 bit platform doing data logging.
>> 
>> You can of course accomplish this with a little 8-bitter, 
>> logging to a FATFS on a stick. It simply takes a little 
>> planning.
> 
> If you mean logging to a USB memory stick, that will require
> your 8-bitter to implement a USB Host interface.

Nope. Why bring USB into it?  Just use a SD memory card.
The interface for it is trivial.

> My approach has been to use SD or SD micro cards with an
> in-house sequential file system.  It doesn't need an
> RTOS,  just an interrupt handler to collect and queue
> the data and a main loop to pull from the queue and 
> write to SD.  ...
> Mark Borgerson

Fine, but that is not user friendly to the user receiving
the SD data. Now he/she needs a special app to pull it off
the stick.

OTOH, you can use minimal FATFS software to create and
write log file(s).

Anyone can just write sectors to the SD without a FS, but 
it is terribly inelegant.

Warren