Online lesen

„Was die Zukunft anbelangt, so haben wir nicht die Aufgabe,
sie vorherzusehen, sondern sie zu ermöglichen.“
(Antoine de Saint-Exupéry),

Unsere Themen:

- Umgang mit Timing Fragen
- Sie haben keine Kontrolle
- Es gibt Werkzeuge ...
- ... und bessere Werkzeuge
- Das ist ein Angebot!


Liebe Kundin, Lieber Kunde,

Zweifelsohne gibt es eine Lernkurve wenn Sie beginnen, ein Echtzeit-Betriebssystem in Ihrer Entwicklung zu nutzen. Diese Phase zu durchlaufen wird Ihnen allerdings nicht erspart bleiben, denn die Anforderungen an heutige Echtzeit-Embedded-Applikationen lassen keine andere Wahl.


Umgang mit Timing Fragen

Mit einem Echtzeit-Betriebssystem werden Sie auf einer höheren Abstraktionsebene arbeiten, indem Sie mehr oder weniger parallele Tasks anstatt nur Unterprogramme verwenden.

NL_1710_1.jpg

Sie müssen sich Gedanken darüber machen, wie Ihre Tasks Daten und die Prozessorzeit mit-einander teilen sollen.

Sie müssen diesen Tasks Laufzeitprio-ritäten zuordnen, und es ist keineswegs sofort klar, was die beste Lösung ist.

Last but not least müssen Sie lernen, wie man das RTOS selbst benutzt, wie die Konfiguration und die API-Funktionen für die Steuerung von Tasks und die Kommunikation zwischen ihnen funktionieren.

Sobald Sie das alles beherrschen und Sie Ihren Applikationscode schreiben, ist es Zeit für die nächste Lernkurve - Sie müssen jetzt auch noch lernen, wie Sie Ihren Code debuggen.


Sie haben keine Kontrolle

Es gibt mehrere Gründe warum sich das Debuggen eines RTOS-Systems (in der Regel mit Pre-emptive Multitasking) vom Debuggen eines Single-Threaded "Superloop"–System unterscheidet, in dem Sie den gesamten Code selbst geschrieben haben. Die beiden wichtigsten Gründe sind:

  • Mit mehreren Tasks, die mit gemeinsam genutzten Ressourcen interagieren und konkurrieren, kann das Softwareverhalten durch Software-Timing und RTOS-Scheduling beeinflusst werden – und Sie sehen nichts davon im Ihrem Quellcode.

  • Sie haben keine direkte Kontrolle über den Programmablauf - Task-Switches können jederzeit und überall auftreten.
NL_1710_2.jpg

Um die Lösung dieser Fragen kommen Sie nicht herum. Sie müssen sich damit aus-einandersetzen, da Sie dem Betriebssystem letzten Endes vertrauen müssen Ihre Tasks richtig zu planen und die Timer korrekt zu verwalten.

Einige Task-Switches können vorhersehbar und daher bekannt sein, aber im Allgemeinen haben Sie keine Ahnung, wo sie im Programm-Flow auftreten werden.

In dem Maße, wie die Anzahl der Tasks und Threads, die Sie in Ihrem System haben, steigt, steigt auch die Anzahl der möglichen Kombinationen.

Das kann zu einer enormen Zahl von Ausführungsszenarien mit unterschiedlicher Timing- und Ausführungsreihenfolge führen – auch wenn die meisten davon gut funktionieren.

Aber dann taucht da dieser "Alptraum Bug" auf, vom dem einer Ihrer Kunden berichtet hat! Er erscheint nur, wenn die Bedingungen genau richtig sind – und Sie können diese nicht reproduzieren.

Oft haben diese Symptome ein gewisses Maß an Zufälligkeit; das Problem taucht manchmal auf - aber nicht immer. Nachfolgend einige typische Symptome, aus denen Sie sehen können, dass Sie RTOS-bezogene Timing-Bugs haben:

  • Tasks funktionieren isoliert gut, aber nicht im gesamten System
  • Die Applikation hat eine zu geringe Leistung, alles schleicht dahin
  • Das System hängt sich auf oder reagiert nicht mehr
  • Das System erscheint fragil - kleinste Änderungen führen zu sonderbaren Fehlern
  • Sie beobachten zufällige Variationen im Ausgangstiming
  • Manchmal erhalten Sie beschädigte Daten oder falschen Output
  • Die Applikation stürzt zufällig ab, hat harte Fehler

Es gibt Werkzeuge ...

Timing abhängige Bugs können sehr schwer reproduzierbar und lokalisierbar sein. Die meisten Debug-Tools helfen da auch nicht, da sie wenig Unterstützung für Multitasking-Probleme bieten.

NL_1710_3.jpg

Es sieht so aus, als ob die meisten Werkzeuge immer noch auf stat-ische, angehaltene Systeme ausgerichtet sind, anstatt auf das dynamische Software-verhalten.

Im Gegensatz dazu haben viele Appli-kationen Echtzeitanford-erungen und können zum Debuggen gar nicht gestoppt werden.

Jenseits der Suche nach Symptomen, sollten Sie natürlich alle Werk-zeuge, die Ihnen zur Verfügung stehen mit der Instrumentierung, die sie ermöglichen, nutzen, um Ihr RTOS und Ihre Anwendung auf Bugs und Fehlverhalten zu untersuchen.

Zum Beispiel kann Ihre IDE vermutlich eine einfache Inspektion von RTOS-Objekten während des Debuggens (manchmal über Plugins) unterstützen und sogar die Stack-Usage Ihrer Tasks analysieren.

Das RTOS wird Ihnen erlauben, die CPU-Auslastung auf einem hohen Niveau zu messen, so dass Sie herausfinden können, wie viel CPU-Zeit jede Task im Durchschnitt benötigt.

Einige Debugger können Variablen zur Laufzeit des Systems in Echtzeit anzeigen ("Live Watch"), obwohl dies natürlich für schnell wechselnde Variablen wenig Sinn macht.


... und bessere Werkzeuge

Wenn Sie in einer zuverlässigen Timeline sehen wollen, was in Ihrer Applikation und Ihrem RTOS wirklich passiert, brauchen Sie ein RTOS-aware Tracing, das die Dinge aufzeichnet wie sie tatsächlich geschehen, und ein Tool, dass Ihnen helfen kann, einen Sinn aus den umfangreichen Trace-Informationen zu machen.

Der Tracealyzer von Percepio ist eine unschlagbare Lösung für diese Aufgabe, für Aufzeichnung und Analyse von Trace-Informationen. Dieses extrem nützliche Werkzeug sollte in keiner Debugging-Toolbox fehlen!

NL_1710_4.jpg

Vor wenigen Tagen hat Percepio die neue Version v3.2 des TRACEALYZER für FreeRTOS vorgestellt.

Sie können die neue Version im Download von Percepio zum unverbind-lichen Test herunterladen.

Registrierte Kunden mit einer Lizenz für den TRACEALYZER v3.x für FreeRTOS können das Up-grade natürlich kosten-los laden und permanent aktivieren.

Die wichtigste Neuerung steckt im Recorder-Modul. Die Verbesserung ist das neue Filtersystem, das es einfach macht, sich bei der Fehlersuche auf die relevantesten Teile Ihrer Firmware zu konzentrieren.

Auf diese Weise können Sie die Datenrate reduzieren und damit das Streaming von RTOS-Trace über ein breiteres Spektrum an I/O-Schnittstellen ermöglichen. Dies funktioniert sowohl für "Snapshot" Trace als auch für kontinuierliches Streaming Trace.

Der aktualisierte v3.2-Recorder macht es auch einfacher, eigene benutzerdefinierte Stream-Ports zu erstellen. Es werden nur zwei Definitionen benötigt, eine "Lese" und eine "Schreib"-Funktion. Auf diese Weise können Sie den TRACEALYZER problemlos einrichten, um alle verfügbaren I/O-Schnittstellen in Ihrem System für den RTOS-Trace zu verwenden. Und falls die I/O-Geschwindigkeit ein Engpass sein sollte, können Sie nun einen Filter definieren, um die Trace-Datenrate zu reduzieren.

Es wurden auch zwei zusätzliche "Stream-Ports" hinzugefügt, ein Beispiel dafür, wie man den Trace in ein lokales Dateisystem streamt. Bei einer 4 GB Speicherkarte können Sie viele Stunden Trace-Daten aufzeichnen.

Zusammen mit mehreren weiteren Korrekturen und Verbesserungen macht diese Aktualisierung den TRACEALYZER für FreeRTOS v3.2 für eine breitere Palette von Systemen und Entwicklungsaufgaben nutzbar.

Weitere technische Details über den TRACEALYZER für FreeRTOS v3.2 finden Sie hier


Das ist ein Angebot!

Arbeiten Sie an nicht-kommerziellen Projekten, an einer Lehrinstitution oder sind privater Embedded Entwickler, können Sie eine node-locked Lizenz des TRACEALYZER für kurze Zeit zu einem Sonderpreis von € 349 erwerben.

NL_1710_5.jpg

Aber auch kommerz-ielle Anwender haben nun einen großen Vor-teil: Sie können eine node-locked Lizenz des TRACEALYZER für nur € 495 erwerben.

Beide Angebote gelten bis 31.Oktober 2017. Ich mache Ihnen gerne ein verbindliches Angebot.

Die Webinare von Jacob Beningo der letzten Monate haben offensichtlich bei vielen Entwicklern den Nerv getroffen: Der Bedarf an Wissen in der Entwickler Community ist enorm!

Sie haben die Webinare im Mai und Juli verpasst? Kein Problem. Auf Youtube können Sie sich diese nun in aller Ruhe nochmals anschauen oder auffrischen:


Drei Quartale von 2017 sind bereits Vergangenheit. Nicht mehr viel Zeit, die Ziele zu erreichen, die wir uns gesteckt haben. Genau 57 Arbeitstage sind es noch bis Weihnachten. Erschrocken?

Was auch immer Sie noch planen auf dem Weg zu Ihrem Jahreserfolg, denken Sie immer an den Satz von Henry Ford: Mit Absichten kann man nicht berühmt werden.

Herzlichst, Ihr
Marian A. Wosnitza

„Ein Kompromiss ist eine Übereinkunft,
bei der jeder vorgibt, dass er nachgibt.“
(Unbekannt)

(*) Automatische Übersetzungen können den Sinn des ursprünglichen Satzes verändern. Wir übernehmen keine Gewähr für die Richtigkeit.
Anmerkung zum neuen Telekommunikationsgesetz (seit 1.03.2006):
Sie erhalten diese Nachricht aufgrund eines bestehenden Kundenkontaktes oder aufgrund einer Anfrage an uns oder einen unserer Partner. Sollten Sie in Zukunft keine Zusendungen mehr von uns wünschen, so klicken Sie bitte auf Unsubscribe in der Fußnote dieser Email. Sie werden unverzüglich aus dem Verteiler genommen.
Impressum: Medieninhaber und Herausgeber: Carnica Technology, Marian Wosnitza, Untervellach 96, A-9620 Hermagor, www.carnica-technology.com, Email: info@carnica-technology.com