From: Grahame J. <gb...@th...> - 2008-01-09 05:38:26
|
I am a little confused about this. In general I want to get a sure understanding of creating delays/sleeps that are actually what I ask for +- some reasonable resolution. 20msec is not reasonable for usleep(1-19000) or even for nanosleep(xxx); This particular program is written in user space, with threads. One thread is reading a Liquid Flow Meter via I2C Another thread is controlling a character LCD The LCD requires sub usec sleeps to operate at a nice speed, which I am implementing with gettimeofday() * n (~5us) which is ugly, The Flow Meter needs to sleep for specific(accurate) amounts of time in the msec range < 20msecs in some cases to enable accurate flow readings. The sleeps need to be non_blocking so that the other thread can do its bit. I would like to be sure at least in the cased of Flow Meter that the sleeps are within +- 0.5 msec every time so that I can get accurate flow/volume calculation. However the usleep should be able to do the same +- 0.5usec. Linux does things sometime that exceeds the time of the sleeps. Is there a method to get the usec sleeps to be what I ask for. An example would be nice. Help and guidance will be much appreciated Thanks Grahame Dan McDonald - Gumstix wrote: > I don't know what the prototype for getmem is like. It may be discarding > the volatile cast. > > try a direct memory access with > > time[i] = *OSCR0 > > where the OSCR0 is a pointer to a volatile unsigned int. > > Later, > Dan McDonald > > >> Dear Tom Shepard, >> >> >>> Date: Sat, 22 Dec 2007 13:30:28 -0800 (PST) >>> From: Tom Shepard <tom...@ya...> >>> >> ... >> >>> Here's the core of the test (OSCR0 is defined as 0x40A00010): >>> >>> getmem(OSCR0); >>> >>> for (i = 0; i < N; i++) { >>> times[i] = getmem(OSCR0); >>> } >>> >>> for (i = 0; i < N; i++) { >>> printf("%u\n", times[i]); >>> } >>> >> ... >> >>> Here's something else that's funny: if you remove the first >>> getmem(OSCR0), >>> the sample values never change, even over 3000 samples. >>> >> ... >> >> Dear Tom Shepard, >> >> I'm mystified by the other things you mention, but "values never >> change" is a classic sign of missing "volatile" declarations. >> >> I suspect that OSCR0 should be defined as something like >> #define OSCR0 ( (int volatile *)0x40A00010 ) >> . >> If somehow it is being defined as >> #define OSCR0 ( (int *)0x40A00010 ) >> then the compiler may (or may not) "optimize" away repeated reads, >> re-using the first read cached in a register, giving the "values never >> change" problem you see. >> >> I've heard that some compilers have had a bug, causing them to >> improperly ignore the "volatile" qualifier in some specific programs >> under some specific optimization levels -- do you still get the >> "values never change" problem if you re-compile with all optimizations >> turned off? >> >> "volatile" >> http://en.wikibooks.org/wiki/Embedded_Systems/C_Programming#volatile >> >> -- >> David Cary >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |