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. 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.
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.