[Rtl]Driver
Hallo, I want to use a RS422-card with RTLinux. There is no RTL-driver available for this card. Can I use the Linux driver with RTLinux ? If not, is there a document, which desribes the development of a RTLinux driver ? Thanks Andy -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! ___ Rtl mailing list [EMAIL PROTECTED] http://www2.fsmlabs.com/mailman/listinfo.cgi/rtl
Re: [rtl] Basic questions about RTL driver writing
wrt item 1. i had two different devices that i needed to make drivers and also interface to rtl. i did about a half a pass at making a driver that could be connected to rtl via compiler directives. after generating c code that was unreadable, i split the driver into two parts. one part was hardware related such as setting bits. the second part was the linux drvr interface with read, writes, ioctl's. nice for device testing and non rtl use. the hardware part interfaces to the rtl and the board settings are either hardwired into the rtl init or changes can be done via the command handler...chuck On Tue, 14 May 2002, you wrote: Greetings all, I am a recent college grad with a new job and have been assigned to write a driver for a frame grabber that must meet certain real-time constraints. Since I have only a basic understanding of how all this stuff works, I have a few questions for the experts. 1. I more or less understand how one would go about writing a device driver in normal Linux, but it seems that writing an RTLinux driver is two-fold. First you have the real time part that actually deals with the hardware and getting data from that hardware into some data structure. Second, you have the non-real time portion that uses either shared memory or FIFOs to get the data out from the real time portion. I suppose to make the driver generic and reusable you'd need to write a sort of pseudo non-real time driver that holds all the ioctl commands. Is this assumption correct, or should the app simply pull data from the FIFOs/shared memory? What I am trying to understand is whether or not I should make a generic Linux driver to go along with my RTLinux driver or if I should simply embed communication with the real time side into the custom app we're making, since once you get the data into a FIFO or shared memory it's already in user space. Unless you want to have a driver that can operate in RTLinux and also be operated in non-rt-linux there is no point in building a Linux driver interface - it is far more complex than a RTLinux driver and would not provide much. splitting the task cleanly into a RT and a non-RT job and using well isolatet comunication via schared memory or FIFOs is the easier and cleaner solution I would say. 2. Exactly how to the FIFOs work? Let's say that I want to grab frames at 30Hz and the frames are 1k in size. I want to assure that I have a 1 second buffer between the real time side and the non-real time side, so I allocate a FIFO of size 30k. So now I can store 30 1k frames in the FIFO before it gets full, right? Okay, so what happens when it gets full? Does rtf_put() overwrite part of the FIFO or does it not do anything? It will drop the data and if you read the fifo late you will get the old frams - have a hole from the droped frames and then read the new frams - but the solution is brute-force - allocate a 2M fifo if you like and just make shure that you user space app can handle it on time - if it can't with a resonably large buffer - then the hardware is simply too weak to handle the task. 3. When I'm reading or writing to a shared memory buffer or to FIFOs I shouldn't run into one thread/process reading or writing at the same time unless those threads/processes are in the same space, right? What I mean is that if I have a non-real time app accessing shared memory it should never read or write while a real time app is trying to read or write because RT apps get higher priority. If so, does this hold on SMP machines? Also, if a non-real time app was writing and a real time app needed to write to the same shared memory buffer, would it preempt the non-real time app before it got finished writing? no synchronisation provided - that is up to you - if you use shared memory it is only your code that is protecting your code from screwing up the data. 4. Are there any HOW-TO's out there with respect to RTLinux? I have read the documentation and examples that comes with RTLinux v3.1 and have gained a minimal understanding how things work, but if there are any more up-to-date resources I would very much like to read them. I am a sponge for knowledge! There are some in work - and it would be good if some contributions would come in aswell. The best place to start out for driver writing for RTLinux I would say is Rubinis Linux Device Drivers 2nd edition - even if it does not cover RTLinux it covers the essential hardware and synchronisation problems involved hofrat -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail
[rtl] Basic questions about RTL driver writing
Greetings all, I am a recent college grad with a new job and have been assigned to write a driver for a frame grabber that must meet certain real-time constraints. Since I have only a basic understanding of how all this stuff works, I have a few questions for the experts. 1. I more or less understand how one would go about writing a device driver in normal Linux, but it seems that writing an RTLinux driver is two-fold. First you have the real time part that actually deals with the hardware and getting data from that hardware into some data structure. Second, you have the non-real time portion that uses either shared memory or FIFOs to get the data out from the real time portion. I suppose to make the driver generic and reusable you'd need to write a sort of pseudo non-real time driver that holds all the ioctl commands. Is this assumption correct, or should the app simply pull data from the FIFOs/shared memory? What I am trying to understand is whether or not I should make a generic Linux driver to go along with my RTLinux driver or if I should simply embed communication with the real time side into the custom app we're making, since once you get the data into a FIFO or shared memory it's already in user space. 2. Exactly how to the FIFOs work? Let's say that I want to grab frames at 30Hz and the frames are 1k in size. I want to assure that I have a 1 second buffer between the real time side and the non-real time side, so I allocate a FIFO of size 30k. So now I can store 30 1k frames in the FIFO before it gets full, right? Okay, so what happens when it gets full? Does rtf_put() overwrite part of the FIFO or does it not do anything? 3. When I'm reading or writing to a shared memory buffer or to FIFOs I shouldn't run into one thread/process reading or writing at the same time unless those threads/processes are in the same space, right? What I mean is that if I have a non-real time app accessing shared memory it should never read or write while a real time app is trying to read or write because RT apps get higher priority. If so, does this hold on SMP machines? Also, if a non-real time app was writing and a real time app needed to write to the same shared memory buffer, would it preempt the non-real time app before it got finished writing? 4. Are there any HOW-TO's out there with respect to RTLinux? I have read the documentation and examples that comes with RTLinux v3.1 and have gained a minimal understanding how things work, but if there are any more up-to-date resources I would very much like to read them. I am a sponge for knowledge! Thanks in advance for any help!! Brian Rivers _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] Basic questions about RTL driver writing
Greetings all, I am a recent college grad with a new job and have been assigned to write a driver for a frame grabber that must meet certain real-time constraints. Since I have only a basic understanding of how all this stuff works, I have a few questions for the experts. 1. I more or less understand how one would go about writing a device driver in normal Linux, but it seems that writing an RTLinux driver is two-fold. First you have the real time part that actually deals with the hardware and getting data from that hardware into some data structure. Second, you have the non-real time portion that uses either shared memory or FIFOs to get the data out from the real time portion. I suppose to make the driver generic and reusable you'd need to write a sort of pseudo non-real time driver that holds all the ioctl commands. Is this assumption correct, or should the app simply pull data from the FIFOs/shared memory? What I am trying to understand is whether or not I should make a generic Linux driver to go along with my RTLinux driver or if I should simply embed communication with the real time side into the custom app we're making, since once you get the data into a FIFO or shared memory it's already in user space. Unless you want to have a driver that can operate in RTLinux and also be operated in non-rt-linux there is no point in building a Linux driver interface - it is far more complex than a RTLinux driver and would not provide much. splitting the task cleanly into a RT and a non-RT job and using well isolatet comunication via schared memory or FIFOs is the easier and cleaner solution I would say. 2. Exactly how to the FIFOs work? Let's say that I want to grab frames at 30Hz and the frames are 1k in size. I want to assure that I have a 1 second buffer between the real time side and the non-real time side, so I allocate a FIFO of size 30k. So now I can store 30 1k frames in the FIFO before it gets full, right? Okay, so what happens when it gets full? Does rtf_put() overwrite part of the FIFO or does it not do anything? It will drop the data and if you read the fifo late you will get the old frams - have a hole from the droped frames and then read the new frams - but the solution is brute-force - allocate a 2M fifo if you like and just make shure that you user space app can handle it on time - if it can't with a resonably large buffer - then the hardware is simply too weak to handle the task. 3. When I'm reading or writing to a shared memory buffer or to FIFOs I shouldn't run into one thread/process reading or writing at the same time unless those threads/processes are in the same space, right? What I mean is that if I have a non-real time app accessing shared memory it should never read or write while a real time app is trying to read or write because RT apps get higher priority. If so, does this hold on SMP machines? Also, if a non-real time app was writing and a real time app needed to write to the same shared memory buffer, would it preempt the non-real time app before it got finished writing? no synchronisation provided - that is up to you - if you use shared memory it is only your code that is protecting your code from screwing up the data. 4. Are there any HOW-TO's out there with respect to RTLinux? I have read the documentation and examples that comes with RTLinux v3.1 and have gained a minimal understanding how things work, but if there are any more up-to-date resources I would very much like to read them. I am a sponge for knowledge! There are some in work - and it would be good if some contributions would come in aswell. The best place to start out for driver writing for RTLinux I would say is Rubinis Linux Device Drivers 2nd edition - even if it does not cover RTLinux it covers the essential hardware and synchronisation problems involved hofrat -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] Driver for AX10450
Hi, Yes, I've written a driver for that board. It's not very generic. I'm using it to monitor various NO or NC closed switches throughout my house. Let me know what you need. Thanks Bob Warner On Sunday 14 April 2002 10:42, Marcus Tangermann wrote: Hi, does anybody know somtehing about support for the AX10450 PC/104 I/O board? I read somewhere that a driver for RTLinux exists. Best regards Marcus Tangermann -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] pbm installing rtl : driver for my agp chipset not in kernel 2.4.4
Hi, Regarding your configuration, agp AMD irongate is supported, you mast only be sure it is setted up in your kernel looking at .config file : CONFIG_AGP_AMD=y Bye Steph Sébastien Kuntz wrote: Hi! I'm trying to install RT-linux on a kernel 2.4.17 based machine. Since the patch from rtlinux-3.1 can't be applied to another kernel than 2.4.4 , I patched the 2.4.4 sources. It compiled fine, i tell lilo to use the patched kernel, but when I reboot, the kernel says that my agp chipset is not supported (it is in 2.4.17). I have a bi athlon motherboard, with AMP irongate chipset. what are my options ? i think that if i try to upgrade my kernel sources by applying patches until i have a kernel supporting my chipset might not work, would it? is there a rt-linux patch for more recent kernels? should i patch my 2.4.17 on my own? can i use the 2.4.17 agp drivers on the 2.4.4 ? (i've began this, but it's beginning to get hard ;) how are you all? =) have a nice day Sébastien ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
[rtl] driver for computerboards das1200/jr
Does anyone know of a driver for this card, or if one of the other DAS drivers can be used for it? cheers, Willem -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] driver for computerboards das1200/jr
On Thu, Mar 22, 2001 at 04:19:51PM +, Willem Atsma wrote: Does anyone know of a driver for this card, or if one of the other DAS drivers can be used for it? The cb_pcidas driver that is part of Comedi should work with it. http://stm.lbl.gov/comedi dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
RE: [rtl] driver for acquisition card
I think you will want to see Comedi at: http://stm.lbl.gov/comedi/ Rich -- From: oscar[SMTP:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 9:28 AM To: rtlinux mai list Subject: [rtl] driver for acquisition card I have no very much experience in this environments and i am working on an adquisition card (MAtrox meteor) and i want to pass the algorithms to rtlinux and try to make same parts of these in rt . I want to know what i have to do to run the driver on rtlinux. Normally on linux i have to recompile the kernel to install the driver and after install the modules. But i don't know if on rtlinux is the same and if it will works normally. Thanks. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
line noise (was: Re: [rtl] driver for sound card)
David Schleef writes: Hmmm... bad idea. Sound cards have a few properties that make them good sound cards, but bad data acquisition cards. - input is generally heavily filtered, with unknown filters, but generally cut out anything below 20 Hz, around 50 or 60 Hz (depending on your local line frequency), and above 10 kHz. The 20 Hz filter is nasty, since it makes DC measurements impossible. Reminds me. I do have a ComputerBoards PCI-DAS1602-16 board. Currently I use it as a plain single channel D/A converter :-( to generate a voltage ramp.) The voltage of this ramp (or simply a constant output) shows very prominent 50 Hz -- though not all time ! Some days it is not visible on a 1 mV scale (the lowest setting of my bread-and-butter scope) and as such is good enough (for me). Most days I do have problems with my application due to the 50 Hz though (because is is big, like 10 mV p-t-p, or such). The shape isn´t exactly sinus-like, it´s almost a (bad) rectangular wave. (... I am pretty sure this is not a software problem, sorry for the off-topic posting :-) Are others out here seeing similar problems with D/A conversion ? What are you doing to avoid/nihilitate/minimize such problems ? I assume I simply see the line-frequency somewhat modulated by the card. The converters itself are hosted in a small Faraday-box (at least I hope it is one) on the card. Still, are such noises induced by e-smog inside the PC, through the PCI bus, or both ? I appreciate any hints, Jochen -- Heinrich-Heine-Universität, Institut für Physikalische Chemie I Universitätsstr. 1, Geb. 26.43 Raum 02.29 40225 Düsseldorf, Germanyphone ++49-211-8113681 http://www.Jochen-Kuepper.de fax ++49-211-8115195 -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
[rtl] driver for sound card
Hello, does anybody know, are there any driver or applications for a standard sound card for rt-linux. I want it for data aquisition and noise analysis. Thomas -- Sent through GMX FreeMail - http://www.gmx.net -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] driver for sound card
On Thu, May 25, 2000 at 08:16:41PM +0200, Thomas Gross wrote: Hello, does anybody know, are there any driver or applications for a standard sound card for rt-linux. I want it for data aquisition and noise analysis. Thomas Hmmm... bad idea. Sound cards have a few properties that make them good sound cards, but bad data acquisition cards. - input and output signals are currents, not voltages - input is generally heavily filtered, with unknown filters, but generally cut out anything below 20 Hz, around 50 or 60 Hz (depending on your local line frequency), and above 10 kHz. The 20 Hz filter is nasty, since it makes DC measurements impossible. - unknown absolute conversion between input current and sample value - dynamic input gain control - limited range of speeds - output generally has crappy electrical properties that do not cause audible noise, such as high frequency glitches. Having said this, I'm sure there is an application where this would be acceptible for measurement. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Driver
On Wed, May 17, 2000 at 11:06:40AM -0700, Matt Cheselka wrote: Dave, maybe I'm really missing something here. I'm referring to the drivers in comedi-0.7.xx/comedi/drivers/*.c. Nothing in this source code makes any mention of RTL or RTAI. The only things that do are actually in comedi-0.7.xx/comedi/rtl.c and comedi_fops.c. The problem here is that stuff like comedi_rtl_init() -- which to me sounds like a pretty important function -- doesn't DO anything (everything is commented out)!!! Im my opinion, a good driver should simply do what it needs to do, and get out of the way of the operating system. The individual drivers are also somewhat OS independent, in that anything that is different between OSs is moved into the comedi core, and properly #ifdef'd. What you're saying (and please please please excuse my stupidity if this is wrong) is that comedi is already 'wired' to run under RTL or RTAI and nothing has to be done to a particular driver except to modify it so it becomes incorportated into comedi (attach, detach, subdevices, etc). Meaning, I don't need to put any rt_task_init(), rt_task_wait() stuff into my driver. Yes. Drivers work automatically with RTAI and RTL, provided that they don't do anything "RT-stupid", that is, call kernel functions that are not real-time compatible, register interrupt correctly, don't have any unbounded waits, etc. Hardware drivers in comedi are actually _really_ simple -- just a collection of functions that are called by the Comedi core to do specific jobs. Ask yourself why the driver is running a task. Is this really a driver, or an application/driver combination? I prefer to make drivers as simple as possible, so starting a task seems too high level. I can think of reasons why you might want a task, but not in a data acquisition driver. I guess I have some confusion about what's going on in comedi/drivers and comedi/realtime. comedi/realtime contains two "virtual drivers" that are actually applications disguised as drivers. They use real-time tasks to emulate features that exist on higher-level data acquisition boards. It's kind of cool to use them every once and a while, but if you are doing serious work that requires such features, it is better to buy a real board. However, they make nice examples if you are writing applications that use Comedi. If the above paragraph is true, can you point me to where comedi decides that a driver is to be run in RTL or otherwise? The driver is not "run in RTLinux" as you say. The application calls comedi from RTLinux. Comedi calls the hardware driver. The driver doesn't do anything RT-stupid. Thus, the driver works in real-time. (I will readily admit that comedi drivers do many things RT-stupid, but it is not generally an issue. Writing real-time drivers is a continual learning process.) dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Driver
On Wed, 17 May 2000, David Schleef wrote: Look at Comedi, (http://stm.lbl.gov/comedi), which is a collection of data acquisition drivers that work (simultaneously) with both regular Linux and RTAI (or RTLinux). The only thing that I can point to as what makes them different as real time drivers is that the Comedi-to- low-level driver interface allows/encourages drivers to be real time. (And that Comedi provides a real-time interface.) Dave, maybe I'm really missing something here. I'm referring to the drivers in comedi-0.7.xx/comedi/drivers/*.c. Nothing in this source code makes any mention of RTL or RTAI. The only things that do are actually in comedi-0.7.xx/comedi/rtl.c and comedi_fops.c. The problem here is that stuff like comedi_rtl_init() -- which to me sounds like a pretty important function -- doesn't DO anything (everything is commented out)!!! What you're saying (and please please please excuse my stupidity if this is wrong) is that comedi is already 'wired' to run under RTL or RTAI and nothing has to be done to a particular driver except to modify it so it becomes incorportated into comedi (attach, detach, subdevices, etc). Meaning, I don't need to put any rt_task_init(), rt_task_wait() stuff into my driver. I guess I have some confusion about what's going on in comedi/drivers and comedi/realtime. If the above paragraph is true, can you point me to where comedi decides that a driver is to be run in RTL or otherwise? Cheers, Matt Cheselka -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
