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 [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
