LinkBack URL
About LinkBacks
Reply With QuoteHumm.. I need some place to dump files.
read() is by default because most of the drivers implement it that way. The OS doesn't actually do any of that work. Now, I have everything working fine but there is one place where things seem to mess up. For some reason the HQCT radio stops sending reports if it receives two reports too quickly. So, I need to rework the innards one more time... this time I need to make sure that two reports are never sent less than ~50ms apart. Even if the user places two requests within that time frame.Originally Posted by Kusuriya
thought read was a kernel blocked funtion by default anyway but sounds like a plan.. hehdont 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?
If you want to try out the current version then let me know. I just finished the user api and you can do pretty much anything (except RDS). Many more flags are configurable than with the Windows demo. Just don't try to send too many message close together or else you will have to cycle power on the radio. So, I'll post it if anyone actually wants it.
Humm.. I need some place to dump files.
E-mail me at allen@intuitionsys.com and I'll set up an FTP for you if you want...
Silverwolf 2 is dead.
Silverwolf 3...?
OK. But in the meantime you can check out this zip file. The forums wouldn't let me upload a tarball.
I worked around the problem from above by simply placing a sleep at the end of the ioctl function. This causes ioctl to always block for at least 100ms, which in turn, doesn't allow you to send messages fast enough to overload the radio. This is just a fix until I redo the mechanics again.
So, it 'works', but it causes needless waiting and some lag. For example, if you send 20 tef commands at once, then you have to wait ~2seconds for them to all be processed. This should be good enough for people to start writing software with the API.
I am going to rework the innards and it will actually end up being a simplification. The user API will not change (except maybe for some additions). I plan to keep a queue of work needed to be done and have a kthread that loops on the queue and sends out the next packet every 100ms. Changing TEF settings (volume, bass, etc..) will still block until the command has executed, but it won't be a dumb wait like it is currently. Also, if the user sends multiple TEF settings then they will be collapsed into a single packet. For instance, if you set the volume to -10,-9,-8, and -7 within 100ms, then only the -7 will be sent.
Development notes I forgot to place in README:
Do not send TEF settings while seeking and do not seek while the module is initializing. These problems are easy to fix, but I'm going to wait for the new version.
You can use hqct_get_tef() to get the current TEF string. You should do this before your program closes and store the output to a file. This way your program can read the settings from file and use it as the 2nd parameter of hqct_init().
Files contained:
hqct.c - HQCT device driver
hqct.h - HQCT device driver header
hqctapi.c - The HQCT C API, check this file for documentation
hqctapi.h - The HQCT C API header, include this file in your programs
demo.c - Demonstation including initialization, blocking seek, and a few TEF settings.
Makefile - builds the driver, api, and demo
README - Read this, it will provides installation and development tips.
I see that the driver has been downloaded several times. Has anyone tried it out? I want to know what kinds of problems people are having with it (hopefully none). I'm also looking for suggestions. I'm not going to work on the new version until I get _some_ feedback for this one. Must... spend... more time.... on MP3 Player!
Since I'm not running linux I downloaded it just to check the source.. I also realised that since I havn't focused anything on sending stuf to the HQCT, I have alot to do..
If you want the c#.Net source for my RDS decoding (still not ready on the AF parts though) just say the word...
Maybe not. I had to do alot more low-level routines than you will probably have to deal with. I would be interested in the RDS source, check your PMs.
On another note, I am stalling development on the Linux driver for several weeks. I want to get my MP3 player up and running. Apparently I am the only one using the driver at the moment. I will improve and complete the driver once I know there is more interest in it.
Your source appears to be the canonical interface definition that's been lacking for the HQCT module.
Nice work!
Thanks, I still need to add other features to it, but this is simple. I think I covered all the main functions people would be concerned about. I guess I can expand the interface for RDS at least. It would be nice if someone could implement my user api into windows by wrapping the EasyHID stuff. Standardization is good.
Don't forget - I will improve this library if people are interested. I can think of several speed-ups and missing features. Unfortunately, I am the only one using it that I know of.
I've been sort of avoiding this thread because I don't have an HQCT but once sw2 is ready for alpha I can write a high-level radio interface to your API. I'll probably need to bug you again in about a month or two...
Silverwolf 2 is dead.
Silverwolf 3...?
Posting Permissions
Bookmarks