[ALG] ononderbroken (real-time) uitvoering in Windows XP *

[Specy]

Om een stukje hardware (een LEDje op de parallelle printerpoort) aan te sturen heb ik een programma geschreven wat het LEDje steeds gedurende korte tijd (orde 0.5 ms) een puls laat geven. Binnen deze puls wordt het LEDje 38000 keer per seconde aan- en uitgezet, ook via software. Tussen twee pulsjes zit steeds minimaal 0.5 ms rust.

Hiermee wil ik mijn digitale decoder bedienen vanaf mijn PC.

Als ik het programma draai op de allerhoogste prioriteit ("nice -rt", -r = "Realtime priority", t = "Time-critical") gaat het aansturen meestal goed. Maar, aangezien Windows XP geen echte real-time ondersteunt wordt het signaal soms toch kort (rond 0.5 ms) onderbroken. Dat is natuurlijk veel te veel, waardoor het omschakelen naar het gewenste kanaal faalt.

Zijn er nog trucs om het onderbreken nog verder te verminderen? (Ik heb overigens maar 1 CPU). Het totale signaal duurt ongeveer 15 ms, met dus steeds piekjes van elk 0.55 ms met pauzes ertussen van 0.6 of 1.75 ms. Een methode om de onderbrekingen in de pauzes te laten vallen zou ook werken!

[RobIII]

Ik zou eens aan de gang gaan met een microcontroller ertussen die je dan vanuit je PC aanstuurt want dit ga je never-nooit fatsoenlijk werkend krijgen. Er zijn overigens topics genoeg hier op GoT daaromtrent te vinden.

[YopY]

Het probleem is (volgens mij) dat Windows (en Linux, en andere moderne besturingssystemen) meerdere processen ondersteunen. Daarom kun je er nooit van uit gaan dat je programma altijd (constant) draait; om de zoveel tijd wordt het onderbroken om een ander programma wat processorkracht te geven. Het programma wordt daardoor een tijdje gepauzeerd.

Er zijn misschien wel besturingssystemen (DOS?) die (nog) geen multitasking / achtergrondprocessen / whatnot hebben, maar ik betwijfel dat je daar op over wilt schakelen om maar een afstandsbediening te maken.

What RobIII zegt: met een microcontroller kun je dat wel, je hebt daar (afhankelijk van het model) 100% controle over, en ze zijn niet duur (tenminste niet diegenen die je nodig hebt). Het is alleen wel zo dat het wat langer duurt om de zaak te leren dan het standaard 'hello world'.

[leuk_he]

XP tunen voor realtime behaviour? all gegoogled?

b.v.
http://www.xptuneup.com/tip0050.htm

Ook lijkt dit een zeldzaam geval waar ook het uitschakelen van de paging file zinvol kan zijn. Ook kun je geloof ik met link opties aangeven dat een proces in geheugen gelockt moet worden.

gebruik je nu high resolution time multimedia API's om de wachttijd te bepalen?

[PiepPiep]

Specy schreef op maandag 29 oktober 2007 @ 22:29:
Zijn er nog trucs om het onderbreken nog verder te verminderen? (Ik heb overigens maar 1 CPU). Het totale signaal duurt ongeveer 15 ms, met dus steeds piekjes van elk 0.55 ms met pauzes ertussen van 0.6 of 1.75 ms. Een methode om de onderbrekingen in de pauzes te laten vallen zou ook werken!

Als ik het goed heb gebruikt windows nog steeds de timer interrupt die elke 55 ms af gaat. Klopt het ongeveer dat je een kans hebt van 15 / 55 dus ongeveer 3 op de 11 fout?
Als je de originele afstandsbediening gebruikt, stuurt deze denk ik zolang je de knop ingedrukt houd hetzelfde stukje data van 15 ms achter elkaar. Wat je zou kunnen doen is niet 1 keer dit 15 ms durende signaal sturen, maar 10 keer achter elkaar. Als er om wat voor reden dan een storing in het signaal komt dan komt de volgende 15 ms misschien wel goed aan.
Het is geen oplossing voor het real-time uitvoeren, maar misschien kan je het op deze manier ook helemaal zonder real-time doen. Is wel zo leuk als je op dezelfde computer ook nog iets anders aan het doen bent.

[farlane]

leuk_he schreef op dinsdag 30 oktober 2007 @ 11:50:
XP tunen voor realtime behaviour?

Je kunt tunen wat je wilt met XP maar je krijgt het niet (hard)realtime. Daarvoor moet je een realtime OS hebben. WindowsCE is er bijvoorbeeld eentje of Linux met de RTAI patch.

[RobIII]

leuk_he schreef op dinsdag 30 oktober 2007 @ 11:50:
XP tunen voor realtime behaviour? all gegoogled?

b.v.
http://www.xptuneup.com/tip0050.htm

Waar zie jij dan "de tip" staan waarmee je XP op magische wijze omtovert tot een Realtime OS?

[Verwijderd]

Je kan wel met hoge resolutie timers in windows werken, hoe die in de praktijk uitvallen is weer een ander verhaal.

MicroTimer version 0.001 is a timer capable to go down to microseconds.
The goals are to keep it simple and efficient.

It has only two functions:
bool TIMERON(float interval, void (*callback), bool protect);
bool TIMEROFF();

or, in Delphi:
function TIMERON(interval: Single; callback: TProcedure; protect: Boolean): Boolean;
function TIMEROFF: Boolean;

That's all.

Interval can go down to 0.005 ms, if the machine is fast enough...

Parameters:
1) interval is in miliseconds, float.
2) callback is the function to be called when interval has elapsed, repeatedly.
3) protect is true for thread protection (the synchronize() in Delphi and C++Builder).

If Synchronize is used, the minimum time is about 1.0 to 0.5 ms in a Pentium-2 330 MHz.
It may be necessary if you write on screen using the Canvas, as in the Query examples. Of course,
it is not recommended to do a lot of graphics fireworks inside the callback function!
It should be as fast as possible. The example is only to illustrate the utilization of the functions,
but as application it is what you should never do!

In the real world, I have spent severals months looking for a timer with precision down to,
at least, 1ms working in the Windows environment.
The closest I found was a Mabry Hi-Timer OCX. But its thread and event messaging approach imposes
too much overhead. After all I wrote one myself and it worked very well in my software for
real time data aquisition and display of eletrophisiological signals with several channels together.

It does not loose ticks. If some other job keeps Windows busy for a while, it may delay, but
it recovers the missed ticks by counting up to date and the average result is correct.

There is an example for Delphi workers and another one for C++Builder lovers.
The Delphi one uses Synchronize. The C++Builder doesn't.
The uTimer.LIB file present in the C++Builder example was created using IMPLIB.EXE and uTimer.dll.
It's necessary for linking in the C++ Builder environment.

(moet ff het linkje op het www vinden)

[Specy]

Bedankt voor de tips, even een paar reacties tegelijk:

RobIII, YopY: Waarschijnlijk hebben jullie gelijk dat ik dit nooit perfect aan de gang ga krijgen. Maar... Gezien hoe weinig ik weet van microcontrollers, en het feit dat dit een leuk hobbyprojectje is ga ik het toch nog even proberen... Er zijn nog andere trucs mogelijk om het resultaat flink te verbeteren (ik zit inmiddels op 95% correct ontvangen, en ik heb nog een nieuw idee gekregen om het verder te verbeteren).

leuk_he: Ik zal eens naar de Windows-instellingstips kijken. Ik gebruik nu de QueryPerformanceTimer() call om de high-performance timer (> 1 GHz precisie) te lezen, en daar wacht ik steeds op. Zolang het programma niet onderbroken wordt geeft dat een nauwkeurig genoeg signaal.

PiepPiep: Helaas, allerlei andere apparaten kan ik met de truc die je noemt (continu sturen) perfect aansturen. Maar mijn digitale decoder AB stuurt de sequence maar 1 keer... Als ik 'm snel achter elkaar stuur dan ziet 'ie het als losse toetsindrukken. Ik ga wel checken of het idd elke 15 ms fout gaat, als ik kan voorspellen wanneer het fout gaat dan ben ik er natuurlijk ook :-)

farlane: Klopt, op mijn werk zijn we net bezig met kijken naar andere OS'en voor real-time toepassingen, maar voor mijn normale thuis-pc is dit (helaas) niet echt een optie.

Maui71: It does not loose ticks. If some other job keeps Windows busy for a while, it may delay, but it recovers the missed ticks by counting up to date and the average result is correct.: Dit lijkt erop te wijzen dat het precies hetzelfde probleem heeft als wat ik nu heb...


Wat ik nu o.a. doe om de ontvangst te verbeteren: Als ik detecteer dat er een gap in mijn signaal zit en ik zit nog niet op de laatste bit, dan wacht ik 1/4 seconde en daarna begin ik opnieuw. Soms zijn er wel 6 retries nodig, maar uiteindelijk komt het wel precies 1 keer aan in de ontvanger.

Verder heb ik de normale verdeling van de pulsen - helft van de tijd puls, helft van de tijd stilte - vervangen door 2/3 puls, 1/3 stilte. De ontvanger kan hier tegen, en onderbrekingen zijn nu vrijwel altijd korter dan de pulstijd, zodat er altijd wel iets van de puls overblijft. (Ook 1/3 puls, 2/3 stilte komt soms nog aan).

Dit leidt nu tot 95% correct ontvangen (voor deze wijzigingen was dat rond de 30 %). Helaas nog niet genoeg om te kunnen gebruiken om mijn digitale decoder betrouwbaar aan te kunnen sturen voor getimede opnamen...

[ Voor 16% gewijzigd door Specy op 30-10-2007 12:43 ]

[PiepPiep]

Mogelijke manier om die time-gap te detecteren is misschien met de assembler instructie rdtsc (ReaD TimeStamp Counter)

[RobIII]

PiepPiep schreef op dinsdag 30 oktober 2007 @ 12:43:
Mogelijke manier om die time-gap te detecteren is misschien met de assembler instructie rdtsc (ReaD TimeStamp Counter)

Dan zou ik dit maar even lezen als ik jou was

[Janoz]

Specy schreef op dinsdag 30 oktober 2007 @ 12:34:
Bedankt voor de tips, even een paar reacties tegelijk:

RobIII, YopY: Waarschijnlijk hebben jullie gelijk dat ik dit nooit perfect aan de gang ga krijgen. Maar... Gezien hoe weinig ik weet van microcontrollers, en het feit dat dit een leuk hobbyprojectje is ga ik het toch nog even proberen... Er zijn nog andere trucs mogelijk om het resultaat flink te verbeteren (ik zit inmiddels op 95% correct ontvangen, en ik heb nog een nieuw idee gekregen om het verder te verbeteren).

Ikzelf wist helemaal niks van microcontrollers, maar heb laatst een presentatie van een collega bijgewoond (kennis sessie, wat op school de spreekbeurt zou heten ) en die ging over mc's. Ikzelf had gedacht dat het veel moeilijker en hoogdrempeliger zou zijn, maar dat bleek enorm mee te vallen. Als je een beetje kunt programmeren en bereid bent om initieel iets van E30 uit te geven kun je al los.

[Refro]

Gaat je met XP nooit perfect lukken daar zal toch echt een PIC ofzo tussen moeten. Of je moet een echt RT OS op je pc gaan zetten (mischien windows ce gebaseerd op het CEPC bsp).

Tunen met alle al gegeven tips kan natuurlijk wel helpen.

[bobo1on1]

Janoz schreef op dinsdag 30 oktober 2007 @ 13:25:
[...]

Ikzelf wist helemaal niks van microcontrollers, maar heb laatst een presentatie van een collega bijgewoond (kennis sessie, wat op school de spreekbeurt zou heten ) en die ging over mc's. Ikzelf had gedacht dat het veel moeilijker en hoogdrempeliger zou zijn, maar dat bleek enorm mee te vallen. Als je een beetje kunt programmeren en bereid bent om initieel iets van E30 uit te geven kun je al los.

Gewoon samples aanvragen bij microchip

En inderdaad, het programmeren is een eitje, je hebt verder alleen wat elektro kennis nodig.

Je kunt ook een pwm signaal genereren met de geluidskaart, maar omdat er een condensator in de uitgang van een geluidskaart zit moet je zowel een positieve als een negatieve puls genereren, zodoende kun je nooit een duty cycle halen boven de 50%.
Als je deze schakeling pakt en je sluit een diode met de kathode aan op de basis van de transistor en de anode op de emitter dan kun je de data aansluiting aan de uitgang van een geluidskaart hangen.

Dit werkt niet met alle geluidskaarten, sommige leveren gewoon te weinig spanning, wat je wel kunt proberen is voor R1 een 100 ohm weerstandje gebruiken.

[Janoz]

bobo1on1 schreef op dinsdag 30 oktober 2007 @ 16:32:
[...]


Gewoon samples aanvragen bij microchip

Ik had het meer over de programmer, maar goed, zo best ben ik er verder ook niet in. Ik heb pas net een Arduino besteld

[Frash]

leuk_he schreef op dinsdag 30 oktober 2007 @ 11:50:
XP tunen voor realtime behaviour? all gegoogled?
(...)
http://www.xptuneup.com/tip0050.htm

Dacht dat we het tijdperk van dat soort neptweaks al hadden gehad... XP Myths en Mark Russinovich (Microsoft) zeggen daarover nl. het volgende:

quote: http://mywebpages.comcast.net/SupportCD/XPMyths.html

IRQs don't even HAVE a concept of "priority" in the NT family; they do have something called "IRQL" (interrupt request level) associated with them. But the interval timer interrupt is already assigned a higher IRQL than any I/O devices, second only to the inter-processor interrupt used in an MP machine. The NT family of OSes don't even use the real-time clock (IRQ 8 ) for time keeping in the first place! They use programmable interval timer (8254, on IRQ 0) for driving system time keeping, CPU time accounting, and so on. IRQ 8 is used for profiling, but profiling is almost never turned on except in very rare development environments. Even if it was possible it doesn't even make sense why adjusting the real-time clock priority would boost performance? The real-time clock is associated with time keeping not CPU frequency. I would not be surprised if this originated in an overclocking forum somewhere. This "tweak" can be found in most XP all-in-one tweaking applications. This is a perfect example of why they are not recommended.

[ Voor 15% gewijzigd door Frash op 30-10-2007 16:47 ]

[farlane]

bobo1on1 schreef op dinsdag 30 oktober 2007 @ 16:32:
Gewoon samples aanvragen bij microchip

En mensen met MPLAB opzadelen? Zou willen aanraden om wat verder te kijken ( Atmel, AD, TI ), deze fabrikanten hebben chips met gratis ontwikkelomgevingen en een gcc toolchain.

[leuk_he]

RobIII schreef op dinsdag 30 oktober 2007 @ 12:16:
[...]

Waar zie jij dan "de tip" staan waarmee je XP op magische wijze omtovert tot een Realtime OS?

Die zie ik niet. Ik denk ook niet dat het mogelijk is.

Ook is me het doel niet helemaal duidelijk. Ben je aan het hobbieen en wil je op je eigen pc of een stukje driver wil maken dat voor meermensen bruikbaar is. In het eerste geval kun je wellicht ook een echt realtime os (dos....) gebruiken, in het andere geval is het wellicht simpeler een usb IR aansluiting te investeren (10-20 euro)

Ander idee.

met de DDK een kerneldriver maken waar je je vlaggetjes zodanig zet dat er geen taskschededulling/interrupt processing gedaan wordt in het tijd Kritische gedeelte. (Geen idee wat dit voor gevolgen heeft en of dit mogelijk is).

Frash schreef op dinsdag 30 oktober 2007 @ 16:42:
[...]
Dacht dat we het tijdperk van dat soort neptweaks al hadden gehad... XP Myths en Mark Russinovich (Microsoft) zeggen daarover nl. het volgende:
[...]

Hum. les 1 van real time: real time betekend niet "heel snel" maar betekent een binnen een bekende reactie tijd. Dus je os mag rommelen wat je maar wil, als het maar binnen 0,5 ms (in geval van ts) weer reageert op de applicatie.

XP wordt niet ECHT real time, maar wellicht met wat rommelen genoeg voor de topic starter.

[ Voor 21% gewijzigd door leuk_he op 30-10-2007 17:22 ]

[bobo1on1]

Nog over pwm met een geluidskaart, je kunt ook dit schema gebruiken wat ik zojuist getekend heb:



Nu kun je een duty cycle halen van 100% maar je moet nog steeds een positieve en negatieve puls genereren.

[Frash]

leuk_he schreef op dinsdag 30 oktober 2007 @ 17:12:
Hum. les 1 van real time: real time betekend niet "heel snel" maar betekent een binnen een bekende reactie tijd. Dus je os mag rommelen wat je maar wil, als het maar binnen 0,5 ms (in geval van ts) weer reageert op de applicatie.

XP wordt niet ECHT real time, maar wellicht met wat rommelen genoeg voor de topic starter.

Oh dan kwam het niet helemaal goed over: ik probeerde niet te zeggen dat het niet goed werkt, ik probeerde te zeggen dat het helemaal niet werkt; de registersleutel wordt niet eens uitgelezen door Windows. Jammer opzich, heb zelf ook over het onderwerp gezocht voor een (semi-)real-time videoapplicatie.

[ Voor 45% gewijzigd door Frash op 30-10-2007 17:46 ]

[Specy]

Gezien de replies in deze thread (nl. dat ik niet van de onderbrekingen afkom) heb ik het maar eens gezocht via een ander pad: Detectie van fouten. Hier maakte ik al wel wat gebruik van, maar via verder tweaken heb ik zojuist 100 keer achter elkaar een toets kunnen verzenden die steeds goed ontvangen werd door de digitale decoder!

Voor wie geinteresseerd is: Mijn oplossing:

1. Verleng de pulsen tov. wat de afstandsbediening doet (voor zover de ontvanger dit accepteert, testen!). Hierdoor gaat een puls minder snel verloren.
2. Bereken alle puls aan/uit momenten vanaf het startmoment. Dan kunnen er later geen fouten ontstaan doordat er tussen 1- of 0- codes een onderbreking valt.
3. Controleer continu of er geen te grote onderbrekingen vallen. Als er binnen een puls een reeks van 8 of meer hoog/laag schakelingen ontbreken (0.2 ms), OF als van een puls meer dan 1/4 van de hoog/laag schakelingen ontbreken, beschouw dit dan als een error.

Zodra er door die laatste check een error wordt gedetecteerd, onderbreek van de verzending.

Als dit nog NIET de laatste bit van de code was, kan dat zonder problemen, de ontvanger negeert dan de gedeeltelijk ontvangen code. De code kan dan (na een korte pauze) opnieuw gestuurd worden.

Gebeurt het tijdens de laatste bit, dan is de ontvanger hierna in een onbekende toestand (toets wel of niet ontvangen), bij kanaalwijzigen betekent dat: Wacht een paar seconden en begin dan helemaal opnieuw. Dit kwam bij mijn 100 verstuurde toetsen overigens 2 keer voor.

Overigens betekent dat laatste dat deze methode niet geschikt is voor bijv. het aanzetten van de decoder, omdat daarvoor dezelfde code wordt gebruikt als voor uitzetten... Maar voor kanaalwisselingen zou dit voldoende moeten werken.


Ik ga nog wat uitgebreidere tests draaien (100 is nog niet heel erg veel), maar tot nu toe voelt het goed aan.

[Kuhlie]

Ik heb dit ooit ook eens geprobeerd. Wat jij wilt is een signaal sturen met bits in de orde van grootte van 1ms, op een draagsignaal van 38kHz. Ik kan het nu helaas niet terugvinden, maar een andere manier om dit te doen is een 555-timer gebruiken om het draagsignaal te maken, en dan zelf het ~1ms-signaal sturen.

Helaas kan ik de juiste schakeling niet meer terugvinden... ik dacht dat deze op de lirc-site te vindne was, maar dat valt tegen.

[AlphaRomeo]

Ik ken een hardwarebouwer (Beckhoff) die een soort subkernel heeft (TwinCAT) die parallel loopt aan de windows kernel. Die heeft een gegarandeerde omlooptijd voor soft-plc programma's van 10ms. Daar kun je vervolgens met (onder andere) een .NET API tegenaan ouwehoeren.

[Refro]

AlphaRomeo schreef op woensdag 31 oktober 2007 @ 13:42:
Ik ken een hardwarebouwer (Beckhoff) die een soort subkernel heeft (TwinCAT) die parallel loopt aan de windows kernel. Die heeft een gegarandeerde omlooptijd voor soft-plc programma's van 10ms. Daar kun je vervolgens met (onder andere) een .NET API tegenaan ouwehoeren.

De windows kernel draait als thread in de Twincat kernel. Zelfde geintje als met de eerste versies van RTLinux. Maar lijkt mij niet iets om hobbymatig mee te gaan stoeien. Green hills biedt met INTEGRITY PC ook iets dergelijks aan (zelfs windows en linux tegelijk).