pulse_web@hotmail.com wrote:
> I've been looking at similar sourcecode to some of the stuff I'm
> trying to do on the DM642 (video in -> process - > out) and noticed
> that in some functions there seems to be some kind of concurrent
> processes - ie code within a 'while(1){...' loop that only captures
> video.
> How does this kinda thing work? How does it communicate status to the
> calling function? I assume this makes for a much quicker and more
> efficient program?

TI provide a basic real time kernel for their DSPs called DSP/BIOS. It
provides the means to create multiple threads (which TI call 'tasks'),
assign them priorities, and execute them concurrently. All the usual
multithreading widgetry is provided - mutexes, semaphores, thread-local
storage, etc.

Internally, the scheduling is managed using periodic interrupts from a
timer and an idle loop that is entered when your main() function
returns.

The easiest communication method is just to use memory, provided you put
locks around access from different threads. DSP/BIOS provides some
collection objects, e.g. queues and mailboxes, that can be used for
inter-thread comms. There is a pre-packaged comms mechanism called
SCOM that provides an elegant message passing system. TI uses it in
most of their demo code.

Cheers

mark-r

-- 

I've been looking at similar sourcecode to some of the stuff I'm
trying to do on the DM642 (video in -> process - > out) and noticed
that in some functions there seems to be some kind of concurrent
processes - ie code within a 'while(1){...' loop that only captures
video.
How does this kinda thing work? How does it communicate status to the
calling function? I assume this makes for a much quicker and more
efficient program?

Cheers
Dave