Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
Embedded-Systeme jedoch nicht die Komplexität der Anwendung selbst Eine Reihe scheinbar einfacher RTOS-Tasks kann wenn sie als System ausgeführt werden zu einem überraschend komplexen Echtzeitverhalten führen Herausforderungen mit Echtzeitbetriebssystemen Die Entwickler müssen vorgeben wie die Tasks mithilfe der RTOS-Dienste interagieren und Daten untereinander austauschen sollen Überdies müssen Entwickler über wichtige RTOS-Parameter wie etwa die Priorität das heißt die relative Dringlichkeit der Tasks entscheiden die alles andere als selbstverständlich sein kann Selbst wenn der gesamte Code nach den bewährten Methoden für RTOSbasiertes Design geschrieben wurde kann es sein dass andere Systembestandteile ob aus eigener Entwicklung oder zugekauft in derselben RTOS-Umgebung laufen sich jedoch nicht an dieselben Prinzipien halten Ein grundlegendes Problem welches das RTOSbasierte Design so kompliziert macht ist dass es sich bei RTOSTasks nicht um isolierte Objekte handelt Es bestehen Abhängigkeiten die das Ausführen einer Task auf unvorhergesehene Weise verzögern oder anhalten können Das kann die Leistungsfähigkeit beeinträchtigen das System dazu bringen dass es nicht reagiert oder instabil wird oder sogar zu intermittierenden Datenverlusten führen Zwischen den Tasks besteht mindestens die Abhängigkeit dass sie die Verarbeitungszeit desselben Prozessors nutzen Tasks mit höherer Priorität können aktiv werden und die Prozessorzeit zu nahezu jedem Zeitpunkt für sich beanspruchen bis alle aktiven höher priorisierten Tasks abgearbeitet sind Hinzu kommt dass Tasks häufig bestimmte Softwareressourcen gemeinsam nutzen zum Beispiel globale Daten oder Schnittstellentreiber Das erfordert blockierende Synchronisationsaufrufe um Zugriffskonflikte auszuschließen Solche TaskAbhängigkeiten sind von vielen Faktoren beeinflussbar zu denen Änderungen bei den Eingangswerten dem Timing der Eingangswerte oder der Task-Verarbeitungszeiten zählen Solche Probleme sind im Code nicht erkennbar und lassen sich oft mit Modultests nicht aufdecken treten aber im integrierten Produkt dennoch auf entweder beim Test des Gesamtsystems oder erst beim Kunden Das macht es schwer die Phänomene für Debugging-Zwecke zu reproduzieren solange nicht die genaue Sequenz der Softwareereignisse bekannt ist die dem Problem vorausgingen Aufdecken von Fehlern Als die Embedded-Branche von Assemblerauf C-Programmierung umstellte zog man bei den Debugging-Tools schnell nach und bot das QuellcodeDebugging an womit die C-Code-Perspektive zur normalen DebuggingAnsicht wurde Leider haben sich die Tools in der Regel nicht über jenes Level hinaus weiterentwickelt Einige wurden mit Features ergänzt mit denen Entwickler den Zustand von RTOS-ObjekAlles unter Kontrolle? Mit Hitex haben Sie Ihr Projekt im Griff! Hitex sorgt für Safety & Security in Ihren Embedded-Applikationen Mit Consulting Training Tools Software und Services www hitex com safety Hitex_ek_07_20 pdf S 1 Format 210 00 x 82 00 mm 16 Mar 2020 10 57 24 Bild 3 Ein CPU-Auslastungsdiagramm aus Percepio Tracealyzer veranschaulicht wieviel Prozessorzeit die einzelnen Tasks im Lauf der Zeit beanspruchen Das zeigt klar wenn eine bestimmte Task deutlich mehr CPU-Ressourcen verbraucht als andere Bild Percepio