0

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.

sawdust
  • 16,103
  • 3
  • 40
  • 50
Katoch
  • 2,709
  • 9
  • 51
  • 84
  • 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 Dec 04 '12 at 09:18
  • 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 Dec 04 '12 at 09:57
  • 1
    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 Dec 05 '12 at 21:16

1 Answers1

0

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).

Martin Thompson
  • 16,395
  • 1
  • 38
  • 56
  • 1
    And there are real-time schedulers which collaborate with linux to handle the less demanding (but more complicated) tasks. – Chris Stratton Dec 05 '12 at 21:17