Hi, > This principle of using was first time shown to me via eGalax serial touch > screen, but there is user space daemon with interface in /dev - I can not > imagine how it is done, but it works. Daemon is not acceptble to my > application, because of latency in need it in less tahn 30 microseconds > range (RTIA user space realtime does not math this) > even though you are concerned with timeconstraints, I'd like to comment on the fact that you _must_ open this in kernelmode due to the timedelay. The point of _not_ doing this in the kernel, is simply because things can take an awful lot of time and the overall performance of the system degrades. This is generally not your main concern when working with RT-systems, however - are you sure you are facing this the right way? Even though you might meet the timeconstraints in this case, by doing the way you describe - what about the other tasks? My point being: you should not tune your system to work by elevating the priority (because this is what you are doing here) of the process blindly. As suggested earlier, creating a usermode process to fetch the data for you might be the best solution. Give it high priority since it's time-critical, but don't put it in the kernel - you'll end up with a system that is timewise unpredictable, and that's the last thing you want in a RTOS. If you have less than 30 microseconds - maybe accessing a file is the wrong way of doing this? Why do you have such a short timeframe? -- Vennlig hilsen - Yours Sincerely Henrik Austad
Attachment:
pgpqjyUHr30We.pgp
Description: PGP signature
