2012/5/3 Raz <raziebe@xxxxxxxxx> > > specific driver. the CAN address space mapped is the pci hole address space. This is how this specific board is designed. > If i was in your shoes, i would have made some preliminary interrupt latency > tests . There are cases where preempt rt is not suitable due to hardware slowness. > Did you test the board with cyclictest ? Nope, I'm still in the prior step of investigating possible solutions fulfilling my requirements. So, I haven't bought any hardware yet, but I'm trying to find out which platform/set-up is suitable for my development. Do you have any suggestions for me? Marcus > > On Thu, May 3, 2012 at 9:06 AM, Marcus Liebhardt <marcus.liebhardt@xxxxxxxxxxxxxx> wrote: >> >> 2012/5/2 Raz <raziebe@xxxxxxxxx>: >> > funny.. just did CANopen driver a week ago. >> >> What do you mean exactly? Did you create a create a CANopen >> implementation on top of SocketCAN or did you write a specific driver >> for the MCP2515 or the integrated CAN controller (DCAN)? >> >> > >> > On Wed, May 2, 2012 at 5:27 AM, Marcus Liebhardt >> > <marcus.liebhardt@xxxxxxxxxxxxxx> wrote: >> >> >> >> 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? >> > >> > I did it a week a go with AMD Geode 300MHZ. >> >> >> >> 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. >> >> >> > I was required to deliver 4ms with with 200us latency on a hrtimer along >> > with CAN >> > traffic. meaning, I have 5 of high prio threads must launch each 4ms, >> > and check CAN mailbox for axis state , and obviously sending >> > CAN output if needed. >> > The CAN driver is user space. The high prio threads are use space. >> > It took about a month till it worked. they were too many CAN packet losses >> > and overruns. >> >> OK, that makes me feel more confident about a Linux + PREEMPT_RT >> solution, since you managed to get an application running with tougher >> constraints. >> >> > This is what i did: >> > >> > 1. I use preempt rt without any ftrace, or any other debug facility. >> > i also compiled the kernel for a Geode processor. >> > >> > 2. I fixed my CAN kernel driver to use ISR and not threaded interrupt. There >> > is no work in kernel other than waking the user space driver and a context >> > switch on Gedoe AMD costs over 50us . who needs it ? >> > >> > 3. Hack the hrtimer so that it will wake the user space high prio threads >> > each 4 ticks >> > and not sleep ( do not do nanosleep if you need, your thread will not be >> > awakened by the hrtimer but by ksoftirqq) >> > >> > 4. made CAN thread prio less by 1 than high prio threads. >> > >> > 5. modify can user space CAN thread to pull as many packets as possible >> > while it can. >> > >> > 6. reduce lock contention the CAN implementation. i suggest you separate the >> > tx from rx. >> > and if can , do not lock with mutexes but use gcc atomic builtins >> > operations to handle the queues. >> > >> > The code is legacy code written originally to vxWorks - i do the porting to >> > linux preempt rt >> > so i get plenty of user space. >> >> Thanks for these detailed hints. Maybe in some weeks I will actually >> be able to make use of them! ;-) >> >> Cheers, >> Marcus >> >> > >> > >> >> 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 >> > >> > >> >> -- >> 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 > > -- 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
