Synchronschleifen- oder Timer

ten

kommt drauf an wie genau du's brauchst.
mit ein paar tricks wie hochsetzen der threadpriorität auf maximum und der winapi-funktion 'timeBeginPeriod' (damit kann man die 'granularität' der scheduler-ticks verstellen), kannste in grenzen was ausrichten.
wenn das nicht reicht, dann musste das im kernel mode machen, alle interrupts und den taskswitcher temporär disablen usw.
oder du nimmst 'ne realtime extension software für windoofs (ich kenn' da aber leider nix was free ist)

Ich schieb das man nach rudpf. Ich denke da ist der Thread fast besser aufgehoben als in WinAPI.

C++ Forumbot

Dieser Thread wurde von Moderator/in TactX aus dem Forum ANSI C in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Mal vorweg: Du benutzt das wort Synchron hier vollkommen falsch. http://de.wikipedia.org/wiki/Synchronität
Synchron bedeutet Gleichzeitig, was Du willst ist Gleichmässig.

Zum eigendlichen Problem: Das was du da machen willst geht mit Windows XP schlicht nicht, weil windowsXp kein Echtzeitbetriebssystem ist:
http://de.wikipedia.org/wiki/Echtzeitbetriebssystem.

Selbst wenn Du einen entsprechenden Timer laufen hast wird der Aufruf der Timerfunktion immer schwanken weil Du keinen einfluß darauf hast was der computer gerade noch ales macht (->preemtives Multitasking).

Marc++us

Grundsätzlich ist so eine Applikation auch mit Windows oder Linux möglich, sofern man im notwendigen Zeittakt nicht zu weit runter geht... und 250000mal pro Sekunde ist definitiv zu weit.

Dafür braucht man eigene Echtzeitkernel-Erweiterungen, Kithara zum Beispiel ist eine:

http://www.kithara.de/

hustbaer

Windows und Linux sind beides keine Echtzeitsysteme, die 250.000 mal/Sekunde kannste also ganz schnell vergessen. Ganz davon abgesehen dass 250.000 mal/Sekunde nichtmal auf einem Echtzeitbetriebssystem (RTOS) einfach hinzubekommen ist, nicht mit PC Hardware.

Auf 10.000/Sekunde kommste mit nem guten RTOS, mit Windows würde ich mich nicht trauen mehr als ~~500/Sekunde zu machen, wobei du da schon mit einem Jitter von 1-2ms rechnen musst. UND du brauchst dafür schon einen hardware Interrupt der alle 2ms triggert.

Auf guat deitsch: vergiss es

ten

hustbaer schrieb:

Ganz davon abgesehen dass 250.000 mal/Sekunde nichtmal auf einem Echtzeitbetriebssystem (RTOS) einfach hinzubekommen ist, nicht mit PC Hardware.

1/4 Mhz ist doch lächerlich langsam.
weisst du mit welchen taktraten ein aktueller PC arbeitet?
der schläft ein dabei...

Nimm doch ein einfaches echtzeitfähiges System (irgendsoein Starter-kit, wir haben es mit Infineon C167 gemacht), das du dann unter deinem WinXP programmieren kannst :). Oder gleich gscheit (du willst doch bestimmt was regeln?) ein FPGA, da ist man ja die ganze Zeit in dem Timer-Callback drin :).

Auf PC mit Windows wirst du den 4µs-Taktschläger nicht hinbekommen, ohne Betriebssystem schon. Aber es ist nicht gerade bequem zu programmieren und vor allem das Debuggen stelle ich mir wenig spaßig vor.

ten

Superlexx schrieb:

Aber es ist nicht gerade bequem zu programmieren und vor allem das Debuggen stelle ich mir wenig spaßig vor.

ich glaub die pentiums hatten 'ne JTAG schnittstelle eingebaut. ob die heutigen dinger das noch haben, weiss ich aber nicht...

hustbaer

ten schrieb:

hustbaer schrieb:

Ganz davon abgesehen dass 250.000 mal/Sekunde nichtmal auf einem Echtzeitbetriebssystem (RTOS) einfach hinzubekommen ist, nicht mit PC Hardware.

1/4 Mhz ist doch lächerlich langsam.
weisst du mit welchen taktraten ein aktueller PC arbeitet?
der schläft ein dabei...

Aha. Wennst glaubst...
Dass PC Hardware an sich nicht realtime fähig ist hat nichts mit der Taktung der CPU zu tun, sondern eher damit dass die Abarbeitung irgendwelcher Programme jederzeit durch blöde Interrupts unterbrochen werden kann, Interrupts wie den SMI, den du nicht maskieren kannst.
Der wird übrigens gerne hergekommen um Chipset Fehler zu verbergen -- und wenn das Chipset eben glaubt genau *jetzt* einen SMI triggern zu müssen, dann ist das eben so. Kannste nix dagegen machen.
Und da sind IMHO 250.000Hz schon SEHR viel.

ten

hustbaer schrieb:

Dass PC Hardware an sich nicht realtime fähig ist hat nichts mit der Taktung der CPU zu tun, sondern eher damit dass die Abarbeitung irgendwelcher Programme jederzeit durch blöde Interrupts unterbrochen werden kann, Interrupts wie den SMI, den du nicht maskieren kannst.
Der wird übrigens gerne hergekommen um Chipset Fehler zu verbergen -- und wenn das Chipset eben glaubt genau *jetzt* einen SMI triggern zu müssen, dann ist das eben so. Kannste nix dagegen machen.
Und da sind IMHO 250.000Hz schon SEHR viel.

naja, wenn unkontrollierte interrupts reinknallen, dann ist PC-hardware grundsätzlich nicht echtzeitfähig.
aber zur not mach' einfach den pin ab und leg' den auf masse oder, ohne lötkolben, die ISR nur zu einer einzigen 'return from interrupt' instruction
dann ist es nicht mehr ganz so schlimm.

btw: ich hab' mal mit 'nem mit 40Mhz getakteten chip mangels hardware-SPI über bit-banging daten eingelesen, die mit 'ner 1Mhz clock ankamen. da musste man schon taktzyklen zählen und die richtige bufferarchitektur wählen damit das klappt (speichern der daten auf 'ne cf-karte musste aber eine andere CPU machen, dafür hätt's dann doch nicht mehr gereicht). ging aber, obwohl ich anfangs auch am zweifeln war...

hustbaer

ten schrieb:

hustbaer schrieb:

Dass PC Hardware an sich nicht realtime fähig ist hat nichts mit der Taktung der CPU zu tun, sondern eher damit dass die Abarbeitung irgendwelcher Programme jederzeit durch blöde Interrupts unterbrochen werden kann, Interrupts wie den SMI, den du nicht maskieren kannst.
Der wird übrigens gerne hergekommen um Chipset Fehler zu verbergen -- und wenn das Chipset eben glaubt genau *jetzt* einen SMI triggern zu müssen, dann ist das eben so. Kannste nix dagegen machen.
Und da sind IMHO 250.000Hz schon SEHR viel.

naja, wenn unkontrollierte interrupts reinknallen, dann ist PC-hardware grundsätzlich nicht echtzeitfähig.
aber zur not mach' einfach den pin ab und leg' den auf masse oder, ohne lötkolben, die ISR nur zu einer einzigen 'return from interrupt' instruction
dann ist es nicht mehr ganz so schlimm.

btw: ich hab' mal mit 'nem mit 40Mhz getakteten chip mangels hardware-SPI über bit-banging daten eingelesen, die mit 'ner 1Mhz clock ankamen. da musste man schon taktzyklen zählen und die richtige bufferarchitektur wählen damit das klappt (speichern der daten auf 'ne cf-karte musste aber eine andere CPU machen, dafür hätt's dann doch nicht mehr gereicht). ging aber, obwohl ich anfangs auch am zweifeln war...

Mit selektierter PC Hardware geht sicher einiges. Ich meine bloss man kann sich nicht einfach ein Board irgendwo ausm Regal greifen, und dann erwarten damit auf 250.000Hz ohne Dropouts zu kommen. Wenn man das Board natürlich speziell auswählt, u.U. das BIOS oder das Board selbst modifiziert, dann geht sicher mehr.