DSPRelated.com
Forums

RTOS for SHARC Hammerhead DSP(s)

Started by Maria Elena Angoletta October 29, 2003
Dear all,

I'm in the process of designing an all-digital beam control system based on
3 custom-made boards each carrying a SHARC Hammerhead DSP (80 MHz clock).

I'd like to implement the DSP part with the help of a RTOS - however, it's
not easy to find something that can satisfy my system's needs.

In fact, on each board I'll have a high-priority task that must run every 2
microseconds and several low-priority tasks that should run every say 30 to
80 microseconds. The high-priority task (probably implemented as an ISR) is
triggered on one board by interrupts coming from a data acquisition module
and on another board by the internal timer (or by the RTOS, if it can). The
low-priority tasks are ideally threads waiting on periodic semaphores, whose
periods is constant for each measurement.

My first candidate was Analog Devices' VDK, but I discovered that the
overhead is far too high for my needs. I'm now starting to consider VSPWorks
(that evolved from VIRTUOSo) , that has got the advantage of the Virtual
Single Processor Model - allegedly "it allows you to write code that is
independent of the number of processors it runs on". Has anyone got
experience with it? I read it supports only VisualDSP++ v1.0 whilst the
version ADI delivers is the 3.1 . Any other RTOS you'd think could do the
job for my system, and you'd like to recommend?

Any suggestions is gratefully accepted.

Cheers

Maria Elena


Maria Elena Angoletta wrote:
...
> In fact, on each board I'll have a high-priority task that must run every 2 > microseconds and several low-priority tasks that should run every say 30 to > 80 microseconds. The high-priority task (probably implemented as an ISR) is > triggered on one board by interrupts coming from a data acquisition module > and on another board by the internal timer (or by the RTOS, if it can). The > low-priority tasks are ideally threads waiting on periodic semaphores, whose > periods is constant for each measurement.
...
> Any other RTOS you'd think could do the > job for my system, and you'd like to recommend?
Hello Maria Elena, it sounds like you don't need an RTOS at all. What you describe can be implemented by a simple main loop (ie. polling some semaphores) with a couple of interrupts setting the semaphores. You can gain experience by programming this yourself (I guess it will take you about a week or two to get it working). Afterwards, everytime you want something similar you can programm it in a day. And _you_ control how lean and fast the RTOS is. Regards, Andor
Never say in this NG you want to use RTOS. Ridicule and advise to use a
master loop with interrupts will be probably the only response...
As to VSPWorks RTOS from WindRiver Systems, I heard a rumor recently (from
the division that really develop this product) that they plan to discontinue
it...

"Maria Elena Angoletta" <Maria.Elena.Angoletta@cern.ch> wrote in message
news:bnond6$ejd$1@sunnews.cern.ch...
> Dear all, > > I'm in the process of designing an all-digital beam control system based
on
> 3 custom-made boards each carrying a SHARC Hammerhead DSP (80 MHz clock). > > I'd like to implement the DSP part with the help of a RTOS - however, it's > not easy to find something that can satisfy my system's needs. > > In fact, on each board I'll have a high-priority task that must run every
2
> microseconds and several low-priority tasks that should run every say 30
to
> 80 microseconds. The high-priority task (probably implemented as an ISR)
is
> triggered on one board by interrupts coming from a data acquisition module > and on another board by the internal timer (or by the RTOS, if it can).
The
> low-priority tasks are ideally threads waiting on periodic semaphores,
whose
> periods is constant for each measurement. > > My first candidate was Analog Devices' VDK, but I discovered that the > overhead is far too high for my needs. I'm now starting to consider
VSPWorks
> (that evolved from VIRTUOSo) , that has got the advantage of the Virtual > Single Processor Model - allegedly "it allows you to write code that is > independent of the number of processors it runs on". Has anyone got > experience with it? I read it supports only VisualDSP++ v1.0 whilst the > version ADI delivers is the 3.1 . Any other RTOS you'd think could do the > job for my system, and you'd like to recommend? > > Any suggestions is gratefully accepted. > > Cheers > > Maria Elena > >
Hi,

thanks for your answer(s). It's not the first no-RTOS DSP-based system (nor
the second or the third ...) that I develop :-) , so I can imagine how I
might do it without any RTOS - even if the story is not as simple as I told
it (additional requirements etc). My question was really focused on which
RTOS were available, if any, not on the RTOS yes/not dilemma. Thanks for the
info on VSPWorks - anybody else would care of confirming the rumour?

Cheers

ME


Based on the timing requirements you listed, I think you'd be pretty hard
pressed to find any RTOS that would be suitable.  You say your high priority
tasks runs every 2 microseconds on an 80 MHz processor.  That means you have
a whole 160 processor cycles per run of this task.  Hope it doesn't have to
do alot.  If this was implemented as an actual task in an RTOS (not as an
assembly ISR) you'd probably spend a good deal (if not all) of your 160
cycles in context switching time.

I'd suggest that you're going to need to write that ISR in assembler (the C
interrupt dispatch tables will chew up way too much of your precious few
cycles) and if you really want, you could look at an RTOS for the low
priority tasks.   There aren't a lot of choices for 21160 though, besides
what you mentioned.  A good reason for this is because of the nature of the
systems implemented - most use interrupts as their scheduler (high priority
tasks run at interrupt level, low priority invoked from main loop).  You
could poke around at some of the other RTOS's, like Nucleus, Precise, etc.
as some of these claim Sharc support.  OSEck is now supporting the
TigerSharc, but not the21160.

What overhead in VDK was too high for you?

-----
Ron Huizen
BittWare

As for the other tasks running at 30 to 80 microseconds
"Maria Elena Angoletta" <Maria.Elena.Angoletta@cern.ch> wrote in message
news:bnond6$ejd$1@sunnews.cern.ch...
> Dear all, > > I'm in the process of designing an all-digital beam control system based
on
> 3 custom-made boards each carrying a SHARC Hammerhead DSP (80 MHz clock). > > I'd like to implement the DSP part with the help of a RTOS - however, it's > not easy to find something that can satisfy my system's needs. > > In fact, on each board I'll have a high-priority task that must run every
2
> microseconds and several low-priority tasks that should run every say 30
to
> 80 microseconds. The high-priority task (probably implemented as an ISR)
is
> triggered on one board by interrupts coming from a data acquisition module > and on another board by the internal timer (or by the RTOS, if it can).
The
> low-priority tasks are ideally threads waiting on periodic semaphores,
whose
> periods is constant for each measurement. > > My first candidate was Analog Devices' VDK, but I discovered that the > overhead is far too high for my needs. I'm now starting to consider
VSPWorks
> (that evolved from VIRTUOSo) , that has got the advantage of the Virtual > Single Processor Model - allegedly "it allows you to write code that is > independent of the number of processors it runs on". Has anyone got > experience with it? I read it supports only VisualDSP++ v1.0 whilst the > version ADI delivers is the 3.1 . Any other RTOS you'd think could do the > job for my system, and you'd like to recommend? > > Any suggestions is gratefully accepted. > > Cheers > > Maria Elena > >
> I'd suggest that you're going to need to write that ISR in assembler (the
C
> interrupt dispatch tables will chew up way too much of your precious few > cycles) and if you really want, you could look at an RTOS for the low > priority tasks.
Yup, that's exactly what I was thinking of doing - to write the high-priority task as an ISR and see if a RTOS can do the scheduling of the low-priority tasks. Even then, I'm not sure I can succeed in finding a RTOS that is suitable and not going off the market the minute I commissioned the system :-( but I want to give it a try.
> What overhead in VDK was too high for you?
Well, the 2-microsecond high priority task will have to be started by the timing interrupt in one DSP. Problem is, the timing interrupt is used by VDK to generate its interal timing, and with an overhead of 100 cycles per interrupt it's just not possible to use it reliably at 2 microseconds. I examined several ways of bypassing this problem (Analog Devices' technical support was really helpful, I must say) , but still I cannot guarantee that both my 2 microsecond task AND the several ~50-microseconds tasks are executed every time, without skipping any loop. Cheers ME
Maria Elena Angoletta wrote:

> Dear all, > > I'm in the process of designing an all-digital beam control system > based on 3 custom-made boards each carrying a SHARC Hammerhead DSP > (80 MHz clock). > > I'd like to implement the DSP part with the help of a RTOS - > however, it's not easy to find something that can satisfy my > system's needs. > > In fact, on each board I'll have a high-priority task that must > run every 2 microseconds and several low-priority tasks that > should run every say 30 to 80 microseconds. The high-priority task > (probably implemented as an ISR) is triggered on one board by > interrupts coming from a data acquisition module and on another > board by the internal timer (or by the RTOS, if it can). The > low-priority tasks are ideally threads waiting on periodic > semaphores, whose periods is constant for each measurement. > > My first candidate was Analog Devices' VDK, but I discovered that > the overhead is far too high for my needs. I'm now starting to > consider VSPWorks (that evolved from VIRTUOSo) , that has got the > advantage of the Virtual Single Processor Model - allegedly "it > allows you to write code that is independent of the number of > processors it runs on". Has anyone got experience with it? I read > it supports only VisualDSP++ v1.0 whilst the version ADI delivers > is the 3.1 . Any other RTOS you'd think could do the job for my > system, and you'd like to recommend? > > Any suggestions is gratefully accepted. > > Cheers > > Maria Elena
Hello Maria Elena, I started working with the VDK just to find out how it performs. What I found, surprised me. It's pretty fast, once you've learnt how to use it. 1) Your fast ISR would be an assembler routine. 2) The others might be implemented in the activate routine of device drivers or looping on periodic semaphores. I guess it should be possible to solve your application with VDK. However, as the other contributations tell, it won't be easy. If or if not you should use an RTOS, depends. If you described your complete application, it's certainly not worth to bother with the difficulties which come along with the RTOS. But if you have to do a lot of other (slow) stuff an RTOS might be a good approach because it helps you to achieve a neat design. Compared with other RTOSs, I'd recommend VDK because it comes at no cost (if you own VisualDSP++). If you plan to use it, make sure that you use the last updates from ADI, because they removed a lot of errors during summer. Bernhard
Guess I fell in with old traditions :) Sorry about the advice not wanted.

There is a long section on DSP RTOSses in the comp.dsp FAQ at:
http://www.bdti.com/faq/dsp_faq.htm

Regards,



Maria Elena Angoletta <Maria.Elena.Angoletta@cern.ch> schrieb in im
Newsbeitrag: bnqqba$nhn$1@sunnews.cern.ch...
> Hi, > > thanks for your answer(s). It's not the first no-RTOS DSP-based system
(nor
> the second or the third ...) that I develop :-) , so I can imagine how I > might do it without any RTOS - even if the story is not as simple as I
told
> it (additional requirements etc). My question was really focused on which > RTOS were available, if any, not on the RTOS yes/not dilemma. Thanks for
the
> info on VSPWorks - anybody else would care of confirming the rumour? > > Cheers > > ME > >