+ Post New Thread
Results 1 to 11 of 11
  1. #1
    Full Member level 3
    Points: 2,020, Level: 10
    Achievements:
    7 years registered

    Join Date
    Aug 2011
    Posts
    158
    Helped
    0 / 0
    Points
    2,020
    Level
    10

    polling data ready bit on linux device driver

    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

    •   AltAdvertisment

        
       

  2. #2
    Super Moderator
    Points: 75,064, Level: 66
    Achievements:
    7 years registered
    Awards:
    2nd Helpful Member
    betwixt's Avatar
    Join Date
    Jul 2009
    Location
    Aberdyfi, West Wales, UK
    Posts
    12,295
    Helped
    4082 / 4082
    Points
    75,064
    Level
    66

    Re: polling data ready bit on linux device driver

    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.
    PLEASE - no friends requests or private emails, I simply don't have time to reply to them all.
    It's better to share your questions and answers on Edaboard so we can all benefit from each others experiences.



  3. #3
    Super Moderator
    Points: 67,706, Level: 63
    Achievements:
    7 years registered
    Awards:
    Most Frequent Poster 3rd Helpful Member

    Join Date
    Apr 2014
    Posts
    13,846
    Helped
    3158 / 3158
    Points
    67,706
    Level
    63

    Re: polling data ready bit on linux device driver

    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
    Please donīt contact me via PM, because there is no time to respond to them. No friend requests. Thank you.



  4. #4
    Super Moderator
    Points: 249,762, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    43,481
    Helped
    13214 / 13214
    Points
    249,762
    Level
    100

    Re: polling data ready bit on linux device driver

    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.



  5. #5
    Super Moderator
    Points: 28,092, Level: 40
    andre_teprom's Avatar
    Join Date
    Nov 2006
    Location
    Brazil
    Posts
    8,391
    Helped
    1058 / 1058
    Points
    28,092
    Level
    40
    Blog Entries
    6

    Re: polling data ready bit on linux device driver

    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.
    --------------------------------------------------------------------------------------------------
    Part of the world that you live in, You are the part that you're giving ( Renaissance )



    •   AltAdvertisment

        
       

  6. #6
    Full Member level 3
    Points: 2,020, Level: 10
    Achievements:
    7 years registered

    Join Date
    Aug 2011
    Posts
    158
    Helped
    0 / 0
    Points
    2,020
    Level
    10

    Re: polling data ready bit on linux device driver

    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)



  7. #7
    Super Moderator
    Points: 67,706, Level: 63
    Achievements:
    7 years registered
    Awards:
    Most Frequent Poster 3rd Helpful Member

    Join Date
    Apr 2014
    Posts
    13,846
    Helped
    3158 / 3158
    Points
    67,706
    Level
    63

    Re: polling data ready bit on linux device driver

    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
    Please donīt contact me via PM, because there is no time to respond to them. No friend requests. Thank you.



  8. #8
    Full Member level 3
    Points: 2,020, Level: 10
    Achievements:
    7 years registered

    Join Date
    Aug 2011
    Posts
    158
    Helped
    0 / 0
    Points
    2,020
    Level
    10

    Re: polling data ready bit on linux device driver

    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.



  9. #9
    Super Moderator
    Points: 67,706, Level: 63
    Achievements:
    7 years registered
    Awards:
    Most Frequent Poster 3rd Helpful Member

    Join Date
    Apr 2014
    Posts
    13,846
    Helped
    3158 / 3158
    Points
    67,706
    Level
    63

    Re: polling data ready bit on linux device driver

    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
    Please donīt contact me via PM, because there is no time to respond to them. No friend requests. Thank you.



  10. #10
    Super Moderator
    Points: 28,092, Level: 40
    andre_teprom's Avatar
    Join Date
    Nov 2006
    Location
    Brazil
    Posts
    8,391
    Helped
    1058 / 1058
    Points
    28,092
    Level
    40
    Blog Entries
    6

    Re: polling data ready bit on linux device driver

    You need rather a Linux distro with RTOS capability.
    It is not available for many hardware platforms, unfortunatelly.
    --------------------------------------------------------------------------------------------------
    Part of the world that you live in, You are the part that you're giving ( Renaissance )



    •   AltAdvertisment

        
       

  11. #11
    Super Moderator
    Points: 249,762, Level: 100
    Awards:
    1st Helpful Member

    Join Date
    Jan 2008
    Location
    Bochum, Germany
    Posts
    43,481
    Helped
    13214 / 13214
    Points
    249,762
    Level
    100

    Re: polling data ready bit on linux device driver

    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.



--[[ ]]--