ZitierenHallo an alle.
Es geht ja doch noch OnTopic weiter, das freut mich für das Ursprungsthema.
Darf ich nochmals ganz uneitel meinen oben dargestellten Ansatz ins Spiel bringen?
Centronics bietet 1 Byte bidirektional, 4 ControlBits output und 5 StatusBits input. Soweit die leicht recherchierbaren Fakten.
Wenn man die knappe Zahl der Centronics-I/O-Leitungen über Registerbausteine an einem externen Bus erweitern will, wird eine triviale Busablaufsteuerung in SW-fällig. Um sich von der nicht vorhersehbaren Arbeitsgeschwindigkeit des PC unabhängig machen, kann sich die SW a) auf ein freilaufendes externes Taktsignal synchronisieren und Flanke für Flanke die Bussteuerung durchtickern (das muß möglich sein) oder SW-seitig ein externes Zeitglied triggern, dessen Zustand einlesen und das Ganze als Mikrosekundendelay verwenden (das habe ich erfolgreich implementiert).
Fall a) ermöglicht (2^4)x8 Ein- oder Ausgänge, hat aber etwas mehr Leerlaufzeiten. Fall b) ist etwas zeitsparender, man verliert aber durch das TriggerBit die Hälfte der möglichen I/Os.
Mit einer Mikrosekunde als Zeitbasis kommt bei mir auch ein LCD-Modul als langsamste Peripherie klar; ansonsten bietet sich noch Tuning des Bustimings an, um etwas Zeit zu gewinnen.
Auf DOS-Basis habe ich schon recht umfängliche ISRs im 1ms-Raster realisiert, die auch auf einem 33MHz-368er-Uraltlaptop problemlos liefen. Dazu macht man dem DOS-Echtzeituhr-Timer gehörig Beine und klinkt die eigene ISR in den Anwenderinterrupt ein - prinzipiell vergleichbar mit dem Vorgehen bei einem Controller. Warum nur?
Der Einsatz eines RT-OS ist nicht zwingend; unter DOS gehört einem der PC so gut wie alleine; jedenfalls pfuscht niemand an der Centronics rum, solange das eigene Programm läuft ...
Ein ernstzunehmender Schwachpunkt ist allerdings der fehlende ereignisabhängige ISR-Aufruf via Centronics.
Wenn daran Interesse besteht, kann ich Eagles und C-Source gerne weiterreichen.
Gruß
Christian.
Zitat von 021aet04
Lesezeichen