Bridging the educational gap in embedded systems curricula: Developing an e-commerce audio streaming system Marc Leeman, Francisco Barat, Vincenzo De Florio, Geert Deconinck ACCA/ESAT KULeuven Kasteelpark Arenberg 10 3001, Heverlee, Belgium
[email protected]
Abstract
and non technical reasons account for this. First of all, embedded systems have always been quite cost sensitive (the maximal functionality has to be mapped on the cheapest devices). Where the main focus had been to get sufficient functionality on the system, it has been now complicated 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 has a definite advantage in a very competitive market often characterised by technically proficient customers. Secondly, with the progress of chip design, the functionality of the embedded processor increases up to a point that a lot of these can almost compete with general purpose processors. These technical advances enable the embedding of complex systems. Where design used to be done in one division of a company, almost all CBS are now the result of a cooperation between different divisions and sometimes even between different companies. All of this, of course, must be done in the smallest possible time frame. In order to cope with this kind of changing environment, the systems developed must be modular and attention must be focused on a correct integration. A modular system makes sure that last minute implementation or functional changes can be localised and do not affect the entire embedded software system. It also enables the reuse of previous software modules and third party software, as well as easy integration, essential for students in CBS [14]. Clearly, effective teaching of a challenging endeavour is a challenging endeavour in itself. Because of this and of the quickly changing technological scenario, there was somewhat of a gap between what was taught and what skills were expected after graduation of CBS engineers. With these expectations of industry in mind, the need for well qualified engineers and in an effort to revitalise engineering [11] the electrical engineering programme of the University of Leuven was reformed a couple of years ago so as to bridge this educational gap. More stress is put on implementation of
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 department. The aim of the seminar is to ease up the adaptation of the universitary curriculum to what is expected by industry of a high level engineer. The main purpose of the seminar is to provide the students with a real life problem, covering different expertise areas and multiple hardware platforms, programming techniques and development tools in order to develop a commercially viable application with off-the-shelf tools, hardware and software. The interdisciplinary character of this seminar is an excellent opportunity to see how the different topics taught in different courses interact in a real life system.
1
Introduction
The need for Engineering of Computer Based Systems (ECBS) is certainly not a recent discovery—its relevance has been strongly felt since the early days of computers’ industrial usage. It is only recently, though, that the need for a more formalised education in ECBS has been recognised [14], [13], [12] and curricula are being implemented to match with industrial requirements. As the definition of Computer Based Systems1 (CBS) indicates, CBS have a wide span of applications. As such, every field of expertise faces this need and is asked to provide answers to it from its own background and know-how. In our case (Electrical Engineering department of the University of Leuven), this is the CBS field of embedded systems. Efficiently mapping an algorithm to an embedded system has always been a challenging task. A number of technical 1 Computer-Based Systems are systems whose behaviour is, to a substantial degree, determined or controlled by computers [14].
1
a system and not just on its design. Next to a series of renewed courses, a design seminar was scheduled to implement a multimedia application, with signal-processing specific hardware in the Multimedia and signal processing option [22], [15]. This paper describes this case study in engineering education. It is structured as follows: First, a detailed overview of the problem that was put to the students is described. Secondly, the system itself is explained: the hardware, its connections, . . . The third Section focuses on the actual seminar: what the students did, how the seminar was organised and some key design decisions the students developed autonomously. Finally, conclusions are drawn about this first seminar session and on the feedbacks and relapses that it is providing to our engineering programme.
2
the only usable data that is offered to the customer, is the material that was paid for. This introduces a pay-per-view perspective: the customer requests are in terms of timeslots of music. After appropriate authentication (availability check and credit validity), the system sends the requested time-slots to the customer. The task in the sessions would be to build a prototype for this e-commerce system in which a server distributes audio time-slots to a number of clients in a secure way. A couple of restrictions are put up front: Off-the-shelf hardware: Time-to-market is an important issue in industry. For this reason standard components are to be used as much as possible. Only when strict requirements have to be met (power consumption, I/O, ...), a custom design is considered. The cost of these devices is an important factor in the design. However, in the design seminar, the requirements are defined such that no custom hardware needs to be developed.
Project Contents and Problem Description
Our seminar was designed with the goal of providing the students with an in-depth, real life experience with embedded systems. To accomplish this, a problem was selected among a set of industry relevant scenarios. As a result of this, the students were asked to develop a secure e-commerce embedded system allowing a user to securely access a remote repository of audio files, initiate commercial transactions, and play the requested pieces of music. This Section describes the seminar assignment for our students. It also presents the hardware and software components the students were asked to develop as well as the problems they had to solve while managing their tasks. Over the last few years, a lot of controversy about the distribution of copyrighted material over the Internet has arisen. The Internet enables easy exchange of digital media at very low cost. This fact, together with the world-wide interconnectivity of the Internet and its enormous user basin, results nowadays in huge loss for audiovisual industry. More importantly, due to judicial actions, service enterprises found themselves 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 greatest and ubiquitous mall ever, urges those enterprises for the development and the spreading of secure, Internet-aware embedded systems integrated, e.g., within a mobile, hand-held device. Our students’ assignment fits in this process: the resulting system has to allow a party offering copyrighted material to transmit data securely over an insecure medium. Two key factors here are authentication and encryption— authentication to make sure that the recipient of the audio stream is the one he is claiming to be and encryption to make sure that if a third party gets access to the data stream, it cannot decipher the data. Furthermore, any e-commerce system must ensure [23] that
Off-the-shelf software: Again, for limiting development costs, no software is to be developed in house, or in this case in the course, for which there are off-the-shelf solutions available. These restrictions are meant to force the students to use available components. The goal is not to reinvent every subpart and come up with a new revolutionary design, but to build a working prototype of the full target complex system within a short time frame.
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 components is also described.
3.1
Software
The most important functional blocks in the system to be implemented is shown in Fig. 1. In the chain, different stages are distinguished: Capture: Audio is offered to the streaming audio distribution system. During the design of the prototype, it was not yet clear what the source would be, so the decision was taken to include the audio capturing. A product built upon this prototype could then remove this step and add its own data source. An Analog to Digital Converter (ADC) converts the audio to PCM samples. Compression: the data should be delivered to a range of customers over the Internet. Since not all of the possible customers enjoy a large bandwidth, and since the 2
Figure 1. System description: software chain. Coder Blade Lame Gogo
company that delivers the service also has a non negligible cost for (upstream) bandwidth, the data must be compressed in order to use the available connection optimally (we chose the MPEG1 layer III audio compression (MP3) [17]).
Elapsed Time 1’02” 0’40” 0’24”
Portability problematic high low
Table 1. Evaluation of different MP3 encoders (elapsed time and portability), Highway to Hell, 3’28”.
Encryption: encryption of the audio stream covers two different problems. First of all, the data stream must be encrypted in such a way that only the designated recipient 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].
The seminar is split up into a system engineering phase (SE) and a CBS phase, that the students have to do. The SE work is done in preparation of the seminar and mainly included selection and design of the hardware and selection of the software. The conclusions of this system engineering phase are the design specifications the integration has to fulfil. In order to decide upon which implementation of the MP3 encoder and decoder is going to be used, different public domain solutions were tested. The results of this are summarised in table 1 for the encoders.
Serial connection: in order to transmit the data to the embedded 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 connection, when it drops or corrupts data for some reason and restart normal operation as soon as the communication is restored. It does not have to correct the faults.
The encoding2 was done on an AMD 750 PC3 , 512 MB SDRAM on a single song [24]. The gogo [16] encoder is a hack of the lame [18] encoder which is partly written in assembler. For this reason, it is not usable in our system. 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. The choice for the MP3 decoder was easier since
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.
1. Decoding consumes only a fraction of the processing power needed for encoding.
At the decoding side, the complementary tasks are done, i.e. decrypting, decoding the MP3 stream and putting it on the speakers. As can be seen on Fig. 1, a couple of steps are not addressed here. These ((de)framing, resampling and equalising) are practical problems the students had to solve. This is discussed in Section 4.
2 Conversion from WAV format, RIFF (little-endian) data, WAVE audio, 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.
3
2. Most public domain MP3 decoding use some form of the mpg123 decoder [9].
tem (on the decoder as well as on the encoder side) has the following components:
3. There is a trimmed down version available in the source tree of mpg123.
• 1 TMS320C6711 DSK board • 1 MSP430 microcontroller with a keypad and an screen
4. Searching on the Internet showed that this decoder could even be used on older systems as an 80486DX2 [1], which makes it fast.
• 1 communication DSK daughter board
The encryption and decryption code was obtained from the K.U.Leuven, where the Rijndael algorithm was developed [6], [7].
3.2
LCD
There was no readily available solution for interfacing the µc and the DSKs. After some study of the hardware, a custom daughterboard was developed to fit on the extension slots of the DSKs. This daughterboard centralises all interfacing between all the devices in one system: DSK, microcontroller and keypad. The advantage of this board is that it is robust and flexible, since the hardware has to be set up and disassembled every session. The system is connected with a cable with two SUB D9 connectors. In conclusion of this section, the global structure as shown in Fig. 3 is as follows:
Hardware
The choice of the hardware that was used, was also done during the system engineering phase. Each system (on the client and server side) consists of a Digital Signal Processor (DSP) to do the computational tasks (number crunching) and a microcontroller to control the operations of the system. Again, this is a constraint the student CBS designers have to work with. The trade-off was made between cutting edge technology and functionality. The bulk of the processing (encoding/decoding and encryption/decryption) is done on DSP. Due to our experience with the Texas Instruments (TI) hardware, combined with the fact that TI occupies the largest market share (and as such, a high probability that graduated students will encounter them when working on embedded systems), the choice was made for the T MS 320 C 6711 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 [20]. The performance of the DSP also makes certain that there is additional room for functional upgrades by the students. On each side (the encoder or server side and the decoder or client side), a microcontroller (µc ) controls the DSPs. Its task is restricted to peer-to-peer communication, some user I/O, and control of the DSK-boards. Considering the computational power of the DSPs, the bulk of the number crunching could be migrated to the DSK boards. The logic of these control tasks is simple and could as such be done in assembly. Again, the use of assembly gives the students an additional important experience in embedded systems. For these reasons, the MSP430 was selected for the seminars, also from TI. Considering the specifications (discussed more in Section 4.4.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. The final master-slave system is seen in Fig. 2. Every sys-
• The bulk of the number crunching tasks is assigned to the DSK boards. • The encrypted MP3 data stream is sent via the DSKto-DSK serial link. • Control of the operations and user interaction is done by the microcontrollers. A simple 4 × 4 keypad and 7 character LCD screen are connected to these microcontrollers. • Key transmission is handled by the microcontroller-tomicrocontroller link, to split it off the insecure MP3 data link. This could be implemented over the insecure link, but we decided not to for security reasons. The keys are now handled via µc - µc communication and gave them an extra communication protocol to handle. Any system built upon the prototype would most likely not use a physical communication link between the two masters (µc ), but considering the sensitivity of the keys, this will most likely be logically completely separated from the audio data stream. The challenge of the seminar is on three subfields: 1. The existing software has to be mapped on the embedded system. 2. The different hardware components have to communicate. 3. Functionality must be added to get the system working. 4
Figure 2. The secure MP3 transmission 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
4
Design Seminar: Building a Prototype
the internals of e.g. the MP3 decoder was not an option due to the time constraint. The software modules with a black top in Fig. 1 were given in the seminar. The decision to do this was mainly motivated by the fact that code is available for download from the Internet, and not giving it would just introduce delay for searching the software. But even then, there were a couple of problems to be tackled while integrating these software modules, related to the hardware platform and the system built. These are depicted by the modules with the gray band in Fig. 1. It was up to the students to conceive and develop solutions for the following problems:
This section reports about the first run of our design seminar, which took place last academic year at our home University. The actual work done by the students in the design seminar is described. Because of the complexity and special fields of the two hardware platforms (DSK and µc ), the students were divided in two categories that would work on a different platform. 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
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.
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 indicated with a black top in Fig. 1 had to be integrated. To this end, a pipe structure was used [19], readily available in the DSP/B IOS environment. These pipes isolate the modules, making their operations independent from each other. In order to write this code, a rudimentary knowledge of how the code uses its buffers is needed and the wrapper code must adapt to this. Changing
resampling: There is a particular problem with the Analog to Digital/Digital to Analog Converter devices. There is a slight drift between the clocks of any two boards. The students had to write code to compensate for this. equaliser: On the client side, the equaliser code has to be plugged in. 4.1.1
Framing of the Data
In order to write the wrapper code for each subsystem (client or server) to integrate the functional modules, detailed knowledge of the interfaces of software modules is 5
Figure 3. System description: hardware. needed. This is then used for correctly processing the data. After some initial C tackling and familiarising 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 nothing but a continuous stream of bits. Obviously a trial and error approach of trying to decrypt the n×128 byte blocks4 (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 preceded by a header the client and server developers agreed upon. The client software then scans through the received data bitwise until it identifies 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 datablock in the frame header. When using this option, 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.
4.1.2
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 low5 [21]. Some groups experienced very slow playback with discontinuities, while others had the problem that the sound was too high pitched, intermitted with short bursts of random noise6 . The first possible problem to eliminate was to check if the data does not get corrupted along the way. After removing this possibility, the groups started testing the hardware and came to the conclusion that the behaviour of their programs 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 MP3 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 processing module in the pipe. In turn, this module produces a new batch of data, releases it, which fires a new software trigger. In the case of the MP3 system, the data entering the system is the sampled audio. At the end of the chain (on the client side) there is a discontinuity: after the decoding, data is consumed by the Digital to Analog Converter (DAC) at a fixed rate (its clock speed), instead of being triggered. At this point, one of the following problems is most likely to 5 The DSK boards have a sampling limit of 8 kHz mono sampling frequency. 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. 6 The random noise was built in the serial communication code to indicate 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
4 128 is the element size of the encryption algorithm. The encrypted data blocks should be a multiple of 128 bits.
6
occur:
frame the audio data; to send it over the serial line where the client DSK received the data stream. It then deframed, decrypted and decoded the audio. Because of the drifting ADC/DAC clocks, it resampled the audio and put it on the speakers. After a couple of seconds, the system selfstabilised its own resampling factor (taking advantage of the known value of the ideally perfect drift of the ADC/DAC clocks). Adding an extra module just before the DAC to perform equalising was quickly done.
• 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.
4.2
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. Two solutions appeared:
Microcontroller
This section describes in more detail the tasks that were done by the so-called microcontroller groups, i.e., the students that had to develop the interface with which the users get access to the overall system, as well as the microcontroller-to-microcontroller and microcontroller-todsp communication tasks. 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 multiplication, 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 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 additional requirement for the microcontroller groups was that of using the MPS430 assembly to develop their software. On the development platform, Windows NT, students had to edit, assembly, load and execute their assembly programs. A frontend 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. Immediately after this preliminary step, they were asked to develop 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 server 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:
• Decoding all the MP3 data. If there is no buffer available to write the data in, it is dropped. The advantage from this approach is, that the code exactly knows how many samples are dropped. This is then used to downsample the PCM data (using simple linear resampling). This adaptation continues until it overshoots: instead of dropping data, samples have to be padded. Again, the exact number of samples added is known, and this data is used to adjust the resampling factor. • Before the MP3 frames are decoded, the code checks if the decoded P CM data will actually be played. If this is not the case, the frame is dropped before decoding. This approach has a larger granularity. The advantage is that this algorithm is “smarter,” in that it only decodes what it knows will be played: there is no use in spending effort for decoding, when decoded data are not going to be used anyway. The drawback is that the computation of the resampling factor is not that easy anymore since the number of dropped samples is no longer known. The group that implemented this algorithm did this by keeping statistics of the average MP3 to P CM ratio. When an MP3 block was then dropped, the code predicted the number of dropped samples. Then they could use the number of samples padded with this figure in order to adjust the resampling factor. Clearly, both approaches have their own merits. While the first approach is more fine-grained (sample level), it wastes cycles on decoding data when it is not used. The other solution performs better in an environment where the available cycle budget or power consumption is a restraining factor. At this point, the groups had an audio streaming system: their server DSK was able to capture, encode, encrypt and 7
6 µc A to µc B: Send key
0. encryption keys: encryption needs two keys, the first one is the encryption key that is used to encrypt and decrypt 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.
7 µc B to DSK B: Send key Parallel processing: 8 µc B to DSK B: Increase/decrease equaliser band no. 0–4 or global gain.
1. 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.
9 µc A to µc B: reminder: still t0 seconds of music are available.
2. equaliser: the user enters or changes the values of the equaliser bands to adjust the music quality. This is a client-only task.
4.3
Integration: DSP and µc meet
The last step of this design process is on the so-called integration sessions, in which the microcontroller groups and the DSP groups had to work together to set up the whole application. Up until this point, the both teams had only used specifications and agreements they made. The students also only used their own hardware and development platform. The systems were connected as in Fig. 2. Initially, a hardware bug in the daughterboards that centralised all the communication caused some problems, but once this was solved the teams saw that the system worked. The microcontroller wrote a command into a register on the daughterboard and enabled an interrupt on the DSK. The DSK then responded by returning the command on to one of the parallel ports of the µc . On the DSK side, the students had to write the interrupt service routine. To obtain the result, the µc polled the parallel port. Once the basic system as described worked, a couple groups invested their remaining time in adding functionality 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 order 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 current 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.
3. change keys: a generated key-pair has a limited lifetime. The servers side µc keeps a counter to see if the keypair is still valid. If it is not valid, it generates a new pair. However, the keys are passed to the DSK byte by byte. If the DSK used these new bytes immediately 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. In order to understand the structure of such application, Fig. 4 was used as a reference. As already described, DSK A is responsible for dealing with some audio streams stored in files or actual CDs. In particular, it has to MP3-encode a given audio stream and send it, encrypted with some key, to DSP B. The latter does the dual job: it decrypts via some key and decode an MP3 stream which is ultimately sent to the loudspeakers. The process of paying a song is described by the following steps: 1 µc B to µc A: Request for music (for t seconds of music) 2 µc A to µc B: Reply (cost is c Euro). c = Df (t)
5
3 µc B to µc A: Accept (with credit card data) / Not accept if Accept:
Conclusions
A number of conclusions can be drawn from this first edition of our design seminar, on a content level as well as on the goals of the project. As for the goals that were set out at the start of the project, the following were reached:
4 µc A : Generate encryption (and decryption) key 5 µc A to DSK A: Send key 8
Figure 4. The microcontroller control communication • 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 internals 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 constrained (memory wise) hardware platform.
(and assembly programming). Even though all of the goals were met in last year’s edition, the feedback given by the students lead to some changes in this year’s edition. • The sessions will start with a more elaborate introduction in C, especially aimed at embedded systems. During the presentations at the end of the seminar, the lack of C knowledge was one of the most prominent remarks. In the long term, it will have to be considered to introduce C in the curriculum as a full fledged course.
• 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.
• Some of the tasks that were considered more as system engineering tasks are going to be given to the students. There will be more groups, doing different things. Amongst the tasks that will be done in the exercise sessions are the serial communication between the two DSK boards and writing/preparing software modules themselves.
• A working prototype was set up within the budgeted time.
Since the students will be working on smaller sub problems of the design, the integration sessions shall start in an earlier stage and will be on two stages: a local integration by the DSK groups in coupling their modules and functionality together followed with a global integration between the µc groups and the DSK groups. When fitting this project in the formal ECBS curriculum proposed in [14], the students have most experience in hardware related topics (architectures, components, communications, . . . ), while there is only basic knowledge on more software and software design topics. When the current curriculum [8] is compared with the elective courses, it has a lot of correspondences. 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 application. 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
• 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 implementation (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 respect to the initial planning, the prototype would never be completed within the time of the seminar. On the DSK side, teams specialised on different subproblems instead of solving them sequentially. This gave the participants experience in project management and inter-group coordination. 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 9
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 session and ideas from industry, these design sessions are modified and extended to fit new requirements and evolutions.
6
[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.
Acknowledgements
[12] J. Lavi, R. Gonzales, M. Mannion, and S. Miroslav. Engineering of computer based systems, enhancement courses - proposed course outlines. In Proceedings of the 1999 IEEE ECBS TC Conference and Workshop. IEEE Computer Society, IEEE Computer Society Press, 1999.
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 seminar 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.
[13] J. Lavi, M. Mannion, B. Melhart, I. Pyle, and S. Miroslav. Engineering of computer based systems, a proposed curriculum fo a degree program at bachalor level. In Proceedings of the ECBS98 Conference and Workshop. IEEE Computer Society, IEEE Computer Society Press, 1998.
References
[14] J. Lavi, B. Melhart, I. Pyle, and S. Miroslav. Engineering of computer based systems, a proposed curriculum at master level. In Proceedings of the ECBS98 Conference and Workshop, volume 1. IEEE Computer Society, IEEE Computer Society Press, 1997.
[1] Anonymous. Freshmeat, mpg123 description, 2001. http://freshmeat.net/projects/ mpg123/. [2] Anonymous. Nist website, 2001. http://csrc. nist.gov/encryption/aes/rijndael/.
[15] M. Leeman and F. Barat. Hj82 dsp seminar sessions, 2001. http://www.esat.kuleuven.ac.be/ ˜mleeman/hj82/.
[3] Anonymous. T I website, 2001. http://focus. ti.com/docs/tool/toolfolder.jhtml? PartNumber=TMDS320006711%.
[16] Shigeo. The gogo encoder, 2001. http: //homepage1.nifty.com/herumi/soft. html/.
[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.
[17] M. Slager. Mpeg/audio, 1997. http://www. csclub.uwaterloo.ca/˜mpslager/ articles/mpeg/mpeg.html.
[5] L. Bierl. MSP430 Family Mixed-Signal Microcontroller Application Reports. Texas Instruments, 2000.
[18] M. Taylor. Lame ain’t an mp3 encoder, 2001. http: //www.sulaco.org/mp3/.
[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.
[19] Texas Instruments, Canada. User’s Guide Code Composer v3.0, Code Composer Simulator v 3.0, 1998. [20] Texas Instruments, Nice,France. Code Composer Studio, Getting Started, 2001.
[7] J. Daemen and V. Rijmen. Rijndael, the advanced encryption standard. In Dr. Dobb’s Journal, volume 26, No. 3, pages 137 – 139, March 2001.
[21] Texas Instruments, Nice, France. TMS320C6201/6701 Evaluation Module Technical Referencei (spru305), December, 1998.
[8] ESAT/KULeuven. Burgerlijk elektrotechnisch ingenieur en burgerlijk werktuigkundigelektrotechnisch ingenieur richting elektrotechniek, 2001. http://cwisdb.cc.kuleuven.ac. be/programmaboek/h/h15.htm.
[22] L. Van Eycken. Seminaries ontwerpen ict: M&s: HJ 82, 2001. http://www.esat.kuleuven. ac.be/˜hj82/2000-2001/. 10
[23] J. Vijalainen and A. Tsalgatidou. Electronic commerce transactions in a mobile computing environment. In Proceedings of the 2000 International Conference on information Society in the 21st Century (IS2000). IEEE Computer Society, IEEE Computer Society Press, 2000. [24] A. Young, M. Young, and S. Bon. Highway to hell, 1979.
11
