Frequently Asked Questions about Visual DSP

This is a collection of some of the most frequently asked questions about Visual DSP as related to Linux running on the Blackfin processor.

Generally the first thing you should ask yourself if you're considering trying to integrate Visual DSP and Linux is why. Trying to do so is much more of hassle, not to mention not supported at this time, then doing all of your work in one environment or the other.

Some of these things may change in the future, but for all versions of Visual DSP up to and including the 5.0 series, everything below holds true.

Are you sure you are in the right place?

You can find most recent copies on ADI's web page

Please refer to this page for porting Visual DSP code to Linux. It covers C, C++, and Assembly source code.

You'll probably need to change the syntax of the file from the GNU assembler syntax to Visual DSP. No article exists to assist in this specific endeavor, but you can probably reverse the steps found in the porting Visual DSP code to Linux yourself.

No.

Reasons:

• the kernel cannot be compiled properly on case-insensitive filesystems (all Windows filesystems)
• the code is full of gcc-specific code and attributes which Visual DSP does not support
• the Visual DSP toolchain does not support the GNU linker script syntax
• additional helper scripts are run to generate symlinks, files, etc… which will not run in Windows
• the Windows environment does not conform to POSIX which breaks most shell scripts
• probably others

No. Many of the same reasons above for the Linux kernel apply here equally well.

No. The ELF format that Visual DSP produces is not compatible with the format the GNU toolchain produces.

You cannot do this under Linux. Visual DSP does not run an operating system so that is why you can arbitrarily place code and data at whichever memory locations you like. Since Linux is managing all of the resources, it will decide where to place your data and text sections.

In an non-Linux/OS environment, this can be done the same way - linker scripts. See the GNU ld manual.

No. Well, maybe, but no one has ever tried nor does anyone plan on doing so.

No. The Visual DSP environment produces applications that are designed to run on bare metal and not underneath an operating system. Furthermore, Visual DSP does not produce FDPIC ELFs which are required to run under Blackfin Linux.

No. Why would you want to? :) The DWARF debugging format that the GNU toolchain utilizes for ELFs is not supported by Visual DSP. Use GDB or a graphical front end to debug your application. For more information, see our debuggers page.

No. See the previous question about debugging Linux applications.

Like most things in life, you can do anything you want - even funambulism, but we don't recommend it.

The same applies to BF561 developments running Linux on Core A, and a VDSP++ compiled object on Core B. There are many reasons why we do not recommend this, and here are the top 4.

• there is no way to do source level debug of both cores (Linux kernel and VDSP object) at the same time. There is only one JTAG port, and one one debugger (gdb or VDSP++) can be connected at one time.
• the Linux kernel believes it owns the entire chip. Many VDSP objects believe the same thing, and will overwrite something that the kernel believes it is managing. This sometimes causes VDSP objects to crash the kernel, even though the kernel is not doing anything wrong.
• the GNU Toolchain and the VDSP toolchain workaround chip anomalies in different ways, sometimes an anomaly workaround on one core can negatively effect the other.
• we can not help track down bugs, since no one who develops the GNU Toolchain or Linux is familiar with VDSP.

For these reasons, once we understand there is a VDSP object on the other core - we stop working on things, and ask you to reproduce a problem with gcc compiled object.

If you can reproduce the problem in a purely GNU toolchain environment, we can help solve the problem.

It depends. On control code - gcc tends to out perform VDSP++. On signal processing code, VDSP++ tends to out perform gcc. On floating point code, gcc tends to out perform VDSP++. It is very difficult to say which compiler is “better” in general, as without trying a specific code base, it is impossible to tell.

If you have an example of where GCC needs to be improved, please submit a feature request with an example.

When it comes to assembly however, the compiled code will obviously execute at exactly the same speed.