See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/251503198

Education of embedded systems: Design of a set-top box for streaming audio

applications on C6711 and MSP430 devices

Article · January 2002

CITATIONS READS

0 243

4 authors, including:

Marc Leeman Vincenzo De Florio

Institute of Electrical and Electronics Engineers Vrije Universiteit Brussel
17 PUBLICATIONS   81 CITATIONS    163 PUBLICATIONS   1,225 CITATIONS   

SEE PROFILE SEE PROFILE

Geert Deconinck
KU Leuven
426 PUBLICATIONS   3,824 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Fractal Social Organizations View project

P2P SmarTest Project View project

All content following this page was uploaded by Vincenzo De Florio on 12 February 2014.

The user has requested enhancement of the downloaded file.

 Education of embedded systems:
Design of a set-top box for streaming audio applications
on C6711 and MSP430 devices
Marc Leeman, Francisco Barat, Vincenzo De Florio, Geert Deconinck
ACCA/ESAT KULeuven
Kasteelpark Arenberg 10
3001, Heverlee, Belgium
firstname.lastname@esat.kuleuven.ac.be
Abstract
In this paper, a design seminar on embedded systems is
described for fourth year students in the Multimedia and
signal processing option at our electrical engineering de-
partment. The goal of this seminar is to confront the stu-
dent with the design a real life example in order to ease up
the adaptation of the universitary curriculum to what is ex-
pected by industry of a high level engineer. The project cov-
ers multiple expertise areas, programming techniques and
languages, development tools and hardware platforms in
order to develop a prototype of a set-top box with off-the-
shelf tools, hardware and software. The interdisciplinary
character of this seminar combines multiple topics taught
in courses in the application.
1 Introduction
Embedded Computing has become ever more pervasive
over the last decades and this evolution has only touched
the surface of the myriad of possibilities. Every day, new or
more challenging applications are conceived and researched
in companies and universities. Despite this promising fu-
ture, the education of the techniques that lie at the basis
of these applications (e.g. programming optimisation and
power consumption aware programming techniques) are
sometimes neglected in favour of new programming con-
cepts that may or may not prove to be useful in real life.
Efficiently mapping an algorithm to an embedded system
has always been a challenging task. A number of technical
and non technical reasons account for this. First of all, em-
bedded systems have always been quite cost sensitive (the
maximal functionality has to be mapped on the cheapest de-
vices). Where the main focus had been to get sufficient
functionality on the system, it has been now complicated
1
by requiring power efficient systems, to be implemented in
ubiquitous, hand held devices. But still, the manufacturer
that is able to offer that extra bit of functionality or perfor-
mance at the same or lower cost has a definite advantage
in a very competitive market often characterised by techni-
cally proficient customers. Secondly, with the progress of
chip design, the functionality of the embedded processor in-
creases up to a point that a lot of these can almost compete
with general purpose processors1 .
In order to cope with this kind of changing environment,
the systems developed must be modular and attention needs
to be put on correct integration. A modular system makes
sure that last minute implementation or functional changes
can be localised and do not affect the entire embedded soft-
ware system. It also enables the reuse of previous software
modules and third party software, as well as easy integra-
tion.
One of the problems with an academic curriculum is that
there is a gap between the skills of the students that grad-
uate and what is expected and required by industry part-
ners. Because of this and the quickly changing nature of
the state of the art technology, the engineering programme
was reformed at the University of Leuven with these ex-
pectations of industry in mind, the need for well qualified
engineers and in an effort to revitalise engineering [11] a
couple of years ago. More stress is put on implementation
of a system and not just on its design. Next to a series of
renewed courses, a design seminar was scheduled to im-
plement a multimedia application, with signal-processing
specific hardware in the Multimedia and signal processing
option [20], [12].
This paper describes a design seminar that was introduced.
In section 2, the goals and constraints of the project are de-
scribed. The topic of the next section is the hardware and
1 And all this should be done by yesterday
software architecture and the differences to the software ar-
chitecture are pointed out in the two editions of the semi-
nar. In section 4, practical solutions from the students and
the work of the students is elaborated. This paper concludes
with a general overview of attained goals and some possible
changes and improvements.
2 Project Contents and Problem Description
In this section, the assignments to the students are de-
scribed, from the initial concept that was implemented
in the first edition, to a more complex modified version
that took hardware limitations into account and was imple-
mented in the second edition. It also introduces the software
and hardware components that were integrated in the final
systems.
Over the last years, a lot of controversy arose around the
distribution of copyrighted material over the Internet. This
medium allows world-wide and fast distribution at a low
cost and results in claims of huge losses by the audiovisual
industry. More importantly, due to judicial actions, lobby-
ing and strict legislations, service enterprises found them-
selves faced with the de-facto obligation to strongly protect
their copyrighted goods from unauthorised copying when
distributing it. On the other hand, commercial exploitation
of the Internet as the largest and ubiquitous mall, gives these
companies a strong incentive for the introduction of secure,
Internet-aware embedded systems and software integrated
in e.g. hand-helds, mobiles, . . .
From the very start of the project, confronting the stu-
dents with a challenging, real life example was one of the
top priorities. As with most students, this audio example is
a problem they are confronted with almost on a daily ba-
sis. The initial problem description was selected among a
set of industry relevant scenarios: to develop a transaction
based client/server system that enabled secure transmission
of CD quality music. This e-commerce allowed one party to
consult a music repository and allowed ordering any num-
ber of audio files. Every transaction needed to include price
negotiation (between server and client) and credit approval
(client).
The two key factors are authentication and encryption:
authentication assures that the recipient of the data stream
is the one he is claiming to be and encryption ensures that
the data stream cannot be used by anyone but the intended
recipient. The set-top prototype was designed with the fol-
lowing restrictions:
off-the-shelf hardware : time-to-market is important in
industry. This requires using standard components
where possible and integrating them in the application
that is developed. Only when strict requirements have
to be met (power consumption, I/O, . . . ) a custom de-
2
sign is considered. Furthermore, these readily avail-
able components are often available at a much lower
cost than a in-house developed solution. In this sem-
inar, the requirements are defined so that no custom
hardware needs to be developed.
off-the-shelf software : the same reasoning applies for the
software modules that are used.
In a digital world were data is intercepted analysed and
scrutinised by unauthorised third parties, secure communi-
cation is important, A number of limitations that will be de-
scribed in more detail in section 3.2.2 required a review of
the problem description. Since CD quality audio transmis-
sion was not possible with the current hardware, the system
was changed to a peer to peer (P2P) secure speech transmis-
sion system.
3 Application and System Description
This section provides a detailed description of the main
hardware and software components of the target system.
The application functionality to be supplied by these com-
ponents is also described.
3.1 Hardware
The hardware choice was done in the preparation phase
of the seminar. Each subsystem (client or server in the audio
distribution case, or peer to peer (P2P) in the secure speech
transmission case) consists of a Digital Signal Processing
(DSP) to do the number crunching and a microcontroller
(µc ) to control the operations of the system and provide a
simple user interaction.
Due to our past experience with Texas Instruments (T I),
the fact that they occupy the largest market segment (and
as such, a high probability that the students would en-
counter that hardware while working in embedded de-
vices after graduation), the choice was made to use the
T MS 320C6711 Developers Starter Kit (DSK) [3]. The
DSP on this DSK is a very large instruction word (VLIW)
DSP, running at 166 MHz, has 128 KB two level cache,
16 MB of external memory, combined with an integrated
development environment (IDE): Code Composer Studio
[18]. The performance of the DSP also makes certain
that there is additional room for functional upgrades and
changes by the students. The Code Composer Studio soft-
ware offers a clear C and assembly programming IDE, an
interface to the DSP/BIOS II Real Time Operating System
(RTOS) that enables modularly extending the system.
On the other hand, the operation of each DSP is con-
trolled by a µc . Next to this, other important task are to
provide the needed user interaction by steering a LCD dis-
play and reading input from a small keypad, setting up a
 Figure 1. The system setup. On the left hand site, the full system is displayed, on the right hand site
the key components. 1: the ’C6711 DSK board, 2: the MSP430 controller, 3: the custom designed
daughterboard, a: the LCD display, b: the keypad, c: audio input, u: audio output
secure link between the boxes and checking the credit va-
lidity of a client. The MSP430, also from T I was selected
for the seminars. Considering the specifications (discussed
more in Section 4.4.1.2), the entire program would have to
fit in 1 kB of memory, the allocation of every byte in order to
meet the software functionality would have to be measured
carefully. While the software of the DSP gave a graphical
interface to the hardware and to the RTOS functionality, the
focus of the µc was completely the opposite, programming
was done in a basic editor and the program was sent over
the serial port to the µc board.
The final system is seen in figure 1. Every system (on the
decoder as well as on the encoder side) has the following
components:
• 1 TMS320C6711 DSK board
• 1 MSP430 microcontroller with a keypad and an LCD
screen
• 1 communication DSK daughter board
For interfacing the DSK with the µc , there was no read-
ily available solution. After some hardware analysing, cus-
tom daughterboard was developed to fit on the DSK exten-
sion slots. This daughter board centralises the most impor-
tant connections on the system: DSK with µc , serial DSK-
DSK and serial µc -µc communication and connecting the
µc with the keypad. An important advantage is its robust-
ness, since the system has to be assembled at the start of
every session and disassembled afterwards. The system is
connected with a cable with two SUB D9 connectors.
3
3.2 Software
The functionality of the original secure audio distribu-
tion system and the secure speech transmission system is
slightly different. First, the audio example is explained and
in a subsequent section, the most important changes for the
speech example are highlighted.
3.2.1 2001: secure audio distribution
The most important functional blocks of the audio distri-
bution system to be integrated are shown in figure 2. The
following steps are distinguished:
Capture: Audio is offered in some form to the set-top box.
During the design of the prototype, the precise defini-
tion of the source is not yet made, but the inclusion
of analog to digital conversion only makes the system
more flexible. If the audio was already stored in dig-
ital form (which is very likely), the Analog to Digital
Converter (ADC) step would have to be removed and
replaced with the new data source. The ADC converter
on the DSK board is used for the conversion of the au-
dio to PCM samples.
Compression: Since the data should be delivered to a
range of customers over the Internet, distribution needs
to be done in a form that consumes the least bandwidth
for the quality required (a combination of customer
downstream bandwidth limitations and expensive up-
stream -server- reduction). We chose the MPEG1 layer
III audio compression (MP 3) [15].
Encryption: Encryption of the audio stream covers two
different problems. First of all, the data stream must
 Figure 2. System description: software chain secure audio distribution system.
be encrypted in such a way that only the designated re-
cipient gets access to the decrypted data. Secondly, the
validated recipient of the audio steam should only be
able to decipher the data stream as long as he/she has
provided enough credits. If the credit runs out, the data
stream should become unusable. The latest encryption
standard is chosen for this task, known as Rijndael or
AES [6], [7], [2].
Serial connection: in order to transmit the data to the em-
bedded system counterpart, a communication link of
some nature is required. Instead of using a full fledged
communication system, a serial link was chosen. As
with the audio capture, this gives the students detailed
knowledge of the hardware. The prototype system has
to be able to recover from errors in this serial connec-
tion, when it drops or corrupts data for some reason
and restart normal operation as soon as the communi-
cation is restored. It does not have to correct the faults.
Equalising: this functionality is added on the client side.
The user of the client device must have the ability to
tweak the audio with a 4-band equaliser and volume
control.
On the client side, the complementary tasks are done: de-
cryption, decompression (MP 3 to PCM) and Digital to Ana-
log Conversion (ADC). As can be seen on figure 2, a num-
ber of software modules are not yet described. These are
practical problems that need to be solved during implemen-
tation in order to get a working system and will be discussed
in section 4.
The decision of the implementation was based on testing
of the different available public domain coders. The results
of this are summarised in table 1 for the encoders. The en-
4
Coder Elapsed Time Portability
Blade 1’02” problematic
Lame 0’40” high
Gogo 0’24” low
Table 1. Evaluation of different MP 3 encoders
(elapsed time and portability), Highway to Hell,
3’28”.
coding2 was done on an AMD 650 PC3 , 512 MB SDRAM
on a single song [21]. The gogo [14] encoder is a hack
of the lame [16] encoder which is partly written in assem-
bler. For this reason, it is not usable on the DSP platform
without rewriting the assembler part. Both the blade [10]
and lame encoders are fully written in C, but the memory
management and usage in the blade encoder makes the
portability to an embedded system problematic.
Decoding the stream is not such a intensive task as encoding
it. Since the same computational power is available on the
client side as on the server side that does the encoding, the
cycle budget should not pose a problem. Still, this should
not be a reason to implement a slow solution into the pro-
totype, the final system might include less performant (and
less expensive) hardware. The choice of a MP 3 decoder was
easier, mostly because the most important public domain
decoder is very good:
2 Conversion from WAV format, RIFF (little-endian) data, WAVE au-
dio, Microsoft PCM, 16 bit, stereo 44100 Hz to MPEG 1.0 layer III audio
stream data, 128 kBit/s, 44.1 kHz, jstereo.
3 Running Debian 2.2r2 (Sid), Linux and the GCC compiler 2.95. The
compiler options used are those found in the Makefile. For the gogo and
the lame encoder, this was -O3 and for the blade encoder, this was -O2.
 Figure 3. System description: software chain secure speech transmission system.
1. Most public domain MP 3 decoding use some form of
the mpg123 decoder [9].
2. There is a trimmed down version available in the
source tree of mpg123.
3. Searching on the Internet showed that this de-
coder could even be used on older systems as an
80486DX2 [1], which makes it fast.
The encryption and decryption code was obtained from
the K.U.Leuven, where the Rijndael algorithm was devel-
oped [6], [7].
3.2.2 2002: secure speech transmission
The choice of the hardware, combined with the software
modules put some additional constraints on the system that
became evident after the first design seminar. The most im-
portant technical issues were:
sampling : The C6711 DSK boards have a ADC converter
that is limited to a mono 8 kHz sampling rate, while
typical CD quality is at stereo 44.1 kHz. While this
obviously does not influence the functionality of the
system, it has a clear effect on the produced audio.
clock drift : In line with the intend of these low cost starter
kits, the boards are equipped with cheap clocks that
steer the ADC/DAC converters. As such, there is a
considerable clock drift between the capturing and
playback clocks (up to 0.8). This problem can be
solved in software by including a re-sampling mod-
ule, however, a synchronisation time is needed. In
combination with the chain that was implemented that
5
buffered the data to enable some operations (encryp-
tion on blocks of data, an MP 3 block has 1142 sam-
ples) made the synchronisation process slow.
These concerns were addressed in the following edition by
modifying the problem to a secure speech transmission sys-
tem. The change in functionality was also reflected in the
system design (figure 3):
serial communication : While the secure audio transmis-
sion example was based on a client server system, a
server sending data to the client, the P2P secure speech
link needs (at least half-duplexed) two-way commu-
nication. This requires that all the code needs to be
present on one system (no distinction between server
and client anymore). The bi-directional link also en-
abled the removal of the µc -µc link and letting the
control communication go over the DSK-DSK serial
link. This reduced hardware complexity and µc func-
tionality requires a complex routing of data between
the modules.
subband en/de-coding : In order to reduce latency, com-
bined with the introduction of more hands-on pro-
gramming4 , the MP 3 code was replace with custom
designed subband encoding and decoding (C code).
functional specialisation : Due to the increased complex-
ity of the overall system, it was no longer feasible
to split people in client and server teams, also be-
cause the full functionality is in every box. Instead,
groups were assigned to do more software develop-
ment (en/de-cryption and subband en/de-coding) or fo-
cus on hardware integration (µc and DSP).
4 In the first edition, practical C knowledge and programming practice
proved to be a larger problem than anticipated.
4 Design Seminar: Building a Prototype
This section reports about the actual design seminars.
The work done by the students in the design seminar is de-
scribed, with a special focus on the implementation on the
DSK and µc platforms. While designing the secure audio
distribution system, all students had a lot of hardware pro-
gramming, while in the secure speech transmission system,
about half had the same hardware oriented focus, the rest of
the students worked on the DSK, mainly to test their algo-
rithms.
4.1 2001: secure audio distribution system
All teams (DSP and µc ) consisted of 2 to 3 persons, with
about 16 DSP teams and 4 µc teams. In turn, the DSP teams
were divided in the ones that would work on the client side
(decoder) and the ones on the server side (encoder). In the
first part, the DSP work is explained. The second part will
go into the work done by the people that were assigned to
the µc tasks.
4.1.1 DSP work
The students had to get a prototype of the secure audio
transmission system working within the time frame defined
by the duration of the seminar. This is regarded as a hard
deadline. All the publically available software modules
were collected before the seminars. The main task of the
DSP groups was to integrate these within the T I DSP/B IOS
Real Time Operating System (RTOS) [4].
The software modules as described in section 3.2.1 had
to be integrated. To this end, a pipe structure was used [17],
readily available in the DSP/B IOS environment. These
pipes isolate the modules, making their operations indepen-
dent from each other. In order to write this code, a rudimen-
tary knowledge of how the code uses its buffers is needed
and the wrapper code must adapted to this (see figure 4).
These software modules were given at the start of the sem-
inar (MP 3, encryption and serial communication), mainly
motivated by the fact that the code is readily available from
the Internet. As a result, not giving these would only delay
the project without providing much added value.
Still, the following problems needed to be solved:
transmission: As long as the data is on one board, it is easy
to retrieve the data at any point, since the programmer
knows in what format and in what buffer it is written.
When the data is transmitted over the serial line, this
is not the case anymore. Code had to be written to
recognise the data packets on the other (client) side of
the system.
resampling: There is a particular problem with the Analog
to Digital/Digital to Analog Converter devices. There
6
is a slight drift between the clocks of any two boards.
The students had to write synchronisation code to com-
pensate for this.
equaliser: On the client side, the equaliser code has to be
plugged in.
Framing of the Data In order to write the wrapper code
for each subsystem (client or server) to integrate the func-
tional modules, detailed knowledge of the interfaces of soft-
ware modules is needed. This is then used for correctly
processing the data. After some initial C tackling and fa-
miliarising with the T MS 320C6711 DSKs and the I DE,
the groups completed the initial integration of the software
modules without problems.
After the development of the wrapper code on the client and
server side, the first integration phase is required: the one
concerning the two DSK boards.
When the data is transmitted over the serial line, the
frame information is lost. To the receiver, the data is noth-
ing but a continuous stream of bits. Obviously a trial and
error approach of trying to decrypt the n×128 byte blocks5
(shifting a bit to the left every time an error was produced)
is not a viable option.
One solution the groups opted for, was to agree on a
fixed length an encrypted block of data would be. Next,
each block would be encapsulated by a header the client
and server developers agreed upon. The client software
then scans through the received data bitwise until it iden-
tifies such a header. At this point, the client is sure that the
next n × 128 bytes do not contain this header anymore. It
then copies these bytes into the decoding buffer.
Another solution was to include the length of the data-
block in the frame header instead of predefining this length.
When this option is used, the server controls the length and
the client adapts its operations. This solution is obviously
more flexible, though in practice there is no difference since
the length of the data block is not changed once the system
is running.
Resampling PCM Data and the Equaliser The next
problem the prototype developers were confronted with, is
that the quality of their decoded music was very low6 [19].
Some groups experienced very slow playback with discon-
tinuities, while others had the problem that the sound was
too high pitched, intermitted with short bursts of random
5 128 is the element size of the encryption algorithm. The encrypted
data blocks should be a multiple of 128 bits.
6 The DSK boards have a sampling limit of 8 kHz mono sampling fre-
quency. The best sound quality is at any time telephone level. This in
contrast with the more expensive Evaluation board Module (E VM) that has
a 48 kHz capability.
 Figure 4. Interfacing software modules with DSP/BIOS in Code Composer Studio
noise7 .
The first possible problem to eliminate was to check if
the data does not get corrupted along the way. After remov-
ing this possibility, the groups started testing the hardware
and came to the conclusion that the behaviour of their pro-
grams changed with the combination of DSK boards they
were using, reducing the search space to the boards. In
order to identify the problem as being drifting clocks, the
students had to know the details of the DSK board.
The data flow in the MP 3 chain is largely governed by
the rate at which the data is sampled, since the release of
a buffer triggers a software interrupt that fires the next pro-
cessing module in the pipe (see figure 4). In turn, this mod-
ule produces a new batch of data, releases it, which fires a
new software trigger. In the case of the MP 3 system, the
data entering the system is the sampled audio. At the end
of the chain (on the client side) there is a discontinuity: af-
ter the decoding, data is consumed by the Digital to Analog
Converter (DAC) at a fixed rate (its clock speed), instead
of being triggered (see figure 5). At this point, one of the
following problems is most likely to occur:
• If the Analog to Digital Converter (ADC) clock on the
server side is faster than the DAC clock on the client
side, the music that is played back would be too slow,
dropping data when the buffers are full. This accounts
for the discontinuities in the sound.
• If the ADC on the server side is slower than the DAC
clock on the client side, then there is not enough data
to be be put on the output line and buffer underruns
occur.
Since it is generally possible that multiple clients, each
with a different DAC clock, connect to a single server, the
adaptation had to be made on the client side. A requirement
that was added, once the groups identified the reason for the
poor audio quality, was that any solution they come up with,
had to be independent from any combination of boards.
7 The
random noise was built in the serial communication code to indi-
cate to the students that something was wrong. This enabled the students
to make the distinction between a crash of the boards (by e.g. overwriting
program memory) and functional problems
7
The groups on the decoder side developed to different
solutions:
• All the data is decoded. If no buffer is available to
write the decoded data in (DAC clock is too slow), the
data is dropped. If there is not enough data to keep
the DAC busy, padding is applied. The main strength
of this example is that the client knows exactly how
much data is dropped or padded and will have a exact
resampling ratio based on these values.
• Another solution was to check if the PCM data will
be played before the MP 3 frame is decoded. If the
DAC has enough data queueing, the frame is dropped.
This approach has a larger granularity but minimises
the DSP load by not decoding unneeded values. It also
uses a step-wise change in the resampling factor, mak-
ing it harder to converge towards a resampling ratio
that reflects the exact client/server clock drift unless a
more complex system is used that compensates for this
effect.
By this time, the groups working on the DSP had a sys-
tem that captured, encoded and encrypted the data, trans-
mitted it to the counterpart client board over a serial line.
This stream was then again converted to PCM data and put
on the speakers. The entire system was able to compen-
sate for the drifting ADC/DAC clocks and after a couple of
seconds, the system self-stabilised. Adding an extra mod-
ule just before the DAC to perform equalising was quickly
done.
4.1.2 Microcontroller
On the µc side, each group had access to two TI MSP430
microcontrollers [5] with a clock frequency of 8 MHz.
These microcontrollers have a 16-bit RISC architecture, 16
integrated registers on the CPU, built-in hardware multipli-
cation, and communication capability using asynchronous
(UART) and synchronous protocols. A digital-controlled
oscillator, together with the frequency lock loop, provides a
fast wake up from the low-power mode to the active mode
in less than 6 µs, which makes this product a good candidate
 Figure 5. Data stream discontinuity: DAC pulls data out the system
when fast real-time response and extended battery lifetime
are both important design requirements.
Unfortunately, the systems were configured with just 1
KB of RAM, which makes it almost an impossibility to
write software via any high level language. Hence, an addi-
tional requirement for the microcontroller groups was that
of using the MPS430 assembly to develop their software. A
front-end software by TI was available, which also allowed
students to debug their code via step-by-step executions and
breakpoints.
After some familiarising with the system, the students
had to learn how to use the system and its software. Imme-
diately after this preliminary step, they were asked to de-
velop a driver for the keypad. As an example, the source
of a driver for printing strings on the LCD was given to the
students.
After this, the students were asked to set up drivers for
the communication between the microcontrollers (via the
UART) and to their slave DSP (via parallel ports). Again,
example code was available to provide hints to the groups.
Then the students had to develop a port-to-port protocol
between DSP-µc including the following requests:
encryption keys : encryption needs two keys, the first one
is the encryption key that is used to encrypt and de-
crypt the data. These keys are generated by the µc and
passed to the DSK boards. The keys are generated on
the server side µc , sent to the client µc and this one
passes the keys to client DSK.
integrity key : this is the second of the key-pair needed for
encryption. This one is used to check if there was any
tampering with the data block. It adds an extra level of
security.
equaliser : the user enters or changes the values of the
equaliser bands to adjust the music quality. This is a
client-only task.
change keys : a generated key-pair has a limited lifetime.
The servers side µc keeps a counter to see if the key-
pair is still valid. If it is not valid, it generates a new
8
pair. However, the keys are passed to the DSK byte
by byte. If the DSK used these new bytes immedi-
ately in its 16 byte (128 bit) key, the data would get
corrupted. To avoid this, the µc passed the new key,
and only when it got confirmation that all keys arrived
and were processed, it generates a signal to the DSK to
start encrypting with the new key-pair.
In the implemented µc -DSK communication protocol, the
µc has to check if a command is received and processed. To
this purpose, it keeps a counter for each command it sent
and then waits. The DSK in turn, returns the command it
received combined with its own counter of the number of
commands it had received. After successful comparison by
the µc , the µc can send a new command, else, it resends the
last command.
4.1.3 Integration: DSP and µc
The last step of this design process is on the integration
sessions, in which the microcontroller groups and the DSP
groups had to work together to set up the entire application.
Up until this point, the both teams had only used specifica-
tions and agreements they made.
The communication from the µc to the DSP was done by
writing into a 16-bit register on the daughterboard. This reg-
ister was mapped in the DSP memory hierarchy and raised a
hardware interrupt to the DSP. Writing from the DSP to the
µc is done by writing to a 8-bit register on the daughter-
board (again memory mapped). The µc polled this register
to see if the contents had changed,
Once the basic system as described worked, a couple
groups invested their remaining time in adding functional-
ity to the system. This was not longer separated, but tightly
coupled since new commands had to be agreed upon. Also,
the µc groups had their programming memory filled. In or-
der to tweak out that last bit of functionality, we saw that
they started moving functionality off the µc on the DSK
boards. Space was then freed for (additional) control tasks.
Two of the important added features are the inclusion of a
start/stop button on the client side and the server warning
the client when the time was about to expire. They could
then start negotiating on a next time frame, before the cur-
rent audio stream was encoded with a new key the client did
not have.
Because of the clear system description, this integration
was done seaminglessly and well within the budgeted time
of two sessions.
4.2 2002: secure speech transmission system
In the second edition of the design seminar, the teams
were divided into functional groups: 1 group working on the
development of subband encoding and decoding, another
group working on encryption and decryption, one group on
the µc , one group on the serial communication between
both DSK boards and one group on the framework that tied
the system together. Every group consisted out of 2 to 3
persons.
4.2.1 DSP work
One of the remarks the students had on the secure audio dis-
tribution system was that they did not have enough freedom
to develop a solution. Therefore, the amount of material
given at the start was reduced, which included a more hit-
ting the metal approach for getting the e.g. serial communi-
cation to work accompanied with browsing through techni-
cal manuals. Unfortunately, this work was hindered by two
main problems that we did not encounter during the previ-
ous sessions:
ADC/DAC code : one of the first examples a student is
confronted with when starting to work with CCS, is
the audio example. The code that was used in the first
edition was based on the 1.2 version of CCS. The main
advantages were that it was clear and clean code for
people to start with. This year, the CCS was upgraded
to the 2.0 version. The modified audio example code
was more complex and included some features to show
possible problems at an advanced level. As a result,
much more time was spent on the familiarising with
the tools and the example code and even rendering the
example useless for students to start with.
CCS bug : a DSP/BIOS configuration tool (cdb) related
bug generated erroneous C code from the graphical in-
terface to the DSP/BIOS functionality. Identifying the
problem took some time.
On the other hand, the group working on the frame-
work code had little problems other than managing the large
complexity of their project. The introduction of the bi-
directional communication required much more interaction
with the RTOS by defining the correct software interrupts
and buffers. The framing code developed was more or less
9
similar to the code developed by the teams in the previous
year, with one important difference: they had to compensate
between different types of data being sent over the serial
line. Instead of pure data, the following types could now be
sent:
encryption negotiation : In the previous edition, the
server µc generated a key-pair and passed it along to
the client µc via the µc -µc serial link. In the speech
system, the functionality was extended with Diffie-
Hellman key initialisation [13]. Since there is no en-
cryption key, this data is not encrypted and should be
directed at the AES modules (see figure 3).
µc control commands : Instead of using a µc -µc link,
all communication is done via the DSK-DSK link.
Such command data should be recognised and directed
to the microcontrollers.
data : The bulk of the traffic over the serial line consists of
data, subband encoded and encrypted audio.
The routing information is added to the framing header and
the packet length. This way, when a header is identified, the
destination (packet type) is extracted and the content is sent
to the correct module by putting it in a different buffer.
4.2.2 Microcontroller
One of the problems of the µc -DSP communication scheme
of 2001 was the constraint that messages had to be a maxi-
mum of 16 bits from µc to DSP and 8 bits from DSP to µc .
In the last edition of the course, this limitation was removed
by using a simple protocol that allowed the transmission of
messages of arbitrary length between both processors. This
allowed the transmission of complete keys in just one mes-
sage. Messages are divided in blocks and then reassembled
on the target system.
Additionally, messages had a target address, which al-
lowed the µc to communicate with several modules (en-
cryption, equaliser and the µc on the other side) in a uni-
form and simple manner.
Message transmission is always initiated by the µc . The
µc periodically polls the DSP to see if there are pending
messages. If there are any messages, the µc requests the
message byte by byte to the DSP and then reassembles it.
In order to transmit a message, the µc sends the message
byte by byte to the DSP. When the message is received, it is
then redirected to the appropriate task.
4.2.3 Integration
The groups each developed their part of the system sep-
arately, but needed to communicate with others to estab-
lish interfaces (mostly algorithmic encryption and encoding
people with the framework team and the µc team with the
framework team) and agreements had to be reached. One of
the most prominent things to notice was how the different
teams developed their own emphasis and view of the func-
tionality of the global system.
The code of the serial communication was integrated
with the framework. The framework code processed com-
mands from the µc and passed it along the serial line.
Unfortunately, a fundamental problem prevented the final
integration of the software modules into this hardware-
dependent code. The decision to let some people work on
the development of algorithms in C was inspired by the im-
portance of C in commercial code and implementations and
the fact that this seminar was the first real hands-on expe-
rience most students had with this language. However, a
working C program is not identical to good C code, and
especially embedded devices (DSP) are sensitive to this.
The combined project did compile, but at run-time prob-
lems were continuously detected, mainly caused by mem-
ory handling. There was not sufficient time left to handle
these problems.
5 Conclusions
After two years, and two different sessions to let the stu-
dent get acquainted and get hands-on experience with em-
bedded systems, a number of conclusions can be made. As
for the goals that were set out at the start of the project, the
following were reached:
A number of things that still need to be improved are:
• A thorough introduction into embedded systems was
offered to the students and the different areas involved
in embedding software: the technical hardware and
software side and the more interactive integration. The
people on the DSP side had a clear idea of the inter-
nals of such a development system, and had mastered
the basics of an operating system and put it to use. The
same goes for the µc side. Since they were working
on a lower level (assembly) and on a simpler system,
they knew the µc inside out. They got to know how to
squeeze out the last bit of functionality on a very con-
strained (memory wise) hardware platform. Especially
in the implementation of the secure speech transmis-
sion system, the framework and the required logic to
tie it together was complex and posed a challenge to
the students.
• We believe that the environment provided to work in,
was closely reflecting the one of industrial projects.
On both of the major platforms, the problem was not
obvious and implementation issues were built into the
seminar sessions; issues that had to be solved by the
students themselves.
10
• In the secure audio distribution system, a working pro-
totype was set up within the budgeted time.
• When the sessions were in danger of running out of
time, rescheduling of the groups was done in order to
get the system working. The time needed for the im-
plementation (and familiarisation) on the systems was
underestimated. It took the students more time than
expected to understand the logic of the DSK and the
development tools (DSP/BIOS). Due to delays with re-
spect to the initial planning, the prototype would never
be completed within the time of the seminar. In the
first edition, this was done by splitting up the work that
needed to be done in subproblems and assigning these
to different groups. In the second edition, such a divi-
sion was already done from the start, but when a group
encountered unexpected problems, another group took
over part of the work. This gave the participants ex-
perience in project management and inter-group coor-
dination. These points were also very important in the
coordination of the integration parts (DSK–DSK and
DSK–µc ).
• Some obvious oversights in the curriculum were fixed:
the students had to attain a profound knowledge of C
(and assembly programming).
• The hardware platform and the provided tools are
good teaching tools and overall, the students found the
course motivating.
• One of the remarks last year, was the lack of C knowl-
edge. This year, the seminar started with a crash-
course (6 hours) into the basics of C and more em-
phasis was put on programming and debugging. Still,
this is the most important recurring remark: the stu-
dents realise the importance and are frustrated to some
degree that it is not more prominent in their curricu-
lum [8].
• In a response to giving more design freedom, the pen-
dulum swung too far to the other side. This combined
with a steep learning curve when working with DSPs
posed additional problems. In following editions, a
middle ground must be found between these two.
• More attention has to be put on the quality of the pro-
duced C code by the people guiding the algorithmic
design groups.
• The tutorials need to be checked after an upgrade of
the development tools. The audio example was too
confusing to be in a tutorial session.
 View publication stats
This seminar, with other initiatives to give engineering a
much needed new appeal, gives the students an opportunity
to apply the theoretical competence in a real-life applica-
tion. Instead of giving additional courses for gaps in the
curriculum, this knowledge is now offered in a hands-on
manner. It offers also experience that cannot be learned in
classical sessions: social interaction, cooperation to obtain
results and a taste of the future.
This seminar is the first step in bridging the gap between
industry and our university. With the experience of the past
sessions and ideas from industry, these design sessions are
modified and extended to fit new requirements and evolu-
tions.
6 Acknowledgements
From the very outset of the project, the department got
large support from TI. They sponsored the hardware and the
best project team was given a TI award, including a set of
DSK boards. The students that followed this design semi-
nar have to be acknowledged for their positive feedback and
suggestions which gave a definite added value to the entire
project.
Geert Deconinck is a postdoctoral fellow of the Fund for
Scientific Research - Flanders.
References
[1] Anonymous. Freshmeat, mpg123 description,
2001. http://freshmeat.net/projects/
mpg123/.
[2] Anonymous. Nist website, 2001. http://csrc.
nist.gov/encryption/aes/rijndael/.
[3] Anonymous. T I website, 2001. http://focus.
ti.com/docs/tool/toolfolder.jhtml?
PartNumber=TMDS320006711%.
[4] Anonymous. T I website, 2001. http:
//dspvillage.ti.com/docs/sdstools/
sdscommon/showsdsinfo.jhtml?path%
=templatedata/cm/dspbios/data/
overview_and_benefits&templateId=57.
[5] L. Bierl. MSP430 Family Mixed-Signal Microcon-
troller Application Reports. Texas Instruments, 2000.
[6] J. Daemen and V. Rijmen. The block cipher rijndael.
In Smart Card Research and Applications, pages 288
– 296. LNCS 1820, J.-J. Quisquater and B. Schneier,
Eds., Springer-Verlag, 2000.
[7] J. Daemen and V. Rijmen. Rijndael, the advanced en-
cryption standard. In Dr. Dobb’s Journal, volume 26,
No. 3, pages 137 – 139, March 2001.
11
[8] ESAT/KULeuven. Burgerlijk elektrotech-
nisch ingenieur en burgerlijk werktuigkundig-
elektrotechnisch ingenieur richting elektrotechniek,
2001. http://cwisdb.cc.kuleuven.ac.
be/programmaboek/h/h15.htm.
[9] M. Hipp. Mpg123 mp3 decoder, 2001. http://
www.mpg123.de/.
[10] T. Jansson. Bladeenc, a free mp3 encoder, 2001.
http://bladeenc.mp3.no/.
[11] C. Kelly. Teaching from a clean slate. IEEE Spectrum,
pages 59 – 64, September 2001.
[12] M. Leeman and F. Barat. Hj82 dsp seminar sessions,
2001. http://www.esat.kuleuven.ac.be/
˜mleeman/hj82/.
[13] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone.
Handbook of Applied Cryptography. CRC Press, 2000
Corporate Blvd., Boca Raton, FL 33431, USA, 5th
edition, 2001.
[14] Shigeo. The gogo encoder, 2001. http:
//homepage1.nifty.com/herumi/soft.
html/.
[15] M. Slager. Mpeg/audio, 1997. http://www.
csclub.uwaterloo.ca/˜mpslager/
articles/mpeg/mpeg.html.
[16] M. Taylor. Lame ain’t an mp3 encoder, 2001. http:
//www.sulaco.org/mp3/.
[17] Texas Instruments, Canada. User’s Guide Code Com-
poser v3.0, Code Composer Simulator v 3.0, 1998.
[18] Texas Instruments, Nice,France. Code Composer Stu-
dio, Getting Started, 2001.
[19] Texas Instruments, Nice, France. TMS320C6201/6701
Evaluation Module Technical Referencei (spru305),
December, 1998.
[20] L. Van Eycken. Seminaries ontwerpen ict: M&s:
HJ 82, 2001. http://www.esat.kuleuven.
ac.be/˜hj82/2000-2001/.
[21] A. Young, M. Young, and S. Bon. Highway to hell,
1979.