> > 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/
