Vincent Morice
email: vincent.morice@univ-grenoble-alpes.fr

Florence Maraninchi
email: florence.maraninchi@univ-grenoble-alpes.fr

Jérôme Cornet
email: jerome.cornet@st.com

Towards A Power Advisor in a Devkit for Internet-of-Things Microcontrollers

Keywords: Transaction-Level Modeling, IoT, Power Consumption, DevKit

Microcontrollers (MCUs) for the Internet-of-Things (IoT) are powerful and versatile computing platforms, which may be hard to program correctly and efficiently; power performance is particularly important. We inestigate automatic methods to detect software performance anti-patterns for this class of systems, so as to help the software developer with power-related aspects. We use a virtual prototype, i.e., we execute the real object code on a simulated model of the hardware platform, given as a transaction-level model (TLM) augmented with dedicated monitors. We study two cases taken from an industrial example, and show that our method can help detect patterns that would be difficult to detect statically, even when the source code is available, because they involve the state of the hardware and the timing of operations.

INTRODUCTION 1.IoT Chips

The STM32WB (STMicroelectronics), the CC2540 (Texas Instrument), the BM70 (Microchip), or the QN9080 (NXP), are powerful and versatile microcontrollers units (MCUs), containing one or more CPUs (like ARM-Cortex series) and integrated with various sensors, actuators, and connectors, designed with power performance in mind. They may be powered by a battery and offer sophisticated clock and power modes. The difficulty to write good software for those platforms is a known problem in the industry: software should exploit the capabilities of the hardware correctly (respecting its specification), efficiently (consuming as little power as possible), and securely (resisting attacks). In this paper we focus on power efficiency. Dealing with numerous sensors makes this type of HW/SW platform a cyber-physical system (CPS): some knowledge about the physical environment can help build efficient solutions, for instance by selecting appropriate refreshment rates for sensors. A thorough understanding of the computing platform is needed in order to guarantee power performance, because a very small variation in the software can have tremendous effects on the consumption, and therefore the lifetime of the IoT object. In one of the examples below (see 2.1.2), the lifetime increases from approximately 3 days to approximately 8 months with a 700 mAh battery. * Also with STMicroelectronics, 38019, Grenoble, France.

Methods and Tools for the Software Developer

Difficulties to write efficient and correct software can be tackled in various ways. Let us consider the pros and cons of each solution.

(1) Careful reading of the source code by experts: requires high expertise, not necessarily available at the customer site, and access to the source code, not always available for libraries.

(2) Using some Hardware-Abstraction-Layer (HAL) provided by the vendor: helps avoiding bugs and writing portable code; but it is sometimes counter-productive as far as power efficiency is concerned.

(3) Using interactive debugging tools like GDB for the software running on the real chip: requires heavy human interaction and may fail to correct power consumption or timing problems because they are due to the invisible hardware states.

(4) Executing the software on some simulated (thus fully observable) model of the hardware: gives non-intrusive access to many details of the hardware platform that may be hard to observe on the real chip, while having a clear impact on power consumption, like the traffic on the bus or the power modes of the CPU; some vendors provide simulators for a partial view of their platform, like the configuration of the clocks.

(5) Applying data mining techniques to the automatic detection of patterns in execution traces [START_REF] Iegorov | Data Mining Approach to Temporal Debugging of Embedded Streaming Applications[END_REF]: relies on the availability of a large number of traces, and algorithms to search those large data sets; it is not meant for a monitoring (incremental) implementation.

(6) Automatically detecting software (anti-)patterns [START_REF] Smith | Software performance antipatterns[END_REF]: can identify critical points quickly in a large number of code lines, but these points are not necessarily bugs or actual problems in real executions; it was first proposed for object-oriented development; it is more difficult on less-structured low-level code.

Exploiting Virtual Prototypes

We focus on power performance: the MCU or the sensors provide several modes that influence power, which makes it very hard to talk about power at a syntactical level; we need to look at the dynamic behavior.

Our goal is to explore a solution of type (4) above. It relies on a virtual prototype of the platform, given as a Transaction-Level Model (TLM). Virtual prototypes in the form of TL models started almost 20 years ago as tools to help hardware and software developers communicate, and also to allow for developing software before the hardware is indeed available [START_REF] Ghenassia | Transaction Level Modeling With SystemC: TLM Concepts And Applications for Embedded Systems[END_REF]; they are on the path to be a key aspect of the IoT ecosystem, providing developers with tools that help accelerate software development [START_REF] Magarshack | Accelerating IoT Device Development -from Silicon to Developer Tools, Keynote Speech[END_REF].

Our ultimate objective is to provide a development kit based on the TL model of a platform, extended with performance diagnosis capabilities. This kit will automatically warn the user about inefficient uses of the hardware, at execution time. Our aim is not only to diagnose inefficient uses, but also to provide the user with some advice for better code, hence smoothing the learning curve.

Contributions and structure of the paper

In Sections 2 and 3 we study a weather station based on a STM32F411 chip [START_REF][END_REF]. The code is a refactoring of a representative real industrial example from STMicroelectronics and partially uses the hardware abstraction layer provided by the company. The chip is mounted on a Nucleo-64 prototyping board [START_REF]Nucleo F411RE Board[END_REF] extended with a sensor expansion board including various sensors [START_REF]IKS01A2 Extension Board[END_REF]. We identify two classes of very common problems to be detected by monitors: polling loops, and inefficient use of sensors. we show why dynamic information is key to the detection of real problems, and we show how to choose specific events and patterns to observe in TL traces in order to find occurrences of those two problems. In Section 4 we give a quick view of the monitor implementation, and evaluate our solution. Sections 5 and 6 give related work and conclude.

CASE STUDY: POLLING LOOPS

The first example is about detecting polling loops because it is generally more costly than waiting for an appropriate interrupt if available. When using methods based on the structure of the code, it means detecting the pattern while(condition){};, either syntactically, or on the binary code. As far as power consumption is concerned, the cost comes from the CPU being active (while it could be sleeping), but also from the bus activity induced by the evaluation of the condition. We aim at detecting polling loops even if the corresponding code is spread across several layers of low-level code, part of it possibly available in binary form only. Moreover, we would like to warn only when they have a significant effect, which may depend on the effective number of passes in the loop: looping twice is probably harmless, but 50 times may be significant.

We give two examples: the first one has to be replaced by something more efficient; the second one can be kept as it is.

Example: a Delay implemented by a Polling Loop

2.1.1 Existing Code. In the first example, polling is used to wait for a certain delay, as shown on Figure 1. HAL_Delay() takes as a parameter the time to wait (Delay), saves the current time and starts the polling loop. uwTick is a global variable incremented on every SysTick timer interrupt. The timer is configured to fire its overflow interrupt every millisecond. This example is used in a weather station application whose main() function is shown on Figure 2: it reads the sensors, then prints the value using the UART and then waits for 800 ms using the HAL_Delay() function. The RTC also has to be initialized and its interrupt handler has to acknowledge the interrupt.

The STOP mode disables a lot of peripherals, including the MCU, the SysTick timer and the bus, in order to save power. According to the ST tool "STM32 CubeMX" [START_REF]STM32CubeMX[END_REF], which gives approximate power consumption related to those MCU states, implementing the wait process using the RTC and the STOP mode instead of the polling loop decreases the consumption from 8.5 mA to 0.12mA. When powered by a 700 mAh battery, the code modification can extend the lifetime of the system approximately from 3 days to 8 months.

Example: Unlocking Registers

Existing Code.

The second example (Figure 3) is a piece of code used to unlock access to the configuration registers of the wake-up timer. The manual [START_REF][END_REF] explicitly requires the software to implement this polling loop. The loop waits for the Wakeup Timer Writing Flag (WUTWF) to be set, indicating that other configuration registers can now be written. The Wakeup timer is a feature of the RTC component, so the left part of the condition checks for the WUTWF bit of the RTC Initialization and Status Register (ISR) using the macro READ_BIT(RTC->ISR,RTC_ISR_WUTWF).

In the real platform the wakeup timer has its own clock, different from that of the CPU, and the unlocking operation takes a few cycles of the wakeup timer's clock. The effective number of iterations depends on the relative speeds of the CPU's clock and the wakeup timer's clock. The faster the CPU's clock, the more loop iterations can be executed during the time it takes to perform the unlocking operation.

Keeping the Polling

Loop. This is a typical case of a harmless polling loop because the way the hardware is designed ensures a very small number of iterations (in our example, we observed 20 in the worst case). We use transaction-level models, which can be approximately timed with realistic assumptions on the duration of transactions. Hence simulations with such models also show a small number of iterations. This type of polling case can be ignored easily, by using a threshold on the number of iterations.

Characterizing and Detecting Polling Loops on TL Models

The first step is to characterize problematic polling loops by observing the dynamic behavior of the code. The idea is to focus on the actual effect of a polling mechanism, even if it is not written as a typical polling loop; or it is, but with harmless effects. The effect of a polling mechanism is characterized by some repetitive pattern being observed, and we can decide to issue a warning after a given number of repetitions. We propose to observe the sequence S of READ transactions issued on the bus. Section 4 explains what is indeed observable (not all variable accesses do generate bus transactions), and how to filter out other READ transactions (e.g., from interrupt handlers).

In the first example above, there are 3 variables in the condition of the loop: Delay, uwTick and tickstart. The latter is stored in a CPU register, hence does not generate bus transactions. There are only two addresses that appear in READ transactions; (HAL_GetTick() function calls also generate READ transactions, but this is not an issue as explained in section 4.) uwTick++ is filtered since it is executed in an interrupt handler.

In the second example there is only one access to a register of the RTC component that generates a READ transaction on the bus. Section 4 explains the instrumentation of the TL model, and shows how to detect the first case, while ignoring the second one.

The last important point is to characterize the repetitive patterns of READ transactions that are indeed issued on the bus for typical polling loops. For instance, if the code indeed contains a loop while(condition){};, each evaluation of the condition generates successive READ transactions, depending on the logical structure of the condition (in C the evaluation of cond1 && cond2 does not evaluate cond2 -hence does not access its variables -if cond1 is false). There is no cache between the CPU and the bus, so each access to a variable generates a transaction. Observing repeated accesses to the variables of cond1 is a hint that some polling situation might be involved, but it depends on which other accesses are observed between the accesses to the variables of cond1. Extracting also the variables of cond2 helps confirm that there is a polling case.

Formalizing Patterns

As an example, let us consider the dynamic behavior of a program that checks repeatedly a condition cond: ((a < 12)&&(a >= 0))||(b == 0)||(c == 0), either written exactly like that, or obtained with macros and calls to other software layers. Notice the same variable may appear several times in the condition.

The iterative evaluation of cond generates sequences of accesses of the form (a|aa|aab|aabc) * if all variables are observable (i.e., generate transactions on the bus) or simply (a|aa|aac) * if, e.g., b does not.

Since we do not know in advance which addresses a, b, c to look for when searching for polling loops, our problem is a parametric version of the above example: we search for (x|xy|xyz|xyzt|...) * , where x, y, z, t, ... can be instantiated with any address. The number of these "parameters" depends on the condition. It is not too restrictive to consider that it is bounded by a relatively small number P. In the sequel, we take P = 3 as an example (3 observable accesses). The problem becomes to check whether an execution trace is of the form: (x|xy|xyz) * for some x, y, z. For a given vocabulary V and m ∈ V * , we can define m ∈(x|xy|xyz) * as: ∃(a, b, c) ∈ V 3 .m ∈(a|ab|abc) * . If the vocabulary V where a, b, c belong is finite, this can be written as a simple regular expression, because ∃ can be expanded into ordinary alternatives: m ∈(x|xy|xyz) * ⇐⇒ m ∈ (a,b,c)∈V 3 (a|ab|abc) * .

Finally, we replace the * by [n,+∞] , to start warning about the presence of a polling loop only if it exceeds a number n of effective iterations. In order to validate quickly the idea of using monitoring techniques to detect polling loops, we implemented a simpler (yet very frequent) case without Boolean operations. Instead of searching instances of (x|xy|xyz) [n,+∞] , we search for x [n,+∞] | (xy) [n,+∞] | (xyz) [n,+∞] . See details in Section 4.

This example does not fully characterize all polling loops. For instance, instructions in the condition or the loop body (especially branching) can partially hide the repetition or produce a large number of repetitive addresses observed on the bus. Moreover, if we choose a very big P, we might end up detecting the infinite loop of the main program. However we think this is a promising approach, since it already detects a lot of typical polling loops in typical code samples. Further work will include more cases.

CASE STUDY: TEMPERATURE SENSOR

The second case-study concerns the use of the LPS22HB temperature sensor [START_REF]LPS22HB Temperature Sensor[END_REF], which has several operating modes: (1) In one-shot mode the software has to set the one-shot bit to ask for a new value to be measured and prepared; the bit will be cleared by hardware when the new value is available; (2) In auto-refresh mode the sensor can produce a new value with a given period chosen in {13, 20, 40, 100, 1000} milliseconds. If the application needs less than one value per second, or more than one every 13 ms, it should use the one-shot mode. In both modes the last measure is always available so that the software can read the value at any time. The idea of this example is to detect the uses of the one-shot mode that could be improved by using the auto-refresh mode instead. The one-shot mode can have a significant impact on the consumption, because it involves more transactions on the MCU bus: (1) the software sends the address of the control register of the sensor and the data ("1" on the one-shot control bit), (2) it sends the address of the temperature data register in order to read the value. The auto-refresh mode is far more efficient, since only step (2) is needed. Moreover a READ needs two distinct accesses to two 8-bit registers containing the MSBs and the LSBs of the temperature value.

Example

Existing Code.

Our application uses the one-shot mode (see 4). The bit is set (Set_One_Shot), requiring a new measure; next time the function will be called, it will access the value (Get_Temp) and get this new measure. In our example, the function is called approximately each 800ms (see main code on Figure 2).

Proposed Modification.

The alternative implementation is to use the auto-refresh mode, as shown on Figure 5. The autorefresh period is set in the init() function called at startup in the main() function. The idea is to choose a period close to the delay D implemented by the application (800ms in our case). If we do not have the full source code, or because it is hard to analyze statically anyway, D can be estimated dynamically by looking at the TL traces. On this example we choose 100ms.

The cost of one bus transaction alone is very hard to estimate, so the power consumption of the main() function (Fig. 2) has been measured on the board with the initial and modified versions of the EnvSensor_GetTemperature() function and our proposed modification for the HAL_Delay() function (see section 2.1.2). Average consumption is 1.57 mA (± 0.01 mA) for auto-refresh mode and 2.47 mA (± 0.01 mA) for one-shot mode. It would correspond to an increase in the lifetime from approximately 12 days to more than 18 days with a 700 mAh battery.

Detecting the One-Shot Mode on TL Traces

The type of situation we want to detect involves software intended to read a fresh value of the temperature at a regular rate. We assume the one-shot mode is always less efficient than the auto-refresh mode when used with a period P r < 1s. P max and P min are the respective maximum and minimum possible auto-refresh periods of the sensor (here P max = 1s and P min = 13ms). The decision is given by Table 1. The last line shows a hypothetical case where the software needs a new value more than once every 13 ms. It might be useful for some critical applications where the temperature is rising up extremely fast, but it cannot be accomplished in auto-refresh mode, the one-shot mode should be used. In this case this is not a matter of power efficiency so this is out of our scope.

We can observe the accesses to the sensor registers: reading the value, and requesting the one-shot mode. The tricky part is to measure time between requests to estimate the period, because we work with a simulated model of the hardware platform for which timing is always an approximation; moreover, even with a simple loop code, the software on the real platform does not read the value on a strictly periodic way.

We measure the period several times and compute the average.

IMPLEMENTATION AND EVALUATION 4.1 The TL Platform

The virtual prototype is implemented as a SystemC TL model of the STM32 MCU, including an instruction-set-simulator provided by ARM, and a TL model of the LPS22HB temperature sensor. For the first example (polling loops) we observe bus transactions. Direct Memory Interface (DMI) has to be disabled to ensure transactions visibility. For the second example, we observe the transactions on some registers of the sensor: CTRL_REG2 is written when a value is asked in one-shot mode, TEMP_OUT_H and TEMP_OUT_L contain the temperature value, CTRL_REG1 controls the auto-refresh rate.

How to Add Monitors

In our proof-of-concept implementation, the monitors are first implemented as classes in Python scripts. The scripts are called at the beginning of the SystemC simulation, and instantiate Python objects representing the monitors. Using Python allows high flexibility and coding simplicity: adding a new monitor can be done without heavy C++ re-compiling of the platform.

In the TL model, the bus and the sensor registers are SystemC modules that receive transactions. The object constructor of the monitors sets a watchpoint on a SystemC module and is programmed to trigger when the module receives a transaction with certain conditions, which may involve the metadata of the transaction. When it happens, the SystemC simulation is paused, the state of the hardware model can be inspected (for instance bits in control registers), the simulation date and all the metadata of the transaction are given to a Python method of the monitor. When the method returns it gives control back to the SystemC simulation.

The monitors can wait for a user action before giving control back to the SystemC simulator. This can be useful for the user to see the current instruction of the embedded software, via a connected debugger, or to inspect the internal state of the monitors.

Monitor for the Detection of Polling Loops

Observing the transactions on the bus is always available in TL models, but not necessarily the values of the registers internal to the CPU, like the program counter, if the CPU model is vendorspecific. So our polling loop detection works only with the memory accesses and the accesses to registers in components distant from the CPU. The monitor sets a watchpoint on the bus that triggers on the condition READ. When SystemC gives control to the Python script, it also transmits the target module name and the address.

Filtering Bus Transactions.

We need to observe the sequence S of read addresses issued on the bus by running the polling loop alone. But other accesses are due to the execution of the interrupt handlers on the same CPU (or even other threads if some scheduler was used, but we consider bare-metal implementations). It is possible to ignore any transaction issued while an interrupt is in active state. The virtual prototype includes a model of the nested vector interrupt controller (NVIC) that provides a register to indicate whether any interrupt is active or not. An interrupt is active when the CPU is running the interrupt handler (see STM32 reference manual [START_REF][END_REF]). As the first monitor is disabled when an interrupt is active, we instantiate another monitor -destroyed at the end of the interrupt handler -in order to detect polling loops inside it. So the maximum number of monitor instances is the number of possible interrupts: 255. Transactions due to fetching instructions from memory can also be filtered out: the memory location of the code is known so the corresponding addresses can be ignored.

Recognizing a

Polling Loop Sequence. We now work only with READ transactions observed on the bus, targeting the data memory section and the peripherals. As mentioned in section 2.4, the monitor looks for the regular expression x [n,+∞] | (xy) [n,+∞] | (xyz) [n,+∞] in the sequence of transactions. The recognizer is fully implemented in Python in the monitor class, initialized with a given maximal size of the repetitive patterns to be recognized P, and a minimum number of iterations n. We use P = 3 and n = 21 in the example.

Monitor for Sensor Mode Advice

We consider that the user provides our tool with the reference of the sensor used (here LPS22HB); the tool can instantiate a corresponding TL model enriched with the detection of the available refresh periods.

The monitor sets three watchpoints: (1) On the one-shot bit of the register CTRL_REG2 triggering on the condition WRITE, (2) on the register TEMP_OUT_L triggering on the condition READ and (3) on the register TEMP_OUT_H with the same condition. When a watchpoint is triggered, the monitor updates the associated measured periods with the simulation date. It then checks for the inequalities of the table 1 and warns the user in the inefficient cases. The monitor also checks the field ODR of the register CTRL_REG1 that indicates the sensor mode (ODR 0 for auto-refresh, 0 for one-shot).

Example Results as Shown to the Developer

In our example, Fig. 6 is the message displayed when the monitor detects an inefficient use case of the sensor. If a debugger is connected then the simulation is stopped and it indicates that the software is currently running the TEMP_SENS_Set_One_Shot() function in the call stack. Fig. 7 is the message for a polling loop. The debugger indicates that the software is currently running HAL_Delay().

Possible inefficient use of the sensor: top.NODE_0.LPS22HB.registers.CTRL_REG2 ONE-SHOT asked with a period: 803,135,151 ns. auto-refresh at 100 ms might save some transactions. The Hal_Delay() polling loop (Fig. 1) is detected correctly after 21 iterations and the message of Fig. 7 is displayed. Our proposed modification using the RTC wakeup timer, running the harmless loop (Fig 3) is filtered out correctly with the same monitor. Other polling loops are also successfully detected like the example of Fig. 8, although they include some code inside the loop which generates other transactions on the bus.

Impact of the Instrumentation on Simulation Time

In all cases above, the embedded software has been compiled with the -O0 option using embedded GCC. The additional cost of the instrumentation is due to: (1) the context switches between SystemC and Python; (2) the fact that we have to disable the Direct-Memory-Interface (DMI) optimization to ensure visibility of transactions;

(3) the cost of the pattern detection algorithms themselves. The cost of detecting sensor uses is negligible, because the registers are accessed very seldom in the main loop, and checking the sensor mode does not require any costly operation. We therefore focus on the polling-loop monitor. We measured the simulation duration from the start until the first call to HAL_Delay(800) in the main function (Fig. 2) with various combinations of DMI and monitor enabling and disabling. In monitor is implemented directly in the model in C++, Empty indicates a monitor that triggers a SystemC to Python context switch at each READ bus transaction, but does nothing. This is useful to evaluate separately the cost of the pattern detection algorithm. The DMI is disabled (Off ) only on the data section memory zone, hence code fetching remains invisible.

The duration have been measured using the "time" linux command, adding the user and the system times. Results show a serious performance breakdown due to Python/SystemC context switches, but this can be avoided writing the monitor in C++. The pattern recognition algorithm itself and disabling the DMI also slow down the simulation. In addition leaving DMI enabled, and instantiating monitors, also have a small impact while it should not (DMI enabling hides all memory bus transactions, so the watchpoint never triggers). This is due to the loading of the python monitor when simulation starts.

These measures show that we can focus on the detection algorithms alone, the instrumentation mechanism being sufficiently efficient. [START_REF] Peiris | Automatically Detecting Excessive Dynamic Memory Allocations Software Performance Anti-Pattern[END_REF] proposes to use dynamic binary instrumentation (DBI) to detect excessive dynamic memory allocations, and argues that it is a software performance anti-pattern very difficult to detect statically, because it relies on timing (it detects short-lived, high-frequency dynamic memory allocations). The general framework is very similar to ours. We use a simulation of the hardware because power consumption depends on the state of the hardware platform, and sometimes on timing. We may use instrumentations of an instruction-set simulator, which has the same potential as DBI. [START_REF] Peiris | Automatically Detecting Excessive Dynamic Memory Allocations Software Performance Anti-Pattern[END_REF] also provides an interesting review of other dynamic approaches for other software performance anti-patterns.

RELATED WORK

[9] is able to detect certain software performance anti-patterns (resource leaks such as CPU, memory, battery) in android applications, which are sometimes imposed by the underlying frameworks. In our case, this would be due to the HAL. The approach is based on analysing the code of the application, thus being static but without the need for the source code. The 8 patterns detected are all related to the static structure of the code.

[10] applies data mining techniques to the analysis of real-time streams in multimedia applications. It helps understand the violations of QoS properties, due to tasks missing their deadline. The implementation is not meant for monitoring contexts, and may need the full trace.

[7] presents efficient algorithms to find frequent sequences in databases of ordered transactions. The type of patterns that may be searched resembles what we need for the polling case, but the search criteria is a quantitative measure of the frequency in the whole database. On the contrary, our definition of a polling is local, it does not relate to the frequency, in the whole behavior, of the memory transactions generated by the evaluation of the loop condition. Moreover, the family of algorithms developed for pattern mining in databases does not necessarily work in a incremental way, which is necessary for our monitoring purpose.

CONCLUSION AND FURTHER WORK

We showed on two frequent examples how detecting problems dynamically allows to focus on the real impact of bad software. A piece of code that looks like a polling loop is not always one, and even if it is, it is not always bad for energy consumption. The replacement of the polling loop involves the use of a CPU sleep mode, whose effect cannot be captured at source level. For the sensor example, the dynamic detection on a timed simulation model allows to reason about periods, which, again, would be difficult statically. Further work will be devoted to other classes of power-related problems. Ongoing work is devoted to the design of a dedicated algorithm for the detection of polling loops, exploiting the fact that the pattern (x|xy|xyz) has a very particular shape. We will also investigate whether our patterns can be formalized as properties of the traces written in languages like PSL [START_REF] Cohen | Using PSL/Sugar for formal and dynamic verification: Guide to Property Specification Language for Assertion-based Verification[END_REF], so that they can then be compiled into monitors, using techniques similar to those of [START_REF] Pierre | A tractable and fast method for monitoring SystemC TLM specifications[END_REF], for instance.

Figure 3 :

 3 Figure 3: Polling loop on registers of the wakeup timer

1 int16_tFigure 4 :

 14 Figure 4: Temperature measurement code in one-shot mode (simplified).

Figure 5 :

 5 Figure 5: Temperature measurement code in auto-refresh mode (simplified).

Figure 6 :

 6 Figure 6: Detection of Inefficient Uses of a Sensor Polling suspected at addresses 0x20000260, 0x20017FD0 target: top.NODE_0.NUCLEO.STM32.RAM You might consider putting the CPU in sleep mode and programming a wake-up interrupt!

Figure 7 :

 7 Figure 7: Detection of a Polling Loop 4.6 Accuracy of the Detection Principle

1 /* 2 tmp1Figure 8 :

 128 Figure 8: A Complex Polling-Loop Example.

Table 1 :

 1 Detecting Inefficient Uses of the Sensor

		One-shot	Auto-Refresh
	P max > P r > P min	inefficient (too transactions) many	efficient
			inefficient (some
			values will be
	P r > P max	efficient	overwritten
			before they are
			read)
			wrong (some
	P r < P min	correct	values will be
			read twice)

table 2 ,

 2 None indicates that the monitor is disabled. C++ indicates that the

	Monitor	None	C++	Empty	Present
	DMI	On Off 1.19 sec 1.24 sec 24.05 sec 28.41 sec 0.7 sec 0.73 sec 2.82 sec 3.06 sec

Table 2 :

 2 Impact of enabling/disabling DMI and monitor during simulation, measured until first call to HAL_Delay().


I would like to begin by thanking the CSPG for organizing this conference, and for giving me the opportunity to present my ongoing reflections.

These reflections began last spring, during the COVID-19 pandemic, when the French population was put on lockdown. At that time, I was shocked to see to what extent the French National Assembly was caught off guard, both its deputies and its governing bodies. It was widely reported in the press, and deputies and their staff shared about it on social media.

My purpose here is not to pass judgment on how unprepared they were, nor to lecture on the decisions that should have been made. The fact is, no existing regulatory provision, nor any precedent in the annals of this institution, could have guided the President of the Assembly on what to do: in the face of the unknown, improvisation was really the only option. Rather, the purpose of my talk is to examine how the new normal, with the constant threat of the pandemic, is an issue for parliamentary institutions: the focus is less on explaining past indecisions and more on shedding light on likely future decisions. When the pandemic hit last spring, it revealed a major weak spot in how French democracy currently operates, and the National Assembly will have no choice but to address it.

Before getting into what that weak spot is, I'll wrap up my introduction by saying that all of the reflections that follow are part of a personal research program in political anthropology on the infrastructure of parliamentary assemblies, that is, on their necessary and ordinary operating conditions, whether from a human, regulatory or technical perspective. In this context, the pandemic was of interest to me because of how it called into question the ordinary operations of the institution, as well as some of its founding principles.

Transmission of the virus through parliamentary channels

Here's a fact: a virus is not only more likely to appear in France's National Assembly than anywhere else in the country, but also, once it appears, it is likely to spread to the French population far more quickly through parliamentary connections than through any other vector.

There are two reasons for this: the first is the crowded conditions in the Palais Bourbon, a fairly small historical building in which deputies work, meet and sit, as do their staff members and Assembly employees. Approximately 4,000 people work there, and individual workspaces are hard to come by, even for deputies: most workspaces are shared by at least two or three people (and often even more on the administrative side). The chamber itself is too small for deputies to have their own seats, so they have no choice but to share benches. At the Palais Bourbon, it is a headache to determine how to implement social distancing, when it is even possible.

The second reason is the number of miles the deputies put in, travelling between Paris and their constituencies at least once a week, as well as the high number of people they meet with on a daily basis. This means that deputies are not only at a higher risk of being exposed to the virus, but also collectively they are a key vector for spreading the virus to all levels of society across the entire country. If a major outbreak occurs at the Palais Bourbon, then 577 parliamentary offices are one only step behind. In the parliamentary world, communication and activities take place within a closely integrated network, and therefore any virus can spread easily.

For both of these reasons, and on a strictly structural level, national representation is a serious threat to public health during a pandemic. As such, it would be inconceivable if the Assembly (as well as the Senate) did not change how it operates if a new epidemic were to occur. The safest option would be to suspend all parliamentary activity in the Palais Bourbon (and in the constituencies) while the crisis is ongoing, and to do so very early on, as a precautionary measure.

The deputy's indispensable body

Of course, shutting down all parliamentary activities, whether before or during the crisis, is not a viable option because of the crisis itself. To conduct government business, deputies must be able to make decisions, enact legislative changes, defend the interests of their constituents, and support as well as monitor government policy.

Can the Assembly function without the body of deputies? Not body in the symbolic or metaphorical sense (as in a "legislative body"), but the body of elected representatives made of flesh and bone, who can individually or collectively be infected by a virus. This is the heart of the matter. My position is that, no, we cannot do without the physical presence of deputies, even as organizations and administrations are turning to telework, and the pressure to have employees work offsite is very strong.

Why do I think parliamentary work cannot happen unless deputies are physically present? Because at the Palais Bourbon, as in all other places where parliamentary life unfolds, the physical presence of the deputy affects their ability to take action. Standing up for a cause or a particular piece of legislation is a physical show of force. It means elected officials making themselves available when leaving the chamber, for example, and speaking to journalists in the "Four Columns Hall" It also means sharing informal moments, and lunches, for example, with ministerial advisors, with lobbyists, or with colleagues from their parliamentary group. Or, for example, crossing paths with a minister in a common space and bending their ear for a moment. In other words, deputies can apply pressure with their physicaFrench-style hybrid procedures?l presence, ensuring their political opponents and allies don't overlook them. This unique way of socializing, where the challenge is to be in the right place at the right time, has no digital equivalent (although socializing online has its own unique advantages and disadvantages). Therefore, at least in France, if the Assembly decided to move deputies to telework -preventing them from being physically present at the Palais -it would no longer be able to properly carry out its constitutional purpose. It would upset the balance of power and leave the field wide open for the executive branch.

This situation reveals the serious limitations of having national representation depend on the physical presence of a restricted group of elected individuals. Any physical threat involving elected officials is in fact a threat to French democracy (not in the absolute sense, but, to reiterate, because of the current situation).

French-style hybrid procedures?

How can this problem be solved? How can we move away from having deputies physically present (due to the pandemic) while preserving their ability to meet in person, so they can fulfill their parliamentary functions? First, I must say, before going any further, that in the case of the crisis in the spring, the problem went away before the institution really addressed it. The president of the Assembly did not implement any measures until the first cases had already been identified in the Palais. At that point, the government decided to put the entire French population on lockdown, and to pass emergency legislation authorizing it to govern by decree. In so doing, the Assembly agreed to temporarily forego its legislative power. Although its purpose, which is to monitor the government's actions, remained unchanged, the institution suspended all of its activities until the summer. Only a handful of deputies (mainly group leaders) were needed to monitor the government's activities. The question of deputies being physically present on site at the Palais did not come up, so there was no need to adopt "hybrid proceedings," as was the case in the United Kingdom, for example, to ensure that the rest of the deputies on lockdown could continue working remotely. This turn of events was unavoidable due to the novel and unexpected nature of the crisis, allowing the government to take advantage of the tacit agreement of a majority of deputies who were caught off guard and at a disadvantage. That said, this is not a viable long-term solution, since it upset the balance between institutions and required the Assembly to renounce its very purpose. Of course, in the event of a future pandemic, there is no guarantee that the government of the day will have a majority, as it did in our case when it agreed to and voted for this temporary transfer of legislative power.

The question has therefore not been resolved, and the problem remains. The Assembly should come up with a solution so it is ready in the future if a similar situation were to occur. It will have to come up with a set of provisions, and possibly adjust its regulatory framework in anticipation.

In my opinion, there is only one possible way forward. If it is not an option to forego the physical presence of deputies in the matter of national representation, and if it is also not possible to completely suspend the activities of the Assembly, the only solution is a hybrid one.

If we go back to a collective understanding of the objectives of a parliament, that is, national representation that cannot be compromised,(which is theoretically a strong principle in France), it would in fact be possible to envision a system of procedures for exceptional circumstances, integrated into the Assembly's rules of procedure, which the president could invoke temporarily when deemed necessary, based on provisions that would have been debated beforehand in a public sitting. This system could include distributing assignments to all deputies based on location (prorated based on the representation of elected officials), so that all the territories and the Palais Bourbon have physical representatives, while limiting movement as much as possible.

It would mean, on the one hand, that most deputies would be assigned to their constituencies, distributed equally across the country, so that each political group would have deputies available on the ground and accessible to citizens; and on the other hand, that a smaller number of deputies would be assigned to the Palais Bourbon, ensuring that all standing committees are covered, so that each parliamentary group would have deputies who could use their physical presence to engage in their legislative work and in government oversight. It would mean, on the one hand, that most deputies would be assigned to their constituencies, distributed equally across the country, so that each political group would have deputies available on the ground and accessible to citizens; and on the other hand, that a smaller number of deputies would be assigned to the Palais Bourbon, ensuring that all standing committees are covered, so that each parliamentary group would have deputies who could use their physical presence to engage in their legislative work and in government oversight.

In this system for exceptional circumstances, specific rules of procedure would be needed to ensure equality between those deputies who remain in their constituencies and those who are assigned to the Palais: this could be achieved by making voting by public ballot the norm and by allowing remote voting, to ensure the recent achievements for individual voting are not rolled back; and by allowing and arranging for deputies to speak from a remote location, both in committees and in public sittings.

Conclusion

To conclude, it is true that a hybrid solution like this one, modeled on the British system, is a departure from parliamentary representation in its current form in France. It is important to reflect on new ways that would ensure national representation, which may look a bit different than our current practices, and the representation of politicians at the national level. Therefore, promoting a hybrid solution would take real political will on the part of the President of the Assembly, as well as raising collective awareness among deputies. From the point of view of the balance of power, however, it seems to me that it would be preferable for the Assembly to decide on its operating conditions in a time of crisis rather than having them be dictated by the executive branch, as was more or less the case this spring.

"

  Perspectives on Legislatures and Legislative Power: Past, Present, Future" Parliamentarians' body face the virus Reflections on parliamentary representation in a pandemic context in the French National Assembly Thursday, October 15, 2020, Panel "Parliament in Unique Times" by Jonathan Chibois, IIAC (EHESS-CNRS) Translated by the Translation Bureau (a federal institution of Canada).