www.mikrocontroller.net

Forum: PC-Programmierung REAL TIME: Timer-INT öfter als 18.2 * pro Sekunde aufrufen


Autor: Dierk U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

für ein Projekt (Schrittmotorsteuerung via Parallelport) benötige ich
ein fixes Zeitintervall.

Das erste Problem ist, das Zeitintervall soll nicht durch andere
Anwendungen gestört werden, da bei kleinsten Zeitverzögerungen der
Schrittmotor mit dem Steuerprotokoll desynchronisiert, was zu einem
zusätzlichen Drehmomentverlust führt, evlt. kann es sogar zum abrupten
Stillstand führen, besonders bei höheren Umdrehungszahlen (z.B. 250 -
1000 U/min)

Das zweite Problem ist, das Programm soll unter WIN98SE laufen.

Ich habe mir folgendes gedacht:

ich lasse z.B. den PIT-Baustein des PC ab einem fixen Startwert laufen,
hat der Timer zuende gezählt soll über ein Hardware-Interrupt mein
Programm aufgerufen werden, welches dann den nächsten Schaltimpuls für
den Schrittmotortreiber erzeugt. Besonders wichtig ist hier der
Startwert, über ihn kann die Geschwindigkeit des Motors eingestellt
werden... Das Programm schaltet also den nächsten Impuls, und schreibt
in den PIT erneut einen Startwert, worauf es die Kontrolle an andere
Windows-Programme abgibt.

Soweit so gut. Die Frage ist jetzt, funktioniert das?

Soweit ich weiß hat ein PC mindestens einen PIT, häufig sogar zwei.

Falls zwei vorhanden sind: kann ich den sogenannten
"Fail-Safe-Timer", also den zweiten PIT, für mein Vorhaben
mißbrauchen? D.h. der Fail-Safe-Timer ruft über Hardware-Interrupt mein
im Speicher residentes Programm auf, welches den nächsten Impuls an den
Parallelport schickt (und vorher kurz auch schaut, ob evtl. ein Abbruch
durch den USER erfolgt ist), dann wieder den nächsten Startwert in den
PIT schreibt, und mit IRET wieder die Kontrolle an die
Windows-Programme abgibt.

Wenn das alles so möglich ist, wie führe ich das mit wenig
Programmieraufwand durch? Gibts dazu irgendwo Tipps?

Kann ruhig "dreckig" sein, es ist ja klar daß ich die
Windows-Zeitscheibe umgehen möchte um eine Art REAL-TIME-Programmierung
zu bekommen.

Habe allerdings bis jetzt noch kein TSR programmiert.

Möchte das Ganze mit Delphi bzw. TASM schreiben, möglichst
straightforward ohne groß DLLs oder anderen Kram.

Soweit ich weiß erlaubt WIN98SE noch Portzugriffe auf z.B. PIT und
Printer-Port oder stimmt das nicht? Sonst verzichte ich evtl. auf
Windows-GUI und mache es im "MS-DOS-MODE"

Für alle Anregungen vielen Dank,

Grüße,
Dierk

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre das nicht der klassische Einsatz eines µC? Dem überträgst du per
COM lediglich die Aktion, z. B. Drehrichtung rechts, Schrittanzahl
1000. Das ganze Timing erledigt der Controller, genauso wie die Start-
und Bremsrampen. Ich glaube nicht, daß Windows 98 echtzeitfähig ist.
Michael

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur am Rande: Die ernstgemeinten Windows-Versionen arbeiten
standardmäßig mit Timerauflösungen von 15 bzw. 10 msec. Mit einem
einfachen API-Aufruf kann die Timerauflösung auf 1 msec Genauigkeit
erhöht werden ...

Aber dann muss man - igittigitt - Hardware über Devicetreiber anfassen
und das gehört sich ja nicht.

Autor: Dierk U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

nur um das Timing-Problem nochmal zu konkretisieren:

der Motor läuft zur Zeit unter DOS mit Uralt-Hardware und QBASIC(!!)
mit bis zu 4 Umdrehungen pro Sekunde (240 U/min) schrittfehlerfrei, dh.
es werden 4 * 400 = 1600 exakt getimte Schaltvorgänge pro Sekunde am
Parallelport erforderlich - die Timing-Auflösung muß daher deutlich
unter 1 ms liegen.

µC ist momentan (noch) keine Lösung, da dadurch weitere Kosten
entstehen - eigentlich sind in einem PC auch schon genug µC drin... wie
z.B. der Timerbaustein - die Frage ist halt, wie man das System
"umgeht" und sozusagen ein kleines ASM-Programm von ein paar Bytes zu
fest definierten Zeitintervallen (="hard real time") unabhängig von
Windows-Prozeßen aufrufen kann... die Abarbeitung ist dann so schnell
daß es niemanden (auch keine anderen DAQ-Programme) stört. Evlt. den
Windows-Timer-API hooken? Ich möchte halt so low-level wie möglich
gehen ohne viel Overhead...

Habe schon gelesen daß manche es über eine 16bit DLL versuchen um so
aus der Protected-Mode-Falle (in der keine direkten Portzugriffe
möglich sind) herauszukommen...

Tipps?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

eben das will ja Windows und jedes andere ordentlich (nicht RT)
Multiprozessing-OS verhindern.
Du sollst nicht auf die Hardware zugreifen sondern immer über
API-Funktionen des OS gehen. Und da kann dir der Scheduler halt
dazwischenhauen wie er grade will und dir auch mal für 100ms den
Prozessor entziehen.

DOS ist kein Multiprozessing-OS. Da gehört dir der Prozessor ganz
alleine bis du ihn wieder abgiebst.

Wenn das für dich nicht aktzektabel ist mußt du auf etwas setzen was
echte Echtzeit kann. Also z.B. die von Michael vorgeschlagene Lösung
mit seperatem µC der nur noch Kommandos empfängt.

Matthias

Autor: Dierk U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, ok.

Wie ist das mit "Sleep"? Anscheinend kann man die Granularität der
Zeitscheibe bis auf 1 ms herabsetzen... das ist zwar nicht das was ich
eigentlich wollte (ich wollte das System veranlassen, nach einer fixen
Zeit mein Programm aufzurufen) aber vielleicht tut das auch, wenn man
in der Zwischenzeit die Zeit pollt.

Ich brauche die < 1ms Auflösung nur für den Fall, daß der Motor schnell
vor- bzw. zurückfahren muß (so wie fast forward / rewind beim Tapedeck),
dies ist die Ausnahmesituation, während der notfalls der Rechner auch
100% der Rechenzeit mit meinem Task verbringen darf. Die meiste Zeit
sind die Anforderungen einiges geringer.

Dann gibts da noch die directX-timer, zum Teil werden die zur Kontrolle
der Framerate eingesetzt... mal schauen.

Grüße,
Dierk

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, wenn irgendwelches Hardwaregefummel mit Timerauflösungen < 1 msec
erforderlich ist, dann sollte das in einem Devicetreiber geschehen.
Alternativ könnte eine der verschiedenen verfügbaren
"Realtime"-Erweiterungen verwendet werden - Windows ist schließlich
kein Echtzeitbetriebssystem.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Dirk U,
schau dir mal bei www.ros.de die Karte Stepper 8 an. Wenn du mit den
Leistungen hinkommst, melde dich bei mir. Von den Karten haben wir noch
einige hundert (aus einer Konkursmasse). Die Programmierung erfolgt dann
über die serielle Schnittstelle vom PC. Und dann bist du die
Timingprobleme los.
Michael

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.