I'm glad to hear that someone else did the same thing I did. I have an FPGA and just wrote directly to it in user space like you did. I also contemplated a nice driver and then decided I didn't have much time to get this working and just gave in. It works great and took very little time. Obviously if I later want to port this to an MMU based system I guess I will be writing a driver then.
Regards, Gary -----Original Message----- From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Philip Nye Sent: Wednesday, December 23, 2009 9:00 AM To: uClinux development list Subject: Re: [uClinux-dev] Device driver types David Wooff wrote: >> Try the char driver, it is simplest of three. > Sounds like a good plan. Thanks for your advice. I'm currently > following the ioctl route. > It's slightly complicated because my FPGA is effectively a bridge to a > number of hot-pluggable > backplane I/O cards. It seems to me that I should probably attempt to > structure it (the FPGA and backplane) > as a bus with I/O card devices hanging off it. The FPGA also performs > other functions. > So, although I could talk to my FPGA via ioctl commands, how should I > talk to the I/O cards > when they are plugged in? Should each of these be recognised as a > single char device? > My other option is to keep it simple and use the driver just to talk to > the FPGA and > let the application code make sense of the remote I/O cards, for now at > least. I have done the same sort of thing with an FPGA. I had several character devices, one for each of the various functions defined in the FPGA. In fact I simply addressed the hardware directly from userspace (possible since I was using NOMMU) to write the configuration into the FPGA in the first place. Your choice depends on how much it is worth investing in time and effort up front to "do the right thing" in the device drivers. At one extreme, you can have a very simple driver which you "spoon feed" with highly specific code and custom ioctls - this makes your application(s) very device dependent and opaque. At the other end of the scale, you try and define elegant generic devices for each function and for your I/O cards, and use the hotplug infrastructure and dynamic device creation to make them come and go. The first extreme is likely to be quicker if you have just one or two dedicated applications which you will co-develop with the device driver and do not expect to change much over time. The second extreme will be more appealing if you intend to make the hardware accessible to programmers outside your own remit or you have multiple programmers developing applications. It will also pay off if you expect to develop multiple applications to use this hardware over a long time and you can get the basic device driver structure right at the outset. Philip _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
