Gilles Chanteperdrix wrote:
> Karch, Joshua wrote:
>  > Gilles, (and anyone else who has had overrun errors or has experience with the Xenomai serial port driver)
>  > 
>  > It seems that even though I turned off fprintf and even though I stopped logging to disk, I still get the same number of overrun errors.  I broke the loop down to the bare basics.
>  > 
>  > my task now consists of the following
>  > 
>  > Task was launched as follows:rt_task_create(&read_task, "read_task", 0, 51, 0);
>  > 
>  > 
>  > void sensor::mainloop()
>  > {
>  > 
>  > 
>  > 	//set up serial read
>  > 	struct rtser_event rx_event;
>  > 	rtser_status_t serstatus;
>  > 	int numread,err;
>  > 
>  > 		 while(1)
>  > 		 {
>  > 			if(exitprogram)		//
>  > 				 break;
>  > 
>  > 			err = rt_dev_ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
>  > 
> 
> As I already said, using read with timeout directly without first
> calling ioctl leads to a better latency because of the fewer system
> calls.
> 
>  > 			if (err)
>  > 			{
>  > 				printf(RTASK_PREFIX
>  > 					       "error on RTSER_RTIOC_WAIT_EVENT, %s\n",
>  > 				  strerror(-err));
>  > 				err = rt_dev_ioctl(read_fd, RTSER_RTIOC_GET_STATUS, &serstatus);
>  > 				printf(RTASK_PREFIX "Error code line_status=%d modem_status=%d\n",serstatus.line_status, serstatus.modem_status);
>  > 
>  > 			}
>  > 
>  > 			else
>  > 			{
>  > 				numread = rt_dev_read(read_fd, buf, 1);
>  > 				{
>  > 					printf(RTASK_PREFIX "error on rt_dev_read, code %d %s\n",numread,
>  > 					       strerror(-numread));
>  > 					err = rt_dev_ioctl(read_fd, RTSER_RTIOC_GET_STATUS, &serstatus);
>  > 					printf(RTASK_PREFIX "Error code line_status=%d modem_status=%d\n",serstatus.line_status, serstatus.modem_status);
>  > 					continue;
>  > 				}
>  > 			else
>  > 			{
>  > 				err = rt_dev_ioctl(read_fd, RTSER_RTIOC_GET_STATUS, &serstatus);  //if data received normally, make sure 96 was received, 98 = overrun
>  > 				if(!serstatus.line_status==96)
>  > 				printf(RTASK_PREFIX "Error code line_status=%d modem_status=%d\n",serstatus.line_status, serstatus.modem_status);
>  > 			}
> 
> On compilers I know if () { } else { } else {} does not even
> compile. Are you sure you are showing us the code you are really running
> ? Have you tried T_WARNSW as I suggested in a previous mail ?
> 
> At what frequency do characters arrive on the serial line ? Did you try
> to run the latency test with the same frequency to see if Xenomai on
> your hardware is able to support this frequency ? Try latency -t 1 or -t
> 2 to see if switching to kernel-space would improve situation. Do you
> observe unexpected peaks (such as those caused by SMIs) when running
> latency ?
> 
> Is not it possible to enable hardware buffering so as to receive more
> than one character at a time when overflow occurs ?
> 
> If you need ultra-high frequencies, you should probably write some part
> of your application (at least the real-time control loop) in
> kernel-space.

The 16650A driver architecture is know to be able to handle multiple
500kBit/s serial streams on a Pentium III 700 box (granted, with 128
byte RX fifos then).

But if you are at the limits of your system can be analyzed via
/proc/xenomai/stat (see also the Wiki, IIRC). If you aren't, you should
check of you box suffers from hardware-related latency peaks. What do
standard Xenomai latency tools tell you about this (like 'latency')?

Jan