Much Value to DSP RTOS?

I am speaking with a potential customer who wants a DSP board designed
for his needs which I could also market generally.  We will consider
the NRE price based on the value of having this as a product, but also
an RTOS he is willing to provide for this product.

We haven't discussed any particulars yet, but he claims his RTOS is
"accurate to" an eighth of a ms.  I'm not entirely sure what that
means, but I assume he is saying a process can be kicked off on that
granularity.  I don't have a good feel for how much value this would
add to a DSP board product.  Do many DSP apps need an RTOS?  If so, do
they typically buy or write their own?  Would the availability of an
RTOS for a given DSP influence the purchase of a board product?

I know there are a lot of RTOS products for embedded processors in
general, some commercial, some open source, some in between.  I
remember when TI used to offer DSPBIOS.  I don't see it around
anymore.  Maybe that is the answer to my question.

Rick

On 09/07/2010 09:34 PM, rickman wrote:
> I am speaking with a potential customer who wants a DSP board designed
> for his needs which I could also market generally.  We will consider
> the NRE price based on the value of having this as a product, but also
> an RTOS he is willing to provide for this product.
>
> We haven't discussed any particulars yet, but he claims his RTOS is
> "accurate to" an eighth of a ms.  I'm not entirely sure what that
> means, but I assume he is saying a process can be kicked off on that
> granularity.  I don't have a good feel for how much value this would
> add to a DSP board product.  Do many DSP apps need an RTOS?  If so, do
> they typically buy or write their own?  Would the availability of an
> RTOS for a given DSP influence the purchase of a board product?
>
> I know there are a lot of RTOS products for embedded processors in
> general, some commercial, some open source, some in between.  I
> remember when TI used to offer DSPBIOS.  I don't see it around
> anymore.  Maybe that is the answer to my question.

Few 'pure DSP' apps need an RTOS.  But if you've got a DSP chip that's 
spending 90% of it's non-idle clock ticks in 5% of its code, the other 
95% of the code may benefit from an RTOS.

"Accurate to" is a meaningless term for an RTOS.  Maximum latency is, 
but that depends on things beyond the RTOS (just turn off interrupts for 
a second, and see what I mean).

There are a ton of RTOS's out there, and I would imagine that most 
software groups that are going to use an RTOS are either going to want 
to use one that they're familiar with, they're going to want to spend a 
good long time choosing one, or they're going to roll their own.  Using 
an RTOS because that's what the board came with makes sense if you're a 
student, a hobbyist, or if you're building a really low volume 
prototype; there's not much wisdom in it beyond that.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Tim Wescott <tim@seemywebsite.com> wrote:
(snip of question on RTOS)
 
> Few 'pure DSP' apps need an RTOS.  But if you've got a DSP chip that's 
> spending 90% of it's non-idle clock ticks in 5% of its code, the other 
> 95% of the code may benefit from an RTOS.
 
> "Accurate to" is a meaningless term for an RTOS.  Maximum latency is, 
> but that depends on things beyond the RTOS (just turn off interrupts for 
> a second, and see what I mean).

Well, it might make sense in terms of jitter in response to timer
requests, though it does sounds strange to me, too.

It seems that many use Linux, though, as far as I know, it isn't
really an RTOS.

-- glen 

>Tim Wescott <tim@seemywebsite.com> wrote:
>(snip of question on RTOS)
> 
>> Few 'pure DSP' apps need an RTOS.  But if you've got a DSP chip that's 
>> spending 90% of it's non-idle clock ticks in 5% of its code, the other 
>> 95% of the code may benefit from an RTOS.
> 
>> "Accurate to" is a meaningless term for an RTOS.  Maximum latency is, 
>> but that depends on things beyond the RTOS (just turn off interrupts for

>> a second, and see what I mean).
>
>Well, it might make sense in terms of jitter in response to timer
>requests, though it does sounds strange to me, too.
>
>It seems that many use Linux, though, as far as I know, it isn't
>really an RTOS.
>
>-- glen 
>

>Tim Wescott <tim@seemywebsite.com> wrote:
>(snip of question on RTOS)
> 
>> Few 'pure DSP' apps need an RTOS.  But if you've got a DSP chip that's 
>> spending 90% of it's non-idle clock ticks in 5% of its code, the other 
>> 95% of the code may benefit from an RTOS.
> 
>> "Accurate to" is a meaningless term for an RTOS.  Maximum latency is, 
>> but that depends on things beyond the RTOS (just turn off interrupts for

>> a second, and see what I mean).
>
>Well, it might make sense in terms of jitter in response to timer
>requests, though it does sounds strange to me, too.
>
>It seems that many use Linux, though, as far as I know, it isn't
>really an RTOS.

There are hard real time extensions for Linux which give select processes
genuine RTOS behaviour, while the rest of the processes run in the usual
Unix best efforts way.

Steve


Steve

rickman wrote:

> I am speaking with a potential customer who wants a DSP board designed
> for his needs which I could also market generally.  We will consider
> the NRE price based on the value of having this as a product, but also
> an RTOS he is willing to provide for this product.
> We haven't discussed any particulars yet, but he claims his RTOS is
> "accurate to" an eighth of a ms.  I'm not entirely sure what that
> means, but I assume he is saying a process can be kicked off on that
> granularity.  I don't have a good feel for how much value this would
> add to a DSP board product.  Do many DSP apps need an RTOS?  If so, do
> they typically buy or write their own?  Would the availability of an
> RTOS for a given DSP influence the purchase of a board product?
> 
> I know there are a lot of RTOS products for embedded processors in
> general, some commercial, some open source, some in between.  I
> remember when TI used to offer DSPBIOS.  I don't see it around
> anymore.  Maybe that is the answer to my question.

Depends on what is the hardware, who are the intended customers and what 
are the intended applications.

It is a lot of work to develop a sensible framework for the application, 
including hardware abstraction, tasks, memory managemement and the 
things like TCP/IP and USB.

OEM boards are usually purchased by studiots, amateurs and pure software 
people who don't have a clue and don't want to have a clue. It is good 
if the board is shipped with something that they have heard of: such as 
Linux, or Labview. Some unknown unsupported undocumented RTOS would be a 
little value for them.

Professional folks use OEM boards as a temporary, until their own 
hardware is ready. I don't think pre-installed OS and BSP is a big value 
for them.

TI DSPBIOS is very much alive. There is even a port of DSPBIOS for ARM; 
some people use it.


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

On 09/07/2010 11:06 PM, glen herrmannsfeldt wrote:
> Tim Wescott<tim@seemywebsite.com>  wrote:
> (snip of question on RTOS)
>
>> Few 'pure DSP' apps need an RTOS.  But if you've got a DSP chip that's
>> spending 90% of it's non-idle clock ticks in 5% of its code, the other
>> 95% of the code may benefit from an RTOS.
>
>> "Accurate to" is a meaningless term for an RTOS.  Maximum latency is,
>> but that depends on things beyond the RTOS (just turn off interrupts for
>> a second, and see what I mean).
>
> Well, it might make sense in terms of jitter in response to timer
> requests, though it does sounds strange to me, too.
>
> It seems that many use Linux, though, as far as I know, it isn't
> really an RTOS.

No DSP chips I know of are capable of running Linux.  If you're doing 
some big application that needs PCs then yes, Linux may be a good 
choice.  If you're doing some little embedded DSP application like a 
modem or a motor controller then you're going to be interested in a much 
smaller OS.

Like Steve said, there are real-time extensions to Linux, in various 
flavors and levels of strictness, that can make it anything to 
"real-time-ish" to a computer with a strict real-time OS which will also 
run Linux apps.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Tim Wescott wrote:


> No DSP chips I know of are capable of running Linux.

ucLinux (albeit not a full Linux) is a common thing with AD, TI, NXP, ST 
DSPs. There are also composite cores like ARM+DSP; ARM part could run 
just about any OS.


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

Tim Wescott <tim@seemywebsite.com> wrote:
(snip, I wrote)

>> It seems that many use Linux, though, as far as I know, it isn't
>> really an RTOS.
 
> No DSP chips I know of are capable of running Linux.  If you're doing 
> some big application that needs PCs then yes, Linux may be a good 
> choice.  If you're doing some little embedded DSP application like a 
> modem or a motor controller then you're going to be interested in a much 
> smaller OS.

I do know that VoIP analog phone adapter boxes often run Linux.

The compressed modes do some amount of signal processing, though
maybe not quite as much as some heavy DSP problems commonly done 
on DSP chips.

-- glen

On 09/08/2010 08:35 AM, Vladimir Vassilevsky wrote:
>
>
> Tim Wescott wrote:
>
>
>> No DSP chips I know of are capable of running Linux.
>
> ucLinux (albeit not a full Linux) is a common thing with AD, TI, NXP, ST
> DSPs. There are also composite cores like ARM+DSP; ARM part could run
> just about any OS.

Yes, I forgot to qualify my statement by mentioning that I wasn't 
counting ucLinux as Linux.

(I should look at ucLinux, mebbe it's good.  Most of my microprocessor 
work is either too small for anything that even vaguely resembles 
"desktop", or it's _on_ a desktop.  So far nothing in between.)

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html