AVR Autosar

AVR-Autosar

AVR-Autosar est un système d'exploitation en temps réel pour les microcontrôleurs AVR basés sur les normes OSEK / VDX OS et Autosar OS 4.4.

AVR-Autosar implémente la classe d'évolutivité 1 de l'automobile Autosar.

Motivation

La motivation pour AVR-Autosar a été de créer une implémentation open source facile à comprendre du système d'exploitation automatique qui peut être exécuté sur des microprocesseurs largement disponibles.

Le projet a été développé dans le cadre d'une thèse finale à l'Université des sciences appliquées Dortmund.

Start

Le projet a été créé avec l'Atmel Studio 7 et l'actuel AVR8-GCC-Toolchain sur Windows. La solution et les fichiers de projet sont inclus dans le référentiel.

La configuration du système est effectuée dans l' AppCfg.h . Les macros nécessaires sont définies et documentées dans include/CfgGenMacros.h . La documentation de la version actuelle peut être trouvée ici. Pour générer la documentation actuelle, le doxyfile fourni peut être utilisé.

Le code d'application est placé dans App.c

Le référentiel contient une application de test pour les appareils ATMEGA1284 qui a été utilisé pendant le développement pour tester toutes les fonctionnalités du système d'exploitation. Il peut être utilisé comme exemple. De plus, plusieurs applications sont fournies pour les tests sous AutosarOS/test .

Microprocesseurs pris en charge

Le système d'exploitation a été testé avec les appareils suivants:

• Atmega32
• Atmega328p
• Atmega128
• Atmega1284
• Atmega2560

D'autres microprocesseurs de la famille atmega devraient fonctionner avec un travail minimal requis.

Tracé

Pendant le développement, un système basé sur le débogueur pour le traçage a été utilisé pour enregistrer le flux du programme.

Les tracepoints définis dans ATMEL Studio peuvent être importés dans le fichier tracing.xml . Notez que les tracepoints pour les ISR ne se chargeront probablement pas correctement car ils sont définis sur les fonctions utilisateur en dehors du système d'exploitation.

De plus, un tracepoint de données peut être défini pour errorInfo.id (accès en écriture) si des informations d'erreur sont utilisées. Le message d'impression suivant peut être utilisé pour générer des commentaires dans la sortie de trace qui montrent quels services OS sont appelés:

# {currentTask};{isISR} called $FUNCTION

La trace générée devrait ressembler à ceci:

 #version 1.0
# INVALID_TASK;0 called OS_StartOS
898158796,Core_0,0,T,Idle,0,activate
898158921,Core_0,0,T,Task1,0,activate
898159328,Core_0,0,T,Task1,0,start
# Task1;0 called Events_SetEvent
# Task1;0 called Task_TerminateTask
898167984,Core_0,0,T,Task1,0,terminate
898169140,Core_0,0,T,Idle,0,start

Les traces suivent le "meilleur format de trace" pour OSEK et peuvent être importés dans Eclipse Trace Compass.

Notez que les horodatages sont générés sur l'hôte et non la cible! Cela signifie que les horaires absolus ne peuvent pas faire confiance. Par conséquent, cette méthode ne doit être utilisée que pour tracer le flux / ordre d'exécution du programme.

Limitations connues

• Le système ne prend pas en charge les liens détendus (optimisation des appels de queue). L'option -mrelax qui peut être automatiquement activée par ATMEL Studio lors de la modification de l'appareil dans les paramètres du projet doit être désactivée pour le fonctionnement correct du système d'exploitation.
• Le système n'utilise pas de files d'attente prête pour les tâches. Si plusieurs tâches avec la même priorité sont activées, elles seront sélectionnées en fonction de leur commande dans la configuration et non au moment de l'activation.
• Le système ne prend pas en charge les compteurs matériels (à la place, une minuterie qui incrémente un compteur basé sur un logiciel doit être utilisée).
• Les constantes de la base d'alarme ne sont pas automatiquement créées et doivent être créées par l'utilisateur ou GetAlarmBase() doivent être utilisées.