A variety of integrated circuit systems is known from the prior art which comprise more than one processing unit. Information is exchanged between the processing units via transmission channels while the communication interface is realized by means of communication modules and physical connections. In an embedded micro controller environment where one processing unit has to exchange information with different peer processing units and/or communication peripherals the processing unit needs to support all of the communication protocols used by any peer and/or communication peripheral in terms of hardware and software.
The communication module hardware implements the physical link from the transmission channel to/from the processing unit. The boundary of the hardware portion of the module is formed by a register interface.
The communication module software is divided into a number of functional blocks. The processing unit peripherals need to be initialised in order to allow for communication at all. Initialisation is performed by the initialisation software portion of the communication module software. The driver software is the portion of the overall communication software which accesses the register interface of the communication module hardware and exchanges data between the communication interface and processing unit internal memory. The driver software is active after initialisation while data is communicated in an error free manner. Application software operates upon data held in the processing unit internal memory after reception and provides data to the processing unit internal memory for transmission. The error software of the communication module software acts on the occurrence of an error in data transmission while signalling such a condition to the application software and allowing the communication software to recover from error affected conditions.
Currently available processing units (e.g. legacy microcontroller devices, dedicated communication peripheral ICs, . . . ) implement for each communication module hardware which is specific to the communication interface in all respects. This approach demands for specific software for each communication channel on initialisation, driver, and error level. Consequently, the engineering effort for implementing and testing communication software as well as program memory requirement grows in a manner proportional to the number of communication interfaces supported. Aiming to reduce the engineering effort and program memory requirement demands for a new approach of communication module interface.
FIG. 1 shows a typical example of a prior art system. The system has communication interfaces I, II, . . . N (CI1, CI2, CIN). Each of the communication interfaces has its dedicated communication interface I, II, . . . N specific register interface (SRI1, SRI2, SRIN). Likewise, each of the communication interfaces I, II, . . . N has a dedicated driver software I, II, . . . N (SDS1, SDS2, SDSN) which communicates with the communication interface I, II, . . . N specific register interface (SRI1, SRI2, SRIN). The driver software (SDS1, SDS2, SDSN) for communication with a specific communication interface (CI1, CI2, CIN) is invoked by the application software (AS) which has a communication interface independent call routine for the required communication. The realization of specific register interfaces (SRI1, SRI2, SRIN) for each communication interface (CI1, CI2, CIN) and the programming of dedicated driver software (SDS1, SDS2, SDSN) is expensive both in terms of time and cost.
USPTO Backgrounds
USPTO Backgrounds