how to handle -- fast tx & recepion of data --- device driver Linux

0
votes

I am looking forward to implement a driver for CAN bus communicationin Linux.
Need some design suggestion.

Linux there are user space & kernel space. Drivers run at kernel space application at user space.

1> Now suppose if packets are received at very high speed then how drivers can manage this situation ?

2> If packets have to transmit at high rate then what to do ?

3> how data should be moved between user & kernel space. Should we use system call or some fast mechanism apart from this ?

4> Can it be done in threads at kernel level ? But if there are two threads running at kernel level to TX from CAN bus & RX from CAN bus then do we have to use mutex to save critical section (i.e our internal registers)

5> If suppose shared libraries are used to access the driver from application. Can shared libraries access driver functionality using system call ?

Totally confused what should be the right approach.

Please suggest. Any reply will be appreciable.

1
multithreadinglinux-device-driverembedded-linuxcan-bus
Which CAN controller are you using, probably it's driver will be available on Linux and you can access it directly using the device node. – manav m-n
may be i have explained bit wrong.. I have just given an example of --- Can bus -- Question is an general question which can apply to any communicating device like CAN bus, Usart , raw-ethernet. please suggest. – Katoch
The high frequency trading people have developed some interesting optimizations to network stacks/drivers you could look at in theory; however as Martin says your CAN bus isn't likely to be anywhere near as demanding. – Chris Stratton

1 Answers

0
votes

Data-rate wise CAN isn't that fast compared to most processors you'll be wanting to run Linux on. Most buses stick below 60% loading, which is only about 60kB/s! A simple packet FIFO from user space to kernel space ought to be fine.

What can be a problem is if you have a hard-real-time deadline for transmitting messages on a schedule. Or worse getting transmitting a message in response to a received message within a given time period. If you have either of those requirements, Linux probably isn't for you - you need a proper real-time operating system (RTOS).