[C]1 ms delay

[tomvleeuwen]

Ik ben bezig een programma voor het programmeren van een microcontroller te porten van Windows naar Linux.
Ik ben al aardig ver, maar ik heb een delay nodig van 1 ms.
De meeste functies die ik hiervoor kan vinden zijn niet precies genoeg, ze tellen met 1 ms tegelijk of zelfs meer.
Ik heb hrtimer-support geprobeerd, maar hier krijg ik rare resultaten mee (geen gelijke tijden)
Hoe zou ik het beste een delay van 1 ms kunnen maken?

[NMe]

Voldoet een simpele sleep of usleep niet?

Anders zou je kunnen kijken welke bitjes je moet setten om de timer te activeren, en deze een interrupt laten genereren op het moment dat er 1 ms voorbij is. Dan zul je echter wel in de technische documentatie van die controller moeten kruipen.

[tomvleeuwen]

Nee het zit anders, ik ben niet bezig met het programma voor de microcontroller, maar het programma om de microcontroller te programmeren vanaf de computer.
Een usleep heb ik geprobeert maar werkt niet goed, ik zal nog een keer kijken waarom ook al weer.
Het gaat over de High Voltage Serial programmer van elm-chan.org
Ik kan geen ISP gebruiken omdat ik een attiny11 heb. De programmer werkt goed in windows.

edit:

Op mijn computer doet een usleep(1) er al ongeveer 3 ms over, dus dat is niet bruikbaar.

offtopic:
Microcontrollers programmeren we natuurlijk in assembly

[ Voor 9% gewijzigd door tomvleeuwen op 13-11-2005 20:41 ]

[NMe]

tomvleeuwen schreef op zondag 13 november 2005 @ 20:33:
Een usleep heb ik geprobeert maar werkt niet goed, ik zal nog een keer kijken waarom ook al weer.

Ik ben benieuwd.

offtopic:
Microcontrollers programmeren we natuurlijk in assembly

Zo natuurlijk is dat niet, ik kan ook prima microcontrollers programmeren in C. Vandaar ook mijn initiële verwarring.

[tomvleeuwen]

Op mijn computer doet een usleep(1) er al ongeveer 3 ms over, ik weet ook niet hoe dit komt
Het volgende programma neemt ongeveer 3 seconde in beslag:

code:

main()
{
    int x;
        for(x = 0; x < 1000; x++)
        {
            usleep(1);
        }
}

En dat van assembly was niet zo serieus bedoelt hoor.

[ Voor 22% gewijzigd door tomvleeuwen op 13-11-2005 20:45 ]

[Verwijderd]

Je zou natuurlijk heel bruut gewoon een forse for-next loop kunnen timen en op basis daarvan een waarde uitrekenen.

Dus eerst van 0 naar 10 triljoen loopen, dan uitrekenen hoe lang hij daar over gedaan heeft en dit vertalen naar 1ms.

Niet echt zwaar betrouwbaar lijkt mij, maar kon in de praktijk wel eens prima functioneren..

//edit
maar waarom zit je het wiel opnieuw uit te vinden? Die ATiny is toch gewoon via JTAG of JTAGICE te programmeren? Met bv. uisp?

[ Voor 18% gewijzigd door Verwijderd op 13-11-2005 20:49 ]

[Robbemans]

[ Voor 100% gewijzigd door Robbemans op 13-11-2005 21:02 ]

[NMe]

Robbemans: TS is een stuk code om aan het zetten van Windows naar Linux en ondervindt daarbij problemen. Dan heeft ie natuurlijk niets aan een Win32 COM-functie, die sowieso voor C++ bedoeld is als ik het zo in de gauwigheid even zie.

[Super_ik]

op google vindt ik welles stukjes die gebruik maken van select()
volgens mij staat zelfs in de manpage nog wel een stukje code.
en anders met time_t en while() aan de slag (google)

[tomvleeuwen]

@hezik Een JTAG of JTAG ICE is toch alleen voor de nieuwe grote avr's? en Uisp is een in system programmer, gaat niet werken op mijn tiny11, en op een tiny12 kreeg ik een isp ook niet aan de praat (heb er wel 5 gebouwd of zo)
Ik ga even kijken voor time_t en select.

[ Voor 31% gewijzigd door tomvleeuwen op 13-11-2005 21:05 ]

[Verwijderd]

Je hebt idd gelijk, die atyiny11 doet idd niet aan JTAG of JTAGICE, my bad. Alleen high voltage programming, wat idd. door de meeste progjes niet ondersteund wordt.

Waar je niet in gelijk hebt, is dat uisp niet werkt. Je kunt via een STK500 een atiny11 programmeren met uisp.

Ik kwam laatst een heel leuk schema voor die STK500 tegen, waarbij het 'chicken and egg' probleem niet meer bestond (je moest de programmer programmen). Ding ging ook nog op USB, wat ook wel handig is.

Even googlen:
http://tuxgraphics.org/electronics/200510/article05101.pdf

Als je die bouwt, kun je je tiny11 gewoon met uisp programmeren..

Waarom werkte ISP op die tiny12 niet trouwens? Ik heb zelf deze 'programmer' gebouwd:
en dat werkt als een tiet. Wel bij nadenken dat je eerst je device moet uitzetten voordat je de stekker uit je PC robt, maar voor de rest geen klachten en kost geen drol..

@Super_ik: Select() is toch deprecated en voor file descriptors? Hoe wil je daar mee timen?

[ Voor 28% gewijzigd door Verwijderd op 13-11-2005 21:58 ]

[Super_ik]

C:

struct tv time;
time.tv_sec = num_seconds_to_sleep;
time.tv_usec = num_microseconds_to_sleep;

select(NULL,NULL,NULL,& time);

via google, van http://www.experts-exchan...Cplusplus/Q_20556300.html

This will sleep for time.tv_sec seconds and time.tv_usec microseconds.

Setting tv_sec to 0 and tv_usec to 1000 will wait for one millisecond. setting tv_usec to 500 will wait for 500 microseconds or half a millisecond. Not sure if that is meaningful to do though, sleep(x) only guarantees that you will not wake up BEFORE x time units has passed, you may wait longer than that and if you specify a very short time interval, for example 1 microsecond you will probably in reality wait much longer than you specify.

Alf

[Soultaker]

Er zijn twee problemen waar je rekening mee moet houden.

Ten eerste heb je als 'gewone' applicatie het probleem dat je proces op elk moment gepauseerd kan worden, omdat Linux aan pre-emptive multiprocessing doet en geen real-time OS is. Dat geldt tenminste met de normale scheduler; als je wat meer privileges hebt kun je een soft realtime scheduler kiezen met sched_setscheduler. Realtime processen onderbreken direct niet-realtime processen als ze runnable zijn en kunnen zelf niet door andere processen onderbroken worden; ideaal voor het aansturen van een microcontroller dus. (Hoewel de kernel ondertussen nog wel signals afhandelt; maar met ~1ms resolutie moet dat geen problemen opleveren.)

Ten tweede is er het probleem dat alle features die een beroep doen op de kernel om te wachten gesynchroniseerd worden met de kerneltimer. De granulariteit daarvan wisselt per platform en kernelversie, maar onder i386 was het altijd 100 Hz (10 ms) wat later is aangepast naar 1000 Hz (1 ms) en weer later naar 250 Hz (4ms). De precieze waarde kun je instellen met de CONFIG_HZ parameter van je kernel. De select()-truc hierboven is leuk, maar zal dus ook die kerneltimer als ondergrens hebben, dus om echt 1ms te slapen moet je ook je CONFIG_HZ op 1000 zetten.

Ik weet niet hoe portable je applicatie moet zijn, maar als het instellen van de kernelklok geen optie is, is het enige alternatief een busy loop. Helaas heeft Linux ook een chronisch gebrek aan accurate timers (om uit te lezen), dus ik denk dat je het beste een assembly loop kunt schrijven die de time-stamp counter uitleest (RDTSC). Dan moet je wel de processorsnelheid weten, maar die kun je wel weer uit /proc/cpuinfo vissen.

[ Voor 3% gewijzigd door Soultaker op 14-11-2005 01:00 ]

[Verwijderd]

Soultaker schreef op maandag 14 november 2005 @ 00:56:
Ik weet niet hoe portable je applicatie moet zijn, maar als het instellen van de kernelklok geen optie is, is het enige alternatief een busy loop. Helaas heeft Linux ook een chronisch gebrek aan accurate timers (om uit te lezen), dus ik denk dat je het beste een assembly loop kunt schrijven die de time-stamp counter uitleest (RDTSC). Dan moet je wel de processorsnelheid weten, maar die kun je wel weer uit /proc/cpuinfo vissen.

De 1e hit bij google op RDTSC:

Delphi:

const
  D32 = $66;

function RDTSC: comp;
var
  TimeStamp: record
             case byte of
               1: (Whole:  comp);
               2: (Lo, Hi: LongInt);
             end;
begin
  asm
    db $0F; db $31;         {BASM doesn't support RDTSC}
        {Pentium RDTSC - Read Time Stamp Counter - instruction}
{$ifdef Cpu386}
    mov [TimeStamp.Lo],eax  // the low dword
    mov [TimeStamp.Hi],edx  // the high dword
{$else}
    db D32
    mov word ptr TimeStamp.Lo,AX
        {mov [TimeStamp.Lo],eax - the low dword}
    db D32
    mov word ptr TimeStamp.Hi,DX
        {mov [TimeStamp.Hi],edx - the high dword}
{$endif}
  end;
  Result := TimeStamp.Whole;
end;

en:

RDTSC is a two byte instruction - 0F 31 - and it returns a 64-bit count in EDX:EAX.

bron

[ Voor 19% gewijzigd door Verwijderd op 14-11-2005 01:20 ]

[curry684]

tomvleeuwen schreef op zondag 13 november 2005 @ 19:47:
Ik ben bezig een programma voor het programmeren van een microcontroller te porten van Windows naar Linux.
Ik ben al aardig ver, maar ik heb een delay nodig van 1 ms.
De meeste functies die ik hiervoor kan vinden zijn niet precies genoeg, ze tellen met 1 ms tegelijk of zelfs meer.
Ik heb hrtimer-support geprobeerd, maar hier krijg ik rare resultaten mee (geen gelijke tijden)
Hoe zou ik het beste een delay van 1 ms kunnen maken?

Mag ik vragen hoe dit in godesnaam op Windows is geimplementeerd overigens daar Sleep(int dwMilliseconds) een documented precisie heeft van ruwweg 10ms?

Ik weet wel hoe het kan, maar ik vermoed dat je originele code net zo buggy is als je port

[Verwijderd]

curry684 schreef op maandag 14 november 2005 @ 01:25:
Mag ik vragen hoe dit in godesnaam op Windows is geimplementeerd overigens daar Sleep(int dwMilliseconds) een documented precisie heeft van ruwweg 10ms?

Kijk eens naar die Delphi functie boven je post ..

[curry684]

Verwijderd schreef op maandag 14 november 2005 @ 01:28:
[...]


Kijk eens naar die Delphi functie boven je post ..

Dat zegt niets over hoe TS het in z'n Windows-origineel heeft staan

[farlane]

Soultaker schreef op maandag 14 november 2005 @ 00:56:
Ik weet niet hoe portable je applicatie moet zijn, maar als het instellen van de kernelklok geen optie is, is het enige alternatief een busy loop. Helaas heeft Linux ook een chronisch gebrek aan accurate timers (om uit te lezen), dus ik denk dat je het beste een assembly loop kunt schrijven die de time-stamp counter uitleest (RDTSC).

Als ik me niet vergis is nanosleep bij waits kleiner dan x ms een busyloop.

Op windows plarformen zou je kunnen proberen om de timing wat precieser te krijgen door timeBeginPeriod/timeEndPeriod te gebruiken.

Iha kun je denk ik wel stellen dat als je 'sub ms nauwkeurige' timing nodig hebt geen plain windows/linux kunt gebruiken. Maar daarvoor hebben we uP's of realtime OS'en.

[ Voor 23% gewijzigd door farlane op 14-11-2005 10:44 ]

[.oisyn]

Soultaker schreef op maandag 14 november 2005 @ 00:56:
Ik weet niet hoe portable je applicatie moet zijn, maar als het instellen van de kernelklok geen optie is, is het enige alternatief een busy loop. Helaas heeft Linux ook een chronisch gebrek aan accurate timers (om uit te lezen), dus ik denk dat je het beste een assembly loop kunt schrijven die de time-stamp counter uitleest (RDTSC). Dan moet je wel de processorsnelheid weten, maar die kun je wel weer uit /proc/cpuinfo vissen.

Waar je weer niet op kunt vertrouwen aangezien sommige processoren langzamer gaan lopen als ze minder nodig zijn (op laptops vooral, om stroom te sparen)

[curry684]

farlane schreef op maandag 14 november 2005 @ 10:37:
[...]

Iha kun je denk ik wel stellen dat als je 'sub ms nauwkeurige' timing nodig hebt geen plain windows/linux kunt gebruiken.

Als jij je process priority op REALTIME_PRIORITY_CLASS zet in Windows en niet yield heb je het systeem zowat geblokkeerd, en dat is icm een busy-loop op QueryPerformanceCounter iig ruim afdoende voor 0.1ms resolutie

[Creepy]

Met de standaard Linux kernel is het inderdaad het beste om een busy-loop te maken. M.b.v. gettimeofday() kan dit op dezelfde manier als bijv. QueryPerformanceCounter in Windows.

[farlane]

curry684 schreef op maandag 14 november 2005 @ 11:29:
[...]

Als jij je process priority op REALTIME_PRIORITY_CLASS zet in Windows en niet yield heb je het systeem zowat geblokkeerd, en dat is icm een busy-loop op QueryPerformanceCounter iig ruim afdoende voor 0.1ms resolutie

Totdat de gebruiker de kans ziet om een bv andere applicatie de focus te geven. Die 0.1 ms resolutie is dan niet bepaald betrouwbaar.

Afgezien van dat zal een gebruiker geen fijn gevoel krijgen bij een applicatie die je systeem blokkeert, alhoewel dat alleen merkbaar is bij relatief lange waits met 'hoge' resolutie. ( sub us resolutie is in een uP gemakkelijk haalbaar )

Windows ( en ook Linux ) is gewoon niet geschikt voor dit soort timing ze zijn er eenvoudig niet voor gebouwd.

[ Voor 5% gewijzigd door farlane op 14-11-2005 13:23 ]

[Olaf van der Spek]

.oisyn schreef op maandag 14 november 2005 @ 11:24:
Waar je weer niet op kunt vertrouwen aangezien sommige processoren langzamer gaan lopen als ze minder nodig zijn (op laptops vooral, om stroom te sparen)

Veranderd de frequentie van de TSC dan ook?
Origineel dacht ik dat de TSC inderdaad synced was met de processorklok. Maar dat is later veranderd dacht ik.

[farlane]

Zou toch ff man 2 nanosleep nakijken of deze voldoet aan je wensen.

[Creepy]

farlane schreef op maandag 14 november 2005 @ 13:39:
Zou toch ff man 2 nanosleep nakijken of deze voldoet aan je wensen.

Niet als je 1ms of kleiner wilt (en afhankelijk van de kernel instelling kleiner dan 10ms zelfs)

The current implementation of nanosleep() is based on the normal kernel
timer mechanism, which has a resolution of 1/HZ s (i.e, 10 ms on
Linux/i386 and 1 ms on Linux/Alpha). Therefore, nanosleep() pauses
always for at least the specified time, however it can take up to 10 ms
longer than specified until the process becomes runnable again. For the
same reason, the value returned in case of a delivered signal in *rem
is usually rounded to the next larger multiple of 1/HZ s.

[farlane]

Misschien moet je em dan ook even helemaal quoten

As some applications require much more precise pauses (e.g., in order to control some time-critical hardware), nanosleep is also capable of short high-precision pauses. If the process is scheduled under a real-time policy like SCHED_FIFO or SCHED_RR, then pauses of up to 2 ms will be performed as busy waits with microsecond precision.

Imho voldoen de eisen van de TS hieraan

[ Voor 5% gewijzigd door farlane op 14-11-2005 14:03 ]

[curry684]

farlane schreef op maandag 14 november 2005 @ 13:23:
[...]

Totdat de gebruiker de kans ziet om een bv andere applicatie de focus te geven. Die 0.1 ms resolutie is dan niet bepaald betrouwbaar.

Focus boeit niet in deze. Enige risico is dat een andere applicatie ook op het hoogste niveau gaat zitten

Afgezien van dat zal een gebruiker geen fijn gevoel krijgen bij een applicatie die je systeem blokkeert, alhoewel dat alleen merkbaar is bij relatief lange waits met 'hoge' resolutie. ( sub us resolutie is in een uP gemakkelijk haalbaar )

Absoluut, deze oplossing is niet langer dan enkele seconden acceptabel imho.

Windows ( en ook Linux ) is gewoon niet geschikt voor dit soort timing ze zijn er eenvoudig niet voor gebouwd.

True, daar heb je RTOS'es voor.

[Soultaker]

farlane schreef op maandag 14 november 2005 @ 14:02:
Misschien moet je em dan ook even helemaal quoten

Ja, maar dan moet je ook nog dit even quoten:

Old behaviour
In order to support applications requiring much more precise pauses (e.g., in order to control some time-critical hardware), nanosleep() would handle pauses of up to 2 ms by busy waiting with microsecond precision when called from a process scheduled under a real-time policy like SCHED_FIFO or SCHED_RR. This special extension was removed in kernel 2.5.39, hence is still present in current 2.4 kernels, but not in 2.6 kernels.

Dus dat werkt alleen onder een realtime scheduler én alleen in een 2.4 kernel. Als je het je kunt veroorloven je platform te beperken tot Linux 2.4, kun je waarschijnlijk ook wel je kernel clock op 1 ms zetten, wat dan makkelijker is. Onder andere kernels zul je toch zelf aan de slag moeten.

.oisyn schreef op maandag 14 november 2005 @ 11:24:
Waar je weer niet op kunt vertrouwen aangezien sommige processoren langzamer gaan lopen als ze minder nodig zijn (op laptops vooral, om stroom te sparen)

Klopt ja, daar dacht ik ook aan. Ik gok er op dat het voor een paar milliseconden wel goed gaat, of schakelen die processoren zo snel over? Sowieso vraag ik me af waarom 'ie zou terugschakelen in een busy-loop; lijkt me dat je dat pas wil doen als je relatief vaak een HALT krijgt (dan is er blijkbaar weinig werk te doen). Maar ik moet zeggen dat ik zo goed als niets weet van power management.

Sowieso zijn er allemaal kleine dingen die mis kunnen gaan, bijvoorbeeld als je te lang onder realtime priority blijft draaien.

edit:

Creepy schreef op maandag 14 november 2005 @ 12:36:
Met de standaard Linux kernel is het inderdaad het beste om een busy-loop te maken. M.b.v. gettimeofday() kan dit op dezelfde manier als bijv. QueryPerformanceCounter in Windows.

Het lijkt er op dat gettimeofday() inderdaad niet gebonden is aan de kernel clock. Die zou je ook kunnen gebruiken om een busy loop te implementeren.

[ Voor 23% gewijzigd door Soultaker op 14-11-2005 14:55 ]

[farlane]

Soultaker schreef op maandag 14 november 2005 @ 14:51:
Dus dat werkt alleen onder een realtime scheduler én alleen in een 2.4 kernel. Als je het je kunt veroorloven je platform te beperken tot Linux 2.4, kun je waarschijnlijk ook wel je kernel clock op 1 ms zetten, wat dan makkelijker is. Onder andere kernels zul je toch zelf aan de slag moeten.

Mijn man 2 was idd kernel 2.4.nogwat. Nuttige informatie, dank je

[Verwijderd]

_Zo_ enorm kritisch is die timing nu ook weer niet hoor. Daarnaast is het geen ramp als een flash een keer mislukt. Goed, het aantal keer dat je kunt flashen is eindig, maar het getal is dermate groot (>1000) dat er geen man overboord is als het flashen incidenteel mislukt. Je gaat de inhoud van het ding toch verifyen nadat je'm geflashed hebt.

Sowieso, zelfs met uisp onder windows heb ik nog regelmatig dat een flash mislukt. Kan gebeuren, is geen ramp.

Zo kritisch is het allemaal dus niet. Daarnaast; hoe hard je je best ook doet, zowel onder windows als onder linux is het gewoon onmogelijk een vaste resolutie van 1ms te krijgen, het is altijd mogelijk voor een andere app om je flashproces te verstoren. Simpel voorbeeld: een app die enorm veel geheugen gaat gebruiken en de load van je server flink omhoogooit. Als jij bv. een app die 2Gb geheugen consumeert en een load van >100 gaat veroorzaken op je werkstation start, zal je flashproces altijd misgaan, hoe je het ook wend of keert.

Ik denk dat TS z'n tijd beter besteed is aan het maken van het best werkende systeem in een acceptabele doorlooptijd, dan om het helemaal perfect te willen maken. Gewoon een busyloop i.c.m. gettimeofday of de hier eerder geposte asm is goed zat.

[Super_ik]

je maakt toch zelf de klok? k neem aan dat die alleen een maximale snelheid heeft? teminste, PIC-controllers wel.