Hi everybody! Due to bandwidth and latency problems, I am currently investigating a set-up involving CAN bus, an ARM board and a Linux RTOS to improve our motion control framework. For development and testing purpose, I have the following set-up in mind: A master node consisting of the Beaglebone [1] (similar to the Beagleboard, powered by an ARM Cortex A8) in combination with a CAN Cape [2] (includes two MCP2515 CAN controllers and additionally allows the use of the integrated CAN controller of the ARM microprocessor). The other nodes in the CAN network are custom boards. Before going into details about performance and configuration, I like to ask, if there is anybody out there who successfully applied the RT-patch to a kernel working on the Beagleboard? There have been discussions on this list and elsewhere about this topic, but I couldn't find out, if someone finally succeeded in this. However, this paper [3] made me believe it is possible. Since I am no expert in ARM software development, Linux, CAN nor real-time systems, I'm looking for a working solution with a (as) simple (as possible) configuration. In my investigation I took a look at Xenomai (see [4] for example set-up), but discarded it, because I couldn't find real-time safe drivers for the mentioned CAN devices. Using the Linux RT-patch seems to be less work than setting up Xenomai and writing specific modules for it. Also, telling from what I read in this interesting discussion [5] it should be well-suited for our requirements - we need 10 ms cycles and latencies below 1 ms should be enough, since that is already much better than what we have now. However, the CAN support still gives me an headache. The CAN cape manufacturer claims a SocketCAN support. However, I'm not sure, if the SocketCAN driver is suitable for RT applications. As far as I understood, the RT patch will not change or affect the SocketCAN driver, meaning that it will not make this driver real-time safe. So, I am wondering if a SocketCAN device will actually support the cycle time and latency we need. I read, that one can tune the RT system by configuring it according to one's needs. For example, I could adapt the priorities of the IRQs connected to the CAN device. Assuming what I wrote so far is correct - please correct my if otherwise - my question is: Do you think the described set-up is feasible and will support our requirements? Thanks a lot for your feedback! Best regards, Marcus Liebhardt [1] http://beagleboard.org/bone [2] http://www.towertech.it/en/products/hardware/tt3201-can-cape/ [3] https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf [4] http://veter-project.blogspot.com/2011/09/real-time-enough-about-pwms-and-shaky.html [5] http://www.spinics.net/lists/linux-rt-users/msg05648.html -- Dipl.-Ing. (M.Sc.) Marcus Liebhardt Control Engineer Yujin Robot 주소: 대한민국 서울시 금천구 가산동 345-30 남성프라자 #601, 153-023. Address: Door #601, Namsung-Plaza, 345-30 Gasan-dong, Guemcheon-gu, Seoul, 153-023, Republic of Korea Website: http://www.yujinrobot.com Email: marcus.liebhardt@xxxxxxxxxxxxxx Phone: +82-2-2104-0435 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
