Events

hustbaer

ich kenne kein System welches auf 200 CPU cycles genau irgendwas machen könnte
timer die "events" generieren arbeiten üblicherweise über interrupts

EDIT: vertipper korrigiert

hustbaer schrieb:

timer die "events" generieren arbeiten üblicherweise über interrupts

...oder callback-funktionen.

Schurke

und wie funktioniert son interrupt oder ne callback funktion am beispiel timer?

Ben04

Das hängt davon ab was das OS dir erlaubt. Es ist gut möglich, dass dir gar kein direkter Zugriff auf Interrupts zur Verfügung steht und du die vom OS angebotenen Timerfunktionen nutzen musst.

hustbaer

~fricky schrieb:

hustbaer schrieb:

timer die "events" generieren arbeiten üblicherweise über interrupts

...oder callback-funktionen.

Ich meinte damit dass das OS (welches die Timer üblicherweise implementiert) nen Interrupt verwendet. Denn so ein Callback muss ja auch irgendwie ausgelöst werden. Und wenn man weit genug "zurück" geht, dann landet man (fast immer) irgendwann bei einem Interrupt der von irgendeinem Hardware-Teil (z.B. Timer-Chip) ausgelöst wird.

@Schurke:
OK, hat Ben04 schon geschrieben, nur nochmal mit anderen Worten.

und wie funktioniert son interrupt oder ne callback funktion am beispiel timer?

Normalerweise hast du, als "normales Programm", keinen Zugriff auf irgendwelche Interrupts, zumindest nicht aus Betriebssystemen wie Windows oder Linux.
D.h. du kannst deine Timer wieder nur über die OS-Funktionen implementieren. D.h. du wirst wohl einen OS-Timer verwenden müssen um "deine" Timer "anzutreiben".

Auf OS-Ebene kenne ich 2 Arten wie Timer implementiert werden:

Es gibt einen fixen "Heartbeat" Interrupt der z.B. alle 10 oder 20ms feuert. In diesem Interrupt checkt das OS dann einfach welche Timer "abgelaufen" sind, und sorgt dafür dass die nötigen Aktionen (Events setzen, Callbacks ausführen - was auch immer) baldmöglichst ausgeführt werden.
Das OS ermittelt bei jedem "SetTimer()" welches der Timer ist der als nächstes ablaufen wird, und programmiert nötigenfalls den Timer-Chip um, damit dieser früh genug einen Interrupt auslöst. Im Interrupt wird dann wie bei Variante 1 dafür gesorgt dass die Timer die "dran" sind tun was sie tun sollen, und der Timer-Chip wieder für den "nächsten" Timer umprogrammiert.

Windows verwendet für alle mir bekannten Timer Variante (1). Wenn ich raten müsste würde ich sagen dass die meisten "General-Purpose" Betriebssysteme das so machen, weil es viel weniger Overhead ist (Hardware ansprechen dauert "extrem" lange, d.h. es wäre recht "teuer" den Timer-Chip andauernd umzuprogrammieren, und meist reicht eine Genauigkeit von 5 oder 10ms locker aus).

----

Wenn du möchtest kannst du natürlich genau das was das OS schon macht selbst nochmal "nachprogrammieren", indem du statt des Timer-Chips halt einen einzigen OS-Timer verwendest für alle deine "eigenen Timer" Instanzen. Bis auf "Lernen wie mans macht" ist der Sinn allerdings fraglich.

hustbaer schrieb:

Wenn ich raten müsste würde ich sagen dass die meisten "General-Purpose" Betriebssysteme das so machen, weil es viel weniger Overhead ist (Hardware ansprechen dauert "extrem" lange, d.h. es wäre recht "teuer" den Timer-Chip andauernd umzuprogrammieren, und meist reicht eine Genauigkeit von 5 oder 10ms locker aus).

ansprechen von hardware dauert überhaupt nicht lange. wie kommst du darauf? vor allem sowas wie das umprogrammieren eines timer-chips ist mit wenigen zugriffen erledigt. variante(1) hat übrigens den nachteil, dass eine einzige timer-ISR (oder vielleicht ein DPC) eine unmenge an code durchlaufen muss, um alles zu behandeln, dass von timer-ticks abhängig ist. *das* ist teuer.

pointercrash**

Wenn Du unter 5 ms reagieren willst, warum nimmst Du dann nicht gleich ein Realtime- OS? In meiner Studienzeit hatte ich ein Praktikum auf einer OS-9- Kiste, mit der es gar kein Aufwand war, hochpriorisierte Tasks anzulegen. Ein Freund von mir schwört auf QNX (http://www.qnx.com), das quelloffen und für nichtkommerzielle Nutzung kostenlos ist. Gibt aber auch andere POSIX- Derivate mit gleicher Zielsetzung.

Windows und Linux haben andere Zielsetzungen als RT und sind eigentlich gar nicht dafür geeignet, aber es gibt fertige RT- Subsysteme, die sich vom Host die Ressourcen klauen und selbst vergeben. Guckst Du mal hier für Windows http://www.codeproject.com/KB/system/RealTimeModule.aspx, das ist sogar mit Beispielen. Aus den Sourcen ist zudem auch ersichtlich, wie man am OS vorbei auf die HW bzw. den HAL kommt. Für Linux gibt es natürlich auch ein RT- Subsystem, mach' Dich mal hier schlau http://rt.wiki.kernel.org/index.php/Main_Page
Auf jeden Fall mußt Du Dich dann nicht verkopfen, wie Du an die Timer usw. rankommst.

pointercrash() schrieb:

Guckst Du mal hier für Windows http://www.codeproject.com/KB/system/RealTimeModule.aspx, das ist sogar mit Beispielen.

das ist aber nur 'ne demo. die eigentliche RTX wollen die geld haben, so wie's aussieht (unverschämtheit, dass heutzutage manche für nur-software immer noch kohle haben wollen).
btw, wenn ich'n RTOS auf 'ner pc-kiste haben wollte, würde ich nicht windows was unterjubeln, sondern vielleicht 'nen FreeRTOS-, oder TNKernel-port nehmen, oder davon was: http://www.nilsenelektronikk.no/neprod.html
das gibt's nämlich alles umsonst.

Schurke

Danke, das sieht schonmal alles recht brauchbar aus das wozu ich das eigentlich plane ist die tastsache das ich vom pc was von einem ISP bausatz auslesen möchte ^^ ( mit festen zeitabständen dazwischen )

pointercrash**

~fricky schrieb:

das ist aber nur 'ne demo. die eigentliche RTX wollen die geld haben, so wie's aussieht (unverschämtheit, dass heutzutage manche für nur-software immer noch kohle haben wollen).

Hmm, sorry, ich hab's mir nicht genauer angesehen, aber wenn man nach realtime und windows sucht, wird man wohl auch auf ein kostenloses RT-Subsystem stoßen.

~fricky schrieb:

btw, wenn ich'n RTOS auf 'ner pc-kiste haben wollte, würde ich nicht windows was unterjubeln, sondern vielleicht 'nen FreeRTOS-, oder TNKernel-port nehmen, oder davon was: http://www.nilsenelektronikk.no/neprod.html
das gibt's nämlich alles umsonst.

Ja, aber dann ist es kein Windoof, Du weißt doch, wie die Leute sind. Früher habe ich alles in einen Controller gepackt auf' 'ne ISA- Karte geklatscht, was Win nicht kann, der Weg ist aber über PCI und PCIe unhandlicher geworden und der Zertifikatskram verbaut da auch immer mehr. Über ein RT- Subsystem kann man halt einfach auf den Rest der Win- Funktionalität zugreifen und für die Leute bleibt es "seamless" Windows.

Wobei es schon Spiderschwein- Qualitäten hat: Homer preßt es einfach an die Decke.

hustbaer

~fricky schrieb:

hustbaer schrieb:

Wenn ich raten müsste würde ich sagen dass die meisten "General-Purpose" Betriebssysteme das so machen, weil es viel weniger Overhead ist (Hardware ansprechen dauert "extrem" lange, d.h. es wäre recht "teuer" den Timer-Chip andauernd umzuprogrammieren, und meist reicht eine Genauigkeit von 5 oder 10ms locker aus).

ansprechen von hardware dauert überhaupt nicht lange.

doch

wie kommst du darauf?

wie kommst du darauf dass es anders wäre?

vor allem sowas wie das umprogrammieren eines timer-chips ist mit wenigen zugriffen erledigt.

hardware hängt normalerweise en einem bus (jetztmal egal an welchen). und busse sind langsam. PCI ist z.B. mit 33 MHz getaktet, und ein zugriff braucht AFAIK auch mehr als nur einen zyklus. sagen wir mal 2 zyklen. das wären dann 2/33m sekunden. bei 2 GHz CPU-takt entspricht das ca. 120 CPU takten. wenn wir davon ausgehen dass ~1.5 instructions pro takt "retired" werden sind das 180 instructions. wobei das die untergrenze ist von der ich ausgehe. würde mich nicht wundern wenns in wirklichkeit 3 oder 4 mal soviel ist. oder noch viel mehr. und das für das setzen eines einzigen hardware-registers.

ergo: hardware ansprechen ist langsam.

das umprogrammieren des timer-chips eines handelsüblichen PCs würde auch wesentlich mehr als nur einen zugriff erfordern und wäre allgemein recht heikel, aber das ist wieder ein anderes thema.

bei hardware die schneller angebunden ist (in der northbridge integriert, über PCIe angebunden etc.) sieht die sache natürlich besser aus, aber *schnell* wird es dadurch auch nicht.

variante(1) hat übrigens den nachteil, dass eine einzige timer-ISR (oder vielleicht ein DPC) eine unmenge an code durchlaufen muss, um alles zu behandeln, dass von timer-ticks abhängig ist. *das* ist teuer.

es wäre teuer, wenn man wirklich "eine unmenge an code" durchlaufen müsste. muss man aber nicht.

im timer-ISR macht man schonmal (fast) garnix, ausser den DPC anzufordern.
im DPC hat mann dann eine sortierte (!) liste von "fälligen" timern, was bedeutet dass man bei N timern die es "auszulösen" gilt N+1 checks machen muss.
was daran teuer sein soll weiss ich nicht.

das verwalten der timer in einer sortierten liste (bzw. irgendeiner struktur in der man schnell das kleinste element finden und entfernen kann) würde man sich auch in der anderen variante nicht sparen, da man ja immer das kleinste element finden müsste um den timer neu zu programmieren.

----

wahrscheinlich ist aber der wichtigere grund gegen das dauernde umprogrammieren des timers dass es einfach zu heikel ist. ein system das mit einer fixen timer-interrupt-frequenz arbeitet ist viel viel einfacher zu programmieren als ein system welches den timer andauernd umprogrammiert. vor allem wenn man (wie auf handelsüblichen PCs) nur einen einzigen hardware-timer hat den man für alles verwenden muss - also zum hochzählen der systemzeit, zum tasks wechseln, zum "auslösen" von software-timern etc.

----

das ist aber nur 'ne demo. die eigentliche RTX wollen die geld haben, so wie's aussieht (unverschämtheit, dass heutzutage manche für nur-software immer noch kohle haben wollen).

hihi
[leicht übertrieben]
wer verlangt denn für hardware noch geld?
[/leicht übertrieben]
nahezu jede software für die es nur einen kleinen markt gibt, und die ausreichend kompliziert ist, ist sau-teuer. dass es manchmal gratis alternativen gibt ist eine andere sache. und was diese gratis alternativen dann können wieder eine ganz ganz andere sache.

hustbaer schrieb:

hardware hängt normalerweise en einem bus (jetztmal egal an welchen). und busse sind langsam. PCI ist z.B. mit 33 MHz getaktet, und ein zugriff braucht AFAIK auch mehr als nur einen zyklus. sagen wir mal 2 zyklen. das wären dann 2/33m sekunden. bei 2 GHz CPU-takt entspricht das ca. 120 CPU takten. wenn wir davon ausgehen dass ~1.5 instructions pro takt "retired" werden sind das 180 instructions. wobei das die untergrenze ist von der ich ausgehe. würde mich nicht wundern wenns in wirklichkeit 3 oder 4 mal soviel ist. oder noch viel mehr. und das für das setzen eines einzigen hardware-registers.

ach du schreck, *solche* busse meinst du. ich hab' mal hardware mit einem infineon-c16x angesteuert, die am sogenannten 'compact flash' bus hing (ein pcmcia-ähnlicher bus). etwa 10% der rechenzeit hat allein der 'bustreiber' gefressen (wegen mangelnder hardwareunterstützung musste alles per software gemacht werden). klar, sowas ist natürlich superlahm. aber nur narren hängen einen simplen timer-baustein an einen solchen bus. bei den hochintegrierten gerätschaften, mit denen ich's für gewöhnlich zu tun habe, dauert (aus sicht des codes) das setzen eines timer-registers etwa so lange, wie ein speicherzugriff auf eine RAM-zelle.

hustbaer schrieb:

es wäre teuer, wenn man wirklich "eine unmenge an code" durchlaufen müsste. muss man aber nicht.
im timer-ISR macht man schonmal (fast) garnix, ausser den DPC anzufordern.
im DPC hat mann dann eine sortierte (!) liste von "fälligen" timern, was bedeutet dass man bei N timern die es "auszulösen" gilt N+1 checks machen muss.
was daran teuer sein soll weiss ich nicht.

das ganze listenbasiert aufzuziehen ist natürlich oft ein guter ansatz. 'teuer' daran ist aber z.b. die verwaltung und steuerung dieses 'subsystems'. und dafür bringen dpcs noch unvorhersehbare delays mit ins spiel. es gibt leider kein allgemeingültiges und bestes verfahren. hat man wenige software-timer, kann z.b. eine simple schleife direkt in der timer-ISR das beste sein. hat man sehr viele software-timer, müssen schon aufwendigere lösungen her. idealerweise hat man so viele hardware-timer wie timer-tasks, aber das ist ja in der praxis fast nie der fall.

hustbaer schrieb:

wahrscheinlich ist aber der wichtigere grund gegen das dauernde umprogrammieren des timers dass es einfach zu heikel ist. ein system das mit einer fixen timer-interrupt-frequenz arbeitet ist viel viel einfacher zu programmieren als ein system welches den timer andauernd umprogrammiert.

richtig. ich wollte mit meinem posting auch nicht für ein ständiges umswitchen von hardware-timern plädieren. sowas ist eigentlich nur sinnvoll, wenn der timer exklusiv genutzt wird.

hustbaer

@~fricky:
ich bin von general purpose betriebssystemen ausgegangen, nicht von irgendwelchen spezialisierten systemen wo man mehr oder weniger das OS bzw. teile davon selbst schreibt.