Embedded system engineering magazine 2006.01,02

TODAY’S DEVICE marketplace has increasingly competitive as devices rapidly becoming more complex and in cases, provide unique combinations

of advanced, connected applications and services. For example, compare the functionality of a mobile phone five years ago to features even the least expensive mobile phones offer today such as digital cameras, internet access and video recorders. In this competitive environment, the ultimate goal for a device manufacturer is to deliver highly differentiated products faster and cheaper, yet the majority of these organisations are still developing device software with a traditional method that is both costly and inefficient.

Device manufacturers in this market place build many types of devices based on widely different form factors, vertical markets and functions. The development teams within these companies traditionally have created multiple one-off, in-house solutions that constantly have to be re-integrated and don’t scale across an entire product range. Because these companies are not capitalising on the fundamental sameness of development technologies and processes, their productivity and success rate is limited. With this traditional development approach, it has been shown through independent research that 66% of device projects are completed behind schedule, 33% are functionally unacceptable and 24% are cancelled before completion. While market requirements are advancing, the traditional development processes just aren’t effective and the business and competitive needs of today’s device manufacturers are not being supported.

New methodology

A new methodology that enables device manufacturers to develop and run device software faster, better, at lower cost and more reliably is emerging. This methodology is called Device Software Optimization (DSO). DSO is an open, standardised end-to-end approach to device software development and provides device manufacturers with a common platform and development suite that can be leveraged across a company’s entire product line. Standardising code, development tools and processes across projects and throughout the enterprise means that duplicated efforts are cut and time spent on resolving sudden incompatibilities and short-

comings is drastically reduced. Also, because DSO is based on the tenets of open standards and operating system agnosticism, this approach enables device companies to choose the best technologies available today and the infrastructure to make them function efficiently together, no matter what their source.

As a result, the move to open-source is a viable option for vendors interested in the DSO approach. The tremendous developer support for Linux in devices has created a real demand for commercially available Linux device software solutions. Previously, developers built their own home-grown Linux versions based on technology available from kernel.org. These home-grown solutions have proven costly and challenging for device companies because the software is often forked, becomes incompatible with other components over time and result in long-term management disasters. Trying to resolve these disasters without any vendor support continues to cost the device software world millions that will never be quantified.

Commercial grade

With a commercially available Linux device software solution, Device manufacturers have some relief from these challenges. For example DSO vendor Wind River offers a commercial-grade Linux solution. This solution ensures customers are successful with their Linux projects by combining a fully tested, validated Linux distribution, an Eclipse-based development suite and customer enablement functions such as professional services, global support and training.

DSO is allowing developers the freedom to focus on building product specific plug-ins and more functional applications onto a robust and proven architecture. This means that time and effort previously spent on building device software infrastructure is now directed toward adding value to the device with differentiating applications that are compelling in the marketplace. In the past, device differentiation was a priority that never made it to the top of the list when each device and feature had to be created from scratch.

Innovation and functionality are now flourishing in the US market, where DSO is already well on the way to revolutionising how OEMs and device manufacturers approach their development cycle. This innovation is also spurred on

by the incubation of ideas fostered with commercial backing from vendors such as Wind River and a multitude of not-for-profit, opensource groups like the Eclipse Foundation, the Open Source Development Lab (OSDL) and the uClinux community. "These three organizations support the things the DSO community needs to do to build their embedded devices effectively and efficiently," says Jeff Dionne, co-creator of uClinux, a pioneering embedded Linux tool community.

Functionality

Interoperability is also being pushed forward by the DSO approach to rethink components and stacks in device software. With modern devices frequently using multiple operating systems and requiring application and switching support for products from various vendors, freeing resources to work on these functionalities rather than starting at the foundation for every project is allowing more sophisticated devices to reach market faster and on-budget. It’s also allowing developers to apply their talents where they’re most urgently needed. Incorporating Linux capabilities with experienced support from an established vendor is also reducing bugs and incompatibilities from plaguing systems where Linux had previously been a risky proposition.

DSO provides device manufacturers with technology choice and flexibility when building devices. They are not locked into proprietary platforms but rather can leverage the best technology and tools suited to any type of device incorporated into their product line. This newfound freedom means finding a proven solution that can be recycled and modified for new uses without starting from scratch. DSO opens the door to higher quality code that can be reused for any device type because it was created with company-wide priorities in mind. It means that, just as technology in the Model T appears in the latest super-cars, the initial investment in finding effective solutions can be improved upon for years to come. This approach is one that needed a name of its own to encapsulate its proposed reforms. Finding solutions the old way is still prevalent in the UK but we can no longer afford to spend our time re-inventing the wheels in our products. <End/>

www.windriver.com

Eclipsecon 2006

Eclipsecon is the premier technical and user conference for Eclipse, and the third gathering is March 20th to 23rd at the Santa Clara Convention Center. There are keynotes, conference sessions and tutorials covering all aspects of the Eclipse platform.

www.eclipsecon.org

Workbench

Genuitec, has released the MyEclipse Enterprise Workbench 4.1. a J2EEand Web-

development tool suite. It is designed for use on Linux, Mac OS X and Windows workstations.

www.genuitec.com

Eclipse 3.0 Platform

The QNX Momentics development suite has been upgraded, based on new versions of the Eclipse framework and the Eclipse C/C++ Development Tools (CDT)

It also features better interrupt-handling capabilities for the QNX system profiler, and

deeper traceback and leak detection in the memory analysis tools for advanced debugging. Included are customized Eclipse plugins, such as a code “dietician” that reduces memory footprint by removing unnecessary functionality from shared libraries, and an application profiler that pinpoints problem algorithms and identifies functions needing optimization.

www.qnx.com

Software architecture management

Lattix has released Lattix LDM for Eclipse, providing Lightweight Dependency Models (LDM) to formalise, communicate and control the architecture of Eclipse projects.

www.lattix.com/news/news.htm

RTOS Functions Measured

Context Switch (CS): Time required to save current thread’s context, find highest priority ready thread, and restore its context.

Interrupt Latency Range (ILR): Amount of time interrupts are disabled.

RTOS System Services

●tx_thread_suspend – Suspend an application theread.

●tx_thread_resume – Resume a previously suspended thread.

●tx_thread_relinquish – Relinquish control to other application threads.

●tx_queue_send – Send a message to a message queue.

●tx_queue_receive – Get a message from a message queue.

●tx_semaphore_get – Get an instance from a counting semaphore.

●tx_semaphore_put – Place an instance in a counting semaphore.

●x_mutex_get – Obtain ownership of a mutex.

●tx_mutex_put – Release ownership of a mutex.

●tx_event_flags_set – Set or clear event flags.

●tx_event_flags_get – Retrieve event flags.

●tx_block_allocate – Allocate a memory block.

●tx_block_release – Release a memory block.

●tx_byte_allocate – Allocates bytes of memory.

●tx_byte_release – Release a previously allocated memory area.

For each system service, the following are measured:

●Immediate Response (IR): Time required to process the request immediately, i.e., no thread suspension or thread resumption.

●Thread Suspend (TS): Time required to process the request when the calling thread is suspended due to unavailability of the resource.

●Thread Resumed (TR): Time required to process the request when a previously suspended thread (of the same or lower priority) is resumed as a result of the request.

●Thread Resumed and Context Switched (TRCS): Time required to process the request when a previously suspended higher-priority thread is resumed as a result of the request. Since the resumed thread is higher-priority, a context switch to the resumed thread is also performed from within the request.

system as interrupts. The processor, upon recognizing an interrupt, performs certain actions and executes instructions that were designed to react to this event. In most cases, the processor is already performing some instructions immediately prior to recognizing the interrupt. This processing must be “interrupted,” and then later resumed when the critical real-time response of the interrupt has been completed. Most RTOSes are designed to provide a means for the developer to handle interrupt processing and also to schedule and manage execution of application software threads. Interrupt processing generally includes the following:

●suspending whatever thread currently is executing,

●saving thread-related data that will be needed when the thread is resumed,

●transferring control to an interrupt service routine (ISR),

●performing some amount of processing in the ISR to determine exactly what action is needed,

●retrieving/saving any critical (incoming) data associated with the interrupt,

●setting any required device-specific (output) values,

●determining which thread should now execute given the change in environment created by the interrupt and its processing,

●clearing the interrupt hardware to allow the next interrupt to be recognized,

●transferring control to the selected thread,

including retrieval of any of its environment data that was saved when it was last interrupted.

Whew! All of that (and perhaps more, depending on the RTOS) is included in “interrupt processing,” which is only one aspect of real-time performance. It’s no wonder that implementation of these operations in a particular RTOS can make a significant difference in real-time performance.

System services

Real-time operating systems must do more than simply respond to interrupts. They also must schedule and manage the execution of application software threads and handle

'REAT "RITAIN ,AUTERBACH ,TD

0HONE WWW LAUTERBACH CO UK

'ERMANY ,AUTERBACH 'MB( WWW LAUTERBACH DE

)TALY ,AUTERBACH 3RL

WWW LAUTERBACH IT

53! ,AUTERBACH )NC

WWW LAUTERBACH COM

#HINA

3UZHOU ,AUTERBACH #ONSULTING #O ,TD WWW LAUTERBACH CN

*APAN

,AUTERBACH *APAN ,TD WWW LAUTERBACH CO JP

,%!$).' THROUGH 4ECHNOLOGY

0OWER4RACE ))

s'"YTE OF TRACE MEMORY TO RECORD PROGRAM AND DATA FLOW

s-ORE THAN PROCESSOR ARCHITECTURES SUPPORTED BY THE TRACE PORT

s 4RACE PORT SPEED UP TO -(Z

s3OPHISTICATED ANALYSIS METHODS TO PERFORM COMPREHENSIVE PERFORMANCE ANALYSIS AND QUALITY ASSURANCE TESTS

0OWER$EBUG ))

s! 'IGABIT ETHERNET INTERFACE GUARANTEES IMMEDIATE DISPLAY AND RAPID ANALYSIS