&&& &&& &&& &DSP/BIOS Real-Time Operating System (RTOS)
Part Number
Buy from Texas Instruments or Third Party
DSP/BIOS 5.x Real-Time Operating System
Description
DSP/BIOS(TM) kernel is a scalable real-time multi-tasking kernel, designed specifically for the TMS320C6000(TM), TMS320C55x(TM), and TMS320C28x(TM) DSP platforms. Together with its associated networking, microprocessor-DSP communications, and driver modules, DSP/BIOS kernel provides a solid foundation for even the most sophisticated DSP applications. DSP/BIOS kernel has been proven in thousands of customer designs and is one of the world’s mostly widely used real-time operating systems. DSP/BIOS kernel requires no runtime license fees and is backed by Texas Instruments worldwide training and support organizations.
DSP/BIOS kernel provides standardized APIs across C6000(TM), C55x(TM) and C28x(TM) DSP platforms to support rapid application migration and is also optimized to run on the DSP cores on OMAP(TM) devices. DSP/BIOS kernel is available both standalone and as an integral part of the Code Composer Studio(TM) Interactive Development Environment (IDE) and includes graphical Kernel Object Viewer and Real-Time Analysis tools specifically focused on debugging and tuning multitasking applications.
DSP/BIOS kernel is backed by an experienced development team that regularly adds new capabilities, such as variable length message passing and power management.
More Than a Kernel
In addition to the core, DSP/BIOS multitasking kernel services and development tools, TI provides other DSP/BIOS-compatible modules that simplify application development:
: A TCP/IP stack including higher level services such as HTTP server and telnet.
DSP/BIOS Link: See below for more information: Microprocessor-DSP communications and control software that enables a microprocessor to bootload and communicate with a DSP.
Processor Support Package (PSP): The PSP includes DSP/BIOS drivers for devices such as serial ports and EMACs, as well the low-level software layer for the all the DSP peripherals (Chip Support Library). Most PSPs are available for download in the applicable Software Development Kits (DVSDK and SDKs).
: These systems software modules are augmented by DSP/BIOS-compatible Multimedia Framework Products, including the xDAIS Developer’s Kit, Codec Engine, Framework Components that eliminate many of the issues associated with developing and integrating multi-function DSP applications.
DSP/BIOS Kernel Overview
DSP/BIOS kernel provides a rich set of C-callable deterministic kernel services that enable developers to create sophisticated applications without compromising real-time deadlines. DSP/BIOS kernel is highly scalable with multithreading configurations requiring as few as 1K words.
DSP/BIOS kernel is configurable to minimize memory footprint. Configuration can be done either statically through graphical or scripting tools or dynamically using operating system calls. In addition to excluding unused modules, static configuration further reduces target memory footprint by eliminating the code required to dynamically create and delete operating system objects such as threads and semaphores.
DSP/BIOS includes the following kernel modules:
Kernel Module
Description
Hardware Interrupts (HWI)
Interface from hardware interrupts to DSP/BIOS kernel
Software Interrupts (SWI)
Lightweight preemptible threads that use program stack but cannot yield
Tasks (TSK)
Independent threads of execution that can yield the processor
Periodic Functions (PRD)
Time-triggered lightweight threads
Message Queues (MSGQ)
Variable-length zero copy messages
Mailboxes (MBX)
Synchronized data exchange between tasks
Locks (LCK)
Nestable binary semaphores
Semaphores (SEM)
Counting semaphores
Queues (QUE)
Atomic link lists
Clock (CLK)
Interface to hardware timers
Streams (SIO)
Streaming I/O
General I/O (GIO)
Extensible I/O module with support for asynchronous I/O & synchronous read/write
Memory Manager (MEM)
Low overhead dynamic memory allocation
Buffer Manager (BUF)
Fast, deterministic fixed-size buffer allocation
Power Manager (PWRM)
Power management functions
Cache Control (BCACHE)
Cache configuration and management
DSP/BIOS MultithreadingTo provide the fast response required by DSP applications, DSP/BIOS kernel augments the traditional tasking model with additional threading mechanisms. Software Interrupts are lightweight pre-emptible threads that share a common stack. This results in lower memory overhead and faster context switch times, as there is no need to save and restore a task stack. Periodic Functions are time-triggered high-priority threads that can be easily set up to process samples of data arriving at fixed time intervals, simplifying the design of multirate systems.
DSP/BIOS IPC MechanismsDSP/BIOS kernel offers several IPC mechanisms for interthread communication. Semaphores and Locks provide basic synchronization and resource locking. Mailboxes enable synchronous transfer of fixed sized messages between tasks. Message queues enable zero copy, variable-length message passing between any DSP/BIOS kernel thread type. The exact memory for each message is allocated when the message needs to be sent. Message passing is transparent at the application level and can be within a single DSP or between multiple DSPs. For inter-DSP communication, a Message Queue Transport is required. Some of these (for example, Serial RapidIO(R)) are available pre-tested from TI.
DSP/BIOS Multicore SupportDSP/BIOS kernel fully supports TI’s multicore DSP solutions. For devices designed to execute the same image on multiple cores, DSP/BIOS kernel provides shared image support, maximizing the amount of local core memory available for data. In addition, a shared memory transport is provided to enable core-to-core communication using the DSP/BIOS MSGQ module. This transport utilizes the underlying hardware features such as atomic access monitors or hardware semaphores to provide the most efficient implementation.
DSP/BIOS Interrupt ManagementDSP/BIOS kernel includes a comprehensive set of services for interrupt management. The interrupt dispatcher enables developers to write ISRs in C by performing low-level operations such as context save/restore and temporary disabling of the scheduler. This approach reduces code size by eliminating the need to specifically add such code to each ISR. To reduce data memory requirements, all ISRs use a common stack rather than the stack of the task they interrupt, with the exception of the first interrupt context, which is stored on the task stack for performance reasons. The HWI and Event Combiner modules provide additional APIs for enabling/disabling interrupts and multiplexing multiple interrupt sources on to a single pin.
DSP/BIOS Power ManagementFor TI DSPs used in portable applications where power consumption is a key consideration, such as the TMS320C5509 DSP, DSP/BIOS kernel offers a range of power management features. These may include automatically idling the CPU when in the IDL task, voltage and frequency scaling APIs, sleep or hibernate APIs, automated idling of peripherals when the peripheral domain is not in use, and a register/notify mechanism for coordinating complex system-wide power management.
DSP/BIOS OS-Aware Analysis & DebugIn conjunction with Code Composer Studio(TM) IDE, DSP/BIOS kernel provides several tools to aid debugging and optimization of multithreaded applications. The Kernel Object Viewer enables a developer to check the status of OS objects such as tasks, mailboxes, and semaphores, including whether a task is ready, running, or blocked, and which tasks are blocked on an IPC. The Real-Time Analysis tools display the thread execution and switching sequence, average and maximum execution times for a thread, and system CPU load, as well as providing a very low overhead printf capability.
DSP/BIOS Link
Many DSP-based applications, ranging from digital cameras to communications switches, use a microprocessor (GPP) to control one or more DSPs. To meet this need, TI is increasingly delivering devices that offer an ARM(R) and DSP core in the same package. DSP/BIOS Link is software designed to facilitate communication between the ARM and the DSP in SoC devices.
To develop applications that reside on GPP+DSP solutions, developers must implement communications software that enables data and control information to be exchanged between the GPP and the DSP. In addition, the GPP must also boot the DSP and often control which algorithms the DSP executes for a specific task. DSP/BIOS Link eliminates the need to create these functions from scratch by providing a robust set of MCU-DSP communications services including:
Variable-length messaging between the GPP and DSP
Ring buffer communication between GPP and DSP
Point-to-point, asynchronous data streaming between the GPP and DSP
Bootload the DSP from GPP
Pre-tested GPP-DSP communications driver support for select devices
DSP/BIOS Link is available for both SoC devices, such as DaVinci(TM), where the ARM and DSP communicate using shared memory, and discrete DSPs offering a PCI interface. DSP/BIOS Link is provided as a source code porting kit and includes pre-tested ports for some versions of embedded Linux.
Technical Documents
More literature&(1)
*This is not an TI official document.
01 Aug 2011
Application Notes&(1)
Multiple Files
06 Feb 2012
User Guides&(5)
09 Oct 2012
09 Oct 2012
09 Oct 2012
09 Oct 2012
28 Feb 2009
Related Products
Software&(2)
Multimedia Framework Products (MFP) - Codec Engine, Framework Components and XDAIS&
Application Software & Frameworks&
TI-RTOS Networking&
Software Libraries&
Development Tools&(1)
Part Number
Code Composer Studio (CCS) Integrated Development Environment (IDE)&
SW Development Tools, IDEs, Compilers&
TI Devices&(73)
OMAP-L137&
C6000 DSP+ARM Processor&
Applications Processor&
DSP+ARM Cortex-A8&
Applications Processor&
OMAP™ Processors&
TMS320C5504&
Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320C5505&
Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320C5514&
Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320C5515&
Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320C6202&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6202B&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6203B&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6204&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6205&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6211&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6211B&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6410&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6411&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6412&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6413&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6414&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6414T&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6415&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6415T&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6416&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6416T&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6418&
Fixed-Point Digital Signal Processor&
Fixed-point&
TMS320C6701&
Floating-Point Digital Signal Processor&
Fixed/Floating-point&
TMS320C6711B&
Floating-Point Digital Signal Processor&
Fixed/Floating-point&
TMS320C6713&
Floating-Point Digital Signal Processor&
Fixed/Floating-point&
TMS320C6713B&
Floating-Point Digital Signal Processors&
Fixed/Floating-point&
TMS320C6722&
Floating-Point Digital Signal Processor&
Fixed/Floating-point&
TMS320C6726&
Floating-Point Digital Signal Processor&
Fixed/Floating-point&
TMS320C6727&
Floating-Point Digital Signal Processor&
Fixed/Floating-point&
TMS320C6747&
Fixed/Floating-Point Digital Signal Processor&
Fixed/Floating-point&
TMS320C6748&
Fixed/Floating Point Digital Signal Processor&
Fixed/Floating-point&
TMS320DM640&
Video/Imaging Fixed-Point Digital Signal Processor&
TMS320DM641&
Video/Imaging Fixed-Point Digital Signal Processor&
TMS320DM642&
Video/Imaging Fixed-Point Digital Signal Processor&
TMS320DM643&
Video/Imaging Fixed-Point Digital Signal Processor&
TMS320DM6435&
Digital Media Processor&
DSP + ARM9&
TMS320DM6441&
DaVinci Digital Media System-on-Chip&
DSP + ARM9&
TMS320DM6443&
DaVinci Digital Media System-on-Chip&
DSP + ARM9&
TMS320DM6446&
DaVinci Digital Media System-on-Chip&
ARM9 + Video Core&
TMS320DM6448&
Digital Media System-on-Chip (DMSoC)&
DSP + ARM9&
TMS320DM647&
Digital Media Processor&
TMS320DM648&
Digital Media Processor&
TMS320F2801&
32-Bit Digital Signal Controller with Flash&
Real-time Control&
TMS320F28015&
32-Bit Digital Signal Controller with Flash&
Real-time Control&
TMS320F28016&
32-Bit Digital Signal Controller with Flash&
Real-time Control&
TMS320F2802&
32-Bit Digital Signal Controller with Flash&
Real-time Control&
TMS320F28044&
Digital Signal Controller&
Real-time Control&
TMS320F2806&
32-Bit Digital Signal Controller with Flash&
Real-time Control&
TMS320F2808&
32-Bit Digital Signal Controller with Flash&
Real-time Control&
TMS320F2809&
32-Bit Digital Signal Controller with Flash&
Real-time Control&
TMS320F2810&
32-Bit Digital Signal Controller with Flash&
Real-time Control&
TMS320F2811&
32-Bit Digital Signal Controller with Flash&
Real-time Control&
TMS320F2812&
32-Bit Digital Signal Controller with Flash&
Real-time Control&
TMS320F28232&
Digital Signal Controller&
Real-time Control&
TMS320F28234&
Digital Signal Controller&
Real-time Control&
TMS320F28235&
Digital Signal Controller&
Real-time Control&
TMS320TCI6482&
Fixed-Point Digital Signal Processor&
Semiconductors&
TMS320TCI6484&
Communications Infrastructure Digital Signal Processor&
Semiconductors&
TMS320TCI6486&
Communications Infrastructure Digital Signal Processor&
Semiconductors&
TMS320TCI6487&
Fixed-Point Digital Signal Processor&
Semiconductors&
TMS320VC5501&
Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320VC5502&
Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320VC5503&
Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320VC5504&
Low-Power Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320VC5505&
Low-Power Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320VC5507&
Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320VC5509&
Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320VC5509A&
Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320VC5510&
Fixed-Point Digital Signal Processor&
16-bit Fixed-point&
TMS320VC5510A&
Fixed-Point Digital Signal Processors&
16-bit Fixed-point&
Support and Community
TI E2E™ community
As a member of
you can join the
where you can ask questions, share ideas and collaborate with fellow engineers and TI experts
Contents are provided "AS IS" by the respective TI and Community contributors and do not constitute TI specifications. See .
Engage in the Community
Training & events
Available During
On-Line Training
On-Line Training
Customer Tags
Most Popular Tags for调度模板微控制器(Scheduler Template for Microcontrollers)　
Praveen describes the process of writing a scheduler template for a single-chip microcontroller.Although he used this technique when he designed a real-time digital wall clock, you can apply it to your next single-chip microcontroller-based project.
When I was younger， I had a strong interest in electronic gadgets. This led me to the study electronics engineering，and with the God‘s blessing， I eventually became an engineer.
When I was a student， I spent all of my pocket money on parts for electronic circuits. My dream back then was to develop a multifunctional digital clock with a large display. A few years later， I reached my goal.
As a designer， you need to apply your programming skills to optimize a microcontroller's resources in order to meet an application‘s requirements. If you practice real-time programming，you can use a real-time operating system（RTOS） to efficiently manage the CPU's resources. An RTOS provides a framework for the development of reliable， predictable， and deterministic multitasking embedded systems. Not only does it offer a homogenous platform for developing applications in modular form， it assigns a definite time frame to your code and simplifies the coding process. To provide such features， it requires resources such as memory （code and data）， on-chip peripherals （e.g.， timer and interrupt），and of course the CPU time.
In this article， I‘ll walk you through the process of building a multifunctional digital clock （see Photo 1）。 As I do so， I'll describe a scheduler template for a single-chip microcontroller.
RTOS VS. SINGLE-CHIP MCUs
RTOS-based coding is a concern for single-chip microcontrollers with small amounts of data （64 to 256 bytes） and code memory （1 to 4 KB）like those in Atmel‘s AT89Cx051 series （a 20-pin derivative in the MCS51 family）。 Although an RTOS is available in scalable form for such tiny devices， they consume significant resources and you may be unable to code your application in the remaining space. Because of limited resources， the RTOS cannot offer all of its services.
When I was writing code for singlechip microcontroller applications， I realized that I should have a fully customizable option for the operating system. How did I do this？ Simple. I developed my own scheduler.
A simple minimal OS-like template will enable you to write multitasking code for a resource-constrained tiny microcontroller. Follow my lead， and you‘ll find it easy to estimate the timing performance and control the system's behavior.
MULTITASKING & SCHEDULING
An RTOS is a well-documented code bundle that will assist you in developing real-time applications and guarantee a predefined timing performance and deterministic behavior. The response time is predictable for known events （e.g.， on-chip peripherals and interrupts）。 Moreover， a commercial version is thoroughly tested and fairly bug-free.
Naturally， when you‘re trying to develop a critical embedded application，you're first choice should be a reliable commercial RTOS. With its proven code， you‘ll be confident that a system failure won't occur because of a bug in the operating system code. For a noncritical system， you have numerous options.
An RTOS provides three basic functions：task scheduling， task dispatching，and inter-task communication. A scheduler determines which task will run next in a multitasking system. A dispatcher performs the necessary bookkeeping to start the task. For a real-time application using an RTOS，you can ensure that a response to a certain event will occur within a certain time frame.
An RTOS bundle has a kernel or scheduler at its core. The RTOS multitasks by way of various task-scheduling techniques. The scheduler is responsible for switching between the tasks either periodically or because of internal or external events. Some scheduling schemes allow you to assign static or dynamic priorities to the task. The decision to schedule the next task depends on the task‘s priority. If two eligible tasks have identical priorities， then scheduling occurs sequentially.
A task， a thread， or a process is a piece of code that runs independent of other code. It assumes that it controls the CPU completely. But in reality， it's suspended either periodically or because of a high-priority task becoming active or as the result of an interrupt or event.
There are two kinds of scheduling：preemptive and nonpreemptive. For preemptive scheduling， an interrupt is used at a fixed rate （time slices）， it‘s event driven （hardware or software）， or both. The dispatching is performed by the interrupt-handling routine. This type of scheduling requires the preservation of a snapshot of the microcontroller（it's called "context"） when switching tasks.
If a higher-priority task is eligible to run， a preemptive scheduler will always interrupt and then block a lower-priority task. The scheduler maintains a database （typically referred to as the task control block（TCB）） to save the task attributes such as its priority， present state， pointer to its context， and other parameters. The RTOS maintains a separate stack area for each task. It saves the task context（all of the CPU registers， flags， the program counter， and the stack pointer） of the running task in its own stack area after it is suspended and restores it back before it is made to run again. This operation is known as context switching， and it consumes data memory. The context switching process is a one of the major contributors to the response time. The amount of data memory needed by the RTOS is decided by the number of tasks you declare. This also puts an upper limit for the number of tasks you declare. For single- chip devices， such operations eat up a significant amount of data memory and leave behind less memory for application data.
A nonpreemptive scheduler works because of cooperation between the tasks. The tasks designed for cooperation are sometimes called coroutines. A nonpreemptive scheduler does not interrupt a running task （irrespective of its priority）。 The task itself makes a call to the scheduler after it （partially or fully） completes its job. The dispatcher holds the pointer （program counter） for a list of tasks that are executed in round-robin fashion （i.e.， it selects the next task to execute）。 This task then executes until completion and the scheduler is called again.
This scheduling approach doesn‘t require an interrupt. Communication between the processes is achieved via global variables. Any data that needs to be preserved between dispatches must be deposited in global variables. The numbers of tasks are limited only by the code memory. Task-specific housekeeping isn't required for the scheduler. The design of coroutines requires disciplined programming. It‘s the programmer's responsibility to ensure that a task doesn‘t hang up too long.
When writing a program， your job is to organize your application as a collection of various independent tasks and then code them （e.g.， you may have a task to monitor/scan a matrix keypad， refresh an LED display， or read an ADC）。 The RTOS provides numerous services in the form of an application- programming interface （API） to interact with it. This way you can look at the RTOS as an object and everything inside（e.g.， variables and data structures）is hidden. Hiding data helps you achieve a robustness similar to object-oriented programming（OOP）。 The API enables communication between the tasks （signals， messages，and mailboxes）， memory protection （e.g.， semaphores and shared variables）， and management task attributes. Because the RTOS manages the CPU time for various tasks， it makes the most efficient use of the CPU without bothering you.
Multitasking can lead to a problem. Resource conflict occurs when two or more different parts of a system try to use the same physical or logical device at the same time. Let‘s consider an example in which a task is midway through manipulating a long （4 bytes） variable. Because of a timer tick event， it is suspended and the most eligible task controls the CPU. This new task reads and writes the same long variable and finishes its job. The old task regains the CPU and continues its pending job of manipulating the same long variable. Will the task now see the old value of the variable？
This is a typical scenario in a producer- consumer type of problem，where one task produces the data （e.g.，it‘s reading the ADC， keypad， or a user input） and one or more tasks consume it （e.g.， data analysis code or keypad handlers）。 If you aren't careful， the data passed between the producer and consumer tasks will be corrupted. The two tasks that share a resource should be mutually exclusive. Thus， only one task can execute at a time. For instance，you don‘t allow the producer and consumer tasks to run concurrently.
In the aforementioned example， the RTOS provides a locking mechanism with the help of semaphores to solve the data corruption problem. The producer task locks the shared variable by declaring a semaphore. All of the consumer tasks accessing the shared variable are automatically blocked by the RTOS until the producer completes its access. The producer notifies the RTOS about the completion of its shared variable access， and the RTOS unblocks all of the pending tasks waiting to access the shared variable. This way data transfer takes place smoothly under the supervision of the operating system's code.
The tasks need to synchronize with certain events. For example， an integrating type of ADC reading task may need to wait few tens of milliseconds for data conversion. Thus， the RTOS provides a timing-related sleep service that enables you to ask the operating system to wake up a task after a predefined time interval （specified in units of a timer tick）。 In this case， the sleeping task is automatically blocked for the requested time and the CPU is assigned to the next eligible task in the queue.
There is another method of synchronization. You can send a signal or message in response to an event （e.g.，the end of the conversion of an ADC signal）。 Thus， the ADC read task may not wait to poll the ADC status signal，but some other task （e.g.， an ISR hooked to the ADC status signal）may send notification （via a signal or message） of an event.
DIGITAL CLOCK
Before I describe my tiny scheduler code template， you should know a few things about my digital clock project.
I designed a wall-mountable digital alarm clock （see Photo 1）。 The system includes a remote keypad for setting the clock. I also added a remote control for the clock‘s tube light so my wife can see in the dark when she has to check on our young son. I used a microcontroller-based design because no dedicated clock chip was available that met my requirements.
The clock features a seven-segment LED display. I use an IR remote transmitter from a CD-ROM drive to control its operation. It has a numeric keypad and several other useful keys. To receive IR signals， I use a Vishay Intertechnology TSOP1738 IR receiver module， which gives me the demodulated TTL output signal for IR pulses. It has an ambient light filter （focusing optics at the receiving photodiode）， an amplifier， and a PLL-based IR demodulator in a small three-pin plastic package.
An Atmel AT89C2051 microcontroller（clocked using a crystal oscillator）provides a fairly reasonable time base for a digital clock. This is good enough when the power source （AC mains） is available. In the absence of an AC supply， you need an additional circuit that uses a battery to keep the time.
Maxim Integrated Products‘s eightpin DS1307 real-time clock has all of the necessary features built right in. It has a two-wire I2C serial interface for communication and 56 bytes of battery- backed RAM for data storage. The chip， which provides a clock calendar， needs an external 32.767-kHz watch crystal for timing. It automatically shuts down and invokes a low-power mode （500 nA） during a power failure. I‘ve used a +3-V lithium button cell（CR3203） as an external battery for the DS1307.
The digital clock has six seven-segment displays for showing the time in a 12-h format （see Photo 1 and Figure 1， p. 61）。 The six display digits are time multiplexed to save current. I drive each LED segment independently using a separate port pin to display letters and numbers. Pressing the Menu key on the IR keypad displays a menu for the system‘s various operations.
To drive an LED display digit， you need eight port pins for segment drive and one pin for digit drive. Thus， you need more port lines than U1（AT89C2051） can provide （only 15 I/O pins）。 I use two cascaded 74HC164（serial input parallel output 8-bit） shift registers as an output port expander for interfacing the six LED digits （see Figure 1）。 Now the AT89C2051 requires only two port lines-serial clock （CLK） and serial data （DATA）-to output information to the LED display. U7‘s （74HC164） 8-bit output drives eight display segments through a 74HC245 buffer that supplies 10-mA current （depending on the current-limiting resistors） to the individual LED segment. The other 74HC164 device（U8） drives ULN2003A seven- Darlington transistors that sink 80 mA of digit current for common cathode LED displays.
One port pin （P1.5） drives the base of the T1 （BC549C） NPN transistor through the current-limiting resistor R8. This transistor supplies 30-mA current to energize a 12-V relay that controls the tube light. A buzzer is connected through the current-limiting resistor R9 for the alarm's output. A bit-banged I2C master protocol is implemented in software using two general port pins （P1.6 and P1.7） for interfacing the DS1307 chip （U2） and a slave I2C device with a D0H/D1H address.[1， 2]
TINY SCHEDULER TEMPLATE
A tiny scheduler template for multitasking is based on coroutines that use event-driven mechanisms and state machines. The tiny scheduler code samples external and internal events. It dispatches the tasks in round-robin fashion based on the available events. The scheduler is a hybrid in the sense that it allows you to write a few preemptive time-critical tasks （limited by the number of CPU interrupts） for improved response time. If you know the task priorities， then you must write the event handlers in the order of priority. Higher-priority tasks will get the CPU time earlier.
The size of the scheduler is determined by the number of events to poll or generate. The scheduler‘s nature is cooperative. You can code the tasks as state machines that share same context and save valuable data memory and time by avoiding the contextswitching overhead！
APPLYING STATE MACHINES
Using a state machine is a wellestablished method for describing a system‘s behavior. You can arrange its format to implement real-time systems with numerous concurrent and interrelated processes or execution threads.
A state machine is a model that includes states， transitions， and actions. A state shows that the system is doing something （usually when waiting for an event to occur）。 It stores information about the past （i.e.， it reflects the input change from the start of the system to the present）。 It is also possible to perform a task while waiting.
A transition describes the condition under which the system changes from one state to another. The transition is usually triggered by an event， and it can perform one or several actions. An event is a message to the state machine that something has occurred （e.g.， a button has been pressed， time has elapsed， or a communication has been received）。 An action executes a function in the application. This function will， for instance， set an output， write text to the LCD， or send a message.
The tiny scheduler is based on the state machine diagram for your application. You can design it for a certain application and optimize it as much as you like. This automatically ensures minimal overhead.
As the scheduler runs， it will sequentially execute the states in a round-robin fashion. You need to include the code for your tasks as state actions. The transitions between the states are unconditional. （The basic skeleton template for the tiny scheduler is posted on the Circuit Cellar FTP site.） Listing 1 （p. 62） is the C language code template for the scheduler.
I‘ve described unconditional state transitions among various tasks， but in reality， your application may have conditions attached. You can estimate the execution time for each task in order to easily predict （compute） the response time for the known events.
I don't have special operating-system- like code for task switching because all of the tasks share the same context （the one provided by the microcontroller） to save valuable data memory. This enhances the task switching speed. The state machine construct， together with co-operative scheduling， automatically solves the problem of shared variables. The two states （I have tasks declared as states）of a single state machine are mutually exclusive. Thus， if you have a shared variable between two or more tasks，the state machine inherently guarantees a smooth data transfer using the shared variables.
When you refer to the basic skeleton template on the Circuit Cellar FTP site， keep in mind that the task priorities are fixed （all of the tasks have equal priority）。 To implement prioritybased scheduling， you must alter the skeleton. Before scheduling the task（i.e.， calling the state machine Tiny_Scheduler_Skeleton（））， you must check the events responsible for scheduling a particular task. Depending on the priority scheme， the scheduler will set the state variable and call the state machine （dispatcher） to execute the highest-priority task. This will ensure the allocation of the CPU to the highest-priority task.
Sometimes you have a time-critical asynchronous task （e.g.， IR signal monitoring）。 This means an event can fire at any moment （e.g.， a user can hit the keypad at any time）， and this event must immediately trigger the state transition to handle the user input. （The entire IR input pulse train must be monitored to recognize the key.） If you use conventional scheduling，you won‘t know how long it will take to execute the desired IR handling task. Will you lose real-time operability？ What is the remedy？ In order to handle such events， you need to preempt the corresponding task（state）。 Does this clue trigger an event in your mind？ No！ I will give you another one. The MCS-51 microcontroller（or any other） already provides you with such a capability. Still confused？I am referring to the interrupt mechanism.
When it comes to interrupt behavior，the microcontroller performs the job of preemptive scheduling in hardware. The MCS-51 CPU samples an interrupt request at the end of every machine cycle. If the request is active and the interrupt is enabled， the CPU immediately stops executing the current program， pushes the contents of the program counter （this is the context of the current task） on the stack，and vectors to the interrupt service routine （ISR）。 This is exactly the behavior you‘re looking for.
Be careful when manipulating a shared variable from a preempted task because it may lead to the problem of variable corruption. You have two options for the ISR task. Either you notify the scheduler by generating an event or you call the task code from the ISR. If your task code is highly time-critical （e.g.， the expected response time is short）， you can't afford a time delay （i.e.， the event recognition and processing time needed by the scheduler to make the task running）。 As a result， you must include the task code in the ISR. Otherwise， you can wait for the scheduler to prioritize the tasks and it will become active.
Sometimes you‘ll need to synchronize a task with respect to an event（e.g.， an external event like a hardware trigger input or an internal event like a timeout）。 You can easily implement this by generating events and polling them. The task that needs to be synchronized monitors， or polls， a specific event until it occurs. The synchronizing task generates the event （e.g.， an ISR to notify a hardware trigger and state machine code for internal event）。The waiting task captures it and the synchronization takes place. You may pass a message in addition to raising events to supply additional information about the trigger.
DIGITAL CLOCK STATES
For the digital clock， the microcontroller handles the time multiplexing of the LED display， monitors the IR receiver for user interaction， and decodes the received IR command. It must then periodically read the realtime clock （RTC） in order to take any appropriate actions. It can update the time on the LED display， sound the alarm （if required）， control the tube light （if requested）， and provide a user interface for clock operation （see Figure 2， p. 64）。 Most of these jobs are independent and assigned as tasks.
To represent a task as a state machine， you must identify the states，the conditions for transitions between them， and the events associated with each task. You must then draw a state machine diagram. The LED display time-multiplexing task must be called periodically in order to keep the display alive. The required display refresh rate is about 2 ms. You have to output the data serially to the display.
MCS-51 architectures provide you with two 16-bit timers. Using coroutines，it‘s difficult to ensure a periodic 2-ms response time for this task. Using the Timer0 interrupt for dispatching，the display refresh task will solve the problem. Be sure the display memory is a shared resource with this preemptive task and the other tasks that write to the LED display!
Monitoring IR reception is a challenging job. It is an asynchronous time-critical task that requires preemptive scheduling. If written as a coroutine， there is the danger of missing a few initial IR pulses. For this reason，I connected the IR receiver module to the AT89C2051‘s *INT0 pin. This external interrupt， which can be programmed as falling-edge triggered，is assigned the highest priority by the power-on-reset internal code sequence. I didn't have any other asynchronous inputs， so I decided to poll the IR receiver module from within the *INT0 ISR code until there was IR activity. Although this wasn‘t the best method， it wasn't too harmful in my case. It was the only way to implement preemption with minimal overhead. The IR interrupt suspended all of the other tasks， including the seven-segment display multiplexing that would have generated feedback（display blinks） to indicate that the IR interrupt had processed the IR reception code.
The alarm-checking and playback functions are handled as a separate task with state machine code （see Figure 3a，p. 66）。 This task is synchronized on an EvOneMinute event generated by the function that the DS1307 RTC chip updates in real time. After the alarm is triggered， the code activates the buzzer for either 0.5 h or until you press the Mute key to stop it. This ensures that you wake up in the morning. The relay operation for controlling the tube light is carried out in another state machine （see Figure 3b）。
A relay can have only two states： on and off. I assigned the Mouse key on the keypad to toggle the relay state. The detection of this anguage code. In each of the state machines， there‘s an INIT state for initializing all of the associated variables and events. You can wait in this state if you want to synchronize it with another state machine； otherwise， you can jump to the next state to continue executing the state machine. You typically won't revisit the INIT state unless you reset the microcontroller.key triggers the transition between the two states.
I added a special function that enables me to turn on the tube light at night （from 11 PM to 7 AM） by pressing any key on the remote. This is a helpful function. My wife can turn on the light with any key when she‘s half asleep and walking in the dark.
Implementing the alarm's state machine diagram is a fairly straightforward process. Listing 2 is the C language code. In each of the state machines， there‘s an INIT state for initializing all of the associated variables and events. You can wait in this state if you want to synchronize it with another state machine； otherwise， you can jump to the next state to continue executing the state machine. You typically won't revisit the INIT state unless you reset the microcontroller.
All of the variables used internally by a state machine must be declared global. They can‘t be reused （with the other state machines） because they may be holding vital information from the past. As a result， this implementation asks for memory. Because you don't have a separate stack for each task （state machine）， you can‘t push local variables on the stack and reuse the stack area. You can carefully work out and share a few variables if you're sure they hold temporary data and their scope is limited. Moreover， sharing is typically possible in mutually exclusive state machines.
Although I won‘t cover the IR decoder ISR code in detail， note that it digitizes the IR signal to determine the alternate sequence of high and low pulses and then compares it in a table in ROM. If a match is found， the table index is returned as the key code.
CLOCK MENU
My clock features a simple menu system that enables you to select operations like setting the alarm and toggling the relay. This user interface menu task is implemented as a state machine.
If you have another state machine for reading the DS1307 RTC chip and updating the time to the display， it may interfere with the menu state machine when both try to execute concurrently. （Remember： the display memory is a shared resource！） This means you must define a relationship between the two state machines so they can coexist amicably. You need them to be mutually exclusive. Only one machine should execute and the other should be blocked.
You also need to block the alarm task when the set alarm function is active. To ensure this relationship， I included them as two states of the same state machine. MENU_NOP is the DS1307 RTC time display task. The rest of the state machine flow handles the clock menu （see Listing 3）。 A help function （GetTime（）） enables you to enter the time （hh：mm） with the A/P（AM or PM） flag. You can use the same function to set the new clock time or the new alarm time.
To reduce the number of states in the menu state machine， you can use the Menu_Index variable to keep track of the active menu item. The menu navigation keys （VOL_PLUS and VOL_MINUS） manipulate this variable to reach the current menu item. The corresponding predefined pattern string is displayed with the help of the DspPat（） function.
Use the Enter key to select an active item and trigger the state transition to EXEC_MENU_FUNCTION. Because I have three menu items，they‘re handled in three different states. The actual state is reached by adding the contents of the Menu_Index variable to the MenuState variable that invokes the corresponding menu item handler. After executing the individual function，the menu system returns to a previous menu level. You can exit the menu system by pressing the Menu key during the execution of the SELEC_MENU state.
WRITE YOUR OWN TEMPLATES
In this article， I described the process of writing a real-time application. I covered the main concepts， but I didn‘t use the RTOS framework. I hope you now understand the advantages of writing your own scheduler templates for single-chip microcontroller（see Table 1）。 It isn't that bad in terms of performance. As the number of tasks increases， so does the complexity. Such an implementation is highly efficient for single-chip microcontrollers，but I‘ll leave it to you to explore the possibility of extending it for a fully expanded MCS-51 microcontroller- based system.
In a purely cooperative system， all of the sequencing can be built into a program（like the one I've described）。 The RTOS is redundant. The design of such sequencing requires careful planning during the design stage. You must have a clear understanding of the principles of multitasking. If you think things through， this type of scheduling scheme will be a viable alternative to conventional RTOS-based designs for even the smallest embedded systems. If you can avoid using a preemptive RTOS， you‘ll save on context switching，reentrancy issues， and add-on OS services without compromising your device's performance.
With the help of a circular buffer implementation and some data structures，you can overcome the problems of data sharing between an ISR and normal tasks. The availability of more on-chip interrupts enables you to have more preemptive tasks. Now you can work out the architecture for your future embedded systems using the state machine event-driven programming technique. Happy real-time multitasking！
Praveen Deshpande （）earned a Bachelor‘s degree in electronics engineering from the Regional Engineering College in Nagpur， India. He is a senior scientific officer in the field of distributed data acquisition and control. Praveen is currently working on superconducting magnet testing and measurement （the LHC project） at the CERN physics lab in Geneva. His interests include real-time operating systems and distributed control.
PROJECT FILES
To download the code, go to .
REFERENCES
[1] Jean-Marc Irazabal and S. Blozis,"AN10216 I2C Manual," Philips Semiconductors, 2003.
[2] Maxim Integrated Products,"Interfacing the DS1307 with an 8051-Compatible Microcontroller,"AN95, 2001.
Atmel Corp., "Atmel Corporation Microcontroller Data Book," October,1995.
Intel Corp., "MCS 51Microcontroller Family User's Manual," ,1994.
AT89C2051 Microcontroller
Atmel Corp.
DS1307 Real-time clock
Maxim Integrated Products, Inc.
AN10216 I2C
Philips Semiconductors
TSOP1738 IR Receiver module
Vishay Intertechnology, Inc.
旗下网站： |
与非门科技(北京)有限公司 All Rights Reserved.
京ICP证:070212号 北京市公安局备案编号： 京ICP备：号}