Hi all,
shame on me!!! I have found the reason why! It's a delay in the hardware of
the chip and is enabled by enabling the hardware fifos! If the threshold for
the receiver irq is not reachead (because only one char arrived and it will
be set i.e. to 8) than an timeout occures to force the receiving interrupt.
May be the delay can depends from the bit clock (baudrate and divider
register), so seen in different delay times.
Thanks all and happy programming ;-)))
Thomas
-----Ursprungliche Nachricht-----
Von: Thomas Lehwald [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 24. April 2001 17:12
An: '[EMAIL PROTECTED]'
Betreff: [rtl] rt_com and irq driven receive timing
Hi all,
I'am a newbee in RTL. I have a litte bit problems with the timing of the
receiving IRQ at the serial line.
My problem is, that i will try to read back a just sent char immediatly for
verification. The goal is to detect arbitration problems on a single wire
RS232 similar bus. The baudrate is slow (9600) so no other timing problems
my be important.
The conditions:
I have successfully installed the prepached kernel 2.2.18-rtl from the
RTLINUX ftp-server and the RTLINUX3.0-sources.
I use a standard Mandrake 7.2 system.
In addition, I use the latest release of rt_com (0.5.4pre). I can load the
rt_com module properly and it works. During the boot sequence the serial
dumb driver is loaded at a module, but before using rtl removed by hand via
rmmod command.
Everything seems to work well until I performed some timing researches.
I tied togehter Pin 2 and 3 of the RS232 port (TXD and RXD) an set up the
mode of the com-port to "No Handshake".
The code inside the body of my rt-task looks like this:
snip---------
char sbuf[] = "Hello World\n";
char rbuf[128];
int loops; // for counting
while (1) {
for (i=0; i<5; i++) {
rt_com_set_modem(com1, RT_COM_RTS, 1); // set hardware flag for oszi
rt_com_write(com1, &sbuf[i], 1); // one char only
loops = 0;
do {
// wait for receiving the char ....
if (0 > (n = rt_com_read(com1, &rbuf[0], sizeof(rbuf)))) {
// the following line was moved into the irq service function later
rt_com_set_modem(com1, RT_COM_RTS, 0); // clr hardware flag for oszi
rtl_printf(">%c\n", rbuf[0]); // echo
break;
}
} while (++loops < 10000); // timeout
if (loops >= 10000)
rtl_printf("Timeout occured....\n");
else
rtl_printf("Loops: %d\n", loops); // give an idea of the waiting time
} // for..
} // while
snip--------
The thread runs periodically i.e. with 150ms.
The hammer is: It takes from 1.5ms upto 6ms time between sending the char
and detecting it in the receive fifo!!!! The delay depends on the baudrate
(115k - 9600Baud)!!
I made some debug chages in the original rt_com driver (move the oszi flag
into the irq-services-routine) to see, how fasten is the response. The first
interrupt services starts immediatly after writing the first char, because
the "send register empty irq" occures. But the expected receive-irq after
succesfully send (shiftet out) the char is delayed!!! Shortly (some
microsecs) after the service for the received char is done, the next irq
service request comes up, because the next char was sent.
May be its a hardware or initialization problem with the 16550A chip ???
The timing behavior is reproducable and I have no idea, whats the reason
why!!
Anybody else??
Thanks
Thomas
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
