Much Value to DSP RTOS?

On 09/08/2010 09:04 AM, glen herrmannsfeldt wrote:
> 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.

That's a smart thing, because if there's any one thing that Linux is 
good at, it's transparent Ethernet connectivity.  And chances are 
they're running some open-source VoIP software, too.  It'd be 
interesting to see just what's used...

-- 

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

Vladimir Vassilevsky <nospam@nowhere.com> writes:
> [...]
> TI DSPBIOS is very much alive. 

I can vouch for this. Even the older 5.33 (ala CCS 3.x) still seems
fairly prevalent. 

To address rickman's original question, I'm on the fence. I agree with
Vlad that it's a lot of work, and that many applications don't need it,
but at some (unquantifiable) level of complexity you're going to benefit
from a "real" OS instead of just a main loop and some interrupts. I'm
now saying that having written one or two of each type. 
-- 
Randy Yates                      % "The dreamer, the unwoken fool - 
Digital Signal Labs              %  in dreams, no pain will kiss the brow..."
mailto://yates@ieee.org          %  
http://www.digitalsignallabs.com % 'Eldorado Overture', *Eldorado*, ELO

On 09/08/2010 12:12 PM, Randy Yates wrote:
> Vladimir Vassilevsky<nospam@nowhere.com>  writes:
>> [...]
>> TI DSPBIOS is very much alive.
>
> I can vouch for this. Even the older 5.33 (ala CCS 3.x) still seems
> fairly prevalent.
>
> To address rickman's original question, I'm on the fence. I agree with
> Vlad that it's a lot of work, and that many applications don't need it,
> but at some (unquantifiable) level of complexity you're going to benefit
> from a "real" OS instead of just a main loop and some interrupts. I'm
> now saying that having written one or two of each type.

My model for using an OS (or, for that matter, using assembly vs. C vs. 
C++ or whatever), is this:

In general, the 'higher' you go in terms of framework complexity (OS vs. 
task loop, C vs. assembly, C++ vs. C), the bigger a hurdle you're going 
to have to overcome to get started -- i.e., the cost of getting the 
LED's to blink with a real-time OS is higher than getting the same thing 
done with a task loop.  Ditto blinking the lights with an honest C++ 
framework vs. doing it in a few lines of assembly.

But if you're making wise choices, once you get in that door, the climb 
to more and more complexity is less steep with an RTOS or with C (or 
C++).  (Obviously if you're making dumb choices then not only is the 
entry harder, but so is the extra work vs. extra complexity curve).

So you have to use your judgement about how complex the problem is that 
you need to solve -- and possibly how complex it'll be when you go from 
rev 1.5 to rev 2.0 -- and decide which approach is going to have the 
least _overall_ cost.  You will _always_ get to blinky lights and basic 
"works on a bench but not in the field" functionality using the simplest 
approach (or using a vendor's OS, environment, and IDE).  The 
responsible engineer tries to figure out what's going to lead to the 
earliest positive return on investment by his 
client/boss/employer/self/whatever.

-- 

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:

> On 09/08/2010 12:12 PM, Randy Yates wrote:
> 
>> Vladimir Vassilevsky<nospam@nowhere.com>  writes:
>>
>>> TI DSPBIOS is very much alive.
>>
>> I can vouch for this. Even the older 5.33 (ala CCS 3.x) still seems
>> fairly prevalent.
>>
>> To address rickman's original question, I'm on the fence. I agree with
>> Vlad that it's a lot of work, and that many applications don't need it,
>> but at some (unquantifiable) level of complexity you're going to benefit
>> from a "real" OS instead of just a main loop and some interrupts. I'm
>> now saying that having written one or two of each type.
> 
> 
> My model for using an OS (or, for that matter, using assembly vs. C vs. 
> C++ or whatever), is this:
> 
> In general, the 'higher' you go in terms of framework complexity (OS vs. 
> task loop, C vs. assembly, C++ vs. C), the bigger a hurdle you're going 
> to have to overcome to get started -- i.e., the cost of getting the 
> LED's to blink with a real-time OS is higher than getting the same thing 
> done with a task loop.  Ditto blinking the lights with an honest C++ 
> framework vs. doing it in a few lines of assembly.

This is what has to be done to get the LED blinking:

1) Configure compiler, linker and libraries.
2) Write the linker file.
3) Get the toolchain output converted to loadable image.
4) Get the loadable image uploaded into the target.
5) Write initialization procedures for clocks, ports, DDRAMs.
6) Modify C startup code.
7) Ensure that the hardware works properly.
8) Write a LED blinking procedure.

If you do a single mistake at any of those steps, the LED won't blink. 
There is no easy way to figure out why it is not working.

> But if you're making wise choices, once you get in that door, the climb 
> to more and more complexity is less steep with an RTOS or with C (or 
> C++).  (Obviously if you're making dumb choices then not only is the 
> entry harder, but so is the extra work vs. extra complexity curve).
> 
> So you have to use your judgement about how complex the problem is that 
> you need to solve -- and possibly how complex it'll be when you go from 
> rev 1.5 to rev 2.0 -- and decide which approach is going to have the 
> least _overall_ cost.  You will _always_ get to blinky lights and basic 
> "works on a bench but not in the field" functionality using the simplest 
> approach (or using a vendor's OS, environment, and IDE).  The 
> responsible engineer tries to figure out what's going to lead to the 
> earliest positive return on investment by his 
> client/boss/employer/self/whatever.

The ideal engineer does ideal things in the ideal world. The realistic 
engineer performs in the limits of his comprehension and attitude.


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

On Sep 8, 3:12&#4294967295;pm, Randy Yates <ya...@ieee.org> wrote:
> Vladimir Vassilevsky <nos...@nowhere.com> writes:
> > [...]
> > TI DSPBIOS is very much alive.
>
> I can vouch for this. Even the older 5.33 (ala CCS 3.x) still seems
> fairly prevalent.
>
> To address rickman's original question, I'm on the fence. I agree with
> Vlad that it's a lot of work, and that many applications don't need it,
> but at some (unquantifiable) level of complexity you're going to benefit
> from a "real" OS instead of just a main loop and some interrupts. I'm
> now saying that having written one or two of each type.

Thanks to all for your replies.  Part of my questions were answered
when it was pointed out that that DSPBIOS is still alive.  I guess
they don't promote it as heavily as they used to and I didn't see
anything about it on the DSP chip page.

The real question is, how much value would it add for *me* to provide
this with the hardware product.  I realize that the value to the user
depends on his application, method of development, etc.  I am trying
to get a feel for how many of the potential users would want this and
how important it would be to them to have it.

My customer seemed to think this was a really big deal so I expect he
found it necessary to develop at some point.  I will have to ask him
to explain why he couldn't do the job with DSPBIOS or some other
RTOS.  My concern with using his RTOS is the level of documentation
and support that would be needed and whether that would be
forthcoming.

When I offered COTS DSP board products some years ago, the hardest
part was trying to provide all the support people seemed to want.
They weren't hobbyists, but they needed a lot of hand holding and
often wanted interfaces to all sorts of third party tools.  The ideal
customer is one who has used DSP before and needs 100 boards a year.
That is too low a volume for them to design their own board and high
enough to provide a reasonable profit without a lot of headache.  But
they seem to be hard to find.  I found many customers who wanted to
buy less than 10 boards and wanted a 100 board price along with a few
who wanted 1000 boards a year at 1,000,000 board price.  I wouldn't
have made any money off of either, but it would have been nice for
them!

So I am reluctant to go down this path again unless I have some
reasonable business plan that would make a difference.

Rick

RTOS, eh?  Hmmm....  What exactly is meant by 'real time'?

Without prejudice...

Realize that, in a very real sense, if one has to ask this particular 
question, (Much value to DSP RTOS?) then...

One is not quite ready for the answer!

-- Pete, Indialantic By-the-Sea, FL


"rickman" <gnuarm@gmail.com> wrote in message 
news:b73df851-8308-494f-b99c-755db24d85c6@f26g2000vbm.googlegroups.com...
On Sep 8, 3:12 pm, Randy Yates <ya...@ieee.org> wrote:
> Vladimir Vassilevsky <nos...@nowhere.com> writes:
> > [...]
> > TI DSPBIOS is very much alive.
>
> I can vouch for this. Even the older 5.33 (ala CCS 3.x) still seems
> fairly prevalent.
>
> To address rickman's original question, I'm on the fence. I agree with
> Vlad that it's a lot of work, and that many applications don't need it,
> but at some (unquantifiable) level of complexity you're going to benefit
> from a "real" OS instead of just a main loop and some interrupts. I'm
> now saying that having written one or two of each type.

Thanks to all for your replies.  Part of my questions were answered
when it was pointed out that that DSPBIOS is still alive.  I guess
they don't promote it as heavily as they used to and I didn't see
anything about it on the DSP chip page.

The real question is, how much value would it add for *me* to provide
this with the hardware product.  I realize that the value to the user
depends on his application, method of development, etc.  I am trying
to get a feel for how many of the potential users would want this and
how important it would be to them to have it.

My customer seemed to think this was a really big deal so I expect he
found it necessary to develop at some point.  I will have to ask him
to explain why he couldn't do the job with DSPBIOS or some other
RTOS.  My concern with using his RTOS is the level of documentation
and support that would be needed and whether that would be
forthcoming.

When I offered COTS DSP board products some years ago, the hardest
part was trying to provide all the support people seemed to want.
They weren't hobbyists, but they needed a lot of hand holding and
often wanted interfaces to all sorts of third party tools.  The ideal
customer is one who has used DSP before and needs 100 boards a year.
That is too low a volume for them to design their own board and high
enough to provide a reasonable profit without a lot of headache.  But
they seem to be hard to find.  I found many customers who wanted to
buy less than 10 boards and wanted a 100 board price along with a few
who wanted 1000 boards a year at 1,000,000 board price.  I wouldn't
have made any money off of either, but it would have been nice for
them!

So I am reluctant to go down this path again unless I have some
reasonable business plan that would make a difference.

Rick