Real Time OS: DSP/BIOS

Real Time OS: DSP/BIOS

Texas Instruments Incorporated

12 - 1
 Objectifs du Cours

Ce Cours traite les fonctionnalités de

base pour l’utilisation de DSP / BIOS
dans un système.
Des fils de planification (Scheduling
threads), des fonctions périodiques et
l'utilisation d'outils d'analyse en
temps réel seront présentés.
12 - 2
 Objectifs du Cours

Introduction à DSP / BIOS

Planification (Scheduling) des threads

DSP / BIOS

Fonctions périodiques

Outils d'analyse en temps réel

Modules API DSP / BIOS et récapitulatif

12 - 3
 Introduction to DSP/BIOS
What is DSP/BIOS?
Un noyau temps réel complet et évolutif
Outils de configuration du système
Planificateur multi-threading préemptif
Outils d'analyse en temps réel
Why use DSP/BIOS?
Aide à gérer les ressources système complexes
Intégré à IDE de Code Composer Studio
Ne nécessite pas de frais de licence d'exécution
Entièrement pris en charge par TI et est un élément clé de
la technologie logicielle temps réel eXpressDSP ™ de TI
Utilise un minimum de MIPS et de mémoire (2-8Kw)
12 - 4
 Basic Input Output System BIOS, en français : « système
élémentaire d'entrée/sortie »
DSP / BIOS est un petit firmware qui fonctionne sur des puces de
processeur de signal numérique (DSP). Il offre les composants logiciels
qui permettent aux développeurs d'applications d'avoir les deux
capacités :
Surveillance et contrôle en temps réel - surveillance et contrôle de
l'exécution du programme et des variables programme en temps réel
Planification en temps réel - planification et communication du
système multi-thread en temps réel

L'objectif du BIOS est de rendre transparent, à tout système

d'exploitation, la façon dont le fabricant a développé son
processeur.
12 - 5
 Pourquoi le noyau DSP / BIOS ?

Le noyau DSP / BIOS est une collection riche en

fonctionnalités, évolutive, avec des noyaux services que les
développeurs utilise pour gérer les ressources au niveau du
système et pour construire l'infrastructure des applications
DSP

La gestion des ressources au niveau du système, y compris

le DSP, est le rôle du logiciel système et du noyau DSP /
BIOS.

le noyau DSP / BIOS facilite le transfert de votre

application vers un autre DSP TMS320 XXX

12 - 6
 Pourquoi le noyau DSP / BIOS ?
Le logiciel requis dans les systèmes embarqués DSP typiques
comprend deux composants: l'application et le logiciel système.

12 - 7
 Pourquoi le noyau DSP / BIOS ?
En utilisant le noyau DSP / BIOS, vous :
• Gérer efficacement le MIPS DSP en utilisant le multithreading.
• Utilisez des interfaces standard pour les E / S et les interruptions
matérielles HWI.
• Définir et configurer efficacement les ressources système, telles que
la mémoire système.
• Obtenez une visibilité en temps réel sur l'exécution de votre
application en utilisant les outils d'analyse en temps réel.
• Ajoutez une structure à votre application, en l'organisant autour
d'une collection de threads interdépendants.
• Facilitez la migration vers de nouveaux DSP TMS320 puisque les
DSP / BIOS font abstraction de la plupart des
matériel du système.

12 - 8
 DSP/BIOS Terminology

thread un chemin d'exécution du programme

scheduler un programme qui gère les threads
preemption l'acte d'un thread de priorité supérieure
interrompant un thread de priorité inférieure
post un signal d'événement qui rend souvent
un thread «prêt»
Pend Quand un thread attend un message
d'événement
semaphore un objet de données qui suit les
occurrences d'événements (utilisé par post et pend)

12 - 9
Systèmes d'exploitation en temps réel (Real Time
Operating Systems) (RTOS)
Qu'est-ce qu'un RTOS?
Classe particulière de systèmes d'exploitation
pour les systèmes de processeurs numériques
DSP
Capable de servir plusieurs tâches en même
temps ("système d'exploitation multitâche") (
“multi-task OS”)
Toutes les tâches doivent être servies
simultanément («système d'exploitation multi-
tâches») ET opportunes («RTOS»)
Les RTOS sont très populaires dans le contrôle
embarqué 12 - 10
Real Time Operating Systems (RTOS)
What is a Task?
Un programme objet en cours d'exécution ou
exécutable, qui:
est contrôlé par une partie du code machine
'Possède' un ensemble donné de ressources d'exploitation
pour démarrer / reprendre son cours d'action
est caractérisé par un ensemble de variables d'état
(registres, compteur de programme, variables de pile
locales, sémaphores, boîtes aux lettres MailBox)
Les tâches sont programmées et déboguées
indépendamment les unes des autres
Les accès aux périphériques ou les transferts de
données entre les tâches sont effectués par des appels
de fonctions RTOS.
12 - 11
 Real Time Operating Systems (RTOS)
Qu'est-ce qu'un modèle tâche-état?
Chaque tâche peut résider dans l'un des états suivants :
1 existant
Pret
5 7

2 3
bloqué terminé
4 6
8
fonctionnement

Pas existant
12 - 12
 Real Time Operating Systems (RTOS)
Quand l'état de la tâche change-t-il?
1. Une tâche est créée par une fonction d'initialisation
2. Une tâche est sélectionnée par le planificateur (scheduler) pour
utiliser le CPU
3. Le planificateur (scheduler) effectue un changement de tâche
selon les règles du RTOS
4. La tâche en cours d'exécution attend un événement externe, un
message d'une autre tâche ou d’un signal
5. L'événement qui bloquait une tâche s'est produit
6. La tâche a terminé son programme
7. La tâche est réactivée par une autre tâche ou par un événement
8. La tâche ne sera plus jamais utilisée (tant que le système
embarqué n'est pas éteint)

12 - 13
 Real Time Operating Systems (RTOS)
Qu'est-ce qu'une tâche – Planificateur (Task – Scheduler)?

Une partie importante du RTOS qui planifie la

séquence des phases d'exécution des tâches et le
changement d'état des tâches
Deux modes de fonctionnement de base pour les
planificateurs:
Mode (time slice ) tranche de temps - le temps de calcul est
affecté aux tâches dans une durée prédéfinie du temps
processeur
mode priorité (priority mode ): le temps de calcul est
affecté aux tâches en fonction de la priorité de chaque
tâche dans le système. Si une tâche avec une priorité plus
élevée entre dans le statut «prêt», la tâche en cours sera
préemptée.

12 - 14
Outil de configuration DSP/BIOS (file .cdb)

System Setup Tools

Gère la configuration de la
mémoire (crée le fichier .cmd), les
bibliothèques de support
d'exécution, les vecteurs
d'interruption, la configuration et
la réinitialisation du système, etc.
Real-Time Analysis Tools
Permet à l'application de
s'exécuter sans interruption
pendant l'affichage des données
de débogage
Real-Time Scheduler
Noyau du gestionnaire de bande
de roulement
Real-Time I/O
Permet une communication
bidirectionnelle entre les threads
ou entre la cible et le PC 12 - 15
Problème de conception: Ajoute d’une nouvelle
fonction

Function 1 Existing Function

New Function
Function 2
Problèmes:
Avons-nous assez de puissance de calcul pour
TI DSP ajouter une autre fonction?
Y a-t-il des conflits de ressources possibles entre la
nouvelle fonction et le système existant?
Le nouveau système respectera-t-il toutes les
restrictions de temps dans un système de contrôle
intégré en temps réel?
Une routine entrera-t-elle en conflit avec l'autre?

Quelles sont les solutions possibles? 12 - 16

Solution 1: étendre la boucle principale
Appelez chaque fonction à partir
Main()
{ d'une boucle sans fin (endless loop)
while(1) dans le principal
{ Problèmes potentiels:
Function 1 Et si les algorithmes s'exécutent à des
vitesses différentes:
Function 2
- boucle de courant du moteur à 20 kHz
} - répondre à l'entrée du clavier à 2 Hz
}
Et si un algorithme consomme suffisamment
de MIPS pour forcer l'autre algorithme à
manquer ses délais en temps réel / retarde
sa réponse?

12 - 17
 Solution 2: utiliser les interruptions
Un système piloté par interruption place
main chaque fonction dans son propre ISR
{
while(1); Period Compute CPU Usage
}
Function 1: 0.05 ms 1 µs 2%
Function1_ISR Function 2: 500 ms 3 µs ~ 0%
{ 2%
Function 1
} running
Function 1
idle
Function2_ISR
{ Function 2
Function 2
}
TI DSP Time 0 1 2 3 4 5 6 7

Une seul ISR peut fonctionner à la fois: la fonction 1 sera retardée,

finalement manquant son délai ... 12 - 18
Solution 3: Interruptions matérielles imbriquées (HWI)
Les interruptions imbriquées permettent aux
main interruptions matérielles de se préempter
{ mutuellement
return; running
}
idle

Function1_ISR
{
Function 1
} Time 0 1 2 3 4 5 6 7

Function2_ISR Utiliser le répartiteur HWI DSP / BIOS pour

{ enregistrer / restaurer le contexte et autoriser la
Function 2 préemption
}
Approche raisonnable si vous avez un nombre
limité d'interruptions / fonctions
Limite : le nombre de HWI et leurs priorités sont
déterminés statiquement, une seule fonction HWI
12 - 19
pour chaque interruption
 Another Solution – Tasks (TSK)

main Les tâches DSP / BIOS (TSK) sont similaires à

{… SWI, mais offrent une flexibilité supplémentaire
// return to O/S; TSK ressemble plus à une tâche O / S
} traditionnelle
Les compromis :
DSP/BIOS Le commutateur SWI est plus rapide que
Function 1 TSK
Le module TSK nécessite plus d'espace de
Function 2 code
Les TSK ont leur propre pile
La préférence de l'utilisateur et les besoins du
système dictent généralement le choix, facile à
utiliser les deux!

Quelles sont les différences majeures entre SWI et TSK?

12 - 20
 SWIs and TSKs
SWI_post SEM_post
SWI TSK
start

SEM_pend Pause
“run to (blocked
completion” start state)

end end
Similaire à l'interruption SEM_post () déclenche
matérielle, mais déclenchée l'exécution
par SWI_post ()
Tous les logiciels de système Chaque TSK possède sa propre
de partage de SWI pile, ce qui lui permet de faire
une pause (c'est-à-dire de
bloquer)
12 - 21
DSP/BIOS - Software Interrupts (SWI)
Faire de chaque algorithme une interruption
main logicielle indépendante
{… La planification SWI est gérée par DSP / BIOS
// return to O/S;
} Fonction HWI déclenchée par le matériel
Fonction SWI déclenchée par un logiciel
DSP/BIOS e.g. a call to SWI_post()
Pourquoi utiliser un SWI?
Function 1
Aucune limite sur le nombre de SWI, et les
Function 2 priorités pour les SWI sont définies par
l'utilisateur
SWI peut être planifié par événement (s)
matériel ou logiciel
Déplacer le traitement des tâches de HWI
vers SWI

12 - 22
Activation du BIOS - Retour à partir de main ()

main Doit supprimer l'interminable boucle

{… while()
// return to BIOS main () retourne au thread BIOS
IDLE, permettant au BIOS de
} planifier des événements, de
transférer des informations à l'hôte,
DSP BIOS etc.
Une boucle sans fin while () dans
Function 1 main () ne permettra pas au BIOS de
Function 2 s'activer

12 - 23
 DSP/BIOS - HWI Dispatcher for ISRs
Pour le code non-BIOS, nous utilisons le mot-clé d'interruption pour
déclarer un ISR
demande au compilateur d'effectuer un sauvegarde / restauration
interrupt void MyHwi(void)
{
}
Pour le code DSP / BIOS, le répartiteur (dispatcher) effectuera la
sauvegarde / restauration
Supprimer le mot-clé d'interruption de MyHwi ()
Cochez la case "Use Dispatcher" lorsque vous configurez le vecteur
d'interruption dans les outils de configuration DSP / BIOS

12 - 24
 DSP/BIOS - Periodic Functions
tick
DSP/BIOS
CLK

period

LED LED LED

Les fonctions périodiques s'exécutent à un rythme spécifique dans

votre système: - par ex. Le clignotement de la LED nécessite 0,5 Hz
Utilisez le gestionnaire CLK pour spécifier le taux CLK DSP / BIOS
en microsecondes par "tick"
Utilisez le gestionnaire PRD pour spécifier la période (pour la
fonction) en ticks
Permet plusieurs fonctions périodiques avec des taux différents

12 - 25
 Créer une fonction périodique
tick
DSP/BIOS
CLK

period

func1 func1 func1

12 - 26
 Topologie du code de tâche
Void taskFunction(…)
{

// Prolog… Initialization (fonctionne une seule fois)

while (‘condition’){ Processing loop -option: condition de

terminaison
blocking_fxn() Suspendre jusqu'à débloqué

// Process Effectuez le travail DSP souhaité ....

// Epilog Arrêt (s'exécute une fois - au plus)

}
TSK peut englober trois phases d'activité (prologue, traitement, épilogue)
Les TSK peuvent être bloqués en utilisant: SEM_pend, MBX_pend,
SIO_reclaim, et plusieurs autres (suspendre l'exécution jusqu'à débloqué)
Les TSK peuvent être débloqués en utilisant: SEM_post, MBX_post,
SIO_issue, etc. 12 - 27
SWI Properties

_myFunction

12 - 28
 Managing SWI Priority
Faites glisser et déposez les SWI pour
changer de priorité
Les SWI à priorité égale s'exécutent
dans l'ordre dans lequel ils sont publiés

Comment transmettez-vous les informations aux SWI?

12 - 29
Transmettre la valeur à SWI à l'aide de la boîte aux lettres

HWI:
… _myFunction
SWI_or (&SWIname, value);

value

SWI:
temp = SWI_getmbox();
…

Chaque SWI a sa propre boîte aux lettres

” Pourquoi passer une valeur? Permet à SWI de savoir "qui m'a posté"
SWI_or () OR valeur dans la boîte aux lettres de SWI et messages SWI
pour s'exécuter
SWI_getmbox () dans SWI lit le statut de la boîte aux lettres
Autres publications utilisant la boîte aux lettres SWI:
SWI_inc(), SWI_dec(), SWI_andn() 12 - 30
 DSP/BIOS Thread Types
Utilisé pour implémenter une partie "urgente" d'un
HWI événement en temps réel
Hardware Interrupts Déclenché par une interruption matérielle
Priorités HWI définies par le matériel

Utiliser SWI pour effectuer une activité de suivi HWI

SWI Les SWI sont «postés» par logiciel
Software Interrupts
Priority

SWI multiples à chacun des 15 niveaux de priorité

Utilisez TSK pour exécuter simultanément différents
programmes dans des contextes distincts
TSK
Les TSK sont généralement activés en affichant un
Tasks «sémaphore» (un mécanisme de signalisation de
tâche)

Fonctions IDL multiples

IDL
Fonctionne comme une boucle infinie, comme une
Background boucle traditionnelle
12 - 31
 DSP/BIOS Thread Types
Les tâches HWI : Elles ont la plus haute priorité. Leur fréquence de
fonctionnement peut approcher les 200 kHz et doivent être très
courtes de durée comprise entre 2 et 100 micros secondes. Elles
doivent s’exécuter complètement jusqu’à une instruction de retour.
Elles ne peuvent pas se mettre en sommeil
Les tâches SWI: Elles possèdent elles-mêmes 15 niveaux relatifs.
Elles sont utilisées pour traiter des événements de durée 100 micros
secondes ou plus. elles doivent s’exécuter complètement jusqu’à une
instruction de retour et ne peuvent pas se mettre
en sommeil.
Les tâches TSK : Elles peuvent être suspendues. Elles sont soumises
à l’algorithme de préemption.
Les tâches IDL: La boucle de sommeil est la tâche de plus basse
priorité dans DSP BIOS. On sort par l’appel à une fonction d’un
niveau supérieur HWI , SWI ou TSK.
12 - 32
 Les tâches
Les tâches de type HWI
Une interruption matérielle se déroule jusqu’à la fin de son code
jusqu’à l’instruction « return » : elle ne doit donc jamais se
bloquer. Elle utilise la pile système.
Les tâches de type SWI

Elle peut être interrompue par une tâche de type HWI ou une tâche de type
SWI de priorité supérieure.
Chaque tâche SWI possède une variable sur 32 bits qui sert de « mailbox ».
Les tâches SWI peuvent être validées par la fonction key=SWI_enable() et
invalidées par la fonction SWI_disable(key).
Il est possible d’avoir 15 niveaux de priorité pour les SWI
Il est possible d’utiliser la fonction TSK_setpri() pour changer la priorité
d’une tâche SWI. Ceci n’est pas possible pour les tâches HWI.

12 - 33
 Les tâches
Les tâches de type SWI
Les interruptions HWI et SWI utilisent la même pile pour sauver l’état des
registres du DSP : la pile système.
A chaque ajout d’une nouvelle priorité de SWI cette pile augmente.
La pile système possède par défaut 256 mots : il faut veiller à ne pas
dépasser cette taille. (MEM module)

Les tâches de type TSK

Elles possèdent 15 niveaux de priorité interne. Le niveau le plus bas « 0 »
correspond au fonctionnement de la boucle IDL. Une tâche de niveau « -1 »
est suspendue.
Comme pour tous les objets de DSP BIOS les tâches TSK peuvent être crées
de manière dynamique ou statique.
Pour la création dynamique on a la primitive : TSK_Handle TSK_create(tache, attrs,
[arg]…) ;
Pour la destruction dynamique on a la primitive : Void TSK_delete(TSK_Handle tache) ;

12 - 34
 Les tâches
Les tâches de type TSK
Les états et la préemption des tâches TSK

En cours (running)
Prête (ready)
Suspendue (blocked)
Terminée (ternimated)
La préemption des tâches est immédiate dès que la priorité est suffisante.

Si aucune tâche n’est en cours, c’est la boucle infinie TSK_idle

qui prend le CPU. En général DSP BIOS utilise cette tâche pour
transférer les données de fonctionnement avec le module RTDX
sur le bus JTAG vers le PC.
Si une tâche utilise plus de mémoire que celle qui lui a été attribuée lors de sa
création, elle peut écrire sur la pile d’une autre tâche.

12 - 35
 Les tâches
Les tâches de type IDL
La boucle IDLE est la tâche de fond de DSP BIOS. C’est une
boucle infinie qui peut être interrompue par n’importe quelle autre
tâche de niveau supérieur.

Toutes les tâches placées dans cette boucle s’exécutent les unes
à la suite des autres dans l’ordre défini par l’outil de configuration.

Les tâches de ce type permettent en général la communication

avec le PC
LNK-dataPump : transfert les statistiques de fonctionnement vers le PC (LOG
STS)
RTA_dispatcher : lit et met à jour les données de fonctionnement de la cible
IDL_cpuload : calcule la charge CPU
IDL_rtdxPump : exécute le transfert de données avec le mode RTDX.
12 - 36
 Les outils de synchronisation des taches
Les sémaphores
Les sémaphores de DSP BIOS sont de type à compte. Comme tout objet de
DSP BIOS ils peuvent être crées de manière statique ou dynamique. La valeur
initiale est en général nulle.
Demande d’attente sur un sémaphore SEM_pend()
Signal de libération d’un sémaphore SEM_post()

Les boites à lettres (MailBox)

Une Mailbox, boite à lettres, est une zone mémoire partageable par toutes les
tâches.
Demande d’attente sur une boite à lettres MBX_pend()
Ecriture dans une boite à lettres MBX_post()

12 - 37
 Ordonnancement de threads basé sur la priorité
Principe de fonctionnement de DSP BIOS
Toute application est construite sur le principe des interruptions. Après une
séquence d’initialisation le programme principal « main » donne la main à la
boucle infinie IDL et on attend une interruption.
Pendant la boucle IDL, le noyau formate dans une petite zone mémoire les
données à envoyer au PC.

12 - 38
Ordonnancement de threads basé sur la priorité

Exemple
Soit une application composée de :
Deux tâches HWI_1et HWI_2
Trois tâches SWI_1, SWI_2 et SWI_3

12 - 39
 Ordonnancement de threads basé sur la priorité
post3 rtn
HWI 2 SWI_post(&swi2);
(highest)
post2 rtn
HWI 1
post1 rtn
SWI 3
int2 rtn
SWI 2

SWI 1 rtn

MAIN rtn

IDLE int1
(lowest)
L'utilisateur définit la priorité ... BIOS fait la programmation
Comment créer un SWI et définir des priorités? 12 - 40
 Qu'est-ce qu'un fil (Thread) (SWI)?
SWI_post(&mySWI) return
1. Function Call
HWI 2. Context Save/Restore
3. Priority

return

mySWI

context context
HW interrupt
save restore

IDL

12 - 41
 HWI avec SWI et IDL
SWI_post(swi_name);
return return
post swi1
post swi2
HWI
return

SWI 2
return

SWI 1
return interrupt
main()

IDL
interrupt

Legend

12 - 42
 HWI avec SWI et IDL

return return
post swi1
post swi2
HWI
return

SWI 2
return

SWI 1
return interrupt
main()

IDL
interrupt

12 - 43
 Exemple de préemption TSK

return return post sem2 return

post swi1 post swi2
HWI
return

SWI 2
return

SWI 1 pend sem2 pend sem2

interrupt
TSK 2 pend sem1

TSK 1
interrupt interrupt
main()
return
IDL

12 - 44
 Exemple de préemption TSK

return return post sem2 return

post swi1 post swi2
HWI
return

SWI 2
return

SWI 1 pend sem2 pend sem2

interrupt
TSK 2 pend sem1

TSK 1
interrupt interrupt
main()
return
IDL

Comment définissez-vous les priorités ... 12 - 45

 Exemple de préemption TSK

return return post sem2 return

post swi1 post swi2
HWI
return

SWI 2
return

SWI 1 pend sem2 pend sem2

SEM_pend(&sem2)
interrupt
TSK 2
pend sem1

TSK 1
interrupt interrupt
main()
return
IDL

Comment définissez-vous les priorités ... 12 - 46

 DSP/BIOS - API Modules
TSK Communication/Synchronization
Instrumentation/Real-Time Analysis
SEM Gestionnaire de sémaphores
LOG Gestionnaire de messages MBX Gestionnaire de boîtes aux lettres
STS Gestionnaire d'accumulateurs de statistiques LCK Gestionnaire de verrouillage de ressources
TRC Gestionnaire de traces
Device-Independent Input/Output
RTDXGestionnaire d'echange de données en temps réel
PIP Gestionnaire de canal de données
Thread Types
HST Gestionnaire d'entrée / sortie hôte
HWI Gestionnaire d'interruption matériel SIO Gestionnaire de flux d'E / S
SWI Gestionnaire d'interruption logiciel DEV Interface de pilote de périphérique
TSK Gestionnaire multi-tâches
Memory and Low-Level Primitives
IDL Fonction IDLE et gestionnaire de boucle de processus
MEM Gestionnaire de mémoire
Clock and Periodic Functions
SYS Gestionnaire de services système
CLK Gestionnaire d'horloge système QUE Gestionnaire de file d'attente
PRD Gestionnaire de fonctions périodiques ATM Fonctions atomiques
GBL Gestionnaire de paramètres globaux

12 - 47
Outils d'analyse en temps réel intégrés
Recueillir des données sur la cible
Envoyer des données pendant le BIOS IDLE
Formatage des données sur l'hôte
La collecte de données n'arrête PAS la CPU cible

Execution Graph
Logiciel d'analyse
logique
Débogage de
l'événement et
priorité

CPU Load Graph

Analyser le temps qui passé
dans IDLE

12 - 48
Outils d'analyse en temps réel intégrés

Statistics View
Routines de profil sans
arrêter le processeur
Capturer et analyser des
données sans arrêter le
processeur

Message LOG

Envoyer des messages de débogage à l'hôte

N'arrête pas le DSP
déterministes, Compte de cycles bas du DSP
Plus efficace que le traditionnel printf ()

LOG_printf (&logTrace, “addSine ENabled”);

12 - 49
 RTDX: Real-Time Data Exchange
RTDX permet une communication bidirectionnelle
non gênante entre le PC hôte et le DSP (pendant le mode IDLE)
La vitesse de transfert dépend de la bande passante JTAG,
du type de connexion (parallèle vs XDS) et du niveau d'activité DSP
Transferts effectués via des appels RTDX dans le code d'application DSP

PC TMS320 DSP

USER CODE
Display

RTDX
EMU
User
JTAG
TI CCS
3rd Party
Third Party
Display

12 - 50
 RTDX: Real-Time Data Exchange

Le système Real Time Data eXchange permet de transférer

des données en temps réel entre un système cible DSP et
une application OLE PC sous Windows.

Les données peuvent être transférer soit en mode continu

sur l’écran, soit en mode non continu dans un fichier.

Une application de type OLE reçoit les données côté PC.

Ces applications peuvent être « LabVIEW », « MATLAB » «
Excel », « Visual C++ » etc.

Code Composer Studio utilise cette méthode pour ses

échanges temps réel avec le PC.

12 - 51
 Conclusions
Noyau en temps réel libre de droits pour l'utilisation en
production
DSP BIOS possède quatre familles de tâches : HWI – SWI –
TSK – IDL.
Permet un développement rapide du produit à partir du
concept
Peut être intégré avec un autre OS en temps réel
Faible encombrement (peut être aussi petit que 1K words)
Les modules utilisés sont contrôlés par l'utilisateur
Permet un débogage / analyse
Disponible avec les processeurs C6000 C2000 et C5000

12 - 52