Handling complexity in embedded application development: an example of real time MP3 streaming over Bluetooth

Transcription

1 Handling cmplexity in embedded applicatin develpment: an example f real time MP3 streaming ver Bluetth Authr: Trish Messiter, Clarinx Technlgies Pty Ltd, 8 Bayside Cres, Hamptn VIC, AUSTRALIA, Ph: , Fx: , trish@clarinx.cm Abstract Cntinuing t use the traditinal apprach applied t embedded design int the mdern cmplex designs can becme chatic and ad hc. This paper lks at the issues cnfrnting mdern embedded applicatin design and the embedded ec system that exists t enable the cmbinatin f standard hardware, prven RTOS, middleware and applicatins t present a slutin fr these issues. Intrductin Tday mre micrprcessrs arund the glbe are used in embedded systems than in PCs and thse already large numbers are increasing at a phenmenal rate. Traditinally the requirements placed upn embedded systems are quite different t thse applied fr desktp cmputing. This is because embedded systems are, in general, designed t accmplish a very specific task r grup f tasks there is n single characterizatin that applies t the whle gamut f embedded systems. Hwever sme cmbinatin f the variables f rbustness, small size and weight, real-time requirements, lng life cycle and lw price culd be expected t figure in the design criteria fr mst embedded systems. Less tlerance fr malfunctins in sme cases may be simply a cnvenience and cst issue, such as the lack f permanent I/O cnnectins which makes debugging mre difficult, r it can far mre serius such as the failure a missin critical cmpnent which culd have extreme cnsequences. Real time requirements cmbine the cnstraint f time and crrectness - nt nly des the cmputatin need t be crrect but it als needs t be at the crrect time. This requires an estimate f the wrst case perfrmance, which n cmplicated architectures can be difficult, and leads t verly cnservative estimates. Missin Critical systems as a class have a significant requirement fr real time peratin in rder t meet external I/O and cntrl stability requirements. Lw price translates t reduced resurces such as prcessr speed and memry size which in turn cnstrains sftware develpment and executin. Often embedded devices are very sensitive t cst. A variatin f even a few cents per device can be significant due t the huge multiplier f prductin quantity cmbined with the higher percentage f ttal system cst it represents. These cnstraints, thugh difficult, were manageable, if the applicatin is simple and small enugh t and run withut the need f an underlying perating system. This changes nce there is a need t manage many variables such as serial, USB, TCP/IP, Bluetth, Wireless

2 LAN, trunk radi, multiple channels, data and vice, enhanced graphics, multiple states, multiple threads, numerus wait states and s n. This increase in cmplexity has made the use f a prven rbust and netwrked RTOS cmplete with file system the mst efficient curse in mst cases. Fr many designs hwever this is nt sufficient and further middleware, prtcls and drivers are required t achieve the desired aims. Applicatin and Supprting Infrastructure This paper discusses the implementatin f streaming f MP3 Audi data via Bluetth, and hw the varius challenges were addressed by the use f apprpriate infrastructure: an x86 prcessr with QNX Neutrin RTOS and Clarinx Technlgies embedded framewrk with incrprated Bluetth prtcl. A distinguishing feature f Bluetth is the sphisticated service discvery mechanism that allws fr devices t establish cnnectin, transfer data and discnnect withut requiring user interventin. User apprval may hwever be required fr authenticatin and security purpses. Bluetth als caters fr many devices t c-exist in the same space. These devices may be part f the same picnet, they may be cnnected in scatternet tplgy, r may have n cnnectin t each ther at all. The standard defines all layers f the OSI prtcl stack layer, which translates t a fcus n applicatin develpment inherent in the specificatin design. The Bluetth reasnably lw pwer rates f arund 1mW Class 3 (100mW Class 1) during transmissin make it suitable fr use fr handheld devices. Added t this is varius lw pwer mdes utilized during idle perids which can be under the cntrl f the applicatin. All these attributes suggest Bluetth is ideal fr netwrking f all srts f electrnic devices within 100m f each ther hwever; the use f Bluetth is nt withut challenges such as limited bandwidth, high degree f errr rates, and the time-varying nature f the radi link. The Bluetth prtcl stack cnsists f several layers, starting frm the physical layer, cmprising the Radi, BaseBand, Link Manager, Lgical Link Cntrl and Adaptatin Prtcl, and Hst Cntrller Interface as shwn belw, in Figure1. SDP RFCOM L2CAP LMP Baseband Bluetth Radi Figure 1: Prtcl stack f Bluetth The functins f the varius layers mentined are: Baseband is the physical layer where Bluetth perfrms all lw-level data prcessing including basic Frward Errr Crrectin (FEC) and Autmatic Request fr Transmissin (ARQ), packets handing, data whitening, hp selectin and security.

3 Link Manager Prtcl (LMP) [9] handles link cntrl, pwer-sensitive states changing, and data encryptin. Lgical Link Cntrl and Adaptatin Prtcl (L2CAP) [9] prvides bth cnnectinriented and cnnectinless data services t upper layer prtcls with segmentatin and reassembly peratin. L2CAP nly supprts ACL links with packet size up t 64Kbytes. L2CAP and LMP serve as a Media Access Cntrl (MAC) layer. Hst Cntrller Interface (HCI) [9] prvides a unifrm interface methd t access hardware capabilities. It is respnsible fr transmitting data between L2CAP and baseband thrugh a physical bus (e.g., USB, RS232 and PCI), using LMP. Hardware and sftware infrastructure that was capable f supprting the relatively large cde base f the Bluetth stack, required prfiles and applicatin were required. The Eden x86 prcessr, frm VIA technlgies was selected due t the reasnably high perfrmance, lw pwer and passive cling attributes. The Eden is based n the C5P Nehemiah cre and delivers enhanced digital media perfrmance and is designed t perate with passive cling due t its ultra lw pwer cnsumptin. Mre infrmatin can be btained frm VIA technlgies web site listed in the references. The QNX Neutrin RTOS prvides rbust micrkernel architecture cmplete with POSIX Supprt, IP Netwrking Technlgies and file systems which were the main criteria fr this applicatin. An verview is prvided in Figure 2, adapted frm QNX web site. Memry Prtected Flash File System CDROM File System TCP/IP UART Applicatin Micrkernel Message Passing Bus Self healing attributes HTTP Server Quick restart USB Applicatin Memry Prtected Prvides fr Multi-target, x86 prcessr fr this applicatin Figure 2: QNX Neutrin Micrkernel verview The Clarinx Technlgies embedded framewrk with incrprated Bluetth prtcl prvides the necessary infrastructure fr: Threading Timers Semaphres Mutexes Dynamic memry management withut fragmentatin Inter-prcess message passing

4 Event/Message handling Finite state machine Serial device driver encapsulatin USB device driver encapsulatin TCP/UDP Scket encapsulatin This functined as an extensin t the debugging tls and Bard Supprt Package r Hardware Adaptatin Layer prvided by the RTOS t enable the handling f cmplex multi threaded applicatins. Sme examples f the prvisins include: dynamic memry management. ClarinxSftFrame prvide a simple and effective memry management mdule t replace C style (mallc/free) r C++ style (new/delete) calls. Inside these calls are the smart, and adaptive memry and pl management that des nt result with memry fragmentatin, yet fast and efficient. standard libraries and stream libraries guarantee are prvided that the cde wrks the same way n each platfrm. Debug mde functin prfiling, functin entry/exit tracing and indented display f threads and functins with timestamp wuld prve the value f presenting infrmatin. Especially, while trying t find a prblem that happens in a system with a large number f threads and prtcls running cncurrently The infrastructure is depicted in Figure 3. Figure 3: ClarinxSftFrame structure

5 Tgether these elements enabled this develpment t prceed smthly with reduced errrs, reduced develpment time and reduced cmplexity. Results The real time streaming f MP3 ver Bluetth placed high demands n bth hardware and sftware. The successful slutin used an ec system where the use f standard hardware was cmbined with prven RTOS (rbust, with file system, netwrking etc) and embedded middleware attaching t RTOS and hardware t prvide the bject riented encapsulatin f service based bject riented applicatin develpment. References & Further Suggested Reading Ling-Jyh Chen, Rhit Kapr, Kevin Lee, M. Y. Sanadidi, Mari Gerla, Audi Streaming Over Bluetth, An Adaptive ARQ time ut apprach MPEG Layer3 Bit stream Syntax and decding, MPEG Layer 3 Frame Header Dcumentatin, MP3 Play Lib, mpg123 player RTP/RTCP RFC Staffan Gadd & Thmas Lenart, A Hardware Accelerated MP3 Decder with Bluetth Streaming Capabilities Specificatin f Bluetth System Cre ( in particular Advanced Audi Distributin Prfile / Audi Vide Distributin Transprt prtcl specificatin) Wang Xiahang, Vide Streaming ver Bluetth a survey VIA Technlgies: QNX: Singh, Mritunjay, Trish Messiter, Gkhan Tanyeri MP3 Audi streaming Over Bluetth, WiCn Aisa 2005 Messiter, Trish, The place f Wireless, Radi Cmmunicatins, 2004 Clarinx Technlgies: