FR 2817364 A1 20020531 FR 0015414 A 20001129 L'invention concerne un procédé de détection de l'effacement d'une donnée dans une mémoire gérée circulairement. Le contexte de la présente invention est celui des récepteurs de télévision recevant des programmes audiovisuels numériques. Ces appareils sont dotés d'une antenne de réception permettant de capter des signaux émis sur un réseau de diffusion. Les données transportées dans ces signaux sont de type numérique, elles sont formatées selon des normes tel que par exemple les spécifications DVB et notamment, la couche transport ISO/IEC 13818-1. Les données sont reçues sous la forme de bloc composés d'un certain nombre de paquets d'une taille fixes. Les signaux sont d'abord démodulés, puis demultiplexés pour en extraire leur contenu numérique qui est, par exemple, des images au format MPEG, des données de son, des données de service pour le contrôle des programmes diffusés ou pour donner des informations. Les données sont stockées dans une mémoire tampon avant d'être traitées par un module logiciel appelé interface de réseau . Le traitement consiste à décoder l'image ou le son, puis à les envoyer à l'écran ou aux haut-parleurs, ou s'il s'agit d'informations de service, à traiter ces données pour, par exemple, les afficher sur l'écran dans un Guide Electronique de programme ou EPG . La situation de la mémoire tampon est la suivante : elle reçoit des données d'un processus dit producteur , et elle renvoie ces données vers un autre processus dit consommateur . Les données une fois lues et traitées n'ont plus besoin de rester dans la mémoire. Elles peuvent être écrasées pour être remplacées par de nouvelles données. Selon une technique bien connue, la mémoire est gérée circulairement : l'adresse suivant celle à la fin de la mémoire est l'adresse de début. Le stockage en mémoire tampon permet d'adapter les flux des processus producteur et consommateur. La mémoire doit pouvoir garder les données reçues jusqu'à ce qu'elles soient traitées par le processus consommateur. Lorsque les données proviennent d'un réseau unidirectionnel, Il n'est pas possible au niveau du récepteur de contrôler le débit d'émission des données. Dans certains cas, les débits peuvent être très différents : typiquement 10 Mégabits par seconde (ou 10Mbps) pour l'interface de réseau, 50 Mbps pour le réseau de diffusion. Si les données sont reçues en permanence, la mémoire tampon se remplit vite, il faut donc la doter d'une taille importante. Mais, pour des raisons de coûts, les appareils ne disposent pas d'une très grande mémoire. Il peut donc arriver que la mémoire tampon soit pleine alors que d'autres données sont en cours de réception. Il faut de toutes façons les stocker en mémoire tampon ce qui s'effectue en écrasant des données non lues. Un des buts de la présente invention est de proposer une solution pour détecter de tels écrasements. La présente solution met en oeuvre un indicateur d'écrasement signalant des écrasements. A cet effet, l'invention concerne un procédé de détection de l'écrasement d'un bloc de données écrit dans une mémoire de blocs gérée par un processus d'écriture et un processus de lecture et de traitement, comportant au moins une première étape d'écriture dans la mémoire d'un premier bloc de données et au moins une seconde étape de lecture dans la mémoire de bloc d'un second bloc de données, caractérisé en ce que l'étape de lecture du second bloc de données comporte une étape de détection de l'écrasement de ce second bloc de données consistant à tester si l'adresse de ce second bloc se trouve dans la zone mémoire occupé par un premier bloc non lu et écrit lors d'une première étape. De cette façon, le processus de lecture de la mémoire détecte immédiatement l'écrasement d'une donnée et peut en informer les couches applicatives qui utilisent les données lues. Le processus d'écriture ne gère pas la détection, il est de ce fait plus rapide et peut gérer un débit plus important. Selon une autre particularité l'étape de lecture comprend une boucle itérative de programme permettant de remonter dans la mémoire à partie du dernier bloc reçu et de tester si des blocs reçus précédemment ont provoqué ou non des écrasements. Selon une autre particularité, le procédé comprend une étape de comptabilisation du nombre de blocs écrasés. De cette façon, les applications utilisatrices des données connaissent précisément le nombre des blocs qu'elles ne peuvent plus traiter du fait de leur écrasement. Selon une autre particularité, l'adresse de chaque bloc est écrite dans une mémoire d'adresse, l'accès à un bloc s'effectuant par une étape de recherche de l'adresse de ce bloc dans la zone des adresses. Ainsi, il est facile d'accéder au bloc suivant ou précédent par un simple incrément ou décrément du pointeur dans la zone des adresses. L'invention a aussi pour objet un dispositif de traitement de blocs de données comportant un moyen de réception de blocs de données, une mémoire de stockage des blocs, un programme d'écriture des blocs dans la mémoire et un programme de lecture des blocs de la mémoire, caractérisé en ce que le programme de lecture des blocs comporte un moyen de détection de l'écrasement d'un bloc consistant à déterminer si l'adresse du bloc lu se trouve dans un bloc de données écrit par le programme d'écriture et non lu par le programme de lecture. Selon une particularité, les processus de lecture et d'écriture utilisent la mémoire de façon circulaire. D'autres caractéristiques et avantages de la présente invention ressortiront de la description des exemples de réalisation qui vont suivre, pris à titre d'exemples non limitatifs, en référence aux figures annexées dans lesquelles : La figure 1 représente un récepteur de télévision pour la mise en oeuvre de l'invention ; La figure 2 représente un schéma illustrant les flux de données entre les différentes machines et les deux processus ; La figure 3 représente une organisation de la mémoire utilisée pour la mise en oeuvre de l'invention ; La figure 4 représente un organigramme du processus producteur ; La figure 5 représente un organigramme du processus consommateur. Un récepteur selon le présent exemple de réalisation est décrit à la figure 1. Ce récepteur est, par exemple, un décodeur conforme aux spécifications DVB. Il utilise une couche transport ISO/IEC 13818-1. Le récepteur est relié à une antenne 1, elle-même reliée à un syntoniseur (appelé également tuner ). Le signal fourni par le tuner est démodulé par un démodulateur 3. Les données démodulées sont désentrelacées et corrigées par un circuit correcteur d'erreur 4 et transmises à un démultiplexeur 5. Celui-ci comporte un certain nombre de filtres programmés par un microprocesseur 23 en fonction des diverses applications supportées par le récepteur. Le microprocesseur 23 est connecté à une mémoire 12 comportant le système d'exploitation ainsi que les programmes résidents ou téléchargés de mise en oeuvre d'applications telles qu'un EPG. La mémoire est illustrée sous la forme d'un bloc unique, mais peut physiquement comporter plusieurs blocs de nature différente : mémoire vive RAM, mémoire morte ROM, mémoire reprogrammable EEPROM ou FLASH. La mémoire morte ROM contient entre autres le programme de base du récepteur. Le signal vidéo généré est multiplexé avec l'un des signaux vidéo en provenance du récepteur vidéo 17 vers une prise Péritel (prise SCART en anglais) reliée à un téléviseur 22. Le Circuit de multiplexage 20 est géré par le microprocesseur 23. Pour la clarté du schéma, seules les connexions les plus Importantes du microprocesseur 23 sont illustrées. Les blocs de données audio, vidéo ou de services filtrés par le démultiplexeur sont stockés dans des zones prédéfinies d'une mémoire 25. Cette mémoire et les deux circuits 26 et 27 composent l'interface de réseau entre d'une part la mémoire et les circuits de réception des données constituant un premier réseau, et d'autre part la mémoire et les circuits de traitement des données constituant un second réseau. Le premier circuit 26 gère le stockage dans la mémoire 25. Selon le présent exemple de réalisation, ce circuit est un composant électronique programmable fabriqué par le constructeur ALTERA sous la référence EPF10K130EQC240-2. L'avantage d'un tel composant est sa rapidité de traitement. Le second circuit 27 gère la lecture des données de la mémoire 25. Selon le présent exemple de réalisation, ce circuit est de type ARM fabriqué sous la référence ARM-7TDMI. Il est constitué d'une unité centrale associant des périphériques spécialisés. D'autres circuits sont envisageables, notamment deux unités centrales, dans ce cas les fonctions des circuits 26 et 27 sont réalisées par un programme, ou deux composants programmable ou encore, des composants dont la logique est réalisée sur mesure, par exemple des ASIC (abréviations du terme anglo-saxon Application Specific Integrated Circuit ). La mémoire est de type double accès, elle est dotée de deux ports pour la transmission des données. Les deux ports sont reliés, l'un au composant 25, l'autre au composant 26. Des lignes d'interruption relient les deux composants leur permettant de se contrôler mutuellement. Les flux de données entre les divers éléments ainsi que la place des deux processus sont illustrés par la figure 1. Les données sont reçues dans un récepteur 02 via le réseau LMDS 01 (LMDS est l'abréviation de Local Multipoint Distribution System ) dont les signaux sont transmis sur une porteuse de 40.5 à 43.5 GigaHertz. Le débit des données transmises à travers un tel réseau est de 50 Mégabits par seconde, ou 50 Mbps. Le processus producteur 03 incorporé dans le récepteur prend en charge ces données. Le processus consommateur 04 lit et traite les données et génère un flux dont le débit est typiquement de 10 Mbps. Les données sont ensuite utilisées par une application et par exemple, affichées sur un écran (22) via une liaison de type Ethernet . Le récepteur appelé NIU (abréviation du terme anglo-saxon Network Interface Unit) filtre des blocs à haut débit et reconstitue des trames, dans le cas présent de type ETHERNET. Les blocs de données sont ensuite mis à la disposition d'applications. Ces applications sont exécutées soit par un ordinateur séparé du récepteur, soit par le récepteur lui-même, c'est la cas notamment pour des Guides Electroniques de Programme (EPG). Au niveau logiciel, le composant 26 qui gère l'écriture dans la mémoire 26 des données reçues par le démultiplexeur 5 contient un processus dit producteur . Le composant 27 qui gère la lecture des données qui sont ensuite traitées, contient un processus dit consommateur . La figure 2 montre par des flèches les flux des données entre la mémoire 25 et les deux processus producteur et consommateur. Les processus producteur et consommateur étant asynchrones, les débits d'informations gérés par les deux processus sont indépendants. Le réseau envoie des données selon un débit de 40 Mbps, voire même de 50 Mbps. Les applications reçoivent ces mêmes données selon un débit de 10 Mbps, c'est-à-dire au maximum cinq fois moins vite. Dans de telles conditions, il peut arriver que la mémoire double accès se remplissent et que des données anciennes et non traitées soient écrasées par de nouvelles données. Les écrasements doivent être signalés aux différentes applications qui utilisent ces données. De cette façon, elles peuvent en tenir compte au cours de leurs exécutions. Puisque les applications sont en relation directe avec le module consommateur, c'est à lui de détecter les écrasements et non pas au processus producteur. Les processus producteur et consommateur assurent en commun la gestion de la mémoire double accès 25 que nous allons maintenant présenter. La figure 3 montre le contenu de la mémoire double accès 25. La mémoire est divisée en trois zones principales : la zone de contrôle, la zone des blocs ZBL, et la zone des adresses ZAD. La zone de contrôle contient les variables nécessaires à la gestion des processus. La zone des blocs contient les blocs de données reçues du démultiplexeur, par exemple des trames Ethernet. Cette zone commence à l'adresse Add~Deb~ZBL et se termine à l'adresse Add Fin ZBL La zone des adresses contient l'adresse de chaque bloc enregistré dans la zone des blocs. Cette zone commence à l'adresse Add~Deb~ZAD et se termine à l'adresse Add~Fin~ZAD. Selon le présent exemple de réalisation, la taille de la mémoire 6 est de 16 Kilo-mots, l'adresse de chaque mot s'exprimant sur 14 bits. Les tailles maximale et minimale d'un bloc sont respectivement de 1516 octets et 64 octets. La taille de la zone de contrôle est de 32 octets, ce qui laisse (32768-32 =) 32736 octets pour stocker des blocs de 64 octets minimum, auxquels il faut rajouter deux octets pour exprimer la taille du bloc et deux octets pour l'adresse de stockage du bloc. La mémoire 6 peut donc contenir au maximum (32736/ [64+2+2] =) 481 blocs avec leurs tailles et leurs adresses. La taille de la zone des adresses est donc fixée à 481 mots. Lors de l'enregistrement, le premier mot de chaque bloc contient le nombre de mots du bloc (de 64 à 1516). La zone de contrôle contient les variables suivantes : Add~Deb~ZBL : valeur de la première adresse de la zone des blocs. Add~Fin~ZBL : valeur de la dernière adresse de la zone des blocs. Add~Deb~ZAD : valeur de la première adresse de la zone des adresses. Add~Fin~ZAD : valeur de la dernière adresse de la zone des adresses. AdrBLCProd : adresse d'écriture du bloc par le processus producteur. PosAdBLCProd : Pointeur d'adresse dans ZAD de l'adresse du prochain bloc à écrire par le processus producteur. AdrBLCons. adresse de lecture du bloc par le processus consommateur. PosAdBLCons : Pointeur d'adresse dans ZAD de l'adresse du prochain bloc à lire par le processus consommateur. CptBLRec : Compteur de blocs reçus. Cpt~BL~Lu : Compteur de blocs lus. CptBLTrt ; Compteur de blocs traités. TAILLE : Longueur en octets du bloc pointé dans ZBL. Après avoir décrit les éléments du présent exemple de réalisation, nous allons maintenant expliquer le déroulement des deux processus producteur et consommateur. Les processus producteur et consommateur sont asynchrones. Les flux d'informations peuvent typiquement varier de 0 Mbps à 50 Mbps. Le processus producteur pouvant être cinq fois plus rapide que le processus consommateur, la mémoire double accès peut se remplir complètement et des nouvelles données peuvent être écrites à l'emplacement de données non encore traitées par le processus consommateur. Le but de la présente invention n'est pas d'éviter des écrasements, ou de les corriger mais seulement de les détecter. Le processus consommateur détecte les écrasements et en informe les applications qui utilisent ces données. Les deux processus sont lancés à la mise sous tension du récepteur et fonctionnent ensuite en parallèle. La figure 4 montre l'organigramme du processus producteur L'étape 4.1 consiste à initialiser certaines variables utilisées par ce processus. Le compteur CptBLREC de blocs reçus est mis à zéro. L'adresse de stockage du prochain bloc reçu AdrBLCProd reçoit la valeur Add-Deb ZBL. L'adresse de stockage dans la zone des adresses de l'adresse du prochain bloc reçu PosAdBLCProd reçoit la valeur AddDebZAD. A la fin de l'étape 1, les pointeurs AdrBLCProd et PosAdBLCProd sont prêts pour le stockage du premier bloc de données reçu en début de zone ZBL et son adresse, en début de zone ZAD. Le processus producteur attend à l'étape 42 la réception d'un nouveau bloc. A l'étape 4. 3, le démultiplexeur a reçu un nouveau bloc, il communique au processus producteur la taille et le contenu. Le processus producteur teste si le bloc peut être stocké dans la partie de la zone des blocs ZBL à la suite du bloc courant. Pour cela, il additionne la valeur du pointeur de bloc courant AdrBLCProd à la taille du bloc reçu, et compare la valeur calculée avec l'adresse de fin de la zone ZBL : Add Fin ZBL. Si la valeur est plus grande que Add~Fin~ZBL, il n'y a pas assez de place en fin de zone des blocs pour écrire le bloc reçu. Dans ce cas, il faut stocker ce bloc en début de ZBL c'est-à-dire à l'adresse Add~Deb~ZBL. A l'étape 4, le pointeur de bloc courant AdrBLCProd est mis à la valeur Add~Deb~ZBL. Les étapes 4.3 et 4.4 permettent, selon une particularité de la présente invention, de stocker les blocs en un seul morceau. Les adresses de tous les mots d'un même bloc étant consécutives, cela permet d'accélérer la lecture au moment du traitement. A l'étape 4.5, l'adresse de stockage du bloc reçu est mémorisé dans ZAD à l'adresse définie par PosAdBLCProd. Ensuite, le mot mémoire PosAdBLCProd sera utilisé comme pointeur pour le stockage et sa valeur évolue au fur et à mesure de l'enregistrement. A l'étape 4. 6, le contenu du bloc reçu est stocké dans la zone ZBL, et le mot TAILLE est mis à jour avec le nombre d'octets du bloc reçu telle qu'elle est indiquée par le démultiplexeur. Selon un mode préféré de réalisation, les deux premiers octets du bloc dans ZBL contiennent la taille du bloc. Selon une variante, qui peut être plus avantageuse en terme de temps de traitement, la taille du bloc est écrite à la suite de l'adresse dans la zone des adresses. La taille de la zone d'adresse est alors de 962 mots. Le processus producteur met ensuite à jour le pointeur des adresses PosAdBLCProd en vue de la prochaine réception. A l'étape 4.7, il teste si l'adresse de stockage du bloc courant PosAdBLCProd est égale au dernier mot de la zone des adresses (Add~FIn-ZAD) Si c'est le cas, pour gérer de façon cyclique la zone des adresses, la valeur de PosAdBLCProd est initialisée en début de mémoire des adresses : Add~Deb~ZAD (étape 49). SI non, la valeur de PosAdBLCProd est additionnée d'une unité. (étape 4.8). A l'étape 4.10, le processus producteur met à jour l'adresse de stockage dans ZAD du prochain bloc à recevoir. Cette opération consiste à additionner la valeur de TAILLE + 2 à la valeur AdrBLCProd du bloc qui vient d'être stocké. Cette opération est en fait plus simple, car le mot AdrBLCProd a servi de pointeur de stockage lors de l'enregistrement à l'étape 4.6. Il pointe donc le premier mot qui suit le dernier bloc reçu Enfin, la valeur du compteur de blocs reçus CptBLRec est incrémenté d'une unité. Une remarque concernant les compteurs : Cpt~BL~Rec, Cpt~BL~Lu, ou Cpt~BL-Trt, lorsque la valeur de l'un d'entre eux dépasse la valeur héxadécimale FFFF (65535 en décimale), elle prend la valeur 0000 sans générer de retenue. Une fois toutes ces étapes effectuées, le processus producteur reboucle à l'étape 4.2, d'attente de réception d'un nouveau bloc. Le bloc précédemment reçu, devenu le bloc courant, peut alors être lu et traité par le processus consommateur. La figure 5 montre l'organigramme du processus consommateur. Le processus consommateur, comme le processus producteur consiste en une boucle dotée d'une étape d'attente. Le processus consommateur attend un bloc de données du processus producteur puis, au cours de la boucle, il traite le bloc. Au cours du traitement d'un bloc, le processus producteur a pu en recevoir plusieurs. Le processus consommateur doit donc vérifier si, pour chaque bloc reçu depuis le dernier traitement, il n'y a pas eu d'écrasement. C'est la raison de la seconde boucle dans le processus que nous allons maintenant détailler. L'étape 5.1 consiste à initialiser certaines variables utilisées par ce processus. Le nombre de blocs lus par le processus consommateur est indiqué par un compteur appelé CptBLLu, il est mis à zéro. Le nombre de blocs traités par le processus consommateur est indiqué par un autre compteur appelé Cpt~BL~Trt, il est également mis à zéro L'écart entre ces deux compteurs correspond au nombre de blocs qui ont été lus par le processus consommateur mais qui n'ont pas pu être traités car ils ont été écrasés par le processus producteur. Le pointeur dans la zone des adresse PosAdBLCons , géré par le processus consommateur, est initialisé en début de mémoire : Add-Deb-ZAD. De cette façon, le premier bloc à lire se trouve à l'adresse qui est stockée dans le premier mot de ZAD. Le processus consommateur attend à l'étape 5. 2 la réception d'un bloc non lu. Pour cela, le nombre de blocs reçus par le processus producteur est comparé à celui des blocs lus par le processus consommateur. Si les deux valeurs sont égales, tous les bloc reçus ont été traités et le programme reste à l'étape 5.2. Sinon, il y a au moins un bloc en attente de traitement. Dans ce cas, le programme calcule la valeur de l'adresse du mot dans ZAD qui contient l'adresse du dernier bloc reçu. Or le pointeur PosAdBLCProd est mis à jour au moment du stockage, il ne pointe donc pas le bloc qui vient d'être stocké mais la zone mémoire qui recevra le prochain. Le processus consommateur utilise un pointeur intermédiaire p qui adresse d'abord le dernier mot reçu par le processus producteur et qui va ensuite pointer tous les blocs précédemment reçus depuis le dernier bloc traité par le processus consommateur afin de vérifier qu'aucun d'entre eux n'a écrasé de données. Dans un premier temps, la valeur PosAdBLCProd du pointeur d'adresse du bloc courant géré par le processus producteur est comparée avec la valeur d'adresse de début de zone des adresses (étape 5.3). Si les valeurs sont différentes, le pointeur intermédiaire p est initialisé avec la valeur [PosAdBLCProd]-1 (étape 5.4). Si elle sont égales, p est initialisé avec Add~Fin~ZAD (étape 5.5). A la suite de ces étapes, p pointe l'adresse dans ZAD qui contient l'adresse du dernier bloc reçu et stocké par le processus producteur. Le pointeur p est avantageusement représenté par un registre de l'unité centrale. A l'étape 5. 6, le programme compare la valeur de p avec celle de PosAdBLCons qui est l'adresse de stockage du bloc courant à lire par le processus consommateur. Si les deux valeurs sont égales, le pointeur du processus consommateur pointe un bloc précédemment reçu. Le programme passe alors à l'étape 5.7 de traitement du bloc pointée par le pointeur du processus consommateur. Ce traitement ne fait pas l'objet de la présente invention, il ne sera donc pas détaillé. Puis, les compteurs de blocs traités CptBL-Trt et de blocs lus CptBL-Lu sont incrémentés. Enfin, à la fin de cette étape, la valeur du pointeur PosAdBLCons géré par le processus consommateur et pointant dans ZAD, est incrémentée pour pointer vers le mot de ZAD contenant l'adresse du bloc suivant et qui doit être traité. Cette étape terminée, le programme reboucle à l'étape 5.2 d'attente de réception d'un nouveau bloc à traiter. Si à l'étape 5.6, les valeurs ne sont pas égales, le programme teste à l'étape 5.8 si l'adresse du bloc à traiter ([PosAdBLCons]) est contenue dans un bloc précédemment reçu. Ce test consiste à vérifier si la valeur [PosAdBLCons] est comprise entre la valeur pointée par p dans ZAD et cette valeur additionnée de TAILLE qui est la taille en octet du bloc pointé par p. Si ce n'est pas le cas, le bloc à lire n'a pas été écrasé. Ce bloc peut être précédé d'autres qui n'ont pas encore été traités, il faut donc analyser les bloc précédents. Pour cela (étape 5. 9), la valeur de p est comparée avec la valeur d'adresse de début de zone des adresses. Si les valeurs sont différentes, le pointeur p est initialisé avec la valeur p-1 (étape 5.10). Si elle sont égales, il faut initialiser p avec AddFin~ZAD (étape 5. 11) pour assurer une gestion cyclique de la zone des adresses. A la suite de ces trois dernières étapes, le programme reboucle au début de l'étape 5. 6 pour déterminer si le p pointe sur le même bloc que le bloc courant du processus consommateur. La boucle constituée des étapes 5.6, 5.8, 5.9, 5.10 et 5.11, permet de rechercher les blocs qui ont été stockés par le processus producteur depuis le dernier traitement par le processus consommateur et de vérifier qu'ils n'ont pas écrasé de données. Si à l'étape 5.8 il s'avère que le bloc reçu et pointé par p a écrasé au moins le premier mot du bloc à traiter. Le programme saute à l'étape 5. 12, le compteur de bloc lu CptBLLu est incrémenté, mais pas le compteur de bloc traité puisque au moins une partie de ce bloc a été écrasé. Puis le programme compare la valeur du pointeur PosAdBLCons avec l'adresse de fin de zone des adresses. Si les deux valeurs sont égales, le pointeur a atteint la fin de la zone et doit pointer en début de zone. Dans ce cas, sa valeur est initialisée à Add~Deb~ZAD (étape 5.15). Sinon, la valeur du pointeur est incrémenté (étape 5.14). Puis le programme reboucle à l'étape 5.3 qui, avec les étapes 5.4 et 5.5, permettent de calculer une nouvelle valeur du pointeur temporaire. Voici comment le processus consommateur détecte un écrasement. A l'état initial, l'adresse du prochain bloc à écrire dans la mémoire est à l'adresse de ZAD pointée par PosAdBLProd, c'est à dire [PosAdBLProd] et celle du prochain bloc à traiter est à l'adresse de ZAD pointée par PosAdBLCons ([PosAdBLCons]). Dans un second temps, un premier bloc est écrit, la fin de ce bloc écrase le début du bloc à traiter. Dans un troisième temps et sans que le pointeur du processus consommateur évolue, un second bloc est écrit. Les données de ce second bloc écrasent le reste du bloc à traiter et le bloc à traiter suivant. Examinons le déroulement du programme du processus consommateur lorsque la zone ZBL contient les données et lorsqu'un bloc vient d'être traité. Le programme sort de l'étape 5.7 en mettant à jour PosAdBLCons qui contient l'adresse du bloc qui vient d'être écrasé par les deux derniers blocs reçus. Le processus consommateur, lors des étapes 5.3, 5.4 et 5. 5 initialise le pointeur intermédiaire p pour qu'il pointe l'adresse Add~BL2 du dernier bloc (numéro 2) reçu par le processus producteur. Le bloc 2 a écrasé la seconde partie du bloc à lire. L'étape 5.6 teste si p et PosAdBLCons sont au même niveau, le test est négatif puisque le processus producteur a pris une avance importante sur le processus consommateur. Le test à l'étape 5. 8 détermine si le bloc 2 a écrasé le premier mot du bloc à lire, c'est à dire si la valeur [PosAdBLCons] est comprise entre la valeur (=Add~BL2) pointée par p et cette valeur (=Add~BL2 + TAILLE) additionnée de la taille du bloc pointé par p . A ce moment, ce test est négatif car le dernier bloc reçu à écrasé la fin du bloc et non le début. Aux étapes 5.9, 5.10 et 5.11, le pointeur p est mis à jour pour pointé de bloc précédant, c'est-à-dire le bloc 1 stocké à l'adresse Add-BL1. Le test à l'étape 5.6 est toujours négatif pour la même raison que précédemment. A l'étape 5.8, le programme détecte que le bloc 1 contient bien l'adresse pointée par PosAdBLCons, c'est à dire la première adresse du bloc à lire. Un écrasement est donc détecté. Le programme saute alors au groupe d'étapes de gestion de l'écrasement. A l'étape 5.12, le programme incrémente le nombre des blocs lus, mais le compteur des blocs traités reste inchangé. Le bloc courant du processus consommateur est écrasé, il n'est plus possible de la traiter. Le pointeur PosAdBLCons est mis à jour pour pointer le bloc suivant. Puis le programme reboucle à l'étape 5.3 pour recalculer la valeur du pointeur intermédiaire et refaire les mêmes étapes que précédemment pour tester si le nouveau bloc à lire n'a pas été écrasé. L'adresse pointée par p contient l'adresse du bloc 2. Celui-ci a écrasé au moins le début du bloc à lire. Le programme va donc se dérouler de la même façon que lors de la boucle de programme précédente. Tant que le programme ne détecte pas d'écrasements, il boucle par les étapes 5.6, 5.8, 5.9, 5.10 et 5.11. Le programme teste ainsi que tous les blocs dont les adresses dans ZAD sont comprises entre la nouvelle valeur de PosAdBLCons et PosAdBLProd n'ont pas provoqué d'écrasements. Lorsque le pointeur intermédiaire pointe le bloc à lire (P = PosAdBLCons), le test à l'étape 5.6 devient positif et ce bloc peut être traité. Pour ne pas surcharger la syntaxe des tests et des mises à jour dans la description précédente, il n'a pas été tenu compte du fait que certaines valeurs s'expriment dans un modulo. Dans la pratique, les trois compteurs sont codés sur 16 bits. Donc, la valeur immédiatement après 65535 est 0 . Selon une variante, les valeurs des pointeurs PosAdBLCProd et PosAdBLCons peuvent être représentées comme un déplacement à partir des adresses Add~Deb~ZBL et Add~Deb~ZAD, le déplacement étant alors une valeur soumise au modulo 481. Une variante consiste à utiliser un compteur d'erreur NB~ERR, pour comptabiliser le nombre de blocs écrasés. Ce compteur est mis à 0 à l'étape 5.1 et incrémenté au cours de l'étape 5.12. Ce compteur est représenté par trois octets et peut donc atteindre la valeur de 16.777. 215 (2-1). Cette variante a pour avantage de comptabiliser plus de 65535 (2- 1) blocs écrasés, cette limitation provenant de la taille des compteurs CptBLLu et CptBLTrt qui est de deux octets. Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes, et l'invention ne doit pas être limitée aux détails donnés ci-dessus. ANNEXE Lexique des abréviations ZBL : Zone de stockage et de lecture des blocs de données. ZAD : Zone contenant les adresses des blocs de données AdrBLCProd : adresse d'écriture du bloc par le processus producteur. PosAdBLCProd : Pointeur d'adresse dans ZAD de l'adresse du prochain bloc à écrire par le processus producteur. AdrBLCons : adresse de lecture du bloc par le processus consommateur. PosAdBLCons : Pointeur d'adresse dans ZAD de l'adresse du prochain bloc à lire par le processus consommateur P : Pointeur intermédiaire d'adresse dans ZAD CptBLRec : Compteur de blocs reçus, géré par le processus producteur. CptBLLu : Compteur de blocs lus, géré par le processus consommateur. CptBLTrt : Compteur de blocs traités par le processus consommateur. Add~Deb~ZBL : valeur de la première adresse de la zone des blocs. Add~Fin~ZBL : valeur de la dernière adresse de la zone des blocs. Add~DebZAD : valeur de la première adresse de la zone des adresses Add~Fin~ZAD : valeur de la dernière adresse de la zone des adresses. TAILLE : Longueur en octets du bloc pointé dans ZBL. NB~ERR : Compteur d'écrasements détectés par le processus consommateur. EPG : abréviation de Guide Electronique de Programme. DVB : acronyme de l'expression anglo-saxonne Digital Vidéo Broadcasting MPEG : acronyme de l'expression anglo-saxonne Moving Picture Expert Group LMDS : acronyme de l'expression anglo-saxonne Local Multipoint Distribution System REVENDICATIONS 1. Procédé de détection de l'écrasement d'un bloc de données écrit dans une mémoire de blocs (25) gérée par un processus d'écriture (26) et un processus de lecture et de traitement (27), comportant au moins une première étape d'écriture (4.6) dans la mémoire d'un premier bloc de données et au moins une seconde étape de lecture (5.7) dans la mémoire de bloc d'un second bloc de données, caractérisé en ce que l'étape de lecture du second bloc de données comporte une étape de détection de l'écrasement (5 6,5. 8) de ce second bloc de données consistant à tester si l'adresse de ce second bloc se trouve dans la zone mémoire occupée par un premier bloc non lu et écrit lors d'une première étape (4.6). 2. Procédé de détection de l'écrasement d'un bloc de données selon la revendication 1, dans lequel le bloc courant est pointé par un pointeur de lecture (PosAdBLCons), et caractérisé en ce que l'étape de lecture d'un bloc courant comporte une étape de mise à jour préalable d'un pointeur secondaire (p) sur le dernier bloc reçu, et une étape itérative comportant les étapes successives suivantes : - test si l'adresse du bloc pointé par le pointeur de lecture est égale à l'une des adresses du bloc pointé par le pointeur secondaire (5.8) ; - si le précédent test est positif : validation d'un écrasement et mise à jour du pointeur de lecture pour pointer le bloc suivant (5.12) ; - si le précédent test est négatif : mise à jour du pointeur secondaire pour rechercher le bloc précédent (5.9, 5.10, 5. 11) ; l'itération se terminant lorsque le pointeur a parcouru tous les blocs reçus jusqu'au bloc à lire lors de l'étape de lecture. 3. Procédé de détection de l'écrasement d'un bloc de données selon les revendications 1 ou 2, caractérisé en ce qu'il comporte une étape de comptabilisation du nombre d'écrasements (NB~ERR) détectés lors de l'étape de détection. 4. Procédé de détection de l'écrasement d'un bloc de données selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'adresse de chaque bloc (AdrBLCons) est écrite dans une mémoire d'adresse (ZAD) et en ce que les blocs sont accessibles à travers un pointeur d'adresse (PosADBLCons) pointant dans la mémoire d'adresse, la recherche du bloc à lire dans l'étape de lecture comportant une étape de recherche de l'adresse du bloc à lire (AdrBLCons) dans la zone des adresses (ZAD). 5. Dispositif de traitement de blocs de données comportant un moyen de réception de blocs de données (2,3, 4,5), une mémoire de stockage des blocs (25), un module d'écriture (26) des blocs dans la mémoire et un module de lecture (27) des blocs de la mémoire, caractérisé en ce que le module de lecture des blocs comporte un moyen de détection (5.6, 5.8) de l'écrasement d'un bloc consistant à déterminer si l'adresse du bloc lu (AdrBLCons) se trouve dans un bloc de données écrit par le module d'écriture et non lu par le module de lecture. 6. Dispositif de traitement de blocs de données selon la revendication 5, caractérisé en ce qu'il comporte un compteur d'écrasements (NB~ERR) mis à jour lorsque le moyen de détection (5.6, 5.8) détecte effectivement l'écrasement d'un bloc. 7. Dispositif de traitement de blocs de données selon les revendications 5 ou 6, caractérisé en ce qu'il comporte en outre une mémoire d'adresse (ZAD) contenant les adresses de chaque bloc, l'accès au bloc s'effectuant en recherchant l'adresse du bloc dans ladite mémoire d'adresse. 8. Dispositif de traitement de blocs de données selon la revendication 7, caractérisé en ce que les mémoires de données et d'adresses sont gérées de façon circulaire par les modules de lecture et d'écriture.