[..] > > So what about this: > > modify your drivers sample routine that it takes a timestamp > > (time_for_next_sample) and returns a timestamp (last_sampled) > > together with your voltage value. in the sample routine take your > > spin_lock, loop until currenttime > time_for_next_sample, get your > > value, get a timestamp, spin_unlock, return values; > > now your pascal program can call the sample-routine again with > > time_for_next_sample:=first_time_stamp+(sampleIdx * deltaTime) .. > > This way, it's still the pascal program, that specifies the > > sampling rate .. > > This is a great idea! I am a little bit scared to have to > write so many lines in C. But apart from that, this is a very good > idea... > > The "time stamp" is a 64 bit uninterrruptible counter that counts the > processor clock. There is a GREAT package on lazarus called EpikTimer > by Tom Lisjak. I can use it as an example! I don't know, what you mean by "uniterruptible counter". A timestamp is just, well, similar to the "now" function in fpc.
Check the book, they provide some examples for this. See chapter 7 "Time, Delay and Deffered Work", page 190ff talks about "busy waiting". Also check page 196ff "Kernel Timers". "Kernel timer" and "Blocking I/O" (page 147ff) for the sample-routine would make a good team for this, I guess.. > > 3-- > > > That's understandable, me too. But I had to write a kernel driver > > for a self-made pci board doing 2.6mbyte DMA data input constantly > > for several hours. With the help of "Linux Device Drivers" book > > (read online: > > http://www.oreilly.com/catalog/linuxdrive3/book/index.csp) I > > managed to write that thing within less than a week, without having > > written any piece o C code before .. > > IOW, it's not that har > > Oh yes! Don't worry. I have this book even in my bed. I have been on > this project for weeks now, and can not foresee the end of it... but > I guess I am old... That's a good excuse... Do you have the 3rd Edition? This one covers Kernel up to 2.6.10. > 4-- > > > use nice to give your process the highest possible priority (-20)? > > But however, I guess kernel(drivers) still might jump in to respont > > to any IRQs (e.g. from ISDN board) ... > > I will try that too. Thanks. Even if it responds to an IRQ, if the > "scheduler" (forgot the exact name of this one, sorry) decides to > send it back to my "high priority" loop, then the delay may not be > too long. This is quite different than for example if it decides to > redraw the screen. > > 5- > What about the following (vicious and maybe stupid) idea: > > I call the driver using IOCTL, then the driver will take the spinlock > and then return! > > I do my thing in Pascal. > > Later, I call the driver again using another IOCTL call and the > driver will release the lock! > > I can not imagine that such thing would work. Would you? No, don't do that!! Read chapter 5 "Concurrency and Race Conditions", especially "Spinlock and Atomic Context" (page 118ff) Good luck! Regards Burkhard _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
