Forums

Any comments on Visual DSP++ VDK?

Started by Lawnmower August 12, 2003
Anyone using the RTOS VDK on the Analog Devices SHARC/Blackfin?

A quick trawl of the newsgroup gave 5 posts from ages ago, but nothing
of interest.

We are considering using this RTOS on the next project, but have no
experience of it so comments would be appreciated!

Kevin


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----
Lawnmower wrote:

> Anyone using the RTOS VDK on the Analog Devices SHARC/Blackfin? > > Kevin >
Hi Kevin, I'm currently implementing a prototype application using VDK. Working on Sharc 21161. The basic concepts are pretty, and its footprint is not too bad. On the EZ-Kit board I found an overhead of some few microseconds per ISR (which occurs every 20us), depending on the application this might result in a performance penalty of 3...10%. In my application I benefit of its architecture: it is easy to document an implementation if it's based on concepts like device drivers, tasks, event flags and semaphores... It's a little difficult to figure out the differences compared to the code examples which are provided with VisualDSP, because they will not apply any more, if you use VDK. This is mainly, because interrupts and signals are used differently. But once you get familiar with it, it can be managed. Another issue is debugging: The built-in instrumentation tools use lots of memory and time, therefore they are of help only in the beginning if you set up your architecture, but don't go into real-time world. Afterwards, you'll probably switch it off and don't use it anymore ... Generally, debugging is slow: if a breakpoint is hit, I have to wait maybe 10..20 sec until the debugger gives me any hint that it's still alive. Nevertheless, it works fine. As a summary: Good concept, obviously it can be used for production, but only if the application is not too time-critical. I would recommend it at least for the initial design/implementation phase of the project, even if you replace it later by self-written faster code. Bernhard -- before sending to the above email-address: replace deadspam.com by foerstergroup.de