l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
August 5: Social gathering
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2006 Apr 04 13:38

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Must a 300 microsecond delay keep the CPU busy?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Must a 300 microsecond delay keep the CPU busy?



Not knowing the details of your board, it is a little tough to propose a better solution, but here goes.

Since your using the parallel port, you should consider an interrupt based driver, have the board provide the interrupt signal when the A/D conversion is completed. Most A/D chips provide a sense line that indicates when the converion is completed and the data can be read. that way you don't have to "wait" for the board.
Connect the sense line to the interrupt pin on the parallel port.

Then create a tasklet that is called by the driver to move the data from kernel space to user space.

This is a bit more complex than a simple polling scheme, but far more elegant and reliable and totally independent of CPU speed or processor performance. Odds are you won't even notice the short time the CPU is servicing the interrupt.

Regards
John W

Chris Jenks wrote:


Dear Group,

I'm writing a C program on my Debian system to read from an interface board through the parallel port. I need to wait at least 300 microseconds before reading from the next channel, to give the A/D converter on the board time to stabilize, but I don't want to wait much longer (e.g., 10 milliseconds) because it will make the program too slow. The delay functions (usleep, nanosleep...) only provide delays down to 10-30 milliseconds, despite their name, because they apparently yield the CPU to other tasks with every call. The best solution I've found it to read (or write) to a port (e.g., 0x80), which takes one microsecond. By doing this 300 times, I get something close to the wanted delay, plus a little because of time sharing, but it is good enough. The only thing I don't like is that my process takes about 97% of the CPU, even though it spends almost all its time waiting. The CPU is a fanless 386, and it runs pretty hot at 97% usage. Is there an elegant solution to this, or should I look for a CPU fan? I would like to leave this a time-sharing system.

Thanks,

Chris
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech


_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.