MC2

Zwecks Flashen des Program Memories sowie Remote-Debugging.

OpenOCD kann mit unterschiedlichen JTAG-Interfaces und jeweils zugehörigen Treibern verwendet werden.

Konfiguriert den FreeRTOS-Kernel

Bild

als „Backend-Server“ für den GNU Debugger (GDB) dienen, wodurch ein „Remotedebugging“ aus Eclipse mit relativ wenig Zusatz-Aufwand möglich wird

Der GDB Debugger-Frontend kommuniziert mit dem „gdbserver“, also dem Debugger Backend wozu wir OpenOCD verwenden. OpenOCD steuert also via USB und die JTAG-Debug-Hardware die Debug- Register des Target-Controllers an

TCP/IP über den Port 3333

ja da Kommunikation über TCP/IP über den Port 3333

Bild

• das Projekt ohne Optimierungen übersetzt worden sein

• und das aktuelle Programm mittels External Command Flash Program Memory (make flash)

  auf den Target-Controller geflashed worden sein!!!

Mittels Aufruf von uxTaskGetStackHighWaterMark() kann in beliebigen Tasks überprüft werden, wie viel freier Platz im jeweiligen Taskstack bleibt.

Diese Code-Sequenz darf nicht mittendrin unterbrochen und dann von einem anderen Task von Beginn an neu ausgeführt (so genannt „re-entered“) werden. Ein Missachten könnte nebst Anzeigefehler sogar zum Absturz des Systems resp. zu einem „Deadlock“ führen

main() noch vor dem Starten des Schedulers (!) mittels Funktion vSemaphoreCreateBinary()

Dieser Datentyp sowie die nachfolgend verwendeten Funktionen sind übrigens im Headerfile "semphr.h" deklariert resp. in „semphr.c“ definiert

if( xSemaphoreTake( xSemaphore, ( portTickType ) 10 ) == pdTRUE ) {

//Kritischer Abschnitt

xSemaphoreGive( xSemaphore ); //Freigabe

}

0

(7 ist die niedrigste)

Hard-Realtime muss immer in der vorgegebenen Zeit reagieren.

Soft-Realtime kann die Vorgaben z.Bsp auch nur im Mittel einhalten. Einzele kurze überschreitungen müssen nicht als Versagen gewertet werden.

Zeit zwischen Eintreffen eines (Hardware-) Ereignisses bis zu dessen Behandlung

Nein! Sie sind eher langsamer da mehr Verwaltungsaufwand nötig ist.

Alle Ereignisquellen werden in einer Endlosschlaufe "gepollt" und bei Bedarf behandelt

alle Ereignisbehandlung erfolgt direkt in der ISR; das Hauptprogramm dient nur zur Initialisierung

Zeitkritische Verarbeitung in ISRs; zeitunkritische und lang andauernde im Hauptprogramm-Fluss

Bei Echtzeitsystemen mit mittlerer bis hoher Komplexität

Vorteile:

- bei nur einem Ereignis recht schnell (kein Interrupt-Overhead)
- kaum Race-Probleme (Programmfluss wird nie unterbrochen)
- einfache Erweiterung mit wenig gegenseitiger Beeinflussung (nur zeitlich!)

Nachteile:

- Keine Priorisierung
- Reaktionszeit von Anzahl und Komplexität der Ereignisse abhängig
- Kurzzeitige ereignisse (puls am Eingang) können verloren gehen
- Ereignisse dürfen nicht Blockieren
- Kein Sleep-Mode möglich, da immer gepollt werden muss
- Zwingend mit Statemachine-Ansatz realisiert

Vorteile:

- Resourcensparend (Kein andauerndes pollen, Sleep-Mode möglich)
- Priorisierung möglich

Nachteile:

- evt. nicht alle Inputs interruptfähig
- Latenzzeit etwas höher als bei Polling eines einzelnen Ereignisses
- Prelllen am Input löst mehrere Interrupts aus
- keine Differenzierungsmöglichkeit zwischen dringlicheren und weniger dringlicheren Phasen einer Ereignissbehandlung
- Race-Conditions insbesondere bei priorisiertem "nested interrupt"
- ISR darf nicht blockieren => Nur mit Statemachine-Ansatz lösbar
=> Untauglich wenn viele Ereignisse mit unterschiedlichen Echtzeit-Anforderungen und/oder Verarbeitunsgszeit nahezu gleichzeitig eintreffen.

Die meisten kostenoptimierten "low end" Mikrocontrollersysteme arbeiten so!

Vorteile:

- Schnelle Reaktion auf Ereignisse (sofern alle ISRs kurz sind)
- Keine grossen Anforderungen an Interrupt-Struktur (prellen im Hauptprogramm oder Timer-ISR behandeln

Nachteile:

- Verarbeitung nicht ereignisspezifisch priorisierbar
- Moderate Gefahr von Race-Conditions (bei Entwurfsfehlern)
- Keine komplexe Projekte, da anspruchsvoll und unflexibel

Vorteile:

- Geeignet auch für sehr komplexe Projekte
- „Nebenläufigkeiten“ einfach realisierbar (quasigleichzeitige Abarbeitung)
- Auf Ereignisse bei Bedarf sehr schnell reagieren (ISR + hochpriorisierte Tasks)
- Wenig Anforderungen an Interrupt-Struktur (keine nested ISR benötigt )

Nachteile:

- Der Wechsel zwischen Tasks benötigt Zeit
- Grösserer Speicherressourcenbedarf
- Debugging ev. problematisch (nicht rein sequentiell, stack overflow)
- Shared Ressources sind heikel

 Siehe Bild:

eCos liefert auch einen Bootloader, Treiber, Filesystems, Netzwer/USB-Stacks und Bibliotheken mit.

Lizenzkoste/-bedingungen
Support/Community

Zertifizierung
- SIL 1..4 IEC 61508/IEC61511 (Auto, Medizin)