EP2067099A2

EP2067099A2 - Method of managing the software architecture of a radio communication circuit, corresponding application, computer program product and circuit

Info

Publication number: EP2067099A2
Application number: EP07803445A
Authority: EP
Inventors: Erwan Girard; José LOURENCO
Original assignee: Wavecom SA
Current assignee: Sierra Wireless SA
Priority date: 2006-09-12
Filing date: 2007-09-12
Publication date: 2009-06-10
Also published as: US20090318078A1; WO2008031855A2; FR2905819A1; US8127064B2; WO2008031855A3; FR2905819B1

Abstract

The invention relates to a method of managing the software architecture of a radio communication circuit, this software architecture comprising a radio communication software stack and at least one client application. The radio communication software stack comprising a radio communication interrupt manager (1) and at least one radio communication task (2 to 4). The client application comprising at least one client task. The method comprises a step of intercalating, within the radio communication software stack, at least one client interrupt manager, included in the client application, and belonging to the group comprising: a first client interrupt manager of execution priority level that is higher than said at least one radio communication task (2 to 4) and lower than the radio communication interrupt manager (1); and a second client interrupt manager of execution priority level that is higher than said at least one radio communication task (2 to 4) and higher than said radio communication interrupt manager (1).

Description

A method of managing the software architecture of a corresponding radio communication circuit, application, computer program product and circuit. 1. DOMAIN OF THE INVENTION

The field of the invention is that of radiocommunication systems using interrupts, corresponding to asynchronous events, to ensure the physical synchronization between different radiocommunication devices.

Radiocommunication devices (also known as radio communication terminals or wireless terminals) are any device or means capable of exchanging signals using a radio communication system, for example installed in machines or vehicles ( M2M markets, for "Machine to

Machine ", and automobile).

The field of application of the invention covers any cellular radio technology (GSM, 3G, 4G, DECT, CDMA, Wi-Max ...) or point-to-point (Wifï, Bluetooth, Zigbee ...). More specifically, the invention relates to a management technique of the software architecture of a radio communication circuit, in the case where this software architecture comprises a radio communication software stack supporting the execution capacity of at least one client application, that is to say third-party code by comparison with the code of the main radiocommunication application (fimware) which manages the radiocommunication software stack (GSM stack for example).

The invention applies in particular, but not exclusively, in the case where the radiocommunication circuit is an electronic radiocommunication module intended to be integrated into a radiocommunication device. This is for example a module of the family "WISMO" (registered trademark) of the company WAVECOM (applicant for this patent application). The WAVECOM company has indeed for several years proposed an approach overcoming a number of these disadvantages, consisting in grouping together in a single module (called electronic radio communication module), all or at least most of the functions of a digital radiocommunication device . Such a module is in the form of a single housing, preferably shielded, that the device manufacturers can implement directly, without having to take into account a multitude of components. This module (sometimes called "macro component") is indeed formed of a grouping of several components on a substrate, so as to be implanted in the form of a single element. It includes the essential components (including a processor, memories, and software) necessary for the operation of a radiocommunication device using radio frequencies. So there are no more complex stages of design design, and validation of it. All you have to do is reserve the necessary space for the module. Such a module makes it possible to easily, quickly and optimally integrate all the components in wireless terminals (mobile phones, modems, or any other device operating a wireless standard).

In an application variant of the invention, the radiocommunication circuit is not a radiocommunication module in the aforementioned sense but a printed circuit included in a radiocommunication device and on which are directly implanted a set of electronic components whose purpose is to provide the various radiocommunication functions necessary, since the reception of a signal

RF until the generation of an audible signal (in the case of a radio-telephone), and vice versa. 2. PRIOR ART

Radiocommunication circuits are known in the prior art for embedding client applications.

As only illustrative, the disadvantages of the prior art are presented below in the case where the radiocommunication circuit is an electronic radiocommunication module. This is for example a module of the family "WISMO" (registered trademark) implementing the concept "Open AT" (registered trademark) of the company WAVECOM (applicant for this patent application). It is clear that these disadvantages can be transposed to the case of the aforementioned application variant.

According to a first known technique, no real time capacity is provided for the client application embedded on the radiocommunication module. In fact, in a radiocommunication module, the execution of a radio communication software stack (GSM / GPRS stack for example) requires real-time responses to interruptions from the radio part of the platform of this module. radiocommunication (GSM / GPRS platform for example). If the module does not take into account this interruption in a very limited time, it loses synchronization to the network. Therefore, the module is no longer able to make / receive calls, send / receive SMS, USSD ... For the record, and in the particular case of a GSM / GPRS stack, it is imperative to guarantee the its operation in the following modes: disconnected: the module is not connected to the GSM / GPRS network and therefore can not switch from communication; idle (IDLE): the module is connected to the GSM / GPRS network. It is therefore in the capacity to receive, make calls, send / receive SMS, initiate a GPRS connection but does not use any of these possibilities; connected: the module passes / receives a call; sending / receiving SMS / USSD; GPRS transfer: the module sends / receives data on the GPRS link; - network search: the module lost synchronization with the network

(start / off cover ....) but is in search of network on which to synchronize.

Not knowing what impact the execution of the client application processes will have on the proper operation of their own radio communication software stack and therefore on the overall good functioning of their product, the radiocommunication module manufacturers (especially those destined for the M2M markets and automotive) therefore do not provide their customers with the ability to ship processes whose real-time execution is critical to the proper functioning of the end product.

According to a second known technique, providers of radiocommunication software stack (GSM / GPRS / EDGE / 3G stack for example) provide a code that compiles and runs on an associated platform (GSM / GPRS platform for example) makes it possible to make / receive calls. Calls ... These software solution providers thus allow their clients to execute very low level code, which could therefore allow the integration of processes whose execution in real time is critical. But in no case do they guarantee that the radio communication software stack will work properly. In addition, this implies a very great complexity of design of the client application and therefore a very strong expertise in the field of radiocommunications (GSM / GPRS for example).

For these reasons, this second alternative technique is difficult to use, especially by customers of M2M markets and even more so of any non-expert person both in the final application area of the global product and in the telecommunications field, in particular GSM / GPRS technologies.

As a result, the majority of software architectures for embedding external code on a wireless platform are in accordance with the first known technique and are defined in the manner described in FIG. 1. This software architecture typically comprises a radio communication software stack (in the example of FIG. 1, a GSM stack) comprising: a GSM Stack IT Handler 1, which provides physical link services and synchronize with the GSM network. It corresponds to the GSM physical layer; a set of tasks 2 specific to the GSM stack ("GSM Stack Tasks L1-L3"), divided into layers (Li a L3), and which provide a control service and logical link ("Logical Link and Control Service"). In the GSM standard, it corresponds to L1 / L2 / L3, RR / LAPD / MM / CCRLC /

MAC / LLC / SNDCP / SM; a set of tasks 3 related to AT commands ("GSM AT Commands Task"), which provide a service of control of the GSM stack. In the GSM standard, it corresponds to the Application layer; and a task 4 called "IdIe Task" or "Background task" which executes when no other task requests the CPU resource.

This software architecture further comprises a client application 5 (in this example an "Open AT" application), comprising a set of client tasks. Within the GSM stack, this client application 5 is positioned between the set of tasks 3 linked to AT commands and the background task 4. The arrow referenced 6 indicates an indicative reaction time axis (from about 1 ms to 1 ms). at about 10 ms). The arrow referenced 7 indicates a priority level axis (from background task 4, which has the lowest priority, to the radiocommunication interrupt manager 1, which has the highest priority).

This software architecture can also be broken down into two domains: an interrupt management domain 8, in which is included the radiocommunication interrupt manager 1; and a task management domain 9, in which all the aforementioned tasks are understood (tasks 2 specific to the GSM stack, tasks 3 linked to AT commands, background task 4 and tasks of the client application 5). Thus, with this structure, any client application can be executed by the module while ensuring the smooth operation of the GSM / GPRS stack. However, no real-time capability can be guaranteed to this client application.

Currently, as illustrated in FIG. 2, a processor (not shown) internal to the module 24 executes a main radiocommunication application 24 which manages the radio communication software stack (GSM stack for example). In order to overcome the lack of real-time capacity for the client application 25 also executed by the module (thanks to the aforementioned internal processor), it is necessary to use and implement on the motherboard 21 of the radiocommunication device, a processor additional 22

(For example a microcontroller) and an additional memory 23, which are external to the radiocommunication module 24 and allow to execute client processes whose real time execution is critical. In addition, in this example, the microcontroller 22 is connected to a connector 26 of external devices, via I / O interfaces of various uses (GPIOs) 27, Serial interfaces of the SPI (Serial Peripheral Interface) type.

(SPI1, SPI2) 28 and 29, a USB interface 210 and a link carrying interrupts (IT) 211.

These additional elements (microcontroller and memory) increase the complexity and manufacturing cost of the radiocommunication device.

There is therefore a need to offer a real-time capacity for the client application executed by the module, in order to do without the need to use an additional processor and additional memory external to the radiocommunication module. 3. OBJECTIVES OF THE INVENTION

The invention, in at least one embodiment, is intended in particular to overcome these various disadvantages of the state of the art.

More precisely, one of the objectives of the present invention, in at least one embodiment, is to provide a technique for managing the software architecture of a radio communication circuit, making it possible to execute a client application foreign to the radiocommunication stack, at a very high priority (which allows to execute processes whose real-time execution is critical), while ensuring the proper functioning of this radiocommunication stack. The invention also aims, in at least one embodiment, to provide such a technique, which is simple to implement and inexpensive.

Another object of the invention, in at least one embodiment, is to provide such a technique, which makes it possible to dispense with the need to use an additional processor and a supplementary memory, external to the radiocommunication circuit.

An additional objective of the invention, in at least one embodiment, is to provide such a technique, which can be implemented regardless of the amount of processing involved in the execution of the client application.

SUMMARY OF THE INVENTION In a particular embodiment of the invention, there is provided a method for managing the software architecture of a radio communication circuit, said software architecture comprising a radio communication software stack and at least one client application, said radio communication software stack comprising a radio communication interrupt manager and at least one radiocommunication task, said client application comprising at least one client task. The method comprises a step of interleaving, within said radio communication software stack, at least one client interrupt manager, included in said client application, and belonging to the group comprising: a first level client interrupt manager a higher execution priority than said at least one radiocommunication task and less than said radiocommunication interrupt manager; a second execution priority level client interrupt handler higher than said at least one radio communication task and higher than said radio communication interrupt handler.

The general principle of the invention therefore consists in defining a new software architecture, by adding within the radiocommunication stack at least one client interrupt manager, having a level of execution priority that is lower or higher than that of the manager of the client. radiocommunication interruptions, and higher than that of radiocommunication tasks. In other words, through the client interrupt manager, client application developers (intended to be executed by the circuit) are offered access to low-level hardware resources in order to respect the first critical time constraints ( for example a reaction time of less than 1 ms). Thus, it is ensured that the client application can process interrupts in real time, without endangering the proper functioning of the radio communication stack. Advantageously, said client application comprises at least two subsets of client task (s), each of which comprises at least one client task. In addition, the method comprises a step of managing said at least two subsets of client task (s) allowing, within said radio communication software stack, to separate said at least two subsets of client task (s) by at least one radiocommunication task.

For example, within the task management domain (part of the task stack), some client tasks have a higher execution priority level than others, which allows these client tasks to be executed in the same way. respecting second critical time constraints (for example a reaction time of between 1 ms and 10 ms), less than the aforementioned first ones.

Advantageously, at least one of said subsets of client task (s) comprises a particular client task forming a third client interrupt manager receiving at least one interrupt via at least one of said first and second interrupt handlers. client or another third client of higher priority execution level client interrupts than said third client interrupt manager. Thus, a client application may include several client interrupt handlers, having different levels of execution priority and interposed, within the radio communication stack, between different radio communication tasks.

These client interrupt handlers are cascaded, sending out interrupts (in the decreasing direction of the execution priority levels).

Advantageously, said client interrupts belong to the group comprising: client interrupts external to said radiocommunication circuit; and client interrupts internal to said radio communication circuit, including interrupts from a clock register included in said radio communication circuit.

According to an advantageous characteristic, the maximum execution time of at least one critical process necessary for the design of at least one of said first and second client interrupt managers and / or at least one of said client tasks is predetermined.

In an advantageous embodiment of the invention, the method comprises a step of controlling the execution time of at least one of said first and second client interrupt managers and / or at least one of said client tasks, to ensure that the said duration of execution does not exceed a specified maximum duration.

In a particular embodiment of the invention, said circuit is an electronic radiocommunication module intended to be integrated into a radiocommunication device.

In another embodiment, the invention relates to a computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor. This computer program product includes program code instructions for performing the steps of the aforesaid method, when said program is run on a computer.

In yet another embodiment, the invention relates to a radio communication circuit comprising means for managing a software architecture comprising a radio communication software stack and at least one application. client, said radio communication software stack comprising a radiocommunication interrupt manager and at least one radiocommunication task, said client application comprising at least one client task. The circuit comprises means for interleaving, within said radio communication software stack, at least one client interrupt manager, included in said client application, and belonging to the group comprising: a first level client interrupt manager a higher execution priority than said at least one radiocommunication task and less than said radiocommunication interrupt manager; a second execution priority level client interrupt manager higher than said at least one radiocommunication task and higher than said radiocommunication interrupt manager. The aforementioned various interleaving means are, for example, software elements resulting from the execution, by a processor included in the circuit, of a main radiocommunication application (generally called "fimware").

More generally, the circuit according to the invention comprises means for implementing the management method of the software architecture, as described previously (in any one of its various embodiments). 5. LIST OF FIGURES Other features and advantages of embodiments of the invention will appear on reading the following description of a preferred embodiment of the invention, given by way of indicative and nonlimiting example ( all the embodiments of the invention are not limited to the features and advantages of this preferred embodiment), and the appended drawings, in which: FIG. 1 shows a known software architecture, of a GSM stack supporting the Execution capacity of a client application, without real time capacity for this client application; FIG. 2 shows a radiocommunication device according to the prior art, comprising a radiocommunication module having a software architecture according to FIG. 1; FIGS. 3A, 3B, and 3C each have a software architecture according to a first, a second and a third particular embodiment of the invention respectively, of a GSM stack supporting the execution capacity of a client application, with real-time capacity for this client application; FIG. 4 shows a particular embodiment of a radiocommunication device according to the invention, comprising a radiocommunication module having a software architecture according to any one of FIGS. 3A, 3B or 3C; and FIG. 5A illustrates an example of use of the exemplary software architecture according to the invention of FIG. 3A; FIG. 5B illustrates an example of use of the example of software architecture according to the invention of FIG. 3B. 6. DETAILED DESCRIPTION

In all the figures of this document, identical elements are designated by the same reference numeral.

Figures 1 and 2 relate to the prior art and have already been described above.

With reference to FIG. 3A, a software architecture according to a first particular embodiment of the invention is now presented, of a GSM stack supporting the execution capacity of a client application, with real time capacity for this purpose. client application.

In this first particular embodiment, the invention consists in providing the users of the "OPEN AT" environment with the ability to execute foreign code to the GSM / GPRS stack (that is to say a client application). on a GSM / GPRS hardware platform, at a very high priority (which allows real-time execution of critical processes), while ensuring the proper functioning of the GSM / GPRS stack in different aforementioned modes.

It is recalled that the concept "OPEN AT" is such that, in addition to the main radiocommunication application which manages a radio communication software stack (GSM stack for example), a radiocommunication module (for example of the "WISMO" family) runs at least one client application. In this first particular embodiment of the invention, the software architecture comprises a GSM stack and a client application.

The GSM stack is conventional and identical to that already described above in relation with FIG. 1. It thus comprises a radio communication interrupt manager 1 ("GSM Stack IT Handler"), a set of tasks 2 specific to the stack. GSM ("GSM Stack Tasks L1-L3"), a set of tasks 3 related to AT commands ("GSM AT Commands Task") and a background task 4.

On the other hand, the client application of FIG. 3 differs from that of FIG. 1 in that it is not a monoblock but comprises: a first client interrupt manager (Open AT IT Handler No. 1)

31, managed to be interposed between the radiocommunication interrupt manager 1 and the set of tasks 2 specific to the GSM stack; a particular client task forming a second client interrupt handler (Open AT IT Handler # 2) 32, managed to be interposed between the set of tasks 2 specific to the GSM stack and the set of tasks 3 related to AT commands; and a set of client tasks ("Open AT Tasks Application Tl ... T5), managed to be interposed between the set of tasks 3 related to AT commands and the background task 4.

With respect to the architecture of the prior art described in FIG. 1, this architecture enables the client to execute code at the first and second client interrupt managers referenced 31 and 32.

It is clear that different variants of this example can be considered: with a single client interrupt handler or with more than two client interrupt handlers, and / or with the client interrupt handler (s) interposed differently in the GSM stack, especially as illustrated in connection with Figures 3B and 3C.

Execution of the code implemented in these first and second client interrupt handlers is triggered by an interrupt, which may be external to the module, or internal for the hardware timer. This allows the execution real-time asynchronous processes. The advantage of this solution is the inter-correlation between on the one hand taking into account the real-time needs of the GSM stack to remain synchronized to the network and on the other hand real-time execution needs of any what kind of client processing (which can be very heavy), without jeopardizing this synchronization to the network.

In addition, the maximum execution time of the critical processes necessary for designing the code to be executed at the first and second client interrupt handlers 31, 32 and client tasks 33 is predetermined. For example: - the duration of non-interruptibility (interrupt latency);

- scheduling time ("scheduling time");

- write time in non-volatile memory;

- The allocation time of a storage area in volatile memory;

- value acquisition positioning time on the BUS and GPIOs of the platform;

- switching time between active (normal) and inactive (sleep) modes;

- switching time between standard (26MHz) and 104MHz Boost modes;

A software architecture according to a second particular embodiment of the invention, a GSM stack supporting the execution capacity of a client application, with real-time capacity for this application, is now presented in connection with FIG. 3B. customer.

Unlike the client application of the first embodiment, the client application of the second particular embodiment comprises: a first client interrupt manager (Open AT IT Handler No. 1) 310, managed so as to have a higher priority level of execution than the radiocommunication interrupt manager 1; a particular client task forming a second client interrupt handler (Open AT IT Handler # 2) 32, managed to be interposed between the set of tasks 2 specific to the GSM stack and the set of tasks 3 related to AT commands; and a set of client tasks ("Open AT Tasks Application Tl ... T5), managed to be interposed between the set of tasks 3 related to commands

AT and the background task 4.

Thus, the software architecture according to this second particular embodiment differs from that according to the first particular embodiment of FIG. 3A in that the first client interrupt manager (Open AT IT Handler No. 1) 31 has a higher priority level than the radio interrupt handler 1.

Consequently, in this second particular embodiment, the users of the environment "OPEN AT" have the capacity to execute code foreign to the stack

GSM / GPRS (ie a client application) on a hardware platform

GSM / GPRS, at a higher priority level than the GSM / GPRS stack (which allows real-time execution of critical processes), while ensuring the proper functioning of the GSM / GPRS stack in the various modes mentioned above.

The other operating characteristics remain identical to those described in the presentation of the software architecture of the first embodiment in relation with FIG. 3A.

FIG. 3C shows a software architecture according to a third particular embodiment of the invention, a GSM stack supporting the execution capacity of a client application, with real time capacity for this application. customer.

The software architecture according to this third particular embodiment integrates a first 320 and a second 330 client interrupt managers each having a higher priority level of execution than the set of tasks 2 specific to the GSM stack.

Thus, unlike the client application of the first and second particular embodiments of the invention, the client application of FIG. 3C comprises: a first client interrupt manager (Open AT IT Handler No. 3) 330 managed to have a higher priority level of execution than the radio interrupt handler 1; a second client interrupt manager (Open AT IT Handler No. 1) 320, managed to be interposed between the radio communication interrupt manager 1 and the set of tasks 2 specific to the GSM stack; a particular client task forming a third client interrupt manager (Open AT IT Handler # 2) 32, managed to be interposed between the set of tasks 2 specific to the GSM stack and the set of tasks 3 related to AT commands; and a set of client tasks ("Open AT Tasks Application Tl ... T5), managed to be interposed between the set of tasks 3 related to AT commands and the background task 4.

Thus, with this software architecture, a user can use the first client interrupt handler (Open AT IT Handler # 3) 330 and the second client interrupt handler (Open AT IT Handler # 1) 320, following the Interrupt response time sought. Thus, for example, if the user wishes to obtain a response time of less than 20 μs, he will be able to integrate the code of the client application into the first client interrupt manager 330, and if he is satisfied with response time by ims example (other values can also be envisaged, for example 600 μs), it can have the code of the client application in the second client interrupt manager 320.

We now present, in connection with Figure 4, a particular embodiment of a radio communication device according to the invention.

It comprises a motherboard 41 on which are implanted a radiocommunication module 44 having a software architecture according to any one of FIGS. 3A, 3B or 3C, obtained by execution by a processor (not represented) of: a main radiocommunication application 42 which manages the radio communication software stack (GSM stack for example) and allows the implementation of the method of the invention, to obtain the software architecture of the invention (in which the client application is distributed within of the pile); and a client application 45 whose different parts are distributed within the GSM stack, as detailed above in relation to any one of FIGS. 3A, 3B or 3C.

Since real-time capacity is available to the client application 45, no additional element (neither microcontroller nor memory) external to the module is needed on the motherboard 41.

Furthermore, the radiocommunication module 44 is connected to a connector 26 of external devices, via the same interfaces and links as those already described in Figure 2 (between the same connector 26 and the external microcontroller 22). An example of use of the software architecture example according to the invention of FIG. 3A is now presented in relation to FIG. 5A. This example relates to: the acquisition of a current value by a sensor in a limited and bounded time, time after which the value raised by the sensor has no value (for example 2 ms); the sensor positioning an interruption at the precise moment when the value is available. this value (measurement) is acquired for the calculation of the instantaneous consumption, the average over several days and storage of the result in memory asynchronously. these computation and storage operations will have to be done at each interruption positioned by the sensor and this independently of the GSM modes in which the module is. weekly, the complete system sends by GPRS the complete measurement report (including for example several hundreds of one-off measurements).

We distinguish the following stages:

1. Detection of an interrupt positioned by the sensor signifying that the measurement is ready to be acquired on any bus of the platform.

2. Triggering the customer code intended to acquire this measure in a guaranteed time of less than 2ms (otherwise the measurement has no value), this code being executed at the first interrupt handler (Open AT IT Handler # 1).

3. Acquisition in the first client interrupt manager (Open AT IT Handler n ° 1) of the measurement and storage in volatile memory (very fast process, a few μs).

4. Notification by the first interrupt handler (Open AT IT Handler # 1) to the second Client Interrupt Manager (Open AT IT Handler # 2) that the measurement was acquired and stored in volatile memory at a given location . 5. Awakening of the second Client Interrupt Manager following the measurement notification sent by the first interrupt handler. Acquisition of instantaneous value and execution of instantaneous and average consumption calculations in the second client interrupt manager (Open AT IT Handler n ° 2). Storing the results of these calculations in flash memory (very long operations, several hundred ms).

6. Return to a "normal" state: interrupt waiting for instantaneous value acquisition.

7. Every week, when the alarm that the Open AT Application Tasks Tl client task has set to "1 week" is triggered, this task (Open AT Application Tasks Tl) will look at the defined location of the report. complete which has been acquired, formatted and stored by the second interrupt handler following the instantaneous measurements acquired in a limited time by the first interrupt handler. 8. Once the report is acquired, the Open AT client task initiates a connection

GPRS and sends the report and deletes it from the memory once the sending is completed. It is possible that during this phase the first and second managers interrupt these tasks ("OPEN AT Application Task Tl" and "GSM Stack Tasks") to acquire new values). The actions described in steps 7 and 8 are synchronous (they are repeated in a predictive way: every week, once a week) and do not require no real-time case since receiving the report on a weekly basis by the client infrastructure within plus or minus 2 minutes makes absolutely no difference to the quality of the report and its subsequent operation. Thus these actions are executed by the low priority task (Open AT Application Tasks Tl). Conversely, the quality of the report depends on the quality of the instantaneous measurements which are valid only if acquired in less than 2 ms. Here we need guaranteed response time. This is why measurements are acquired by the first interrupt handler (Open AT IT Handler # 1).

Finally sending the report by GPRS could change the acquisition time of this instant measurement because it makes work the GSM stack. In this, the client needs the real-time architecture proposed by the invention because it alone can guarantee the quality of its measures regardless of the action that the system undertakes.

If these operations 1 to 8 are performed in disconnected mode, they are done sequentially since the GSM / GPRS battery does not turn. If the module is in one of the specified higher modes (whatever it is), the step

2 is guaranteed because the software architecture according to the invention ensures that the processing of an interruption ("GSM IT") coming from the radio part of the module does not last more than lms whatever the mode in which the module is.

Step 3 (processing the customer interrupt "EXT ITl") will only start when the interrupt coming from the radio part ("GSM IT") will be processed, or this step 3 will be interrupted by the processing of this interruption . This ensures that synchronization with the network is maintained regardless of the asynchronous processing to be performed in real time by the client application. In addition, the manufacturer of the module guarantees the maximum time required to allocate a storage area in volatile memory regardless of the GSM status of the module. This ensures that the measurement can be stored less than 2ms after the triggering of the interruption notifying the need for the acquisition of this measurement.

Step 4 (processing of the "EXT IT2" client interrupt) will only begin when the tasks of the GSM / GPRS stack have performed the operations necessary to maintain the voice call, send / receive data on the GPRS link of sending an SMS, USSD .... This cutting in terms of task thus makes it possible to execute real-time processes regardless of the state of the GSM / GPRS part, while ensuring that the stack functions properly.

Optionally, a check process ensures that the client code in each of the first and second client interrupt handlers (Open AT IT

Handler # 1 and 2) does not run for too long.

From now on, with reference to FIG. 5B, an example of use of the example of software architecture according to the invention of FIG. 3B is presented.

In this example, it is assumed that a succession of tasks is executed by the radiocommunication module 44.

Thus, the following steps can be distinguished: detection and processing of a first "GSM IT" interruption 51 from the radiocommunication interrupt manager 1 ("GSM Stack IT Handler"). The software architecture according to the invention ensures that the processing of an interrupt from the radio portion of the module does not last more than lms; detecting and processing a first "EXT IT 1" client interrupt 52 from the first client interrupt handler ("Open AT IT Handler # 1") 310, a time elapsed between the end of the processing of the client first "GSM IT" interruption 51 and the detection of the first "EXT IT 1" client interrupt 52; detecting and processing a second "GSM IT" radiocommunication interruption 53 from the radiocommunication interrupt manager 1; detection and processing of a second "EXT IT 1" client interrupt 54 from the first client interrupt handler 310. The processing of the second "GSM IT" radiocommunication interrupt 53 is suspended in favor of the processing of the second interruption customer "EXT IT 1" 54 more priority. When the processing of the second client interrupt "EXT IT 1" 54 is completed, the processing of the second radiocommunication interruption

"GSM IT" 53 resumes its term; detecting and processing a third "EXT IT 1" client interrupt 55 from the first client interrupt handler 310. During the processing of the third "EXT IT 1" client interrupt 55, a third "GSM IT" radiocommunication interruption 56 is detected. However, the processing of this third "GSM IT" radio interrupt 56 will not begin until the processing of the third customer interrupt "EXT IT 1" 55 is completed. Thus, it may happen that certain radiocommunication interruptions from the radiocommunication interrupt manager 1 are shifted in time in favor of client interrupts from the first priority client interrupt manager 310.

Claims

A method for managing the software architecture of a radio communication circuit (44), said software architecture comprising a radio communication software stack and at least one client application (45), said radio communication software stack comprising an interrupt manager radiocommunication

(1) and at least one radiocommunication task (2 to 4), said client application comprising at least one client task, characterized in that the method comprises an interleaving step, within said radio communication software stack, of at least one client interrupt manager, included in said client application, and belonging to the group comprising: a first execution priority level client interrupt manager (31; 320) higher than said at least one radiocommunication task (2 to 4) and less than said radiocommunication interrupt handler

(i); a second execution priority level client interrupt manager (310; 330) higher than said at least one radiocommunication task (2 to 4) and higher than said radiocommunication interrupt manager

(I) -

2. Method according to claim 1, characterized in that said client application (45) comprises at least two subset of client task (s), which each comprise at least one client task, and in that the method comprises a step managing said at least two sub-set of client task (s) allowing, within said radio communication software stack, to separate said at least two subsets of client task (s) by at least one radiocommunication task.

Method according to claim 2, characterized in that at least one of said subsets of client task (s) comprises a particular client task forming a third client interrupt handler (32) receiving at least one interruption via at least one of said first and second client interrupt handlers or another third higher priority execution level client interrupt handler than said third client interrupt handler.

4. Method according to any one of claims 1 to 3, characterized in that said client interrupts belong to the group comprising: client interrupts external to said radiocommunication circuit; and client interrupts internal to said radio communication circuit, including interrupts from a clock register included in said radio communication circuit.

5. Method according to any one of claims 1 to 4, characterized in that the maximum duration of execution of at least one critical process required for the design of at least one of said first and second client interrupt managers and / or at least one of said client tasks is predetermined.

6. Method according to any one of claims 1 to 5, characterized in that it comprises a step of controlling the execution time of at least one of said first and second client interrupt managers and / or at least one of said client tasks, to ensure that said execution time does not exceed a specified maximum duration.

7. Method according to any one of claims 1 to 6, characterized in that said circuit is an electronic radiocommunication module (44) intended to be integrated with a radiocommunication device.

8. Computer program product downloadable from a communication network and / or recorded on a computer-readable medium and / or executable by a processor, characterized in that it comprises program code instructions for the execution of the steps method according to at least one of claims 1 to 7, when said program is run on a computer.

A radio communication circuit (44) comprising means for managing a software architecture comprising a radio communication software stack and at least one client application (45), said radio communication software stack comprising a radio communication interrupt manager (1). ) and at least one radiocommunication task (2 to 4), said client application comprising at least one client task, characterized in that the circuit comprises interleaving means, within said radio communication software stack, of at least one client interrupt manager, included in said client application, and belonging to the group comprising: a first interrupt manager (31); ; 320) a client of a higher priority level than said at least one radiocommunication task (2 to 4) and less than said radiocommunication interrupt manager;

(i); a second execution priority level client interrupt manager (310; 330) higher than said at least one radiocommunication task (2 to 4) and higher than said radiocommunication interrupt handler

(1).

A radio communication circuit according to claim 9, characterized in that said client application (45) comprises at least two subsets of client task (s), each of which comprises at least one client task, and in that the circuit comprises means for managing said at least two sub-set of client task (s) allowing, within said radio communication software stack, to separate said at least two subsets of client task (s) by at least one radiocommunication task .

11. Radiocommunication circuit according to claim 10, characterized in that the means for executing at least one of said client task subsets (s) include means for executing a particular client task forming a third manager client interrupts (32) receiving at least one interrupt received through at least one of said first and second client interrupt handlers.

Radiocommunication circuit according to any one of claims 9 to

11, characterized in that said client interrupts belong to the group comprising: client interrupts external to said radiocommunication circuit; and client interrupts internal to said radio communication circuit, including interrupts from a clock register included in said radio communication circuit.

Radiocommunication circuit according to one of claims 9 to

12, characterized in that the maximum execution time of each critical process required for the design of at least one of said first and second client interrupt handlers and / or at least one of said client tasks is predetermined.

14. Radiocommunication circuit according to any one of claims 9 to

13, characterized in that it comprises means for controlling the execution time of at least one of said first and second client interrupt managers and / or at least one of said client tasks, making it possible to ensure whereas the said duration of execution does not exceed a specified maximum duration.

15. Radiocommunication circuit according to any one of claims 9 to

14, characterized in that it is an electronic radiocommunication module (44) intended to be integrated with a radiocommunication device.