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 DeconinckACCA/ESAT KULeuvenKasteelpark Arenberg 103001, Heverlee, Belgium

firstname.lastname@esat.kuleuven.ac.be

Abstract

In this paper, a design seminar on embedded systems isdescribed for fourth year students in theMultimedia andsignal processingoption 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 upthe 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 andlanguages, development tools and hardware platforms inorder to develop a prototype of a set-top box with off-the-shelf tools, hardware and software. The interdisciplinarycharacter of this seminar combines multiple topics taughtin courses in the application.

1 Introduction

Embedded Computing has become ever more pervasiveover the last decades and this evolution has only touchedthe surface of the myriad of possibilities. Every day, new ormore challenging applications are conceived and researchedin companies and universities. Despite this promising fu-ture, the education of the techniques that lie at the basisof these applications (e.g. programming optimisation andpower consumption aware programming techniques) aresometimes neglected in favour of new programming con-cepts that may or may not prove to be useful inreal life.

Efficiently mapping an algorithm to an embedded systemhas always been a challenging task. A number of technicaland non technical reasons account for this. First of all, em-bedded systems have always been quite cost sensitive (themaximal functionality has to be mapped on the cheapest de-vices). Where the main focus had been to get sufficientfunctionality on the system, it has been now complicated

by requiring power efficient systems, to be implemented inubiquitous, hand held devices. But still, the manufacturerthat is able to offer that extra bit of functionality or perfor-mance at the same or lower cost has a definite advantagein a very competitive market often characterised by techni-cally proficient customers. Secondly, with the progress ofchip design, the functionality of the embedded processor in-creases up to a point that a lot of these can almost competewith general purpose processors1.

In order to cope with this kind of changing environment,the systems developed must be modular and attention needsto be put on correct integration. A modular system makessure that last minute implementation or functional changescan be localised and do not affect the entire embedded soft-ware system. It also enables the reuse of previous softwaremodules and third party software, as well as easy integra-tion.

One of the problems with an academic curriculum is thatthere 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 ofthe state of the art technology, the engineering programmewas reformed at the University of Leuven with these ex-pectations of industry in mind, the need for well qualifiedengineers and in an effort to revitalise engineering [11] acouple of years ago. More stress is put on implementationof a system and not just on its design. Next to a series ofrenewed courses, a design seminar was scheduled toim-plement a multimedia application, with signal-processingspecific hardwarein the Multimedia and signal processingoption [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

1And all this should be done by yesterday

1

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 andthe work of the students is elaborated. This paper concludeswith a general overview of attained goals and some possiblechanges 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 implementedin the first edition, to a more complex modified versionthat took hardware limitations into account and was imple-mented in the second edition. It also introduces the softwareand hardware components that were integrated in the finalsystems.

Over the last years, a lot of controversy arose around thedistribution of copyrighted material over the Internet. Thismedium allows world-wide and fast distribution at a lowcost and results in claims of huge losses by the audiovisualindustry. More importantly, due to judicial actions, lobby-ing and strict legislations, service enterprises found them-selves faced with the de-facto obligation to strongly protecttheir copyrighted goods from unauthorised copying whendistributing it. On the other hand, commercial exploitationof the Internet as the largest and ubiquitous mall, gives thesecompanies a strong incentive for the introduction of secure,Internet-aware embedded systems and software integratedin 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 thetop priorities. As with most students, this audio example isa problem they are confronted with almost on a daily ba-sis. The initial problem description was selected among aset of industry relevant scenarios: to develop a transactionbased client/server system that enabled secure transmissionof CD quality music. This e-commerce allowed one party toconsult a music repository and allowedorderingany num-ber of audio files. Every transaction needed to include pricenegotiation (between server and client) and credit approval(client).

The two key factors areauthenticationandencryption:authentication assures that the recipient of the data streamis the one he is claiming to be and encryption ensures thatthe data stream cannot be used by anyone but the intendedrecipient. The set-top prototype was designed with the fol-lowing restrictions:

off-the-shelf hardware : time-to-market is important inindustry. This requires using standard componentswhere possible and integrating them in the applicationthat is developed. Only when strict requirements haveto be met (power consumption, I/O, . . . ) a custom de-

sign is considered. Furthermore, these readily avail-able components are often available at a much lowercost than a in-house developed solution. In this sem-inar, the requirements are defined so that no customhardware needs to be developed.

off-the-shelf software : the same reasoning applies for thesoftware modules that are used.

In a digital world were data is intercepted analysed andscrutinised 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 ofthe problem description. Since CD quality audio transmis-sion was not possible with the current hardware, the systemwas 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 mainhardware 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 phaseof the seminar. Each subsystem (client or server in the audiodistribution case, or peer to peer (P2P) in the secure speechtransmission 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 asimple user interaction.

Due to our past experience with Texas Instruments (TI),the fact that they occupy the largest market segment (andas 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 theTMS320C6711 Developers Starter Kit (DSK) [3]. TheDSP 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 integrateddevelopment environment (IDE): Code Composer Studio[18]. The performance of the DSP also makes certainthat there is additional room for functional upgrades andchanges by the students. The Code Composer Studio soft-ware offers a clear C and assembly programming IDE, aninterface 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 toprovide the needed user interaction by steering a LCD dis-play and reading input from a small keypad, setting up a

2

Figure 1. The system setup. On the left hand site, the full system is displayed, on the right hand sitethe key components. 1: the ’C6711 DSK board, 2: the MSP430 controller, 3: the custom designeddaughterboard, 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 TI was selectedfor the seminars. Considering the specifications (discussedmore in Section 4.4.1.2), the entire program would have tofit in 1 kB of memory, the allocation of every byte in order tomeet the software functionality would have to be measuredcarefully. While the software of the DSP gave a graphicalinterface to the hardware and to the RTOS functionality, thefocus of theµc was completely the opposite, programmingwas done in a basic editor and the program was sent overthe serial port to theµc board.

The final system is seen in figure 1. Every system (on thedecoder as well as on the encoder side) has the followingcomponents:

• 1 TMS320C6711 DSK board

• 1 MSP430 microcontroller with a keypad and anLCD

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 ofevery session and disassembled afterwards. The system isconnected with a cable with two SUB D9 connectors.

3.2 Software

The functionality of the original secure audio distribu-tion system and the secure speech transmission system isslightly different. First, the audio example is explained andin a subsequent section, the most important changes for thespeech 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. Thefollowing 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 inclusionof analog to digital conversion only makes the systemmore flexible. If the audio was already stored in dig-ital form (which is very likely), the Analog to DigitalConverter (ADC) step would have to be removed andreplaced with the new data source. The ADC converteron the DSK board is used for the conversion of the au-dio to PCM samples.

Compression: Since the data should be delivered to arange of customers over the Internet, distribution needsto be done in a form that consumes the least bandwidthfor the quality required (a combination of customerdownstream bandwidth limitations and expensive up-stream -server- reduction). We chose the MPEG1 layerIII audio compression (MP3) [15].

Encryption: Encryption of the audio stream covers twodifferent problems. First of all, the data stream must

3

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, thevalidated recipient of the audio steam should only beable to decipher the data stream as long as he/she hasprovided enough credits. If the credit runs out, the datastream should become unusable. The latest encryptionstandard is chosen for this task, known as Rijndael orAES [6], [7], [2].

Serial connection: in order to transmit the data to the em-bedded system counterpart, a communication link ofsome nature is required. Instead of using a full fledgedcommunication system, a serial link was chosen. Aswith the audio capture, this gives the students detailedknowledge of the hardware. The prototype system hasto be able to recover from errors in this serial connec-tion, when it drops or corrupts data for some reasonand 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 totweak the audio with a 4-band equaliser and volumecontrol.

On theclient side, the complementary tasks are done: de-cryption, decompression (MP3 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 arepractical problems that need to be solved during implemen-tation in order to get a working system and will be discussedin section 4.

The decision of the implementation was based on testingof the different available public domain coders. The resultsof this are summarised in table 1 for the encoders. The en-

Coder Elapsed Time PortabilityBlade 1’02” problematicLame 0’40” highGogo 0’24” low

Table 1. Evaluation of different MP3 encoders(elapsed time and portability), Highway to Hell,3’28”.

coding2 was done on an AMD 650 PC3, 512 MB SDRAMon a single song [21]. Thegogo [14] encoder is a hackof the lame [16] encoder which is partly written in assem-bler. For this reason, it is not usable on the DSP platformwithout rewriting the assembler part. Both theblade [10]and lame encoders are fully written inC, but the memorymanagement and usage in theblade encoder makes theportability to an embedded system problematic.

Decoding the stream is not such a intensive task as encodingit. Since the same computational power is available on theclient side as on the server side that does the encoding, thecycle budget should not pose a problem. Still, this shouldnot be a reason to implement a slow solution into the pro-totype, the final system might include less performant (andless expensive) hardware. The choice of aMP3 decoder waseasier, mostly because the most important public domaindecoder is very good:

2Conversion fromWAV format, RIFF (little-endian) data, WAVE au-dio, Microsoft PCM, 16 bit, stereo 44100 Hz to MPEG 1.0 layer III audiostream data, 128 kBit/s, 44.1 kHz, jstereo.

3Running Debian 2.2r2 (Sid), Linux and theGCC compiler 2.95. Thecompiler options used are those found in the Makefile. For thegogo andthelame encoder, this was-O3 and for theblade encoder, this was-O2 .

4

Figure 3. System description: software chain secure speech transmission system.

1. Most public domainMP3 decoding use some form ofthempg123 decoder [9].

2. There is a trimmed down version available in thesource tree ofmpg123.

3. Searching on the Internet showed that this de-coder could even be used on older systems as an80486DX2 [1], which makes it fast.

The encryption and decryption code was obtained fromthe 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 softwaremodules put some additional constraints on the system thatbecame evident after the first design seminar. The most im-portant technical issues were:

sampling : The C6711 DSK boards have a ADC converterthat is limited to a mono 8 kHz sampling rate, whiletypical CD quality is at stereo 44.1 kHz. While thisobviously does not influence the functionality of thesystem, it has a clear effect on the produced audio.

clock drift : In line with the intend of these low coststarterkits, the boards are equipped with cheap clocks thatsteer the ADC/DAC converters. As such, there is aconsiderable clock drift between thecapturing andplaybackclocks (up to 0.8). This problem can besolved in software by including are-samplingmod-ule, however, a synchronisation time is needed. Incombination with the chain that was implemented that

buffered the data to enable some operations (encryp-tion on blocks of data, anMP3 block has 1142 sam-ples) made the synchronisation process slow.

These concerns were addressed in the following edition bymodifying the problem to asecure speech transmission sys-tem. The change in functionality was also reflected in thesystem design (figure 3):

serial communication : While the secure audio transmis-sion example was based on a client server system, aserver sending data to the client, the P2P secure speechlink needs (at least half-duplexed) two-way commu-nication. This requires that all the code needs to bepresent on one system (no distinction between serverand client anymore). The bi-directional link also en-abled the removal of theµc -µc link and letting thecontrol communication go over the DSK-DSK seriallink. This reduced hardware complexity andµc func-tionality requires a complex routing of data betweenthe modules.

subband en/de-coding: In order to reduce latency, com-bined with the introduction of more hands-on pro-gramming4, the MP3 code was replace with customdesigned subband encoding and decoding (C code).

functional specialisation : Due to the increased complex-ity of the overall system, it was no longer feasibleto split people inclient 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).

4In the first edition, practical C knowledge and programming practiceproved to be a larger problem than anticipated.

5

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 theDSK andµc platforms. While designing the secure audiodistribution 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 ofthe 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, withabout 16 DSP teams and 4µc teams. In turn, the DSP teamswere divided in the ones that would work on the client side(decoder) and the ones on the server side (encoder). In thefirst part, the DSP work is explained. The second part willgo into the work done by the people that were assigned totheµc tasks.

4.1.1 DSP work

The students had to get a prototype of the secure audiotransmission system working within the time frame definedby the duration of the seminar. This is regarded as a harddeadline. All the publically available software moduleswere collected before the seminars. The main task of theDSP groups was to integrate these within the TI DSP/BIOS

Real Time Operating System (RTOS) [4].The software modules as described in section 3.2.1 had

to be integrated. To this end, apipestructure was used [17],readily available in the DSP/BIOS environment. Thesepipes 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 neededand the wrapper code must adapted to this (see figure 4).These software modules were given at the start of the sem-inar (MP3, encryption and serial communication), mainlymotivated by the fact that the code is readily available fromthe Internet. As a result, not giving these would only delaythe 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 easyto retrieve the data at any point, since the programmerknows in what format and in what buffer it is written.When the data is transmitted over the serial line, thisis not the case anymore. Code had to be written torecognise the data packets on the other (client) side ofthe system.

resampling: There is a particular problem with the Analogto Digital/Digital to Analog Converter devices. There

is aslight 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 beplugged in.

Framing of the Data In order to write thewrappercodefor 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 correctlyprocessing the data. After some initialC tackling and fa-miliarising with the TMS320C6711 DSKs and the IDE,the groups completed the initial integration of the softwaremodules without problems.After the development of the wrapper code on the client andserver side, the first integration phase is required: the oneconcerning the two DSK boards.

When the data is transmitted over the serial line, theframeinformation is lost. To the receiver, the data is noth-ing but a continuous stream of bits. Obviously atrial anderror approach of trying to decrypt then×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 afixed length an encrypted block of data would be. Next,each block would be encapsulated by a header the clientand server developers agreed upon. The client softwarethen scans through the received data bitwise until it iden-tifies such a header. At this point, the client is sure that thenextn × 128 bytes do not contain this header anymore. Itthen 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 andthe client adapts its operations. This solution is obviouslymore flexible, though in practice there is no difference sincethe length of the data block is not changed once the systemis running.

Resampling PCM Data and the Equaliser The nextproblem the prototype developers were confronted with, isthat 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 wastoo high pitched, intermitted with short bursts of random

5128 is the element size of the encryption algorithm. The encrypteddata blocks should be a multiple of 128 bits.

6The DSK boards have a sampling limit of8 kHz mono sampling fre-quency. The best sound quality is at any time telephone level. This incontrast with the more expensive Evaluation board Module (EVM ) that hasa48 kHz capability.

6

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 hardwareand came to the conclusion that the behaviour of their pro-grams changed with the combination of DSK boards theywere using, reducing the search space to the boards. Inorder to identify the problem as being drifting clocks, thestudents had to know the details of the DSK board.

The data flow in theMP3 chain is largely governed bythe rate at which the data is sampled, since the release ofa 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 anew software trigger. In the case of theMP3 system, thedata entering the system is the sampled audio. At the endof the chain (on the client side) there is a discontinuity: af-ter the decoding, data is consumed by the Digital to AnalogConverter (DAC) at a fixed rate (its clock speed), insteadof being triggered (see figure 5). At this point, one of thefollowing problems is most likely to occur:

• If the Analog to Digital Converter (ADC) clock on theserver side is faster than the DAC clock on the clientside, the music that is played back would be too slow,dropping data when the buffers are full. This accountsfor the discontinuities in the sound.

• If the ADC on the server side is slower than the DACclock on the client side, then there is not enough datato be be put on the output line and buffer underrunsoccur.

Since it is generally possible that multiple clients, eachwith a different DAC clock, connect to a single server, theadaptation had to be made on the client side. A requirementthat was added, once the groups identified the reason for thepoor audio quality, was that any solution they come up with,had to be independent from any combination of boards.

7The random noise was built in the serial communication code to indi-cate to the students that something was wrong. This enabled the studentsto make the distinction between a crash of the boards (by e.g. overwritingprogram memory) and functional problems

The groups on the decoder side developed to differentsolutions:

• All the data is decoded. If no buffer is available towrite the decoded data in (DAC clock is too slow), thedata is dropped. If there is not enough data to keepthe DAC busy, padding is applied. The main strengthof this example is that the client knows exactly howmuch data is dropped or padded and will have a exactresampling ratio based on these values.

• Another solution was to check if the PCM data willbe played before theMP3 frame is decoded. If theDAC has enough data queueing, the frame is dropped.This approach has a larger granularity but minimisesthe DSP load by not decoding unneeded values. It alsouses a step-wise change in the resampling factor, mak-ing it harder to converge towards a resampling ratiothat reflects the exact client/server clock drift unless amore complex system is used that compensates for thiseffect.

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 puton the speakers. The entire system was able to compen-sate for the drifting ADC/DAC clocks and after a couple ofseconds, the system self-stabilised. Adding an extra mod-ule just before the DAC to perform equalising was quicklydone.

4.1.2 Microcontroller

On theµc side, each group had access to two TI MSP430microcontrollers [5] with a clock frequency of 8 MHz.These microcontrollers have a 16-bit RISC architecture, 16integrated registers on the CPU, built-in hardware multipli-cation, and communication capability using asynchronous(UART) and synchronous protocols. A digital-controlledoscillator, together with the frequency lock loop, provides afast wake up from the low-power mode to the active modein less than 6µs, which makes this product a good candidate

7

Figure 5. Data stream discontinuity: DAC pulls data out the system

when fast real-time response and extended battery lifetimeare both important design requirements.

Unfortunately, the systems were configured with just 1KB of RAM, which makes it almost an impossibility towrite software via any high level language. Hence, an addi-tional requirement for the microcontroller groups was thatof using the MPS430 assembly to develop their software. Afront-end software by TI was available, which also allowedstudents to debug their code via step-by-step executions andbreakpoints.

After some familiarising with the system, the studentshad 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 sourceof a driver for printing strings on the LCD was given to thestudents.

After this, the students were asked to set up drivers forthe communication between the microcontrollers (via theUART) 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 protocolbetween DSP-µc including the following requests:

encryption keys : encryption needs two keys, the first oneis the encryption key that is used to encrypt and de-crypt the data. These keys are generated by theµc andpassed to the DSK boards. The keys are generated onthe server sideµc , sent to the clientµc and this onepasses the keys to client DSK.

integrity key : this is the second of the key-pair needed forencryption. This one is used to check if there was anytampering with the data block. It adds an extra level ofsecurity.

equaliser : the user enters or changes the values of theequaliser bands to adjust the music quality. This is aclient-onlytask.

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

pair. However, the keys are passed to the DSK byteby byte. If the DSK used these new bytes immedi-ately in its 16 byte (128 bit) key, the data would getcorrupted. To avoid this, theµc passed the new key,and only when it got confirmation that all keys arrivedand were processed, it generates a signal to the DSK tostart 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. Tothis purpose, it keeps a counter for each command it sentand then waits. The DSK in turn, returns the command itreceivedcombinedwith its own counter of the number ofcommands it had received. After successful comparison bytheµc , theµc can send a new command, else, it resends thelast command.

4.1.3 Integration: DSP andµc

The last step of this design process is on the integrationsessions, in which the microcontroller groups and the DSPgroups 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 bywriting into a 16-bit register on the daughterboard. This reg-ister was mapped in the DSP memory hierarchy and raised ahardware 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 registerto see if the contents had changed,

Once the basic system as described worked, a couplegroups invested their remaining time in adding functional-ity to the system. This was not longer separated, but tightlycoupled 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 thatthey started moving functionality off theµc on the DSKboards. Space was then freed for (additional) control tasks.Two of the important added features are the inclusion of astart/stop button on the client side and the server warning

8

the client when the time was about to expire. They couldthen start negotiating on a next time frame,beforethe cur-rent audio stream was encoded with a new key the client didnot have.

Because of the clear system description, this integrationwas done seaminglessly and well within the budgeted timeof two sessions.

4.2 2002: secure speech transmission system

In the second edition of the design seminar, the teamswere divided into functional groups: 1 group working on thedevelopment of subband encoding and decoding, anothergroup working on encryption and decryption, one group onthe µc , one group on the serial communication betweenboth DSK boards and one group on the framework that tiedthe system together. Every group consisted out of 2 to 3persons.

4.2.1 DSP work

One of the remarks the students had on thesecure audio dis-tribution system was that they did not have enough freedomto develop a solution. Therefore, the amount of materialgiven at the start was reduced, which included a morehit-ting the metalapproach for getting the e.g. serial communi-cation to work accompanied with browsing through techni-cal manuals. Unfortunately, this work was hindered by twomain problems that we did not encounter during the previ-ous sessions:

ADC/DAC code : one of the first examples a student isconfronted with when starting to work with CCS, istheaudioexample. The code that was used in the firstedition was based on the 1.2 version of CCS. The mainadvantages were that it was clear and clean code forpeople to start with. This year, the CCS was upgradedto the 2.0 version. The modifiedaudioexample codewas more complex and included some features to showpossible problems at an advanced level. As a result,much more time was spent on the familiarising withthe tools and the example code and even rendering theexample useless for students to start with.

CCS bug : a DSP/BIOS configuration tool (cdb ) relatedbug generated erroneousCcode from the graphical in-terface to the DSP/BIOS functionality. Identifying theproblem took some time.

On the other hand, the group working on theframe-workcode had little problems other than managing the largecomplexity of their project. The introduction of the bi-directional communication required much more interactionwith the RTOS by defining the correct software interruptsand buffers. The framing code developed was more or less

similar to the code developed by the teams in the previousyear, with one important difference: they had to compensatebetween different types of data being sent over the serialline. Instead of pure data, the following types could now besent:

encryption negotiation : In the previous edition, theserverµc generated a key-pair and passed it along tothe clientµc via theµc -µc serial link. In the speechsystem, the functionality was extended with Diffie-Hellman key initialisation [13]. Since there is no en-cryption key, this data is not encrypted and should bedirected 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 directedto the microcontrollers.

data : The bulk of the traffic over the serial line consists ofdata, subband encoded and encrypted audio.

The routing information is added to the framing header andthe packet length. This way, when a header is identified, thedestination (packet type) is extracted and the content is sentto the correct module by putting it in a different buffer.

4.2.2 Microcontroller

One of the problems of theµc -DSP communication schemeof 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 removedby using a simple protocol that allowed the transmission ofmessages of arbitrary length between both processors. Thisallowed the transmission of complete keys in just one mes-sage. Messages are divided in blocks and then reassembledon 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 pendingmessages. If there are any messages, theµc requests themessage byte by byte to the DSP and then reassembles it.In order to transmit a message, theµc sends the messagebyte by byte to the DSP. When the message is received, it isthen 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

9

people with the framework team and theµc team with theframework team) and agreements had to be reached. One ofthe most prominent things to notice was how the differentteams developed their own emphasis and view of the func-tionality of the global system.

The code of the serial communication was integratedwith the framework. The framework code processed com-mands from theµc and passed it along the serial line.Unfortunately, a fundamental problem prevented the finalintegration of the software modules into this hardware-dependent code. The decision to let some people work onthe development of algorithms inCwas inspired by the im-portance ofC in commercial code and implementations andthe fact that this seminar was the first real hands-on expe-rience most students had with this language. However, aworking C program is not identical to goodC code, andespecially 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 handlethese 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. Asfor the goals that were set out at the start of the project, thefollowing were reached:

• A thorough introduction into embedded systems wasoffered to the students and the different areas involvedin embedding software: the technical hardware andsoftware side and the more interactive integration. Thepeople on the DSP side had a clear idea of the inter-nals of such a development system, and had masteredthe basics of an operating system and put it to use. Thesame goes for theµc side. Since they were workingon a lower level (assembly) and on a simpler system,they knew theµc inside out. They got to know how tosqueeze out the last bit of functionality on a very con-strained (memory wise) hardware platform. Especiallyin the implementation of the secure speech transmis-sion system, the framework and the required logic totie it together was complex and posed a challenge tothe 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 notobvious and implementation issues were built into theseminar sessions; issues that had to be solved by thestudents themselves.

• 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 oftime, rescheduling of the groups was done in order toget the system working. The time needed for the im-plementation (and familiarisation) on the systems wasunderestimated. It took the students more time thanexpected to understand the logic of the DSK and thedevelopment tools (DSP/BIOS). Due to delays with re-spect to the initial planning, the prototype would neverbe completed within the time of the seminar. In thefirst edition, this was done by splitting up the work thatneeded to be done in subproblems and assigning theseto different groups. In the second edition, such a divi-sion was already done from the start, but when a groupencountered unexpected problems, another group tookover 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 thecoordination of the integration parts (DSK–DSK andDSK–µc ).

• Some obvious oversights in the curriculum were fixed:the students had to attain a profound knowledge ofC(and assembly programming).

• The hardware platform and the provided tools aregood teaching tools and overall, the students found thecourse motivating.

A number of things that still need to be improved are:

• One of the remarks last year, was the lack ofCknowl-edge. This year, the seminar started with a crash-course (6 hours) into the basics ofC 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 somedegree 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 combinedwith a steep learning curve when working with DSPsposed additional problems. In following editions, amiddle ground must be found between these two.

• More attention has to be put on the quality of the pro-ducedC code by the people guiding the algorithmicdesign groups.

• The tutorials need to be checked after an upgrade ofthe development tools. The audio example was tooconfusing to be in a tutorial session.

10

This seminar, with other initiatives to give engineering amuch needed new appeal, gives the students an opportunityto apply the theoretical competence in a real-life applica-tion. Instead of giving additional courses for gaps in thecurriculum, this knowledge is now offered in a hands-onmanner. It offers also experience that cannot be learned inclassical sessions: social interaction, cooperation to obtainresults and a taste of the future.

This seminar is the first step in bridging the gap betweenindustry and our university. With the experience of the pastsessions and ideas from industry, these design sessions aremodified and extended to fit new requirements and evolu-tions.

6 Acknowledgements

From the very outset of the project, the department gotlarge support fromTI. They sponsored the hardware and thebest project team was given aTI award, including a set ofDSK boards. The students that followed this design semi-nar have to be acknowledged for their positive feedback andsuggestions which gave a definite added value to the entireproject.Geert Deconinck is a postdoctoral fellow of the Fund forScientific 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. TI website, 2001.http://focus.ti.com/docs/tool/toolfolder.jhtml?PartNumber=TMDS320006711% .

[4] Anonymous. TI 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. InDr. Dobb’s Journal, volume 26,No. 3, pages 137 – 139, March 2001.

[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, 2000Corporate Blvd., Boca Raton, FL 33431, USA, 5thedition, 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/6701Evaluation Module Technical Referencei (spru305),December, 1998.

[20] L. Van Eycken. Seminaries ontwerpen ict: M&s:HJ82, 2001. http://www.esat.kuleuven.ac.be/˜hj82/2000-2001/ .

[21] A. Young, M. Young, and S. Bon. Highway to hell,1979.

11