[VB] hoe hele kleine pauze maken van 1µs?

[robbertb]

Omdat ik via de com-poort wil communiceren met een zelfgemaakte sensor, heb ik korte wachttijden nodig. Nou dacht ik eerst aan om de timer te gebruiken maar die werkt in miliseconden. Hoe laat ik nou 0,25 tot 1µs wachten tot ik de volgende commande over de poort gooi?
Ik heb wel op internet gevonden dat het in C++ met delay_us zou moeten? Maarja ik wil in visualbasic.

[Verwijderd]

http://www.vbaccelerator....CRC32VB_HiResTimer_vb.asp
probeer hier eens iets mee te bouwen

[robbertb]

Verwijderd schreef op 14 maart 2004 @ 23:35:
http://www.vbaccelerator....CRC32VB_HiResTimer_vb.asp
probeer hier eens iets mee te bouwen

Hm dat is een timer en ik wil een kleine pauze.
Ik heb het geplakt in een nieuwe VB-class maar dan wordt de helft rood
Zelfs "Public Class HiResTimer"

[Verwijderd]

het ombouwen van een timer naar pauze zal toch niet zo moeilijk zijn?
alhoewel je voor optimaal resultaat eigenlijk een eigen dll (in c ofzo) zou moeten maken omdat nu 2x QueryPerformanceCounter aanroepen vanuit vb nu al 1 micro sec duurt. helaas ben ik niet zo'n held in C... dus misschien kan iemand anders je dmv deze functie iets maken

[robbertb]

Verwijderd schreef op 15 maart 2004 @ 00:03:
het ombouwen van een timer naar pauze zal toch niet zo moeilijk zijn?
alhoewel je voor optimaal resultaat eigenlijk een eigen dll (in c ofzo) zou moeten maken omdat nu 2x QueryPerformanceCounter aanroepen vanuit vb nu al 1 micro sec duurt. helaas ben ik niet zo'n held in C... dus misschien kan iemand anders je dmv deze functie iets maken

mja in c++ doe je dat dus met wat ik zei in me startpost volgens mij.. maar ik ben ook nog niet zo thuis in C++ en ik heb ook geen C++.
Ik snap dat zoiets misschien om te bouwen valt, maar zoals ik al zei, als ik alles in een class-module zet, is de helft rood. Dus syntax-error voor VB
De melding op de eerste regel (Public class HiResTimer):
Compile error:
Expected: end of statement

[ Voor 7% gewijzigd door robbertb op 15-03-2004 00:13 ]

[Paling1]

Ik heb ooit een VB-proggie geschreven dat via de COM-poort communiceerde met mijn GSM... Toen heb ik zoiets als dit gebruikt:

code:

Dim duration, dummy As Variant
Dim lngDelay as Long
    
    duration = Timer + lngDelay
    Do Until Timer > duration
        dummy = DoEvents()
    Loop

lngDelay is hier het aantal sec dat er gepauzeerd moet worden. Wat het doet is het volgende: De huidige tijd wordt in een variabele gezet samen met de gewenste vertraging. Daarna wordt er een nieuwe huidige tijd vergeleken met de opgeslagen tijd+vertraging totdat de nieuwe huidige tijd groter is. Bij mij ging het om vertragingen van enkele tienden van seconden. Of het ook met milliseconden kan weet ik niet

Later kwam ik erachter dat er vanaf mijn GSM altijd een antwoord op een opdracht altijd werd afgesloten met een 'OK'. Dus toen heb ik de functie verbouwd zodat er pas wat ging gebeuren als er een string 'OK' werd gevonden in de output van de COM-poort. Misschien dat dit voor jou een betere oplossing is, want er werd mij verteld dat er nogal wat nadelen zaten aan het DoEvents gebeuren...

[ Voor 21% gewijzigd door Paling1 op 15-03-2004 00:18 ]

[.oisyn]

Overigens kan het dus niet eens. Je zou met QueryPerformanceCounter () de verstreken tijd bij kunnen houden, en net zo lang loopen tot de juiste hoeveelheid tijd verstreken is. Echter, je werkt in een multitasking, non-realtime OS, er zijn dus geen tijdsgaranties en terwijl jij staat te wachten kan het systeem gewoon overschakelen naar een andere thread, zodat die wachttijd geen microseconde maar ineens een milliseconde is

[robbertb]

Paling1 schreef op 15 maart 2004 @ 00:14:
Ik heb ooit een VB-proggie geschreven dat via de COM-poort communiceerde met mijn GSM...
[knip verhaal]
...verteld dat er nogal wat nadelen zaten aan het DoEvents gebeuren...

Bedankt voor je bedrage, maar ik zoek dus een delay van µs.. dat is dus een 1000e van een ms als ik me niet vergis.

.oisyn schreef op 15 maart 2004 @ 00:15:
Overigens kan het dus niet eens. Je zou met QueryPerformanceCounter () de verstreken tijd bij kunnen houden, en net zo lang loopen tot de juiste hoeveelheid tijd verstreken is. Echter, je werkt in een multitasking, non-realtime OS, er zijn dus geen tijdsgaranties en terwijl jij staat te wachten kan het systeem gewoon overschakelen naar een andere thread, zodat die wachttijd geen microseconde maar ineens een milliseconde is

Ja daar dacht ik dus ook al aan, een looplusje die net zo lang duur blijft gaan tot de tijd verstreken is. Erg netjes is het niet maar de tijd is heel kort. Maar het is idd maar de vraag of dat gaat werken. En zoals ik net al zei heb ik problemen met het importeren van die zooi.
Heb nieuwe classmodule gemaakt en daar die zooi in gegooit, de helft wordt dan niet herkent door vb

[ Voor 54% gewijzigd door robbertb op 15-03-2004 00:19 ]

[Paling1]

een microsec is een duizendste van een sec... een millisec een honderdste dusse kraakkraak pieppiep dan is ehhhhhhh een microsec een tiende van een millisec. toch?

Trouwens ik heb het net nog effe naar een sec geedit... dus heb je er nog minder aan.

[robbertb]

Paling1 schreef op 15 maart 2004 @ 00:21:
een microsec is een duizendste van een sec... een millisec een honderdste dusse kraakkraak pieppiep dan is ehhhhhhh een microsec een tiende van een millisec. toch?

Trouwens ik heb het net nog effe naar een sec geedit... dus heb je er nog minder aan.

Nee,
een millisec is een duizendste van een seconde. Een microseconde is een duizendste van een milliseconde.
Dus: 1 microseconde = 1 µs = 1/1000 ms = 1/1.000.000 sec
Volgens mij

[ Voor 8% gewijzigd door robbertb op 15-03-2004 00:29 ]

[418O2]

je wil signalen sturen neem ik aan? op school gebruiken we (in C) een delay van 150ms voor we signalen naar een pic sturen.. Kweenie of dat userfull is voor jou?

[Paling1]

robbertb schreef op 15 maart 2004 @ 00:28:
[...]

Nee,
een millisec is een duizendste van een seconde. Een microseconde is een duizendste van een milliseconde.
Dus: 1 microseconde = 1 µs = 1/1000 ms = 1/1.000.000 sec
Volgens mij

hmmmm shame on me.... 't is ook al laat hè

[robbertb]

418O2 schreef op 15 maart 2004 @ 00:32:
je wil signalen sturen neem ik aan? op school gebruiken we (in C) een delay van 150ms voor we signalen naar een pic sturen.. Kweenie of dat userfull is voor jou?

Nee, want ik gebruik het voor de 1-wire tempsensor van dallas. En daar staat in de PDF dat ik met delays van 0,25µs-1µs moet pauzeren.

[Knutselsmurf]

Bij het aansturen van mijn LCD vanuit Delphi kwam ik ook een soortgelijk probleem tegen. Met QueryPerformanceCounter heb ik dit uiteindelijk prima opgelost. In mijn geval was het probleem dat mijn computer te snel was voor de LCD, dus het probleem was slechts om een delay te vinden die kort genoeg duurt. Zoals al eerder vermeld, is er geen garantie voor het maximum van de wachtlus. Heb je al gekeken wat het gevolg is als de wachttijd (veel) langer duurt dan 1 microseconde?

[ Voor 11% gewijzigd door Knutselsmurf op 15-03-2004 00:43 ]

[robbertb]

Knutselsmurf schreef op 15 maart 2004 @ 00:43:
Bij het aansturen van mijn LCD vanuit Delphi kwam ik ook een soortgelijk probleem tegen. Met QueryPerformanceCounter heb ik dit uiteindelijk prima opgelost. In mijn geval was het probleem dat mijn computer te snel was voor de LCD, dus het probleem was slechts om een delay te vinden die kort genoeg duurt. Zoals al eerder vermeld, is er geen garantie voor het maximum van de wachtlus. Heb je al gekeken wat het gevolg is als de wachttijd (veel) langer duurt dan 1 microseconde?

Uit de PDF:

The system must be capable of generating an accurate and repeatable 1µs delay for standard speed and 0.25µs delay for overdrive speed.
http://pdfserv.maxim-ic.com/en/an/app126.pdf

Als je daar verderop kijkt staat er ook een tabel met min en max tijdsduur en max is op zn hoogst 640µs. Maar niet alles mag met zo lange duur duren. Zo staat er ook een bij die max 1,85µs mag duren.

[BraveWorld]

Mmm, vroeger, in mijn assembly programmeertijd met embedded devices wilde ik soms even de interrupts disablen om een gedefinieerde delay te maken die niet onderbroken werd door interrupts. Hoe dat precies op PC's zit weet ik niet. En daarbij, als de timing gemaakt wordt door een loopje zonder timer is het afhankelijk van de snelheid van de PC.

Maare... de site zelve geeft toch hulp:

http://www.maxim-ic.com/products/1-wire/software/
http://www.maxim-ic.com/1-Wire.cfm

[robbertb]

BraveWorld schreef op 15 maart 2004 @ 01:01:
Mmm, vroeger, in mijn assembly programmeertijd met embedded devices wilde ik soms even de interrupts disablen om een gedefinieerde delay te maken die niet onderbroken werd door interrupts. Hoe dat precies op PC's zit weet ik niet. En daarbij, als de timing gemaakt wordt door een loopje zonder timer is het afhankelijk van de snelheid van de PC.

Maare... de site zelve geeft toch hulp:

http://www.maxim-ic.com/products/1-wire/software/
http://www.maxim-ic.com/1-Wire.cfm

Jup die sites had ik al bekeken had er alleen niet zo veel aan. Zie ook nergens iets terug van die delays.

Vraag me of het uberhaupt wel kan.. heb flink zitten googlen..
Ik kwam uit eindelijk wel uit op http://www.ryledesign.com/winhrt.html
Maarja dat kost 79 dollar. Maar het lijkt dus wel mogelijk te zijn.

[ Voor 14% gewijzigd door robbertb op 16-03-2004 00:27 ]

[robbertb]

niemand?

[Verwijderd]

Ik ben geen VB-programmeur, maar kun je hem niet gewoon even een kort onzinnig for-loopje laten doorlopen. Als je je processorsnelheid weet, kun je nagaan hoeveel instructies per µs worden uitgevoerd, weet je precies hoe lang hij bezig is met je onzinnige for-loopjes.
Of moet hij echt wachten en moet hij ook naar een andere thread springen?
Zo ja, negeer deze onzinnige reply over onzinnige for-loopjes dan maar

[Verwijderd]

robbertb schreef op 15 maart 2004 @ 01:19:
[...]

Jup die sites had ik al bekeken had er alleen niet zo veel aan. Zie ook nergens iets terug van die delays.

Vraag me of het uberhaupt wel kan.. heb flink zitten googlen..
Ik kwam uit eindelijk wel uit op http://www.ryledesign.com/winhrt.html
Maarja dat kost 79 dollar. Maar het lijkt dus wel mogelijk te zijn.

Dat is toch jou oplissing?

edit:

Messchien dacht ik iets te snel na over je budget. Je schrijft het voor een zelf gemaakte sensor... dus je wilt er zo min mogelijk aan besteden.

[ Voor 24% gewijzigd door Verwijderd op 16-03-2004 22:56 ]

[robbertb]

Verwijderd schreef op 16 maart 2004 @ 22:40:
Ik ben geen VB-programmeur, maar kun je hem niet gewoon even een kort onzinnig for-loopje laten doorlopen. Als je je processorsnelheid weet, kun je nagaan hoeveel instructies per µs worden uitgevoerd, weet je precies hoe lang hij bezig is met je onzinnige for-loopjes.
Of moet hij echt wachten en moet hij ook naar een andere thread springen?
Zo ja, negeer deze onzinnige reply over onzinnige for-loopjes dan maar

Ehm zoals ik eerder al zei is de tijdsduur belangrijk: te lang is niet goed en te kort ook niet. Zoiets is ook vrij intensief. Het is niet de bedoeling dat me cpu-usage stijgt naar 100%. Daarnaast wil ik het ook op andere pc's gebruiken.

Verwijderd schreef op 16 maart 2004 @ 22:53:
[...]

Dat is toch jou oplissing?

edit:
Messchien dacht ik iets te snel na over je budget. Je schrijft het voor een zelf gemaakte sensor... dus je wilt er zo min mogelijk aan besteden.

Inderdaad veel te duur.

[ Voor 19% gewijzigd door robbertb op 16-03-2004 23:04 ]

[farlane]

Als je timing echt zo correct moet zijn moet je overstappen naar een rt os. Er zijn diverse smaken linux te downloaden die op een x86 werken en die dit kunnen.

Je zou er ook over kunnen denken om dit in een uP op te lossen, en die via een seriele link naar de PC te brengen ( RS232, USB, dat soort dingen )

[Verwijderd]

Ik denk toch dat je met QueryPerformanceCounter het verst kan komen...

[farlane]

robbertb schreef op 14 maart 2004 @ 23:56:
[...]

Hm dat is een timer en ik wil een kleine pauze.
Ik heb het geplakt in een nieuwe VB-class maar dan wordt de helft rood
Zelfs "Public Class HiResTimer"

Is VB.NET, vandaar.

[farlane]

Verwijderd schreef op 16 maart 2004 @ 23:18:
Ik denk toch dat je met QueryPerformanceCounter het verst kan komen...

Je zou dan een busywait moeten maken, wat meteen inhoudt dat als je ook maar de focus naar een andere applicatie laat gaan je timing helemaal in de soep loopt.

[Verwijderd]

farlane schreef op 16 maart 2004 @ 23:20:
[...]
Je zou dan een busywait moeten maken, wat meteen inhoudt dat als je ook maar de focus naar een andere applicatie laat gaan je timing helemaal in de soep loopt.

True... ik zou eigelijk geen anderen gratis oplossing weten.

De Preformence counter is iig precieser dan gewoon je DateTime en die substracten. Maar anderen oplossing heb ik niet.

[ Voor 16% gewijzigd door Verwijderd op 16-03-2004 23:28 ]

[robbertb]

Ik zit nou te denken om dan maar een simpel voorbeeld te zoeken voor Visual C++ en hiervan een DLL te bakken en die in VB te gebruiken ofzo.
Ik had deze gevonden:
http://www.labjack.com/files/1wweatherV100.zip
Maar als ik die compileer maakt hij een leuke DLL waar ik verder niks mee kan onder VB.. ik dacht dat je met C++ ook dlls kon maken die andere programmeertalen konden gebruiken..

[farlane]

robbertb schreef op 17 maart 2004 @ 00:42:
Ik zit nou te denken om dan maar een simpel voorbeeld te zoeken voor Visual C++ en hiervan een DLL te bakken en die in VB te gebruiken ofzo.

Daar schiet je niets mee op. Je resolutie is dan nog altijd beroerd. De beste timing zonder een busywait bereik je nog altijd met een waitable timer of een multimedia timer. Als het daar niet mee lukt, moet je naar een realtime os toe.

[Knutselsmurf]

Een heel andere oplossing, die zeker weten werkt. Zorg dat je een 8031 processortje op de kop tikt. Die zijn niet zo heel duur. Die kan je op assembly-niveau programmeren, inclusief alle low-level-trucjes als timer-interrupts zelf bouwen enzo. Een standaard bordje voor zo'n processor heeft ook een seriele poort aan boord. Dan kan je het aansturen van de sensor via timer-interrupts strak regelen op dat bordje en het communiceren met de PC voor het doorgeven van de waarden kan daar wel tussendoor.

[robbertb]

farlane schreef op 17 maart 2004 @ 20:16:
[...]


Daar schiet je niets mee op. Je resolutie is dan nog altijd beroerd. De beste timing zonder een busywait bereik je nog altijd met een waitable timer of een multimedia timer. Als het daar niet mee lukt, moet je naar een realtime os toe.

Hoezo niet ?
Ik bedoel een dll met de methode "getTemperature"
DIe dan in een string de temperaturen geeft..
En die methode roep je dan zegmaar elke 5 minuten aan.. dat moet toch kunnen?
Ik bedoel dus niet een DLL voor de pauze maar een dll die alle communicatie doet met de temperatuursensor.
Daarnaast een realtime OS? In andere programmeertalen zijn er gewoon voorbeelden van dus het moet gewoon kunnen in winxp zonder idioot hoge cpu-load.

Knutselsmurf schreef op 17 maart 2004 @ 20:33:
Een heel andere oplossing, die zeker weten werkt. Zorg dat je een 8031 processortje op de kop tikt. Die zijn niet zo heel duur. Die kan je op assembly-niveau programmeren, inclusief alle low-level-trucjes als timer-interrupts zelf bouwen enzo. Een standaard bordje voor zo'n processor heeft ook een seriele poort aan boord. Dan kan je het aansturen van de sensor via timer-interrupts strak regelen op dat bordje en het communiceren met de PC voor het doorgeven van de waarden kan daar wel tussendoor.

Ik kan geen assembly. Daarnaast dan moet ik dus nog een extra machine aanhebben das niet de bedoeling.

[ Voor 41% gewijzigd door robbertb op 17-03-2004 21:04 ]

[Verwijderd]

Als ik was zou ik nog maar es kijken naar de eerste post van .oisyn. Zeker als het geheel in VB moet gaan werken (de VB compiler leverd niet de snelste executable aan) en een OS als Windows (niet real-time) gebruikt zal worden, zal het het zelden voorkomen dat jou 1 microseconde pauze gehaald wordt. De kans dat het OS de idle time aan processor geeft, is de kans groot dat de pauze meer als 1 microseconde wordt.

No offence verder, leuke discussie ook, maar ik denk dat je een andere manier zult zoeken (ander OS, ander taal etc).

[Korben]

Verwijderd schreef op 16 maart 2004 @ 23:18:
Ik denk toch dat je met QueryPerformanceCounter het verst kan komen...

Nou, nee, niet in VB of VB.NET. Ik heb op een P4 2,8 GHz de volgende code in C# uitgevoerd:

C#:

long PC1, PC2, PF = 0;

QueryPerformanceFrequency(out PF);

QueryPerformanceCounter(out PC1);
QueryPerformanceCounter(out PC2);

MessageBox.Show(((float) (PC2 - PC1) / (float) ((float) PF / 1000000)).ToString());
// toont 't aantal microseconden tussen PC1 en PC2

Daaruit komt minimaal 22 microseconden. Ja, het is C#, maar iedereen die verstand heeft van .NET zal beamen dat je in VB.NET precies hetzelfde resultaat krijgt. En ook dat VB.NET stukken sneller is dan gewoon VB.

[.oisyn]

C++:

#include <iostream>
#include <windows.h>


int main () 
{
    __int64 t1, t2, freq;

    std::cin.get ();

    QueryPerformanceCounter ((LARGE_INTEGER *)&t1);
    QueryPerformanceCounter ((LARGE_INTEGER *)&t2);
    QueryPerformanceFrequency ((LARGE_INTEGER *)&freq);

    std::cout << 1000000.0 * (t2 - t1) / freq << " microseconds" << std::endl;
}

1.39683 microseconds
Athlon XP 3200+ (2200 MHz). Voor echt nauwkeurige meting vrijwel zonder overhead moet je de rdtsc instructie gebruiken, die geeft het aantal verstreken cycles van de processor terug. Nadeel hiervan is echter dat je exact moet weten hoe snel je cpu draait (hoewel je dat van tevoren zou kunnen synchronizeren met een timer, zoals bijv. de performance counter)

[ Voor 3% gewijzigd door .oisyn op 18-03-2004 03:27 ]

[Korben]

.oisyn schreef op 18 maart 2004 @ 03:25:

C++:

#include <iostream>
#include <windows.h>


int main () 
{
    __int64 t1, t2, freq;

    std::cin.get ();

    QueryPerformanceCounter ((LARGE_INTEGER *)&t1);
    QueryPerformanceCounter ((LARGE_INTEGER *)&t2);
    QueryPerformanceFrequency ((LARGE_INTEGER *)&freq);

    std::cout << 1000000.0 * (t2 - t1) / freq << " microseconds" << std::endl;
}

1.39683 microseconds
Athlon XP 3200+ (2200 MHz). Voor echt nauwkeurige meting vrijwel zonder overhead moet je de rdtsc instructie gebruiken, die geeft het aantal verstreken cycles van de processor terug. Nadeel hiervan is echter dat je exact moet weten hoe snel je cpu draait (hoewel je dat van tevoren zou kunnen synchronizeren met een timer, zoals bijv. de performance counter)

MSDN zegt "The frequency of the high-resolution performance counter is not the processor speed.", maar bij mij geeft QueryPerformanceFrequency toch precies de snelheid van mijn processor terug. Overigens denk ik dat QueryPerformanceCounter() op NT5 x86 gewoon rdtsc is, met wat inkapseling, juist vanwege het feit dat QueryPerformanceCounter je CPU clock speed teruggeeft. Maar aangezien dit toch nog te traag is, is idd rdtsc de beste oplossing.

offtopic:
Overigens snap ik de uiteenlopende resultaten niet... Zelfs in C# is de uiteindelijke door de EE gegenereerde code maar 3 instructies:

00000036 lea ecx,[ebp-10h]
00000039 call dword ptr ds:[00B45B10h]
0000003f nop

Is dus gewoon keihard assembler, maar assembler kan nooit zo langzaam zijn...

[ Voor 34% gewijzigd door Korben op 18-03-2004 04:56 ]

[Juicy]

Korben schreef op 18 maart 2004 @ 04:41:
[...]
Overigens snap ik de uiteenlopende resultaten niet... Zelfs in C# is de uiteindelijke door de EE gegenereerde code maar 3 instructies:

00000036 lea ecx,[ebp-10h]
00000039 call dword ptr ds:[00B45B10h]
0000003f nop

Is dus gewoon keihard assembler, maar assembler kan nooit zo langzaam zijn...

Wat denk je wat die "call" doet ? Dat is gewoon een call naar andere code, dus daar zit je "verloren" tijd.

Daarnaast kun je een resolutie van 0.25 tot 1 microseconde vergeten. Misschien dat je met een multimediatimer richting de milliseconde kunt gaan.

[farlane]

robbertb schreef op 17 maart 2004 @ 21:03:
[...]

Hoezo niet ?
Ik bedoel een dll met de methode "getTemperature"
DIe dan in een string de temperaturen geeft..
En die methode roep je dan zegmaar elke 5 minuten aan.. dat moet toch kunnen?
Ik bedoel dus niet een DLL voor de pauze maar een dll die alle communicatie doet met de temperatuursensor.
Daarnaast een realtime OS? In andere programmeertalen zijn er gewoon voorbeelden van dus het moet gewoon kunnen in winxp zonder idioot hoge cpu-load.

Het maakt niet uit in welke programmeertaal je het schrijft, je resolutie blijft onvoldoende om nauwkeurige timing te doen. ( Dus ook als je het door een dll laat doen )

Dat is inherent aan het Windows platform, en kun je kunt daar niet omheen programmeren. Misschien kun je met een oude PC onder MSDOS een beter resultaat krijgen, als je liever niet experimenteert met een rt-linux versie.

En zoals al eerder aangegeven, een dedicated uP zou de trick ook kunnen doen.

[farlane]

Korben schreef op 18 maart 2004 @ 03:03:
En ook dat VB.NET stukken sneller is dan gewoon VB.

Het spijt me zeer maar daar wil ik dan eerst eens wat bewijzen voor zien. Ik geloof er geen hol van namelijk.

[Juicy]

farlane schreef op 18 maart 2004 @ 08:56:
Het spijt me zeer maar daar wil ik dan eerst eens wat bewijzen voor zien. Ik geloof er geen hol van namelijk.

Je zou zelf ook even de moeite kunnen doen om dit even in Google op te zoeken.

[.oisyn]

Korben schreef op 18 maart 2004 @ 04:41:
MSDN zegt "The frequency of the high-resolution performance counter is not the processor speed."

Natuurlijk zeggen ze dat, die garantie kunnen ze namelijk niet bieden. Niemand heeft er wat aan dat ze zeggen dat "het soms weleens de snelheid van je cpu is" . Het is overigens alom bekend dat QueryPerformanceCounter niet de snelste functie is; hij is zelfs relatief erg traag

.edit: bij mij is de frequentie overigens 3579545, de counter gaf dus een verschil van slechts 5 (5/3579545 = 1.39683). Bij mij heeft het dan ook niets met de snelheid van mijn cpu te maken (hoewel ik me afvraag waarmee ie het dan doet)

[ Voor 21% gewijzigd door .oisyn op 18-03-2004 13:22 ]

[.oisyn]

Juicy schreef op 18 maart 2004 @ 12:36:
[...]


Je zou zelf ook even de moeite kunnen doen om dit even in Google op te zoeken.

ja, google geeft dan ook echt een voorbeeld in de zin van: QueryPerformanceCounter is langzaam in VB en snel in VB.Net . Sommige dingen zijn nou eenmaal niet op te zoeken. Ook vb is naar native code te compileren, en even een native win32 functie aanroepen zal ik niet zoveel overhead zijn. Misschien dat vb.net overall sneller is dan vb, maar dat is hier helemaal niet de issue hier

[ Voor 24% gewijzigd door .oisyn op 18-03-2004 13:17 ]

[Korben]

farlane schreef op 18 maart 2004 @ 08:56:
[...]


Het spijt me zeer maar daar wil ik dan eerst eens wat bewijzen voor zien. Ik geloof er geen hol van namelijk.

Bewijs? Alleen al het feit dat VB.NET uiteindelijk van IL naar pure machinecode wordt gecompiled moet genoeg zijn. Itt VB, wat altijd gewoon P-code blijft.

[Korben]

Juicy schreef op 18 maart 2004 @ 07:04:
[...]
Wat denk je wat die "call" doet ? Dat is gewoon een call naar andere code, dus daar zit je "verloren" tijd.

Mjah... en jij denkt dat C++ het anders doet?

[.oisyn]

Korben:

.oisyn schreef op 18 maart 2004 @ 13:16:
Ook vb is naar native code te compileren

Die optie zit bestaat al sinds ik meen VB4

[Korben]

.oisyn schreef op 18 maart 2004 @ 13:14:
[...]
.edit: bij mij is de frequentie overigens 3579545, de counter gaf dus een verschil van slechts 5 (5/3579545 = 1.39683). Bij mij heeft het dan ook niets met de snelheid van mijn cpu te maken (hoewel ik me afvraag waarmee ie het dan doet)

offtopic:
Een performance counter met een snelheid van slechts 3,5 MHz... Hmm... misschien de PIT? Maar anyway, vreemd, want bij mij kwam er 2806400000 uit, en het verschil lag dan ook in de orde van de 10000.

[Korben]

.oisyn schreef op 18 maart 2004 @ 13:16:
[...]
Ook vb is naar native code te compileren

Mjah dan nog zal VB vele malen langzamer zijn door teveel loose types, overflow checks etc. etc. Maar idd, dat was niet de issue.

[farlane]

Korben schreef op 18 maart 2004 @ 15:46:
[...]
Mjah dan nog zal VB vele malen langzamer zijn door teveel loose types, overflow checks etc. etc. Maar idd, dat was niet de issue.

[offtopic]

Het spijt me zeer maar die loose types ( ik neem aan dat je daarmee varianten bedoeld ? ) heb je bij deze calls niet nodig.

Bovendien kun je die runtime checks ( die ook door de .net runtime worden gedaan volgens mij ) ook uitschakelen als je dat wilt

Al met al, VB.Net kan naar mijn idee nooit 'vele malen' sneller zijn.

[edit]
Ik kom in VB6 ( onafhankelijk van runtime check instellingen ) uit op +/- 2us voor een call.
Zou jij em ff willen testen met VB.NET ?

[ Voor 13% gewijzigd door farlane op 18-03-2004 18:07 ]

[.oisyn]

farlane: denk niet dat dat enig verschil heeft met c#
[rml]Korben in "[ VB] hoe hele kleine pauze maken van 1µs..."[/rml]

[ Voor 36% gewijzigd door .oisyn op 18-03-2004 18:39 ]

[Juicy]

Korben schreef op 18 maart 2004 @ 15:37:
[...]
Mjah... en jij denkt dat C++ het anders doet?

Dat zeg ik niet, maar jij zei dat je niet begreep waarom de 3 regels assemblycode zoveel tijd kosten ... Vandaar.

[igmar]

.oisyn schreef op 18 maart 2004 @ 03:25:
Athlon XP 3200+ (2200 MHz). Voor echt nauwkeurige meting vrijwel zonder overhead moet je de rdtsc instructie gebruiken, die geeft het aantal verstreken cycles van de processor terug. Nadeel hiervan is echter dat je exact moet weten hoe snel je cpu draait (hoewel je dat van tevoren zou kunnen synchronizeren met een timer, zoals bijv. de performance counter)

Da's leuk, zolang je als proces gescheduled bent. Daarna is wat anders aan de beurt, en gaat de kernel bv eens lekker een paar milliseconden op een disk lopen wachten. In dit geval zul je denk ik toch naar een embedded platform moeten, of zoals als gezegd naar een microprocessor.

Sommige OS'en hebben de mogelijkheid om een realtime scheduler aan te zetten, maar dan nog ga je die 1 usec niet halen vrees ik.

[pjvandesande]

Knutselsmurf schreef op 17 maart 2004 @ 20:33:
Een heel andere oplossing, die zeker weten werkt. Zorg dat je een 8031 processortje op de kop tikt. Die zijn niet zo heel duur. Die kan je op assembly-niveau programmeren, inclusief alle low-level-trucjes als timer-interrupts zelf bouwen enzo. Een standaard bordje voor zo'n processor heeft ook een seriele poort aan boord. Dan kan je het aansturen van de sensor via timer-interrupts strak regelen op dat bordje en het communiceren met de PC voor het doorgeven van de waarden kan daar wel tussendoor.

Ik denk dat deze oplissing die Kuntselsmurf je geeft dan toch is het overwegen waard is.

[.oisyn]

igmar schreef op 18 maart 2004 @ 20:42:
[..knip..]

he?
Oh je bedoelt dit: [rml].oisyn in "[ VB] hoe hele kleine pauze maken van 1µs..."[/rml]

[farlane]

.oisyn schreef op 18 maart 2004 @ 18:38:
farlane: denk niet dat dat enig verschil heeft met c#
[rml]Korben in "[ VB] hoe hele kleine pauze maken van 1µs..."[/rml]

Hmmm, dat was dan ook meteen het bewijs wat ik wilde hebben

[robbertb]

Maar het moet toch mogelijk zijn om in C++ een DLL te maken die de tempuitleest en deze DLL te gebruiken in VB?
Ik dacht dat ik misschien iets van deze code in een DLL kan zetten:
http://arti.vub.ac.be/~bartj/domoticube/touch.c
(komt van http://arti.vub.ac.be/~bartj/domoticube/1wireboard.html).

Maarja als ik dan delay_us probeer in zo dll in C++ geeft hij daar al een error op:

code:

c:\program files\microsoft visual studio\myprojects\testje\testje.h(41) : error C2059: syntax error : 'constant'
Error executing cl.exe.

testje.dll - 1 error(s), 0 warning(s)

[ Voor 36% gewijzigd door robbertb op 20-03-2004 03:25 ]

[robbertb]

niemand een idee hoe ik de tempmeting in c++ dll vorm kan gooien en die gebruiken onder vb?
Ik weet dat het kan met COM dll.
Ik heb echt al heel wat voorbeelden geprobeert maar ze werken allen niet of waren zo uitgebreid dat ik het overzicht kwijt was. Ik heb namelijk weinig ervaring in C++
www.digitemp.com

[ Voor 43% gewijzigd door robbertb op 21-03-2004 15:11 ]

[farlane]

Die code die je daar postte is geen windows code, het lijkt meer op iets voor een dedicated uP.

Code in een dll zetten is niet moeilijk, je daarvoor alleen tegen de compiler/linker te zeggen dattie een dll moet genereren ipv een applicatie, en de door jouw gewenste functies in een export definition bestand te zetten. ( xxxx.def )

Tenminste, zo werkt het in Visual Studio.

Maar, ik zou eerst gewoon proberen om je code werkend te krijgen, en daarnaa de stap maken naar C/C++ en dll, omdat je waarschijnlijk meer ervaring hebt met VB.

[Creepy]

robbertb schreef op 21 maart 2004 @ 14:49:
niemand een idee hoe ik de tempmeting in c++ dll vorm kan gooien en die gebruiken onder vb?
Ik weet dat het kan met COM dll.
Ik heb echt al heel wat voorbeelden geprobeert maar ze werken allen niet of waren zo uitgebreid dat ik het overzicht kwijt was. Ik heb namelijk weinig ervaring in C++
www.digitemp.com

De wachttijd voor het versturen van het volgende commando kan waarschijnlijk best wat groter zijn. Zolang het maar niet korter is. Zelf gebruik ik de methode m.b.v. QueryPerformanceCounter voor wachttijden van 40 microseconden.
Ik update elke seconden een LCD scherm (aansturing via de LPT poort). Elk karakter versturen zorgt minimaal 1 keer voor een busy loop m.b.v. query performce counter, en dan nog blijft het CPU gebruik erg laag (lees <3% cpu belasting op een 1Ghz machine).

Ik zou gewoon met die query performce counter een loop maken totdat je aan die 1 microseconde zit. Dat dit er meer wordt maakt zeer waarschijnlijk voor de sensor niet uit. EN als 1 loop al langer is dan 1 microseconde heb je dus ook eigenlijk geen busyloop meer.

Hoe stuur je dat ding eigenlijk aan? Want een loos commando sturen naar een LPT poort zorgt ook al voor een delay van (iets groter dan) 1 microseconde. Als je het commando dus 2 keer op de lijn zet (waardoor bij de tweede keer de lijn status van de LPT poort niet mag veranderen) is je delay waarschijnlijk al groot genoeg.

[igmar]

.oisyn schreef op 18 maart 2004 @ 23:06:
he?
Oh je bedoelt dit: [rml].oisyn in "[ VB] hoe hele kleine pauze maken van 1µs..."[/rml]

Mea culpa, ik ben gewoon ietwat scheel, totaal gemist die post