Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

polling data ready bit on linux device driver

Status
Not open for further replies.

garimella

Full Member level 5
Joined
Aug 25, 2011
Messages
260
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,296
Activity points
3,276
Hi
I have a device which responds with a data ready signal which only lasts for 30us. I have to sense this event change in device driver program and subsequently read the converted data. What is the right strategy? polling or ISR? examples would be better
 

An ISR will always respond, polling might miss it if the program isn't reading at the instant it occurs. It very much depends on the system speed and program flow.

To be honest, a 30uS pulse is best detected in hardware, use it to set a latch, read the latch then reset it in the program.

Brian.
 

Hi,

It's not clear how your "ISR" solutikn should work. An ISR is just a piece of software.
***

Every pin with interrupt capability should work.
The pin change will set a flag.
* You may poll this flag, (now you don't have the 30us problem) and clear it manually.
* Or it may (immediately) start an ISR. That's my preferred solution..but in detail it depends on your application.

Klaus
 

The missing point is acceptable read latency. As explained by KlausST, any interrupt capable pin edge with sensitivity should work to detect and latch the event.
 

The concept behind device driver implies the use of peripheral 'devices' dedicated to specific tasks, such as PIO, UART, etc. (built-in on chip, or not). On current Linux systems operating at CPU clock speeds as high as in the range of a few hundred megahehtz, it would not be at all appropriate to consider handling IOs when a high rate repetition occurs; this happens, but waste a lot of processing of the system, therefore in the end all depends on your analysis of what more is being executed on the system,vand what is the demand for immediate response to the other tasks.
 

Hi

Please suggest the workaround. Is it possible to detect short duration pulse from linux? Should we change the hardware then? (most of the ADC's have 10us EOC)
 

Hi,

Should we change the hardware then?
We currently don´t know anything about your hardware - so how can we know if you should change it?

Klaus
 

Hi KlausST

Hardware is an ADC with 10us EOC time , which is stretched upto 30us. Bare metal application runs fine as it is able to poll this bit and read the contents. Now I am in trouble with linux , because the application is not able to catch short duration pulse. please suggest workaround.
 

Hi,

We did know this before. One end is an ADC with 10us/30us EOC time....

But to what hardware is it connected to? Don´t say "LINUX", because this is no hardware....
What inputs does it have, and what IO features? (like interrupt on pin change)

Theoretically
* you may "mis-use" a UART Rx to generate an interrupt...
* You may run a timer interrupt every 25us to poll the flag...

****
Don´t get me wrong.
I´m neither an expert for LINUX, nor for the used platforms.

But you give rather vague informations, thus I just ask for (hopefully) useful informations, to enable others to help you.

Klaus
 

You need rather a Linux distro with RTOS capability.
It is not available for many hardware platforms, unfortunatelly.
 

Please suggest the workaround. Is it possible to detect short duration pulse from linux? Should we change the hardware then? (most of the ADC's have 10us EOC)

You are remarkably unaware of suggestions in your thread (e.g. post #3 and #4). Pulse duration isn't a problem if you use edge sensitive interrupt input for the EOC signal. Most important question is however about ADC update rate. How long will the sample be available after EOC signal, can you reliably read the value?

If you don't have access to interrupt inputs (either due to hard- or software restrictions) you should consider a hardware latch.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top