Lpc2000

Hi! I am building a board featuring the LPC2138 µC. This board will 
basically need to interface with three serial devices (two via 
internal UARTs and a third via MAX3100, though suggestions are 
welcomed about this). This device must be very low power; it should 
wake up only when needed, which is: 1) there's data available from 
any of the three ports, 2) there's data waiting to be transmitted on 
any of the ports and the port becomes free and 3) a periodical 
overall check (every second or so). This means that theoretically the 
processor can enter the idle state quite often. I'm looking for some 
(free if possible) multithreaded OS that would handle the transition 
to the processor's idle state on traditionally blocking calls like 
fread() and fwrite(), expecting to wake up on interrupt; also, some 
preemptive multitasking should be supported, in case some thread 
enters an exceptionally long calculating task. Probably there's no 
known OS that directly supports this; in this case, I'd like to know 
which other OS might be a good starting point to accomplish this by 
making the modifications myself. I'm aiming to use the GNU libraries 
(I ignore how difficult or messy would it be to modify them to 
support this). Finally, it is my understanding that the VERY low 
power "power down" mode would not be useful for my application, since 
the peripherals (therefore the UARTs and SPI) are shut down in this 
mode. Any advise or hint on these subjects will be greately 
appreciated.

Guille

Hi there,

I just finished a project with the same problem. For the third UART I've used a SW made uart via GPIOs and it works @ 115200 baud rate. 

As for the OS I used mine, uSmartX. The OS can inform you when there is nothing to do (scheduler reurns SYS_IDLE) and I'm idling the CPU at that point. My power consumption dropped for ~30%.

If you want visit http://usmartx.sourceforge.net/ for more information regarding the OS.

Hope it helps,
marko

> 
> Od: "guillermoprandi" <yahoo.messenger@...>
> Datum: 2005/10/06 \ufffdet PM 02:37:46 CEST
> Za: lpc2000@yahoogroups.com
> Zadeva: [lpc2000] Low power multithreaded OS suggestion?
> 
> Hi! I am building a board featuring the LPC2138 ?C. This board will 
> basically need to interface with three serial devices (two via 
> internal UARTs and a third via MAX3100, though suggestions are 
> welcomed about this). This device must be very low power; it should 
> wake up only when needed, which is: 1) there's data available from 
> any of the three ports, 2) there's data waiting to be transmitted on 
> any of the ports and the port becomes free and 3) a periodical 
> overall check (every second or so). This means that theoretically the 
> processor can enter the idle state quite often. I'm looking for some 
> (free if possible) multithreaded OS that would handle the transition 
> to the processor's idle state on traditionally blocking calls like 
> fread() and fwrite(), expecting to wake up on interrupt; also, some 
> preemptive multitasking should be supported, in case some thread 
> enters an exceptionally long calculating task. Probably there's no 
> known OS that directly supports this; in this case, I'd like to know 
> which other OS might be a good starting point to accomplish this by 
> making the modifications myself. I'm aiming to use the GNU libraries 
> (I ignore how difficult or messy would it be to modify them to 
> support this). Finally, it is my understanding that the VERY low 
> power "power down" mode would not be useful for my application, since 
> the peripherals (therefore the UARTs and SPI) are shut down in this 
> mode. Any advise or hint on these subjects will be greately 
> appreciated.
> 
> Guille
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
>

Thanks a lot. Looks very interesting. I'll look into it. However, 
some preemptive multitasking is needed in my project since I must be 
able to perform some lengthy calculations in one task while still 
serving other tasks.

Guille

--- In lpc2000@yahoogroups.com, Marko Panger <marko.panger@s...> 
wrote:
> Hi there,
> 
> I just finished a project with the same problem. For the third UART 
I've used a SW made uart via GPIOs and it works @ 115200 baud rate. 
> 
> As for the OS I used mine, uSmartX. The OS can inform you when 
there is nothing to do (scheduler reurns SYS_IDLE) and I'm idling the 
CPU at that point. My power consumption dropped for ~30%.
> 
> If you want visit http://usmartx.sourceforge.net/ for more 
information regarding the OS.
> 
> Hope it helps,
> marko
> 
> > 
> > Od: "guillermoprandi" <yahoo.messenger@m...>
> > Datum: 2005/10/06 Èet PM 02:37:46 CEST
> > Za: lpc2000@yahoogroups.com
> > Zadeva: [lpc2000] Low power multithreaded OS suggestion?
> > 
> > Hi! I am building a board featuring the LPC2138 ?C. This board 
will 
> > basically need to interface with three serial devices (two via 
> > internal UARTs and a third via MAX3100, though suggestions are 
> > welcomed about this). This device must be very low power; it 
should 
> > wake up only when needed, which is: 1) there's data available 
from 
> > any of the three ports, 2) there's data waiting to be transmitted 
on 
> > any of the ports and the port becomes free and 3) a periodical 
> > overall check (every second or so). This means that theoretically 
the 
> > processor can enter the idle state quite often. I'm looking for 
some 
> > (free if possible) multithreaded OS that would handle the 
transition 
> > to the processor's idle state on traditionally blocking calls 
like 
> > fread() and fwrite(), expecting to wake up on interrupt; also, 
some 
> > preemptive multitasking should be supported, in case some thread 
> > enters an exceptionally long calculating task. Probably there's 
no 
> > known OS that directly supports this; in this case, I'd like to 
know 
> > which other OS might be a good starting point to accomplish this 
by 
> > making the modifications myself. I'm aiming to use the GNU 
libraries 
> > (I ignore how difficult or messy would it be to modify them to 
> > support this). Finally, it is my understanding that the VERY low 
> > power "power down" mode would not be useful for my application, 
since 
> > the peripherals (therefore the UARTs and SPI) are shut down in 
this 

> > mode. Any advise or hint on these subjects will be greately 
> > appreciated.
> > 
> > Guille
> > 
> > 
> > 
> > 
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> >

Guille
  Reply to me off-line and I might be able to pass along some 
Helpful information.

Regards
-Bill Knight
R O SoftWare &
http://www.theARMPatch.com

On Thu, 06 Oct 2005 12:37:46 -0000, guillermoprandi wrote:

>Hi! I am building a board featuring the LPC2138 µC. This board will 
>basically need to interface with three serial devices (two via 
>internal UARTs and a third via MAX3100, though suggestions are 
>welcomed about this). This device must be very low power; it should 
>wake up only when needed, which is: 1) there's data available from 
>any of the three ports, 2) there's data waiting to be transmitted on 
>any of the ports and the port becomes free and 3) a periodical 
>overall check (every second or so). This means that theoretically the 
>processor can enter the idle state quite often. I'm looking for some 
>(free if possible) multithreaded OS that would handle the transition 
>to the processor's idle state on traditionally blocking calls like 
>fread() and fwrite(), expecting to wake up on interrupt; also, some 
>preemptive multitasking should be supported, in case some thread 
>enters an exceptionally long calculating task. Probably there's no 
>known OS that directly supports this; in this case, I'd like to know 
>which other OS might be a good starting point to accomplish this by 
>making the modifications myself. I'm aiming to use the GNU libraries 
>(I ignore how difficult or messy would it be to modify them to 
>support this). Finally, it is my understanding that the VERY low 
>power "power down" mode would not be useful for my application, since 
>the peripherals (therefore the UARTs and SPI) are shut down in this 
>mode. Any advise or hint on these subjects will be greately 
>appreciated.

>Guille





> 
>Yahoo! Groups Links



>

Hello,

You can try free RTOS.

http://www.freertos.org/

----- Original Message ----- 
From: "guillermoprandi" <yahoo.messenger@...>
To: <lpc2000@yahoogroups.com>
Sent: Thursday, October 06, 2005 3:21 PM
Subject: [lpc2000] Re: Low power multithreaded OS suggestion?


Thanks a lot. Looks very interesting. I'll look into it. However,
some preemptive multitasking is needed in my project since I must be
able to perform some lengthy calculations in one task while still
serving other tasks.

Guille

--- In lpc2000@yahoogroups.com, Marko Panger <marko.panger@s...>
wrote:
> Hi there,
>
> I just finished a project with the same problem. For the third UART
I've used a SW made uart via GPIOs and it works @ 115200 baud rate.
>
> As for the OS I used mine, uSmartX. The OS can inform you when
there is nothing to do (scheduler reurns SYS_IDLE) and I'm idling the
CPU at that point. My power consumption dropped for ~30%.
>
> If you want visit http://usmartx.sourceforge.net/ for more
information regarding the OS.
>
> Hope it helps,
> marko
>
> >
> > Od: "guillermoprandi" <yahoo.messenger@m...>
> > Datum: 2005/10/06 Èet PM 02:37:46 CEST
> > Za: lpc2000@yahoogroups.com
> > Zadeva: [lpc2000] Low power multithreaded OS suggestion?
> >
> > Hi! I am building a board featuring the LPC2138 ?C. This board
will
> > basically need to interface with three serial devices (two via
> > internal UARTs and a third via MAX3100, though suggestions are
> > welcomed about this). This device must be very low power; it
should
> > wake up only when needed, which is: 1) there's data available
from
> > any of the three ports, 2) there's data waiting to be transmitted
on
> > any of the ports and the port becomes free and 3) a periodical
> > overall check (every second or so). This means that theoretically
the
> > processor can enter the idle state quite often. I'm looking for
some
> > (free if possible) multithreaded OS that would handle the
transition
> > to the processor's idle state on traditionally blocking calls
like
> > fread() and fwrite(), expecting to wake up on interrupt; also,
some
> > preemptive multitasking should be supported, in case some thread
> > enters an exceptionally long calculating task. Probably there's
no
> > known OS that directly supports this; in this case, I'd like to
know
> > which other OS might be a good starting point to accomplish this
by
> > making the modifications myself. I'm aiming to use the GNU
libraries
> > (I ignore how difficult or messy would it be to modify them to
> > support this). Finally, it is my understanding that the VERY low
> > power "power down" mode would not be useful for my application,
since
> > the peripherals (therefore the UARTs and SPI) are shut down in
this
> > mode. Any advise or hint on these subjects will be greately
> > appreciated.
> >
> > Guille
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >






Yahoo! Groups Links

Thanks, Gilles. Do you mean that free RTOS already handles entering 
the processor's idle mode off-the-box? Or should I mod it in order to 
achieve that? Does the 2106 port applies to 2138 without needing any 
modifications?

Guille

--- In lpc2000@yahoogroups.com, "Gilles FAURIE" <gilles.faurie@p...> 
wrote:
> Hello,
> 
> You can try free RTOS.
> 
> http://www.freertos.org/
> 
> 
> ----- Original Message ----- 
> From: "guillermoprandi" <yahoo.messenger@m...>
> To: <lpc2000@yahoogroups.com>
> Sent: Thursday, October 06, 2005 3:21 PM
> Subject: [lpc2000] Re: Low power multithreaded OS suggestion?
> 
> 
> Thanks a lot. Looks very interesting. I'll look into it. However,
> some preemptive multitasking is needed in my project since I must be
> able to perform some lengthy calculations in one task while still
> serving other tasks.
> 
> Guille
> 
> --- In lpc2000@yahoogroups.com, Marko Panger <marko.panger@s...>
> wrote:
> > Hi there,
> >
> > I just finished a project with the same problem. For the third 
UART
> I've used a SW made uart via GPIOs and it works @ 115200 baud rate.
> >
> > As for the OS I used mine, uSmartX. The OS can inform you when
> there is nothing to do (scheduler reurns SYS_IDLE) and I'm idling 
the
> CPU at that point. My power consumption dropped for ~30%.
> >
> > If you want visit http://usmartx.sourceforge.net/ for more
> information regarding the OS.
> >
> > Hope it helps,
> > marko
> >
> > >
> > > Od: "guillermoprandi" <yahoo.messenger@m...>
> > > Datum: 2005/10/06 Èet PM 02:37:46 CEST
> > > Za: lpc2000@yahoogroups.com
> > > Zadeva: [lpc2000] Low power multithreaded OS suggestion?
> > >
> > > Hi! I am building a board featuring the LPC2138 ?C. This board
> will
> > > basically need to interface with three serial devices (two via
> > > internal UARTs and a third via MAX3100, though suggestions are
> > > welcomed about this). This device must be very low power; it
> should
> > > wake up only when needed, which is: 1) there's data available
> from
> > > any of the three ports, 2) there's data waiting to be 
transmitted
> on
> > > any of the ports and the port becomes free and 3) a periodical
> > > overall check (every second or so). This means that 
theoretically

> the
> > > processor can enter the idle state quite often. I'm looking for
> some
> > > (free if possible) multithreaded OS that would handle the
> transition
> > > to the processor's idle state on traditionally blocking calls
> like
> > > fread() and fwrite(), expecting to wake up on interrupt; also,
> some
> > > preemptive multitasking should be supported, in case some thread
> > > enters an exceptionally long calculating task. Probably there's
> no
> > > known OS that directly supports this; in this case, I'd like to
> know
> > > which other OS might be a good starting point to accomplish this
> by
> > > making the modifications myself. I'm aiming to use the GNU
> libraries
> > > (I ignore how difficult or messy would it be to modify them to
> > > support this). Finally, it is my understanding that the VERY low
> > > power "power down" mode would not be useful for my application,
> since
> > > the peripherals (therefore the UARTs and SPI) are shut down in
> this
> > > mode. Any advise or hint on these subjects will be greately
> > > appreciated.
> > >
> > > Guille
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> 
> 
> 
> 
> 
> 
> Yahoo! Groups Links

>Thanks, Gilles. Do you mean that free RTOS already handles entering
>the processor's idle mode off-the-box? Or should I mod it in order to
>achieve that? Does the 2106 port applies to 2138 without needing any
>modifications?


The idle task will automatically execute when there are no user tasks able
to do so.  If you want low power, then the idle task can place the processor
into a sleep mode - this way the processor will automatically power save
whenever there is no processing to do.

The idle task is then nothing more than:

for( ;; )
{
    sleep_now(); // user defined.
}


Pre-emptive schedulers such as FreeRTOS configure a timer to generate a
periodic 'tick' interrupt.  Each tick interrupt will wake the processor, so
the faster the tick frequency the more power the processor will use.

The demo serial port drivers included in the FreeRTOS download use queues to
pass serial port data from interrupt routines to user tasks.  The interrupt
is fast as all it does is read the character from the register and place it
into the queue.  The task that processes the data can block on the queue
waiting for data to become available, so does not use any more processing
power than necessary.

Regards,
Richard.


http://www.FreeRTOS.org

Thanks. Looks mostly like what I need. I'd like to make the OS to 
enter a slower tick rate when there's no more processing to do, but 
this change looks trivial if all other issues are taken care of.

My next thing would be to investigate how to "hook" the GNU STDIO 
libraries into this scheme.

Guille

--- In lpc2000@yahoogroups.com, "FreeRTOS Info" <nospam@F...> wrote:
> >Thanks, Gilles. Do you mean that free RTOS already handles entering
> >the processor's idle mode off-the-box? Or should I mod it in order 
to
> >achieve that? Does the 2106 port applies to 2138 without needing 
any
> >modifications?
> 
> 
> The idle task will automatically execute when there are no user 
tasks able
> to do so.  If you want low power, then the idle task can place the 
processor
> into a sleep mode - this way the processor will automatically power 
save
> whenever there is no processing to do.
> 
> The idle task is then nothing more than:
> 
> for( ;; )
> {
>     sleep_now(); // user defined.
> }
> 
> 
> Pre-emptive schedulers such as FreeRTOS configure a timer to 
generate a
> periodic 'tick' interrupt.  Each tick interrupt will wake the 
processor, so
> the faster the tick frequency the more power the processor will use.
> 
> The demo serial port drivers included in the FreeRTOS download use 
queues to
> pass serial port data from interrupt routines to user tasks.  The 
interrupt
> is fast as all it does is read the character from the register and 
place it
> into the queue.  The task that processes the data can block on the 
queue
> waiting for data to become available, so does not use any more 
processing

> power than necessary.
> 
> Regards,
> Richard.
> 
> 
> http://www.FreeRTOS.org

> Thanks. Looks mostly like what I need. I'd like to make the OS to
> enter a slower tick rate when there's no more processing to do, but
> this change looks trivial if all other issues are taken care of.

Changing the tick rate at run time is only trivial if you do not have very
strict timing requirements.

For example, if one of your tasks wants to execute exactly every 5ms, it can
use the xTaskDelayUntil() API call.  This will calculate the tick count (the
number of times the tick ISR has executed) at which the task should next
execute.  If you change the tick frequency after this then you have a
problem.

If all your blocking calls block for an event (eg serial data rx), as
opposed to a time, then it is not a problem.  Also if your timing
requirements are less strict then also it might not be a problem.  So this
is really application dependent.

Regards,
Richard.


http://www.FreeRTOS.org

> Thanks. Looks mostly like what I need. I'd like to make the OS to
> enter a slower tick rate when there's no more processing to do, but
> this change looks trivial if all other issues are taken care of.

Some more ideas for software power savings:
1.  Power off each peripheral not in use.  Control on the fly.

2.  Enter idle mode in your RTOS idle loop.  Idle mode stops the processor 
clock, but peripherals stay up.  This is a similar to power consumption of a 
DC light controlled via PWM.

3.  If app can afford 4096+ clk dly post interrupt, enter Power Down in RTOS 
idle loop.  Wakeup condition via external interrupt.  Be sure to read the 
Wakeup Timer section in UM_LPC21XX_LPC22XX_2.pdf

Hi Guille,

Philips is to launch SPI/I2C SC16IS750/760 single UART (16C450 equiv.)
with up to 8 I/Os soon. HVQFN24 and TSSOP24 packages. Double UARTs on
SPI/I2C will folow.

Rgds,
Janusz

-----Original Message-----
From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
Of guillermoprandi
Sent: Thursday, October 06, 2005 2:38 PM
To: lpc2000@...m
Subject: [lpc2000] Low power multithreaded OS suggestion?

Hi! I am building a board featuring the LPC2138 µC. This board will 
basically need to interface with three serial devices (two via 
internal UARTs and a third via MAX3100, though suggestions are 
welcomed about this). This device must be very low power; it should 
wake up only when needed, which is: 1) there's data available from 
any of the three ports, 2) there's data waiting to be transmitted on 
any of the ports and the port becomes free and 3) a periodical 
overall check (every second or so). This means that theoretically the 
processor can enter the idle state quite often. I'm looking for some 
(free if possible) multithreaded OS that would handle the transition 
to the processor's idle state on traditionally blocking calls like 
fread() and fwrite(), expecting to wake up on interrupt; also, some 
preemptive multitasking should be supported, in case some thread 
enters an exceptionally long calculating task. Probably there's no 
known OS that directly supports this; in this case, I'd like to know 
which other OS might be a good starting point to accomplish this by 
making the modifications myself. I'm aiming to use the GNU libraries 
(I ignore how difficult or messy would it be to modify them to 
support this). Finally, it is my understanding that the VERY low 
power "power down" mode would not be useful for my application, since 
the peripherals (therefore the UARTs and SPI) are shut down in this 
mode. Any advise or hint on these subjects will be greately 
appreciated.

Guille





 
Yahoo! Groups Links

> 3.  If app can afford 4096+ clk dly post interrupt, enter Power 
Down in RTOS 
> idle loop.  Wakeup condition via external interrupt.  Be sure to 
read the 
> Wakeup Timer section in UM_LPC21XX_LPC22XX_2.pdf

I don't think I can use power down mode, because I need to wake up 
upon new character arrive at the UARTs. Here's my reasoning, please 
correct me if I'm wrong: I think the UARTs are off on power down 
mode, so even if I externally cheat an interrupt at the character's 
start bit, the UART wouldn't wake up fast enough to receive the 
character (at 57600 bauds). It would take at least ~410 µS to wake up 
with a 10 MHz xtal. One bit at 57600 is ~17µS.

Guille

--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote:
> > Thanks. Looks mostly like what I need. I'd like to make the OS to
> > enter a slower tick rate when there's no more processing to do, 
but
> > this change looks trivial if all other issues are taken care of.
> 
> Some more ideas for software power savings:
> 1.  Power off each peripheral not in use.  Control on the fly.
> 
> 2.  Enter idle mode in your RTOS idle loop.  Idle mode stops the 
processor 
> clock, but peripherals stay up.  This is a similar to power 
consumption of a 
> DC light controlled via PWM.
> 
> 3.  If app can afford 4096+ clk dly post interrupt, enter Power 
Down in RTOS 
> idle loop.  Wakeup condition via external interrupt.  Be sure to 
read the 
> Wakeup Timer section in UM_LPC21XX_LPC22XX_2.pdf

> > 3.  If app can afford 4096+ clk dly post interrupt, enter Power
> Down in RTOS 
> > idle loop.  Wakeup condition via external interrupt.  Be sure to
> read the 
> > Wakeup Timer section in UM_LPC21XX_LPC22XX_2.pdf
> 
> I don't think I can use power down mode, because I need to 
> wake up upon new character arrive at the UARTs. Here's my 
> reasoning, please correct me if I'm wrong: I think the UARTs 
> are off on power down mode, so even if I externally cheat an 
> interrupt at the character's start bit, the UART wouldn't 
> wake up fast enough to receive the character (at 57600 
> bauds). It would take at least ~410 µS to wake up with a 10 
> MHz xtal. One bit at 57600 is ~17µS.

You're right. You'll miss many characters at the start during wakeup. Often this isn't a problem as whatever is at the other end may re-send the message if it gets not reply. It all depends on your application. We have a system that does exactly the cheat above, reprogramming the RX1 Uart Pin to be an external interrupt before going to sleep, and in our case it works well. 

[Note, however, with the lpc2124 at least there seems to be some unresolved strangeness when you are trying to use all external interrupts to wake-up depending on the combination of edges and polarities: in some situations 1 of the 3 won't work. I *think* these problems go away with lpc2123 and later when Philips fixed the VPBDIV bugs.]

Cheers,
Bruce

>> 3.  If app can afford 4096+ clk dly post interrupt, enter Power
>Down in RTOS
>> idle loop.  Wakeup condition via external interrupt.  Be sure to
>read the
>> Wakeup Timer section in UM_LPC21XX_LPC22XX_2.pdf
>
>I don't think I can use power down mode, because I need to wake up
>upon new character arrive at the UARTs. Here's my reasoning, please
>correct me if I'm wrong: I think the UARTs are off on power down
>mode, so even if I externally cheat an interrupt at the character's
>start bit, the UART wouldn't wake up fast enough to receive the
>character (at 57600 bauds). It would take at least ~410 \ufffdS to wake up
>with a 10 MHz xtal. One bit at 57600 is ~17\ufffdS.

No clearly your application could not afford the 4096+ clk dly post 
interrupt.
Perhaps a combination of Option 1 and Option 2 is your best best.

guillermoprandi <yahoo.messenger@...> schrieb am Thu, 06 Oct 
2005 12:37:46 -0000:


> I'm looking for some
> (free if possible) multithreaded OS that would handle the transition
    ^^^^
Seems no-one wants to pay for SW anymore ?!

> to the processor's idle state on traditionally blocking calls like
> fread() and fwrite(), expecting to wake up on interrupt; also, some
> preemptive multitasking should be supported, in case some thread
> enters an exceptionally long calculating task. Probably there's no
> known OS that directly supports this;

Any pre-emptiv RTOS out there supports this (non-free Sciopta e.g.
(my companies one)).

All the OS must provide is a way to know when it is idle, which is either
a OS hook or a special process.

Then it is up to you to enter low-power mode, means it depends largely
on the uC you use.

Some (like Sciopta and OSE Epsilon) even allow you to power-off your 
application given you preserve the current state (non-volatile RAM).

This technic is used e.g. in some BlueTooth chips, where the ARM cpu
is 70% of the time off.

-- 
42Bastian Schick

guillermoprandi wrote:
> Hi! I am building a board featuring the LPC2138 \ufffdC. This board will 
> basically need to interface with three serial devices (two via 
> internal UARTs and a third via MAX3100, though suggestions are 
> welcomed about this). This device must be very low power; it should 
> wake up only when needed, which is: 1) there's data available from 
> any of the three ports, 2) there's data waiting to be transmitted on 
> any of the ports and the port becomes free and 3) a periodical 
> overall check (every second or so). This means that theoretically the 
> processor can enter the idle state quite often. I'm looking for some 
> (free if possible) multithreaded OS that would handle the transition 
> to the processor's idle state on traditionally blocking calls like 
> fread() and fwrite(), expecting to wake up on interrupt; also, some 
> preemptive multitasking should be supported, in case some thread 
> enters an exceptionally long calculating task. Probably there's no 
> known OS that directly supports this; in this case, I'd like to know 
> which other OS might be a good starting point to accomplish this by 
> making the modifications myself. I'm aiming to use the GNU libraries 
> (I ignore how difficult or messy would it be to modify them to 
> support this). Finally, it is my understanding that the VERY low 
> power "power down" mode would not be useful for my application, since 
> the peripherals (therefore the UARTs and SPI) are shut down in this 
> mode. Any advise or hint on these subjects will be greately 
> appreciated.
> 
> Guille

Hello Guille,

if you are looking for a full-featured preemtive multitasking RTOS using
CPU idle mode just have a look at

   http://www.net-attack.de/


Sten

-- 
/************************************************
 Do you need a tiny and efficient real time
 operating system (RTOS) with a preemtive
 multitasking for LPC2000 or AT91SAM7?

   http://nanortos.net-attack.de/

 Or some open-source tools and code for LPC2000?

   http://www.net-attack.de/

************************************************/

Thanks, Sten. The web site doesn't mention the software cost. Due to 
the structure of the project, I cannot enter any intrincated 
licensing schemes (such as tied to a defined number of units 
produced). Could you post the cost here? For example, for a single 
product line (a product and its successors), for life?

Guille

--- In lpc2000@yahoogroups.com, Sten <list@n...> wrote:
>
> guillermoprandi wrote:
> > Hi! I am building a board featuring the LPC2138 µC. This board 
will 
> > basically need to interface with three serial devices (two via 
> > internal UARTs and a third via MAX3100, though suggestions are 
> > welcomed about this). This device must be very low power; it 
should 
> > wake up only when needed, which is: 1) there's data available 
from 
> > any of the three ports, 2) there's data waiting to be transmitted 
on 
> > any of the ports and the port becomes free and 3) a periodical 
> > overall check (every second or so). This means that theoretically 
the 
> > processor can enter the idle state quite often. I'm looking for 
some 
> > (free if possible) multithreaded OS that would handle the 
transition 
> > to the processor's idle state on traditionally blocking calls 
like 
> > fread() and fwrite(), expecting to wake up on interrupt; also, 
some 
> > preemptive multitasking should be supported, in case some thread 
> > enters an exceptionally long calculating task. Probably there's 
no 
> > known OS that directly supports this; in this case, I'd like to 
know 
> > which other OS might be a good starting point to accomplish this 
by 
> > making the modifications myself. I'm aiming to use the GNU 
libraries 
> > (I ignore how difficult or messy would it be to modify them to 
> > support this). Finally, it is my understanding that the VERY low 
> > power "power down" mode would not be useful for my application, 
since 
> > the peripherals (therefore the UARTs and SPI) are shut down in 
this 
> > mode. Any advise or hint on these subjects will be greately 
> > appreciated.
> > 
> > Guille
> 
> Hello Guille,
> 
> if you are looking for a full-featured preemtive multitasking RTOS 
using

> CPU idle mode just have a look at
> 
>    http://www.net-attack.de/
> 
> 
> Sten
> 
> -- 
> /************************************************
>  Do you need a tiny and efficient real time
>  operating system (RTOS) with a preemtive
>  multitasking for LPC2000 or AT91SAM7?
> 
>    http://nanortos.net-attack.de/
> 
>  Or some open-source tools and code for LPC2000?
> 
>    http://www.net-attack.de/
> 
> ************************************************/
>

Hi Guille,
I've been working on a preemptive RTOS over the last two years (on and
off...) with the features you are looking for, namely:
- takes advantage of CPU low-power modes in an automatic, transparent way
- has a high degree of responsiveness to external events
- supports deadlines to a sub-microsecond resolution
Basically, "don't do anything unproductive". I wrote it out of
frustration with currently available RTOSes: power
efficiency is at best an afterthought, and always subject to tradeoffs
like reactivity.
I have the basic kernel, and already used it in two 210x based
projects so far (developed with GCC).
I am currently playing with the idea of eventually either having it
open-sourced, or make it available for a one time per-product fee
(royalty-free) through my employer, socsolutions.com.
Having said that, you are welcome to give it a try.
Alfredo

--- In lpc2000@yahoogroups.com, "guillermoprandi"
<yahoo.messenger@m...> wrote:

>
> Hi! I am building a board featuring the LPC2138 µC. This board will 
> basically need to interface with three serial devices (two via 
> internal UARTs and a third via MAX3100, though suggestions are 
> welcomed about this). This device must be very low power; it should 
> wake up only when needed, which is: 1) there's data available from 
> any of the three ports, 2) there's data waiting to be transmitted on 
> any of the ports and the port becomes free and 3) a periodical 
> overall check (every second or so). This means that theoretically the 
> processor can enter the idle state quite often. I'm looking for some 
> (free if possible) multithreaded OS that would handle the transition 
> to the processor's idle state on traditionally blocking calls like 
> fread() and fwrite(), expecting to wake up on interrupt; also, some 
> preemptive multitasking should be supported, in case some thread 
> enters an exceptionally long calculating task. Probably there's no 
> known OS that directly supports this; in this case, I'd like to know 
> which other OS might be a good starting point to accomplish this by 
> making the modifications myself. I'm aiming to use the GNU libraries 
> (I ignore how difficult or messy would it be to modify them to 
> support this). Finally, it is my understanding that the VERY low 
> power "power down" mode would not be useful for my application, since 
> the peripherals (therefore the UARTs and SPI) are shut down in this 
> mode. Any advise or hint on these subjects will be greately 
> appreciated.
> 
> Guille
>

Guillermo Prandi wrote:
> Thanks, Sten. The web site doesn't mention the software cost. Due to 
> the structure of the project, I cannot enter any intrincated 
> licensing schemes (such as tied to a defined number of units 
> produced). Could you post the cost here? For example, for a single 
> product line (a product and its successors), for life?
> 
> Guille
> 

Hello Guille,

it depends on the features you need. You needn't pay for something you
do not want to use. NanoRTOS has a single product license without
royalties. But maybe you also want additional development support or
consulting to your project. Just write me an email directly to discuss this.

  Sten

http://www.standardics.philips.com/support/consultants/sandring/

-- 
/************************************************
 Do you need a tiny and efficient real time
 operating system (RTOS) with a preemtive
 multitasking for LPC2000 or AT91SAM7?

   http://nanortos.net-attack.de/

 Or some open-source tools and code for LPC2000?

   http://www.net-attack.de/

************************************************/