Hi,
On Tue, Apr 20 at 05:48, Terry Coles wrote:
> Can anyone answer a few queries about coding for a real-time Linux kernel?
Perhaps you should define "real-time" for a start. Are you looking to
achieve timing constraints in the tens of millisecond range, microseconds
or nanoseconds ?
Are you looking at a genuine real-time linux kernel (which are real hairy
beasts) or a recent 2.6.x system with the "real-time" scheduler capability.
I've seen people talk about real-time before, and then on analysis the real
requirements have had demands in the 10s or even 100s of milliseconds that
could be handled by a conventional system.
> 1. I'm assuming that any drivers for the test resources would have to run in
> kernel space rather than user space. Is that true?
You can write user space drivers in linux (many X-windows graphics drivers
could be considered user space drivers) but it's not the norm, and several
barriers have to be overcome. One of the primary questions whould be what's
the timing requirements ?
> 2. How hard would it be for a Windows developer with C and C++ experience to
> gain enough knowledge to integrate a driver into a real-time system?
Well I've never written a Windows program, and would consider it a pretty
daunting task. I couldn't even find the C compiler the one time I looked.
The toolset and mindsets are different.
Can they write real C in a text file, or are they GUI box joiners ?
My first genuine device driver probably took me about 2 weeks from scratch
with only the most basic of guides. I was a reasonably competent Unix
applications programmer at the time so already knew the basic tools. That was
nearly 30 years ago. These days the documentation and guides are a lot better
but the whole kernel tends to be more complex.
Are you looking to bitbash a few bits in an I/O port or launch a scatter/
gather multi-channel DMA engine ?
> 3. Is there anything that we should be aware of, other than the things I've
> mentioned above?
Depending on how you intergrate your drivers with the kernel you might want to
consider liciencing issues. Do you want to release the drivers under GPL ?
> 4. Is there a better way? We don't exclude contractors, but the amount of
I shan't give you my thoughts about contractors.
Don't dispair. We handle lots of near real-time (10-50ms) data on an ARM
processor (so not a GHz PC) on a conventional kernel without problem. The
same system has one real time critical application that uses the kernel
"real-time" schedular capability, we expect that user space app to achieve
sub microsecond timing and it does.
Can you give us any info on the devices you are trying to control ?
--
Bob Dunlop
--
Next meeting: Unknown
http://dorset.lug.org.uk/ http://www.linkedin.com/groups?gid=2645413
Chat: http://www.mibbit.com/?server=irc.blitzed.org&channel=%23dorset
List info: https://mailman.lug.org.uk/mailman/listinfo/dorset
