Abstract:
A main processor manages serial communication with one or more external devices by establishing the requisite tasks needed for serial communications. For example, these tasks can include (1) serial device handling, (2) protocol encapsulation, and (3) low-level communication with external devices. A priority is assigned to each of the tasks so that timing requirements are met, while maximizing processor efficiency of the main processor. Upon its completion, each lower priority task initiates execution of a next higher priority task to synchronize data processing with data communication.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]     This application claims priority under 35 U.S.C. 119(e) to U.S. Provisional Patent Application Ser. No. 60/446,524 filed Feb. 11, 2003, and 60/454,734, filed Mar. 14, 2003, the teachings of which are incorporated herein. 
     
    
       [0002]     This invention relates to a technique for achieving asynchronous serial communication between devices.  
       BACKGROUND ART  
       [0003]     Embedded systems often employ some form of asynchronous serial communication with other devices. Usually a coprocessor will manage the intricate details of the serial protocol(s) used for communication. In the absence of a coprocessor, the task of servicing serial devices will fall on the main processor, thus consuming valuable resources and imposing burdensome priority and timing requirements. Most serial protocols typically have stringent timing requirements. Without a coprocessor, the main processor handling the serial communication task will need a detailed knowledge of the system hardware to exploit the processor&#39;s capabilities. Knowledge of the system hardware entails knowing about low-level device driver routines, which are often prone to errors. In that regard, the main processor must verify a serial device&#39;s compliance as well as ensuring its own compliance. Taking a generic approach with regard to processor priorities can waste processor resources. Setting task priorities too low can cause missed deadlines due to task pre-emption resulting from other tasks running at higher priorities Setting task priorities too high can block critical tasks and waste processor time.  
         [0004]     Thus, there is need for a technique for achieving asynchronous serial communication in the absence of a co-processor, which overcomes the aforementioned disadvantages.  
       BRIEF SUMMARY OF THE INVENTION  
       [0005]     Briefly, in accordance with a preferred embodiment of the present principles, there is provided a method for managing serial communication by a main processor. The method commences by establishing the requisite tasks needed for serial communications. For example, these tasks can include (1) serial device handling, (2) protocol encapsulation, and (3) low-level communication with external devices. A priority is assigned to each of the tasks so that timing requirements are met, while maximizing processor efficiency of the main processor. Upon its completion, each lower priority task initiates execution of a next higher priority task to synchronize data processing with data communication. 
     
    
     BRIEF SUMMARY OF THE DRAWINGS  
       [0006]      FIG. 1  depicts a schematic diagram depicting each of a set of logical blocks (objects) associated with different tasks related to serial communication; and  
         [0007]      FIG. 2  depicts a timing diagram that depicts the sequence of events performed by the tasks of  FIG. 1 . 
     
    
     DETAILED DESCRIPTION  
       [0008]      FIG. 1  shows a block diagram of a system  10  in accordance with the present principles for efficiently managing serial communications with one or more peripheral devices (not shown) without the need for a dedicated co-processor. The system  10  comprises a main processor  11  having a first block  12  that takes the form of a set of instructions and associated data files. The first block  12 , herein after referred to as “DeviceManager” performs a first set of operations in connection with serial communications, including the polling of an address space that includes serial device(s) (not shown) with which the processor  10  seeks to communicate through a serial port  13 . When present, each serial device connected to the main processor  11  through the serial port  13  will respond, thereby allowing the DeviceManager  12  to request data from such devices required for communications purposes. For the identified serial device(s), the DeviceManager block  12  creates a task, depicted in  FIG. 1  as DeviceManagerTask  14  that initiates polling of the identified device(s) for data updating purposes. The DeviceManagerTask  14  runs at a lower priority, at least as compared to other system tasks. As discussed hereinafter, a task (e.g., DeviceManagerTask  14 ) is defined as the performance of an action, whereas, an object (e.g., DeviceManager  12 ) provides functions and/or data for use by a task.  
         [0009]     Within the processor  11 , a second block  15 , hereinafter referred to as the SerialProtocol block, encapsulates the details of the serial protocol(s) employed to communicate with external device(s) through the serial port  13 . An example of such a serial protocol is the esTributary protocol, although others exist and could easily be used. The SerialProtocol block  15  provides functions used to format outbound messages according to the protocol specification and ensure outbound messages comply with protocol&#39;s timing requirements. The SerialProtocol block  15  also contains functions to verify inbound messages&#39; compliance with the protocol specifications and the protocol timing requirements. The SerialProtocol block  15  creates a task  16 , hereinafter, referred to as the SerialProtocolTask, which controls the writing of data to, and the reading of data from the external device(s) through the serial port  13  according to this particular protocol&#39;s requirements. The SerialProtocolTask  15  runs at a sufficiently high priority to ensure that the task meets assigned timing deadlines.  
         [0010]     The main processor  11  of  FIG. 1  also includes a third block  17 , referred to as a SerialPort block that encapsulates low-level communication with the serial port  13 . The SerialPort block  17  serves to create an abstract (i.e., a model) of the serial port  13  making the architecture of this block more portable and reusable. The SerialPort block  17  provides functions to read data from and write data to the serial port  13  and also has responsibility to implement timeouts on read operations. The SerialPort block  17  creates a task  18 , hereinafter referred to as SerialReadTask that reads all serial data sent to the processor  11  through the serial port  13 . For that reason, the Serial ReadTask must run at a priority high enough to ensure that the task meets timing deadlines as required by any protocol using the serial port.  
         [0011]      FIG. 2  depicts a timing diagram that illustrates the sequence of events associated with initiating serial communication illustrating the advantage of the serial communication technique of the present principles. The process of serial communication commences when the DeviceManagerTask  14  of  FIG. 1  initiates polling of an address corresponding to the serial port  13  of  FIG. 1  by calling the Poll  90  function of DeviceManager  12 . Poll  90  in turn calls the Poll  100  function of SerialProtocol  15 . Poll  100  in turn calls the SetData  110  function which copies the destination address to SerialProtocol block  15  and then calls the semGive  120  function of SerialPort  17 .  
         [0012]     At initialization or subsequent to some previous poll event SerialProtocolTask  16  blocked (stopped running) in semTake  130  waiting for its semaphore. The semGive  120  functions triggers SerialProtocolTask  16  that it has valid data and may now run. This results in the Write  140  function being called which writes the polling data to serial port  13  of  FIG. 1 . Subsequently the Read  150  function is called. Read  150  in turn calls the semTake  160  function which causes SerialProtocolTask  16  to block (stop running) until it is triggered in  170 .  
         [0013]     SerialReadTask  18  continually looks for incoming data from serial port  13  of  FIG. 1  in its read  180  function. When any data are available they are copied into SerialPort block  17 . The semTake  160  function returns in  170  when the data requested in Read  150  is available or the specified time has elapsed. This triggers SerialProtocolTask  16  to run which returns the poll data (if the read was successful) or an error indication (if the time limit was exceeded) to DeviceManagerTask  14 .  
         [0014]     Since SerialReadTask  18  runs at a high system priority it can be guaranteed to meet its timing deadlines, but since it only runs when data are available from serial port  13  of  FIG. 1  it will never consume system resources unnecessarily.  
         [0015]     Similarly, since SerialProtocolTask  16  runs at a high system priority it too can be guaranteed to meet its timing deadlines. It is only triggered to run when a poll function is required so it will not consume system resources unnecessarily when it is not needed. When it is active and waiting for a response from a serial device it also blocks (stops and waits) on the SerialPort block  17  to trigger it to run again, thus not consuming unnecessary system resources during this phase of the communication cycle. Polling is one method for communicating with a group of serial devices. Another option would be to have the serial port interrupt the processor when data is available. If there were only one serial device attached the processor could communicate to it without any polling or addressing. The present technique is applicable to all these mechanisms. The entire serial communication cycle is gated by the low priority DeviceManagerTask  14 . This allows the system to meet timing requirements of the serial protocol during a serial communication cycle. But these serial communication cycles are only allowed to run when other, higher-priority tasks in the system allow the DeviceManagerTask  14  to run.  
         [0016]     The foregoing describes a technique for achieving serial communication without the need for dedicated co-processor for managing communications tasks.