GSoC Weekly Report #1

Here's my first weekly report on my GSoC work. My dear visitors will probably want to skip to parts 2 and 3 since the first part contains mostly my ramblings about OpenEmbedded, which you've already read.

I'll promise it'll be shorter and easier to read the next time - but well, here goes :)

1) Setting up OpenEmbedded

Since the GSoC coding begins officially on 24th of May, and also since
I'm required to be very familiar with the development environment if I
want to be able to make life easier for DSP developers who'll be
working in the same environment, I was suggested to concentrate mainly
on setting up the OpenEmbedded toolchain correctly and build some of
the DSP/Link-related recipes. My initial experience with the setup was
rather frustrating, and it's slightly ironic that this occured not
because of lack of information on the topic, but due to too much
outdated/irrelevant information which is spread around the net, on the
wikis, etc. I initially tried out manually building the stable/2009
branch and learned that this branch was way too outdated. I then tried
setting up the apt-get'able OE and building the dev branch, which I've
had some success with and made a blog post to talk about the issues I
ran into during the process, only to find out later by Koen's mail
that the apt-get'able OE is somehow broken by design and the Ångström
setup scripts are *the* preferred way of doing things. As of the time
of reporting, I've successfully set up my devenv using the setup
scripts, but I honestly think that the visibility of these scripts
needs to be improved in the community provided documentation.

2) Familiarization with DSP/Link and the existing C6Run code

I should first mention that I haven't been able to spend as much time
on this subject as I would have liked to, since I was practically
struggling with the OE setup during the whole week. I had already
compiled DSP/Link and the sample applications using the CodeSourcery
toolchain and gone through parts of the DSP/Link API documentation,
but I still had a long way to go towards being able to use this
knowledge practically, thus I spent some more time on reading
documentation and source code. Aside from the DSP/Link User Manual and
the provided samples, I found the tutorials and documentation on the
ETH PIXHAWK (Computer Vision on Micro Air Vehicles) very helpful.
After these I went through the C6RunApp (formerly DSPEasy) source code
and I now do feel that I have sufficient practical understanding of
the DSP/Link architecture in general and how C6RunApp works in
specific to be able to start experimenting with GPP-hosted DSP-side
calls. This week I'll be trying to get C6Run to build using the OE
toolchain and play around with the PROC, NOTIFY, MSGQ and RINGIO
DSP/Link modules on my own, including some benchmarking for the
various calls since Daniel Allred mentioned over IRC that GPP->DSP
MSGQ message passing can take as much as 0.5ms on the hawkboard and
using NOTIFY may be able to speed things up, although these numbers
are likely to differ on the Beagle.


3) Order of porting for the POSIX functions and how much work the DSP
should be doing on them

One of my goals in the preliminary period was to determine how much of
the POSIX calls should be executed on the DSP and also in which order
the porting should be carried out with respect to their internal
dependencies. Concluding from my previous talk with Daniel over IRC
and my own studies of the commonly used C library .h functions which
my opinion is that -possibly- aside from a few math functions that
involve some internal number crunching, all of the POSIX calls should
be *completely* hosted on the GPP side, ie the DSP should only send a
request with the function name and parameters without doing any
pre-processing. The reasons behind this would be:

 * the DSP is not really suitable for most of the tasks involved in
the internals of POSIX functions, which usually don't involve heavy
mathemathical operations but things like string manipulation which the
GPP is much more suited and optimized for
 * there isn't really any significant time to be gained by doing some
of the processing on the DSP since it appears as though the bottleneck
will be the speed at which messages are carried through DSP/Link
 * this will result in cleaner and simpler to understand code since
the level at which processing is done on different processors doesn't
change from function to function
 * in the case of any modifications to the GPP side code (thinking of
the RPC framework as in general GPP-side function calling, not just
for POSIX calls which are very unlikely to change :)), there will be
no extra effort involved in keeping the DSP-side code up-to-date

This also means that the internal dependencies of POSIX functions
won't have to be taken into consideration regarding the order of
porting - the POSIX side wrappers will be dependent only on the GPP
side host code which is already there anyway. Therefore, a pragmatic
approach such as porting the generally most frequently used functions
can be taken.