On Tue, 2002-09-10 at 11:53, John Carmack wrote: > I know we went over this once before, but I'll say it again -- I really > think writing kernel drivers is the wrong approach. All my code just runs > as root and uses iopl() to allow access to the io ports for polled A/D and > the parallel port for actuators. >
The current design is two processes - a RTLinux thread and a regular linux process. The RT thread does a fairly simple control loop, should be well under 100 lines of A/D read and integer math. My research on control theory indicates that the closer to true real-time you can get the easier and better the control. The only thing "driver" about the code is a direct access of the A/D board. I left some of the driver code in CVS as reference for anyone wanting to write the A/D init and read functions. > Minimizing build and install complexity is a Good Thing. I don't advocate > breaking code up into libraries for this project, either. My flight > control software has a very simple layout, and a five line makefile: Yes build and install complexity should be kept minimal. When I say "library" I am referring to logicaly seperated code that could be built as a dynamic library, but will be compiled and linked all together. Looking at your list of files, I don't think we are doing anything more complicated - I just compartmentalize more to keep my confusion level down to a manageable level. As an example, the directory RTControl currently contains one file, rtpid.c, and should never contain more than 3 files - rtpid.c, rtpid.h, and a file with developer notes. BTW - the FCTP directory still needs to be cleaned up. Dave _______________________________________________ ERPS-list mailing list [EMAIL PROTECTED] http://lists.erps.org/mailman/listinfo/erps-list
