Embedded Insight Archives

/*------------------------------------------------------------------*\

Embedded Insight

The Monthly Newsletter for Embedded Systems Professionals

Published by Base2 Software Design, Inc.
    http://www.base2software.com
    mailto:info@base2software.com

October, 2002

\*------------------------------------------------------------------*/

• Tell Us What You Think!
• NEW! The Motorola Nitron HC08 Q-Family
• Base2 Embedded Solutions
• Real Real-Time

Tell Us What You Think!

I want to thank you for subscribing to the Embedded Insight newsletter. I hope you find it informative and useful. In order to serve you better, I'd like to get your input. Please drop me a line at mailto:mmiu@base2software.com and let me know what you think of Embedded Insight and what you'd like to see in the future. I hope to hear from you soon.

Sincerely,

Michael Miu
President, Base2 Software Design, Inc.

NEW! The Motorola Nitron HC08 Q-Family

Just last week, Motorola introduced the new Nitron HC08 Q-Family. These tiny new chips are well suited for extremely small applications such as remote controls and key fobs. Some of the family's key features include:

• M68HC08 core
• 3.2 MHz internal oscillator with 8-bit trim
• 8 MHz maximum external oscillator
• Up to 4 KB Flash
• 128 bytes of RAM
• Timer Interface Module (TIM)
  • 16-bit timer
• 2 capture/compare channels
• PWM capability
• 4-channel 8-bit ADCs
• Watchdog timer
• Wait and Stop modes for power savings

You can currently order a promotional development kit from Motorola. For $25, you get a small development board, serial cable, and a fully functional version of Metrowerks CodeWarrior Development Studio for HC08, Special Edition. This special version of CodeWarrior let's you program any HC08 (including the Nitron) with a limit of 4 KB of program size. You can order this development kit on the web at http://motorola.dartmail3.net/cgi-bin3/flo?y=hNfP0Ddm1U0EIe042T0Al.

With the Nitron family, Motorola provides alternatives to the Microchip PIC, Atmel AVR, and Philips LPC51 families. (For reference, look at our review of the Philips LPC51 family at http://www.base2software.com/eiarchives/ie200205.htm.) Nitron microcontrollers come in 8- and 16-pin DIP, SOIC, and TSSOP packages depending upon model and start around $0.70 each (Qty 1K). For more information, check out the Motorola website at http://www.motorola.com/mcu.

Base2 Services

Base2 Software Design provides embedded software development services for your product development needs. We support all levels of embedded software including:

• software analysis and design
• power-on self-test
• device drivers
• board support packages
• board bring-up and diagnostics
• embedded application development

Whether you need help finishing a project or if you're just forming a product development team, give us a call at 510/745-7773 or send an e-mail to mailto:info@base2software.com and see how we can help you bring your product to market.

Real Real-Time

"Real-time" is a term that is often bandied about in the embedded software industry. When applied to other industries, real-time can mean any number of things. But what does it really mean in an embedded system? How does it affect your software? Your hardware?

Hard and Soft Real-Time

Let's start by defining "real-time". Real-time can be defined as the ability to perform a task within a given time constraint.

In embedded systems, there are two types of real-time requirements: hard real-time and soft real-time. Not meeting a hard real-time requirement results in a failure. Not meeting a soft real-time requirement does not result in a failure. The definition of a failure is open to interpretation but generally refers to data loss, damage to equipment, or harming a patient.

Hard real-time requirements can be found in medical devices, cars, aircraft, and even consumer electronics. It's pretty easy to see that if a hard real-time requirement is not met in your car's engine controller, the result could be an undrivable car or even engine damage. Of course, many failures are not that dramatic. If an MP3 player doesn't meet it's real-time requirement to service the audio CODEC on a regular basis, the result is choppy or unintelligible audio.

Soft real-time requirements are commonplace and often refer to human interface elements (e.g. button response and display change rates). That's because people respond so much slower than computers. We simply can't tell the difference between a 100 ms response time and a 200 ms response time.

In most real-time systems, there is a mix of hard and soft real-time requirements. It is very important to identify these requirements early in the design process so that the proper hardware and software are created to meet those requirements. A good way to avoid confusion with hard and soft real-time requirements is by using careful wording. By using words like "must" and "shall", a hard real-time requirement is indicated. Words like "may" and "should be" indicate a soft real-time requirement. Here are just a few examples:

• A button press should be serviced within 200 ms.
• The 7-segment LED displays must be updated every 100 ms.
• The software control loop must be adjusted at least every 1 ms.
• The audio CODEC must be serviced every 100 us.

Meeting Real-Time Requirements

It is important to note that meeting real-time requirements is ultimately tied to a hardware mechanism whether it be interrupts, a timer, or even a super-fast CPU. This is true even with real-time operating systems (RTOSs). For the hardware and firmware designers, the challenge lies in the best way to meet real-time requirements. A good way to look at these requirements is by time ranges:

Microseconds. Handling constraints in the microseconds range usually requires an interrupt. The hardware and software designers need to work very closely together to arrive at the right hardware/software solution. It is critical to analyze the interrupt latency, memory access wait states, effect of instruction/data caching, and the number of instructions in the interrupt service routine. If your system is simple enough, then it may also be possible to poll for a specific event using a fast microcontroller.

Milliseconds. The software designer has many more choices in meeting requirements in this range. Time can be kept using a general purpose counter with a resolution of 1 ms to 10 ms. Hard real-time requirements can then be met using tasks attached to timer interrupts or by using a timer tick count as a reference time base. In a single-threaded design, it may be possible to get by without a timer so long as the microcontroller is fast enough and the hard real-time code is characterized. (e.g. What happens if all possible interrupts occur within the real-time code loop?)

100s of Milliseconds+ (human time). As a software designer, this range has the most latitude. These requirements can be handled within mainline code and without interrupt support. They can also be the most troublesome because UI requirements usually rest in this range, and each person's perception of a timely UI response is quite different.

If you know anyone who would like to receive this informative newsletter, please forward this to them. They can sign up by sending an e-mail to mailto:info@base2software.com?Subject=Subscribe.

If this newsletter was sent to you in error or if you'd like to unsubscribe to our newsletter, simply send an e-mail to mailto:info@base2software.com?Subject=Unsubscribe.

You may use the contents of Embedded Insight in whole or in part if you include the following complete copyright notice and live links:

Copyright 2002, Base2 Software Design, Inc.
http://www.base2software.com. mailto:info@base2software.com.