J’ai continué mes expériences avec la gestion d’interruptions par un driver RTDM-Xenomai sur les ports GPIO d’un Raspberry Pi que j’avais entamées dans le précédent article. Jusqu’alors j’avais pu déterminer « à l’œil » en utilisant un oscilloscope que le temps de réponse était de l’ordre de 3 à 4 micro-secondes, avec des pointes régulières à 8 micro-secondes environ. Ce sont justement ces pointes – et celles plus longues – qui m’intéressent et j’aimerais en avoir un aperçu plus complet. Mon objectif est de pouvoir déterminer le temps de réponse que peut garantir dans le pire des cas un système temps réel construit sur Xenomai avec l’API RTDM.

Ceci pourrait être réalisé avec un oscilloscope numérique ou un analyseur logique à mémoire. Toutefois, ces instruments ne mémorisent généralement qu’un nombre assez faible (quelques centaines ou milliers) de valeurs. J’aimerais avoir des statistiques sur plusieurs centaines de milliers, voire millions d’échantillons. En outre, je souhaite disposer éventuellement d’éléments statistiques plus complets (histogramme des latences, etc.).

J’ai donc décidé de me construire un petit outil de mesure en utilisant un micro-contrôleur externe au Raspberry Pi. Ce micro-contrôleur devra envoyer un signal de déclenchement d’interruption et mesurer le plus précisément possible le temps s’écoulant avant la réponse du Raspberry Pi. L’intérêt d’utiliser un micro-contrôleur est que ce type de matériel est programmé aisément pour réaliser une seule tâche, sans perturbation externe, à l’inverse des micro-processeurs sur lesquels on fait tourner un système d’exploitation qui peut être « parasité » par des interruptions imprévues (réseau, vidéo, etc.).

J’ai choisi un micro-contrôleur assez puissant et peu coûteux : le STM 32. L’implémentation que j’ai décidé d’utiliser est très simple (et très bon marché) : il s’agit de la carte STM32-H103 d’Olimex (on pourrait parfaitement réaliser la même expérience avec d’autres cartes de développement).

Ce petit micro-contrôleur est doté de plusieurs timers (dont le nombre varie suivant la catégorie du micro-contrôleur) capables notamment de fonctionner dans un mode appelé « Input Capture » qui m’intéressera ici. Le timer « tourne » en permanence en comptant des cycles d’horloge, et lorsqu’un signal d’entrée spécifique se présente, il mémorise l’état du compteur dans un registre avant d’appeler un handler d’interruption. Ici j’utiliserai deux signaux d’entrée différents. Observons le fonctionnement sur la capture d’oscilloscope suivante.

Au point 1, le micro-contrôleur bascule l’état d’une sortie (signal du haut), qui est connectée à l’entrée d’interruption du Raspberry Pi. Ce même signal est rebouclé en entrée du premier canal du timer 1 du STM32. Le mode Input Capture mémorise la valeur du compteur et appelle une interruption du micro-contrôleur. Nous enregistrons alors cette valeur de compteur.

Sur le Raspberry Pi, une interruption a également été déclenchée, et elle a fait basculer l’état d’un GPIO de sortie (au point 2 du graphique). Celui-ci est relié à une entrée du STM32, sur le second canal du timer 1. À nouveau le timer mémorise la valeur de son compteur et appelle notre gestionnaire d’interruption qui en déduit la durée du traitement sur le Raspberry Pi. une fois cette latence mesurée, le STM32 peut faire redescendre son signal (au point 3),  et reprendre le même travail après avoir envoyé la valeur mesurée sur son port RS-232.

Le branchement réalisé est schématisé sur la figure suivante.

Le code de mon programme employé sur le STM 32 est le suivant.

/****************************************************************************\
 * Mesure de temps de reponse a un signal                                   *
 *                                                                          *
 * Christophe Blaess 2013.                                                  *
\****************************************************************************/

#include <stdarg.h>
#include <stdio.h>
#include <string.h>

#include <libopencm3/cm3/nvic.h>
#include <libopencm3/cm3/systick.h>
#include <libopencm3/stm32/timer.h>
#include <libopencm3/stm32/usart.h>
#include <libopencm3/stm32/f1/rcc.h>   // Reset and Clock Control.
#include <libopencm3/stm32/f1/gpio.h>

// ---------------------------------------------------------------------------
// 
void clock_setup(void)
{
	// STM32-H103 use an external quartz at 8MHz
	rcc_clock_setup_in_hse_8mhz_out_72mhz();

	// Enable clock for GPIO ports A & C.
	rcc_peripheral_enable_clock(& RCC_APB2ENR, RCC_APB2ENR_IOPAEN);
	rcc_peripheral_enable_clock(& RCC_APB2ENR, RCC_APB2ENR_IOPCEN);

}

// ---------------------------------------------------------------------------
// 
void usart_setup(void)
{
	rcc_peripheral_enable_clock(& RCC_APB1ENR, RCC_APB1ENR_USART2EN);
	rcc_peripheral_enable_clock(& RCC_APB2ENR, RCC_APB2ENR_IOPAEN);
	gpio_set_mode(GPIOA, GPIO_MODE_OUTPUT_50_MHZ,
	              GPIO_CNF_OUTPUT_ALTFN_PUSHPULL, GPIO_USART2_TX);
	gpio_set_mode(GPIOA, GPIO_MODE_INPUT,
	              GPIO_CNF_INPUT_FLOAT, GPIO_USART2_RX);
	usart_set_baudrate (USART2, 115200);
	usart_set_databits (USART2, 8);
	usart_set_stopbits (USART2, USART_STOPBITS_1);
	usart_set_parity   (USART2, USART_PARITY_NONE);
	usart_set_flow_control (USART2, USART_FLOWCONTROL_NONE);
	usart_set_mode (USART2, USART_MODE_TX_RX);
	usart_enable (USART2);
}

int usart_printf(const char * format, ...)
{
	va_list args;
	int r;
	int i;
	char buffer[256];

	if (format == NULL) 
		return 0;

	va_start(args, format);
	r = vsnprintf(buffer, 256, format, args);
	va_end(args);
	if (r <= 0)
		return r;

	for (i = 0; buffer[i] != '\0'; i ++)
		usart_send_blocking(USART2, buffer[i]);
	return i;
}

// ---------------------------------------------------------------------------
//

static int systick_counter_ms = 0;

static void systick_setup()
{
	// 72 MHz with DIV 8 -> systick clock source of 9MHz
	systick_set_clocksource(STK_CTRL_CLKSOURCE_AHB_DIV8);

	// Systick interrupt period 1ms -> 9MHz / 1kHz = 9000
	systick_set_reload(9000 - 1);
	systick_interrupt_enable();
	systick_counter_enable();
}

void sys_tick_handler(void)
{
	systick_counter_ms ++;
}

// ---------------------------------------------------------------------------
//
void tim1_setup_input_capture()
{
	// Enable clock for Timer 1.
	rcc_peripheral_enable_clock(& RCC_APB2ENR,
	                            RCC_APB2ENR_TIM1EN);

	// Configure TIM1_CH1 and TIM1_CH2 as inputs.
	gpio_set_mode (GPIO_BANK_TIM1_CH1, GPIO_MODE_INPUT,
	               GPIO_CNF_INPUT_PULL_UPDOWN,
	               GPIO_TIM1_CH1);

	gpio_set_mode (GPIO_BANK_TIM1_CH2, GPIO_MODE_INPUT,
	               GPIO_CNF_INPUT_PULL_UPDOWN,
	               GPIO_TIM1_CH2);

	// Enable interrupts for TIM1 CC.	
	nvic_enable_irq        (NVIC_TIM1_CC_IRQ);

	timer_set_mode(TIM1,
	               TIM_CR1_CKD_CK_INT, // Internal 72 MHz clock
	               TIM_CR1_CMS_EDGE,   // Edge synchronization
	               TIM_CR1_DIR_UP);    // Upward counter

	timer_set_prescaler     (TIM1, 72-1);  // Counter unit = 1 us.
	timer_set_period        (TIM1, 0xFFFF);
	timer_set_repetition_counter(TIM1, 0);
	timer_continuous_mode   (TIM1);

	// Configure channel 1
	timer_ic_set_input     (TIM1, TIM_IC1, TIM_IC_IN_TI1);
	timer_ic_set_filter    (TIM1, TIM_IC1, TIM_IC_OFF);
	timer_ic_set_polarity  (TIM1, TIM_IC1, TIM_IC_RISING);
	timer_ic_set_prescaler (TIM1, TIM_IC1, TIM_IC_PSC_OFF);
	timer_ic_enable        (TIM1, TIM_IC1);
	timer_clear_flag       (TIM1, TIM_SR_CC1IF);
	timer_enable_irq       (TIM1, TIM_DIER_CC1IE);

	// Configure channel 2
	timer_ic_set_input     (TIM1, TIM_IC2, TIM_IC_IN_TI2);
	timer_ic_set_filter    (TIM1, TIM_IC2, TIM_IC_OFF);
	timer_ic_set_polarity  (TIM1, TIM_IC2, TIM_IC_RISING);
	timer_ic_set_prescaler (TIM1, TIM_IC2, TIM_IC_PSC_OFF);
	timer_ic_enable        (TIM1, TIM_IC2);
	timer_clear_flag       (TIM1, TIM_SR_CC2IF);
	timer_enable_irq       (TIM1, TIM_DIER_CC2IE);

	timer_enable_counter   (TIM1);

}

volatile int latency = 0;
volatile int latency_max = 0;

void tim1_cc_isr(void)
{
	static int last_value = 0;
	int value;
	if (timer_get_flag(TIM1, TIM_SR_CC1IF) != 0) {
		// Timer channel 1 interrupt -> First edge (outcoming signal).
		timer_clear_flag(TIM1, TIM_SR_CC1IF);
		last_value = timer_get_counter(TIM1);
	}
	if (timer_get_flag(TIM1, TIM_SR_CC2IF)) {
		// Timer channel 2 interrupt -> response (incoming signal).
		timer_clear_flag(TIM1, TIM_SR_CC2IF);
		value = timer_get_counter(TIM1) - last_value;
		if (value < 0)
			value = value + 0xffff;
		latency = value;
		if (latency > latency_max)
			latency_max = latency;
	}
}

// ---------------------------------------------------------------------------
//
int main(void)
{
	clock_setup();
	usart_setup();
	systick_setup();
	tim1_setup_input_capture();

	// Wait 3 seconds to allow Linux detecting /dev/ttyUSB
	while (systick_counter_ms < 3000)
		;

	// Output signal is on GPIO C 10 (EXT1-8)
	gpio_set_mode(GPIOC, GPIO_MODE_OUTPUT_2_MHZ,
	              GPIO_CNF_OUTPUT_PUSHPULL, GPIO10);

	while (1) {
		// If the input signal is high.
		if (gpio_get(GPIO_BANK_TIM1_CH2, GPIO_TIM1_CH2) != 0) {
			// Output a raising edge.
			gpio_set(GPIOC, GPIO10);
			// Wait for the input signal going down, max 2 ms.
			for (systick_counter_ms = 0; systick_counter_ms < 2; )
				if (gpio_get(GPIO_BANK_TIM1_CH2, GPIO_TIM1_CH2) == 0)
					break;
			// Output a falling edge.
			gpio_clear(GPIOC, GPIO10);
		} else {
			latency = 0;
			// Output a raising edge (trigger signal).
			gpio_set(GPIOC, GPIO10);
			// Wait for the latency to be available.
			for (systick_counter_ms = 0; systick_counter_ms < 2; )
				if (latency != 0)
					break;
			// Output a falling edge.
			gpio_clear(GPIOC, GPIO10);
			if (latency != 0)
				usart_printf("%3d - %3d\n", latency, latency_max);
		}

		// Wait 1 ms before next trigger.
		for (systick_counter_ms = 0; systick_counter_ms < 1; )
			;
	}
	return 0;
}

Sur le Rapsberry Pi, le programme employé ici est le driver pour RTDM dont nous avons parlé dans cet article.

Sur le PC Linux, relié au port série du STM32, nous pouvons voir défiler les latences mesurées (en micro-secondes) ainsi que la latence maximale depuis le démarrage du STM32.

$ sudo cat /dev/ttyUSB0
 12 -  31
  9 -  31
  8 -  31
  9 -  31
  8 -  31
  9 -  31
  7 -  31
  4 -  31
  4 -  31
  4 -  31
  4 -  31
  9 -  31
  8 -  31
  8 -  31
  9 -  31
 11 -  31
 11 -  31
  9 -  31
  8 -  31
  9 -  31
 12 -  31
 11 -  31
  8 -  31

L’intérêt de cette expérience est de connaître la valeur maximale que nous risquons d’atteindre. Aussi est-il indispensable de charger fortement le Raspberry Pi. C’est le rôle du script dohell livré avec Xenomai, et que je fais tourner en séquences régulières de cinq minutes entrecoupées de petits repos de trente secondes.

# while true; do /usr/xenomai/bin/dohell 300; sleep 30; done

Résultats

La première expérience consiste à faire une série de mesures pendant une heure, avec un Raspberry Pi peu chargé (quelques accès au système de fichiers et consultations d’information de /proc). Les résultats bruts se trouvent dans ce fichier. La latence maximale obtenue est de 24 microsecondes.

J’ai utilisé les petits outils d’analyse des résultats que j’avais développés pour mon livre « Solutions temps réel sous Linux » afin d’obtenir un histogramme des latences. L’axe des ordonnées est logarithmique, afin de mettre en évidence les cas les plus rares (au dessus de 15 microsecondes environ).

L’expérience suivante a consisté à laisser le système faire des mesures pendant vingt-quatre heures, avec une très forte charge système sur le Raspberry Pi. Pour cela j’ai lancé le script dohell mentionné plus haut. Les résultats bruts se trouvent dans ce fichier. La latence maximale rencontrée est de 46 micro-secondes. L’histogramme montre bien les répartitions des latences mesurées. Nous y retrouvons le premier pic centré sur 3-4 microsecondes obtenues pendant les périodes de repos entre l’exécution de dohell.

Nous voyons que la latence de traitement d’une interruption sur Raspberry Pi en utilisant l’API RTDM de Xenomai est inférieure à 50 microsecondes, la valeur maximale étant par ailleurs un cas isolé et très rare. Ces résultats sont très corrects pour un système embarqué peu coûteux et – rappelons-le – non prévu pour un usage industriel.

Conclusion

Pour valider un choix technologique ou vérifier la montée en charge d’un prototype, il est souvent nécessaire de réaliser ce type d’expérience. On voit qu’il est tout à fait possible de construire aisément ses propres outils de mesure adaptés, pour un prix de revient modique et une complexité relativement faible (le plus compliqué est la lecture et l’interprétation du manuel de référence du micro-contrôleur). Je vous encourage à utiliser ces petites plates-formes souples, performantes et bon marché que sont le Raspberry Pi, le STM32, etc. pour vos propres hacks.

Comme toujours, les remarques, commentaires et retours d’expériences sont les bienvenus.