Page 1 of 7 1234567 LastLast
Results 1 to 10 of 64

Thread: HQCT Driver.

  1. #1
    FLAC TheLlama's Avatar
    Join Date
    Jul 2004
    Location
    All over the world
    Posts
    970

    Question HQCT Driver.

    Hello everyone.

    I decided not to release the HQCT driver this weekend because I want to add some more features (frequency seeking, etc...). The good news is the driver runs very well and my seeking algorithm will be very fast (compared to the HQCT Driver example).

    Now, developers -- I have a few options for getting data from the device to userspace.

    Option 1: A non blocking read() function. You can read from the device driver as you would with any other file. e.g:
    Code:
    fd = open("/dev/hqct0", O_RDWR); 
    read(fd, buf, 32);
    This function will return immediately with the current data. I.e: it will not wait for the radio to provide new data since the status is buffered. This is optimal for one-shot reads. Now, the problem is, if you put this in a loop to read from the device then you will get many unneeded reads. You will have to rely on a timer which may still cause unneeded reads or lost reports. Please tell me if you do not understand this.

    Option 2: A blocking read() function. This will behave like option 1, except that it will wait until new data is available. Therefore, you can safely place a read loop inside a thread to get new data as soon as it is available. The con is that if you want to just get the current data then you will have to wait until the radio sends the next report.

    Option 3: A hybrid approach. We can have a read() function that blocks. Then we can an ioctl() function that will return the current data without blocking. So, a non-blocking read would look like:
    Code:
    fd = open("/dev/hqct0", O_RDWR); 
    ioctl(fd, HQCTIOC_READ, buf);
    Option 4: Like option 3 except the read() is nonblocking and the ioctl() blocks.

    Option 5: Not really an option, but more of an enhancement to any of the above options. We can also have a proc file (/proc/hqct) which contains human-friendly data of all the attached radios. Oh yeah, the device driver supports multiple units attached.

    Of course, all of these details will be hidden behind a friendly C library eventually (no reason there couldn't be a Python,etc. library too). The benefit is, all the hardware details will be stored in the device driver so it is trival to write a user program to interface with the device

  2. #2
    Newbie Kusuriya's Avatar
    Join Date
    Oct 2004
    Location
    Fort Drum, New York, USA
    Posts
    23
    would a mixture of Option 3 and Option 5 be an option? or a Blocking read(); with an human readable /proc output?
    ---
    "Flying is easy, Just jump at the ground and miss"
    --Ford Perfect, HHGTTG

  3. #3
    FLAC TheLlama's Avatar
    Join Date
    Jul 2004
    Location
    All over the world
    Posts
    970

    Cool

    Quote Originally Posted by Kusuriya
    would a mixture of Option 3 and Option 5 be an option? or a Blocking read(); with an human readable /proc output?
    Yes. I think this is what I will end up doing anyways. Option 3 and 5 are already implemented. read() is non-blocking while ioctl(HQCTIOC_READ) blocks. The proc file will come later. The ioctl calls are much more efficient than parsing proc output. Proc is naturally a bit slower, so I will probably only update it every 5 radio-updates or so. You can get the status of the driver and certain radio features with various ioctl calls too, but you need to read the whole report for anything else. There is no reason the C api couldn't parse the report and provide a ton of get_fubar() functions.

    Seeking support is finished. It moves between stations much faster than its Windows equivalent. The seeking functions are non-blocking so you can easily use them in non-threaded applications and not lock your program while the radio scans. If you want the seek function to block, it is as simple as:
    Code:
    ioctl(fd, HQCTIOC_SEEK_UP, 0); 
    ioctl(fd, HQCTIOC_READ, 0);
    The first function returns immediately but the read function will not return until the radio is finished seeking and new data is available. Note, you can use standard non-blocking read() while the radio is tuning.

    I still need to add some more calls and there is alot of user error checking that needs to be added before I release the first version. The proc file and RDS will come later.

  4. #4
    Newbie Kusuriya's Avatar
    Join Date
    Oct 2004
    Location
    Fort Drum, New York, USA
    Posts
    23
    yah normally i just use proc to check if its there or to pull info off with like a TAIL file.. the proc file is just a good way to check if its up or not but its sounding pretty good heh
    ---
    "Flying is easy, Just jump at the ground and miss"
    --Ford Perfect, HHGTTG

  5. #5
    FLAC TheLlama's Avatar
    Join Date
    Jul 2004
    Location
    All over the world
    Posts
    970
    Quote Originally Posted by Kusuriya
    yah normally i just use proc to check if its there or to pull info off with like a TAIL file.. the proc file is just a good way to check if its up or not but its sounding pretty good heh
    Yes, I suspect you could also use inotify to signal when the proc file changes.

    Now, I found a problem in the seeking method which could cause systems to hardlock. I was using a semaphore from an interrupt handler. I am changing the system to use tasklets for this task. Unfortunately, I am also in the middle of moving, so it may be a couple days before I get anything usable out.

    Thanks for you patience! It will be worth the wait. This radio sounds soooo good.

  6. #6
    Newbie Kusuriya's Avatar
    Join Date
    Oct 2004
    Location
    Fort Drum, New York, USA
    Posts
    23
    heh man making me want to build it before i get home XD
    ---
    "Flying is easy, Just jump at the ground and miss"
    --Ford Perfect, HHGTTG

  7. #7
    FLAC TheLlama's Avatar
    Join Date
    Jul 2004
    Location
    All over the world
    Posts
    970
    Ugh!!!! I have a version that works fine but it relies on a busy wait that runs in kernel mode, so basically the whole system is locked out for 30ms everytime you send a request to tune. I'm working with someone to resolve this issue. I don't feel comfortable releasing until this problem is solved.

  8. #8
    Newbie Kusuriya's Avatar
    Join Date
    Oct 2004
    Location
    Fort Drum, New York, USA
    Posts
    23
    that does sound a little ugly.. but man take your time lol the more your hurry it the more bugs there are gonna be expecally if its gonna have its own wait timer or polling code that runs independantly of the kernels "heart beat"
    ---
    "Flying is easy, Just jump at the ground and miss"
    --Ford Perfect, HHGTTG

  9. #9
    FLAC TheLlama's Avatar
    Join Date
    Jul 2004
    Location
    All over the world
    Posts
    970
    Quote Originally Posted by Kusuriya
    that does sound a little ugly.. but man take your time lol the more your hurry it the more bugs there are gonna be expecally if its gonna have its own wait timer or polling code that runs independantly of the kernels "heart beat"
    Good news, I just implemented a solution that does not use busy waiting. There is no polling or threads either, everything is driven from interrupts and user requests. I am driving back to my campus tommorow and will be staying there for a few days. I would probably have a version up tommorow otherwise. Fortunately, I can bring my test rig and get some work done there.

    I decided to swap the read() and ioctl(HQCTIOC_READ) functions so that read() blocks. I did this because it is ideal to use the blocking read to block until the previous instruction has finished. read() is ideal for the blocking read because you can call it with a buffer of zero length while the ioctl call will assume you have allocated a buffer for it. I suppose one could call the ioctl read with a NULL address in order to block, but a blocking read() is easy to call from bash etc... Any comments? I'm still 50-50 with this decision.

    So, with tuning out of the way, all that is left (for the first version) is making sure the common TEF set commands (Volume, Treble, Bass, etc..) can be set through ioctl and providing a method for serializing the TEF configuration back and forth.

  10. #10
    Newbie Kusuriya's Avatar
    Join Date
    Oct 2004
    Location
    Fort Drum, New York, USA
    Posts
    23
    thought read was a kernel blocked funtion by default anyway but sounds like a plan.. heh dont drive to fast tho dont want you to get in a car accident on your way to start your coding marathon. but man it sounds like you have something... have you had a chance to play "bug hunt" on it yet?
    ---
    "Flying is easy, Just jump at the ground and miss"
    --Ford Perfect, HHGTTG

Page 1 of 7 1234567 LastLast

Similar Threads

  1. Line Driver Selection? And Audio advice
    By Philly#1 Lex in forum Car Audio
    Replies: 6
    Last Post: 04-24-2006, 11:10 AM
  2. Line Driver Vs. Amp Sensitivity Adjustment
    By 3onDubs in forum Car Audio
    Replies: 5
    Last Post: 11-28-2005, 07:37 PM
  3. XM Driver Install Problem
    By MikeH in forum MacCar
    Replies: 5
    Last Post: 04-24-2005, 11:22 AM
  4. Replies: 4
    Last Post: 01-01-2005, 04:19 PM
  5. USB Sound Card with ASIO driver and volume control
    By tbdombrosky in forum General Hardware Discussion
    Replies: 0
    Last Post: 02-03-2003, 11:00 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •