Roland Tollenaar wrote: > Hi , > > thanks for this. Is it correct that the errors come in on the > messagebuffer where normal can frames also get read from?
Yes, this is the internal socket ring buffer. But the error messages are generated inside the driver on-the-fly when errors are signaled by the CAN controller. They are pseudo-messages not really coming in from the bus. > If so I > presume this is normal CAN behavior The delivery of the error messages is a behaviour of the RT-Socket-CAN stack. > but it does cause the message-buffer > to overflow which in turn causes system messages to be generated which > in turn messes up the RT behaviour of the entire application. If I have > problems on the CAN bus I do not want the RT behavior of other parts of > the application to be affected. So how can i prevent the error messages > causing the message-buffer to overflow? If you can do without the reception of error messages simply use an empty error mask. No error message will then appear in the socket buffer. > > P.S. this question is related to another thread where the current > standing is that I would have to switch off whatever is writing the > system messages, i.e. syslogd? The system messages you refer to are generated by the CAN stack. They will be generated also without syslogd because they use rtdm_printk() in kernel space. > > If I can prevent the CAN errors coming in on the message buffer or > rather maybe reduce their intensity (once is really enough I don;t need > to be notified 100 billion times) that would be an elegant manner too. The behaviour of RT-Socket-CAN is: generate one error frame for errors that appear simultaneously. Consecutive errors therefore lead to the generation of several error frames. In your case the transmission to a disconnected bus leads to errors as long as you don't connect it. That's it. The hardware is busy with trying to send the message *you* want it to send. So it does and so it reports an error on every attempt to a disconnected bus. -- Sebastian _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
