mCAT

mCAT

mCAT ermöglicht ein echtes präemptives Multitasking, das heißt, dass eine Task höherer Priorität eine andere niedrigerer Priorität unterbricht, wenn sie wieder lauffähig wird (z.B. durch Eingang einer Nachricht an der Eingangsqueue der höherprioren Task). Bei mCat kann sogar eine Nachricht priorisiert werden (z.B. eine Alarmnachricht), um damit eine eigentlich rangniedrigere Task zu bevorzugen.

Tasks können in mCAT einzeln nachgeladen und ersetzt werden, was die Modularisierung und Updates stark vereinfacht. Solche Flexibilität kostet leider Platz im (insbesondere RAM-) Speicher, mCAT arbeitet daher mit externem Speicher. Für Anwendungen, die mit prozessorinternem Speicher auskommen sollen, empfehlen wir den µTasker Echtzeitkern.

 Welche Dienste bietet der mCAT Echtzeitkern?

  • Download-Empfänger für Ihre Programme, Flash-Programmierung und Löschen einzelner Seiten.
  • Monitor-Programm zum Debuggen.
  • "Ticker" zur Intervallsteuerung
  • Echtzeituhr zur Zeitpunktsteuerung.
  • EEPROM-Verwaltung für Konfigurations-Parameter.
  • SerDrv für ser. Kommunikation
  • BITBUS-Treiber für Client- und Serverfunktionen am Feldbus.
  • Express-I/O zur einfachen Ansprache von digitalen und analogen E/A. Mit Express Hintergrundfunktionen u.a. für:
  • Ereigniszähler, Frequenzzähler, Impulsfänger
  • Zeitversetzte Ausgänge (Wischrelais, Monoflop)
  • Impulserzeugung, PWM
  • Sensor-Linearisierung
  • BgMem Dateisystem zur Ablage von Datensätzen
  • Preise
  • Detailinfo
  • Einführung
  • Handbuch
  • Tutorial

auf Anfrage *

SFT-MCAT2.2 ARM

Entwicklungs-Hilfsmittel für die Programmierung von Firmware auf dem mCAT 2.2 Echtzeitkern. Mit ANSI-C-Compiler für ARM7 und TLCS-900 (nur für ELZET80-Hardware). 400 seitiges Handbuch, Beispielprogramm, Download-MAKE und diverse andere Utilities. 6 Monate eingeschränkte Anwendungsunterstützung per E-Mail.

auf Anfrage *

SFT-MCAT2SUP

Verlängerung der Supportperiode um ein Jahr (begrenzte Anwendungsunterstützung und Update-Anspruch). Ohne Kosten für Datenträger oder Handbücher zu Updates.

Keine Runtime-Kosten!

Bei allen unseren Produkten mit mCAT Firmware gehört die Runtime-Lizenz zum Lieferumfang. Es entstehen Ihnen also über die Entwicklerlizenz hinaus keine Kosten für den Einsatz von mCAT auf unserer Hardware.

auf Anfrage *

HDB-MCAT2

mCAT2-Handbuch separat

* alle Preise (innerhalb Deutschlands zzgl. MwSt.) ab Werk
** Zur Verwendung mit ELZET 80-Produkten

Ein Echtzeitkern ermöglicht die Aufteilung einer Programmieraufgabe in Einzelprogramme für z.B. Ablauf, Regelung, PC-Kommunikation etc. und nutzt die Wartezeiten jedes Teilprogramms, um die anderen quasi-gleichzeitig laufen zu lassen.

mCATs "Express-I/O" zählt so z.B. auf normalen digitalen Eingängen - es schaut alle 10ms nach, ob der Eingang sich verändert hat, wenn ja, wird der entsprechende Zähler hochgesetzt. Ihre PC-Kommunikationstask z.B. nutzt den seriellen Interrupttreiber SerDrv: Programmiert man diesen etwa auf CR als Telegrammende, dann sendet SerDrv eine Nachricht an Ihre Task, wenn eine Anforderungszeile vom PC komplett eingegangen ist. Ihre Task wird durch die Nachricht geweckt (dabei wird noch der Vorrang evtl. wichtigerer Tasks berücksichtigt) und kann dann beispielsweise mit Statusinformationen antworten. Während diese Antwort durch SerDrv im Hintergrund per Interrupt versandt wird, läuft schon wieder eine andere Task Ihrer Anwendung.

In ähnlicher Weise wartet Ihre Task z.B. auf ein Ethernet-Telegramm über die TCP/IP-Socket-Schnittstelle.

mCAT wurde entwickelt als Echtzeitkern für eine (BITBUS-) Feldbus-Umgebung - sowohl für den Master als auch für die Slaves. Entsprechend der BITBUS-Maxime des Distributed Control (verteilte Intelligenz) statt zentraler Mono-Steuerung mit vielen E/A (distributed-i/o) ist mCAT optimiert auf Nachrichtenverarbeitung zwischen Tasks und Netz im Slave und nicht auf E/A-Zugriff. Die Ethernet-Integration geschieht demzufolge organisch über das Standard-Nachrichtensystem.

mCAT - Eine Einführung

Hier ist die Liste der Vorteile:

Mehrere Tasks parallel

Unabhängige Programme können nebeneinander unterschiedliche Aufgaben wie Bedienerkommunikation, Druckregelung oder Ablaufsteuerung durchführen.

Modularität

Wenn es leicht gemacht wird, Aufgaben in separate Programme aufzuteilen, tendiert der Programmierer dazu, dies zu nutzen und logisch zusammengehörende Funktionen in abgeschlossene Tasks auszulagern. Diese können separat entwanzt und getestet werden. Es ist sehr wahrscheinlich, dass diese Tasks dann nicht nur für die aktuelle Automatisierungsaufgabe eingesetzt werden können, sondern mehrfach wiederverwendbar sind.

Interrupttreiber

Interrupts können unter mCAT durch anwendergeschriebenen (C-)Code in sauberer und konsistenter Weise behandelt werden. Auch sie lassen sich häufig wiederverwerten.

Funktionsbibliotheken

mCAT´s modulares Bibliothekssystem "Shared Library" beherbergt schon den Kernel und wird, je nach Aufgabe und Hardware, erweitert. Auch Anwender können eigene Bibiotheken schreiben, die dann in gleicher Weise über System-Calls aufgerufen werden können wie die Systemfunktionen.

Hilfsprogramme

Ein Monitor zeigt Speicher und den Status von Tasks und Interrupts. Er dient als Empfangsmedium für Programm- Downloads in RAM oder Flash-EPROM. Ein Ticker bewirkt die Zeitsteuerung von Tasks, während der BITBUS-Treiber den Rechner zum Feldbus hin öffnet.

 

Grundfunktionen

Zunächst ist mCAT eine hilfreiche Umgebung auch für einfache Programme ohne Echtzeitansprüche. Der in mCAT integrierte Monitor ist z.B. Empfangsstelle für über die RS232- oder Telenet- Schnittstelle hinuntergeladenen Hex-Dateien (.shx), auch für die Verbringung dieser Programme ins Flash-EPROM. Der Monitor listet den Speicherinhalt, setzt E/A- oder Speicheradressen, schreibt und liest das serielle EEPROM und verfügt über weitere Hilfsmittel für den Umgang mit Tasks. So ist es, unter Verwendung mitgelieferter Schablonen, recht einfach, ein "hello world"-Programm zu schreiben und zu erweitern, auch wenn dazu ein Taskvorspann als Verwaltungsinformation für mCAT nötig ist.

Auch für den Umgang mit dem ARMCPU C-Cross-Compiler und spezieller Zielhardware, also z.B. TSM-CPUH2 oder NET/900h kann Ihnen mCAT viel Arbeit abnehmen: Das "VMAKE"-Programm führt nacheinander für Sie den Compiler, Assembler und Linker aus und füttert die Programme mit den Adressen der jeweiligen Zielhardware - noch unterschieden nach RAM- oder FEPROMBetrieb. Dazu müssen lediglich in einer Steuerdatei namens "MAKEFILE" die gewünschten Angaben zur Zielhardware eingetragen werden.

Echtzeitbetrieb: Tasks und Nachrichten

mCAT ist ein Multitask-Kern, er dient also der Verwaltung vieler Tasks, wie die einzelnen Programme in einem Echtzeit- Betriebssystem heißen. 16 parallele Tasks sind bei mCAT möglich, welche davon derzeit läuft, ist zunächst davon abhängig, ob die Task auf eine Nachricht wartet oder laufbereit ist. Sind mehrere Tasks laufbereit, so entscheidet ihre Priorität (Rangkennzahl) darüber, welcher nun der Prozessor zugeteilt wird. Typische Automatisierungsprozesse sind gekennzeichnet durch Wartesituationen, daher kommt es recht selten vor, dass mehrere Tasks gleichzeitig laufbereit sind. Wird aber eine hochpriore Task laufbereit, während eine rangniedrigere noch läuft, so wird diese einfach unterbrochen und, gegebenenfalls nach weiteren Unterbrechungen durch noch wichtigere Tasks, schließlich da fortgesetzt, wo sie unterbrochen wurde. Dieses Verfahren von mCAT nennt der Prozessinformatiker "preemptives Multitasking".

mCAT kann, wie es für industrielle Automatisierungssysteme nötig ist, ereignis- oder zeitgesteuert arbeiten. Für die Reaktion auf Ereignisse benutzt mCAT Interrupttreiber, also in C oder Assembler codierte, möglichst kurze Programme, die von Hardware-Interrupts (z.B. Zählerstand erreicht, Zeichen an serieller Schnittstelle eingetroffen usw.) gestartet werden. Meist senden die Interrupttreiber nach jedem oder einigen akkumulierten Interrupts (z.B. nach Erkennung eines Endezeichens an der seriellen Schnittstelle) eine Nachricht an die Task, die sich darum beworben hat. Für die Zeitsteuerung ist ein System-Interrupttreiber vorhanden, der Ihrer Task in den gewünschten Intervallen oder für einen einzigen Zeitpunkt eine (leere) Nachricht mit der gewünschten Priorität schickt.

Tasks im Detail

Eine mCAT-Task besteht nicht nur aus der von Ihnen zu schreibenden Programmprozedur TaskMain(), sondern vorweg noch aus dem Vorspann (Header) und dem Startcode (Init). Der Vorspann enthält in Tabellenform Kennung, Taskname, Startpriorität, Versionsnummer, Stackgröße etc. Nach Reset durchsucht mCAT den Speicher nach solchen Vorspann-Tabellen, die bei mCAT auch IMD (Initial Module Descriptor) genannt werden. Findet er anhand der Kennung einen, wird zunächst der Startcode ausgeführt. Der Startcode wird nur einmal bei Reset oder Einschalten durchlaufen und enthält normalerweise die Abfrage (TaskStartup) der von mCAT zugewiesenen Tasknummer. Danach führt er evtl. nötige (Hardware-) Initialisierungen durch. Dann fügt mCAT die Task in die Reihe der aktiven (laufbereiten) Tasks ein. Hat sie die höchste Priorität, so startet mCAT die Prozedur TaskMain() sofort.

Nachrichten

Verteilte Steuerungsarchitekturen senden sich gegenseitig Nachrichten (message passing), da andere Mechanismen, wie globale Variablen oder Flags im globalen Speicher auf eine CPU begrenzt sind.

Warum Nachrichtenaustausch?

Obwohl die Anforderungen der verteilten Steuerung dazu zwingen, hat Nachrichtenaustausch auch große Vorteile gegenüber anderen Lösungen, weil es zu einem wirklich modularen Design mit wirklich wiederverwendbaren Modulen zwingt. Jede Programmieraufgabe kann in Kunden- und Dienstleisterprozesse (Client/Server) aufgeteilt werden, wobei die Dienstleisterprozesse meist universell benutzbar sind. Betrachten wir z.B. eine Dienstleistertask, die gefilterte Analogdaten zur Verfügung stellen soll. Sie benötigt von der Kundentask eine Startnachricht, in der die abzutastenden Kanäle angegeben sind, das Abtastintervall und die Art und Tiefe des Filters. Anschließend fragt die Kundentask mit einer Anforderungsnachricht (Request) nur noch nach einem aktuellen Datensatz. Angenommen, bei einem anderen Projekt müssten die Daten gleich erfasst werden, allerdings müssten spezielle Sensorlinearisierungen und Alarmüberwachungen zusätzlich eingeführt werden. Die Dienstleistungstask kann nun um diese Funktion erweitert werden und reagiert dann auf zusätzliche Nachrichten zur Festlegung der Linearisierungskennlinie etc. Durch das Konzept des Nachrichtenaustauschs kann das alte Programm aber in gehabter Weise auf die neue, erweiterte Dienstleistungstask zugreifen, da diese unverändert auch die alten Anforderungen beantworten kann. Inkompatibilitätsprobleme durch erweiterte Parameterlisten etc. sind also hinfällig. Weitergedacht ließe sich die Datensammlung auch auf eine separate, externe Hardware ausdehnen, ohne an der Nachrichtenstruktur etwas ändern zu müssen.

Die Standpunkte von Kunde und Dienstleister sind übrigens willkürlich, da jede Task gleichzeitig beides sein kann: Die Kundentask Regler wird gegenüber überlagerten Softwareschichten wieder als Dienstleister auftreten, der einen Sollwert einregelt. Auch hier zeigen sich die Vorteile des "message passing".

Vorrang-Nachrichten

Anders als andere Echtzeitkerne arbeitet mCAT mit dynamisch veränderlichen Task-Prioritäten. Nur die Startpriorität wird fest codiert, danach richtet sie sich nach den ankommenden Nachrichten. Eine Task "erbt" bei mCAT die Priorität der ankommenden Nachricht. Dieses Konzept lebt von der Annahme, dass die anfragende Kundentask eher als der Dienstleister weiß, wie wichtig die Anfrage ist. Außerdem bietet diese Herangehensweise den Vorteil, als Dienstleister auf unterschiedlich "wichtige " Kunden unterschiedlich reagieren zu können. Selbst wenn die Task schon bei niedriger Priorität arbeitet, macht sich eine wichtige Nachricht bemerkbar: Die Task wird sofort auf die höhere Priorität gesetzt (und kann damit die laufende Arbeit schnellstmöglich zu Ende bringen, um dann die wichtige Nachricht zu bearbeiten).

Warteschlangen (Queues)

Jede Task hat eine Warteschlange, in der alle Nachrichten zwischengespeichert werden. Dabei werden die Nachrichten nach ihrer Priorität geordnet, bei gleicher Priorität nach Alter. Die Anzeigetask kann also z.B. eine Meldung von der Alarmüberwachung aN drei Istwertnachrichten vorbei aufs Display bringen.

Nachrichten unterscheiden

Eine Nachricht bei mCAT ist eine Datenstruktur, bestehend aus Vorspann und Datenbereich. Im Vorspann finden sich Informationen über die Quelltask, die Priorität und die (normalerweise gleiche) Antwortpriorität, die Länge und die Nachrichtentyp-Kennung MSGID, mit der Nachrichtenquellen unterschieden werden können. MSGID ist nicht auf eine Nachricht bezogen, sondern gruppiert alle Nachrichten einer Art, z.B. alle Zeitgeber-Nachrichten oder alle Nachrichten von einem Ethernet- Socket. Die Nachrichtentypen werden mit MSGID und ASCII-Namen vom mCAT verwaltet und können über eine Systemfunktion unter ihrem Namen gesucht werden. Normalerweise erzeugt der Dienstleister (mit MsgCreate) einen Nachrichtentyp, da er weiß, wie eine Anfrage an ihn strukturiert sein soll.

Warten auf eine Nachricht

Der häufigste Zustand einer Task ist der Wartezustand nach dem Systemaufruf MsgWait. Hinter diesem Aufruf wartet die Task auf Zeitnachrichten vom Ticker, auf andere vom BITBUS oder vom A/D- Interrupttreiber. Die erste Aktion, wenn die Task wieder den Prozessor bekommt (d.h. wenn eine Nachricht eingetroffen ist), muss dann sein, den Nachrichtentyp anhand des MSGID zu erkennen, um ggf. in Behandlungsprozeduren für unterschiedliche Nachrichten zu verzweigen.

Threads und Spezialwarteschlangen

Werden die Aufgaben komplexer, kann man innerhalb einer Task mehrere Threads definieren, das sind Prozesse, die wie Tasks unabhängig erzeugt, aktiviert, priorisiert und suspendiert werden können, jedoch nicht global adressierbar sind. Man kann jedem Thread eine eigene Warteschlange zuweisen, so dass Daten gleicher Art schnell und ohne Fallprüfung bearbeitet werden können. Threads gleicher Priorität können im Reihum-Verfahren aktiv werden, wobei entweder ein Zeitlimit oder der Aufruf ThreadSlice den Prozessor an den nächsten Thread weitergibt. Diese Vorgehensweise ist günstig für Ablaufsteuerungen, um Wartebedingungen reihum auf Erfüllung abzufragen und den Prozessor bei Nichterfüllung mit ThreadSlice weiterzugeben.

Den Aufbau einer komplexeren Task mit Threads und Spezialwarteschlangen zeigt die Grafik.

[Grafik fehlt]

Beispiel

Als Beispiel für die Codierung haben wir eine einfache Kundentask dargestellt, die alle Sekunde vom Ticker eine Nachricht anfordert und auf diese Nachricht hin einen Zähler (pock) hochzählt und anzeigt. Das Programm beginnt mit der Angabe der nötigen Header-Dateien (xxx.h). MCAT.H schließt ihrerseits diverse andere Header-Dateien mit den grundlegenden Datenstrukturen von mCAT (IMD.H, MSG.H etc.) ein. TICKER.H liefert die Struktur des Nachrichtentyps TickerMsg und die Funktionsdefinitionen von ALL und AFTER zur Anforderung von Tickernachrichten.

[Grafik fehlt]

IMD

Mit dem Dienstprogramm IMD.EXE wird der Taskvorspann generiert und hier über #include eingefügt. Zur Änderung der Startpriorität etc. wäre also die Datei ticktest.imd zu bearbeiten.

INIT

Hier wird die eigentliche Task ( bzw. Interrupttreiber, ShLib ) erzeugt und erhält ihre Nummer. Danach können noch ( hier nicht nötig ) Peripherie-Initialisierungen vorgenommen werden.

MAIN

Das Hauptprogramm startet mit der Anfrage an den Ticker, alle Sekunde (1000ms) geweckt werden zu wollen. Dazu gibt es die bequeme Funktion ALL. Danach geht es in eine Endlosschleife, die mit dem Warten auf eine Nachricht startet, nämlich mit dem Systemaufruf MsgWait (mit den Parametern 0=kein Timeout und 0=Standard-Warteschlange). Wenn die Nachricht kommt, wird zunächst geprüft, ob sie die Kennung TickerID hat. Wenn ja, wird der Zähler "pock" erhöht und ausgegeben. Um den Sender der Nachricht darüber zu informieren, dass sie angekommen ist, wird der Systemaufruf MsgSendReply mit positiver Quittung "ACK " gestartet. Dies ist eine einfache Echtzeittask unter mCAT. Sie wird auf Diskette als Schablone für eigene Erweiterungen mitgeliefert. Wenn man bedenkt, dass die Bereiche IMD und INIT meist gleich sind und aus bestehenden Programmen übernommen werden können, und auch die Definition der Nachrichten und der Aufruf von MsgWait meist gleich bleiben, sind die eigentlichen Änderungen hinter dem MsgWait fällig. Es scheint also nur auf den ersten Blick kompliziert zu sein - das eigentliche Programm ist kurz und spielt sich nach Eingang der Nachricht ab. Als Belohnung für die Schreibarbeit kann man bei mCAT nun aber die Flexibilität des Nachrichtenaustauschs, der Zeitplanung und Ereignistriggerung eines Echtzeitbetriebssystems in Anspruch nehmen.

Interrupttreiber

Ein Interrupttreiber ist ganz ähnlich wie eine Task aufgebaut, auch mit IMD (wobei ein Parameter die Task vom Interrupttreiber unterscheidet) und INIT- Prozedur, dann aber aufgeteilt in MAIN-Bereich in die Prozeduren für SERVICE, WAKEUP und NOTIFY. SERVICE bedient den eigentlich Hardwareinterrupt, WAKEUP bearbeitet eingehende Nachrichten, die auch ein Interrupttreiber benötigt, z.B. zur Parametrierung seines Verhaltens. NOTIFY schließlich ist eine Sonderform des Nachrichteneingangs für lokale Bestätigungsantworten.

Die ShLib Bibliothek

mCAT ist von Grund auf modular aufgebaut. Alle Programme (auch schon der Kernel) sind Teil einer gemeinsam benutzbaren Bibliothek (Shared Library, ShLib), die über Systemaufrufe angesprochen wird. Diese Modularität lässt sich auf Anwenderebene weiterführen, denn die ShLib kann auch durch Anwender-Bibliotheken erweitert werden.

Erweiterungen

Neben eher im Verborgenen bleibenden Dienstprogrammen wie dem Speicherverwalter und dem schon eher sichtbaren Verwalter für die nichtflüchtigen Speicher (serielle EEPROMs und Flash- EPROM) ist noch die Auskunftei von mCAT erwähnenswert: Der NameServer unterhält ein Verzeichnis von Tasks, Nachrichten und Interrupttreibern, die über ihren Namen (ASCII) gesucht werden können. Dies ermöglicht wirklich dynamischen Aufbau von Programmen, da immer nach dem Namen möglicherweise vorhandener Systembestandteile gesucht werden kann - ohne Wissen über Kennungen etc.

Express I/O

mCAT macht es leicht, Module hinzuzufügen, daher erweitert ELZET80 ständig die Funktionalität von mCAT um die Programmierung schneller und leichter zu machen. Die Erweiterung mit dem höchsten Zeitspareffekt ist Express-I/O - mit Zugriff auf analoge und digitale Eingänge bzw. Ausgänge in einheitlicher Weise - frei von den Widrigkeiten der Bitebene. E/A-Objekte können mit einem griffigen Namen für alle wichtigen Ports definiert werden (bei TSM z.B. für alle E/A-Ports auf der CPU und allen aktuellen E/A-Modulen). Der Zugriff erfolgt über Macros wie z.B. out(&Bandgeschwindigkeit,176). Darüberhinaus bietet Express-I/O Hintergrundfunktionen, die aus normalen E/A-Ports Impulsfänger, Zähler oder Monoflops machen. Express-I/O kann auch Events erzeugen, z.B. wenn die Polarität an einem Eingang wechselt: Eine beliebige Taste erhält darüber eine Nachricht.

SerCrv

Die derzeit mit mCAT gelieferten Treiber für die seriellen Schnittstellen sind einfache Polling-Treiber. Interruptgetriebene Treiber mit Pufferverwaltung sind aber alternativ über eine Nachrichtenschnittstelle anzusprechen. Dieser SerDrv ermöglicht Telegrammprüfung auf Treiberebene, also z.B. Warten auf bestimmte Start- und Endezeichen, eine einstellbare Telegrammlänge o.dgl.

BgMem

Für Anwendungen wie Rezeptverwaltung, Datenlogger, Betriebsstundenzählung oder Auftragsliste steht das Modul BgMem zur Verfügung - ein Speichermechanismus für Datensätze gleicher Länge. Mit den Speicheroptionen FIFO, LIFO, Ringspeicher oder wahlfrei indiziert passt BgMem sich den Anforderungen an die verschiedenen Log-Typen oder mehr datenbankartiger Speicherung an. Einzelne Datensätze und die ganze Datei sind mit CRC-Erzeugung und -prüfung gesichert; wenn eine Echtzeituhr verfügbar ist, sind Dateierzeugungs- und -änderungszeitpunkte abfragbar. BgMem benötigt Hardware mit batteriegestütztem Speicher. Für weitere Hardware ist Unterstützung in Form von Tasks lieferbar, die den E/A-Zugriff auf unterster Ebene durchführen und als Nachrichten-Schnittstelle anbieten, z.B. für Tastatur und LCD auf eTerm.

BITBUS

BITBUS ist eine der Erweiterungen, die nicht jeder unter mCAT benötigt, obwohl die Mehrzahl der Anwendungen schon Feldbusse unterstützt. Die BITBUS - Unterstützung unter mCAT besteht aus dem Interrupttreiber BitbusDrv und der GBS/RAC-Task. Zum BITBUS-Verkehr bedarf es einfachen Nachrichtenaustauschs wie mit anderen Tasks: Man fragt mit MsgIdQuery nach der Kennung MSGID des Treibers "BitbusName", dann wartet man mit der normalen MsgWait-Funktion auf hereinkommende Nachrichten und überprüft, ob der MSGID einer BITBUS -Nachricht entspricht. Der Datenteil der Nachricht ist dann die originäre BITBUS-Nachricht. Zurückgeschickt wird die Nachricht dann ganz einfach als mCAT-Antwort mit MsgSendReply.

Vom Bitbus-Master aus ist Ihre Task über eine Funktionskennung (Function-ID) ausfindig zu machen, die ein Parameter im Vorspann (IMD) Ihrer Task ist.

Ethernet

mCAT V2.0 läuft auf der ethernode® TSM-ARMCPU, TSM-CPUH2, DinX, allen IPC-BIT900 und PER-NET/900H und H+, damit auch auf allen Produkten, bei denen diese aufgesteckt werden können.

Hardwarevoraussetzungen:

Ein 80x86 Computer mit einer seriellen Schnittstelle, gegebenenfalls Bitbus und Ethernet.

Hier finden Sie das 400-seitige Handbuch zu mCAT2.2 (PDF-Datei, 8,6MB)

"Hello World" - Tutorial