When using qtalk is see 1b 5b 3f 36 63 (hex) sequences when I slay and
restart a new serial driver I am working on. It happens when data is being
received while I restart the driver after slaying it.
This does not happen all the time and I cannot seem to recreate it with the
devc-ser8250 driver.
Does anyone know why qtalk would send this odd sequence?
Thanks
Allan Smith wrote:
When using qtalk is see 1b 5b 3f 36 63 (hex) sequences when I slay and
restart a new serial driver I am working on. It happens when data is being
received while I restart the driver after slaying it.
It looks like the response that the QNX console (or a pterm) sends back
when it receives the sequence ESC Z. Is there a chance that when your
driver is starting up, it tickles the UART in a way that could cause it
to send something that looks like ESC Z when received at the other end
of the wire?
Thanks for the tip. I traced it down to a response to the hex char 9a being
received causing this ESC sequence to be sent back out.
“Wojtek Lerch” <Wojtek_L@yahoo.ca> wrote in message
news:d6gceb$78n$1@inn.qnx.com…
Allan Smith wrote:
When using qtalk is see 1b 5b 3f 36 63 (hex) sequences when I slay and
restart a new serial driver I am working on. It happens when data is
being received while I restart the driver after slaying it.It looks like the response that the QNX console (or a pterm) sends back
when it receives the sequence ESC Z. Is there a chance that when your
driver is starting up, it tickles the UART in a way that could cause it to
send something that looks like ESC Z when received at the other end of the
wire?
Allan Smith wrote:
Thanks for the tip. I traced it down to a response to the hex char 9a being
received causing this ESC sequence to be sent back out.
Ah yes, a 0x9A would do it, too.
That’s because 0x9A == ‘Z’+0x40. In the ANSI protocol, each control
code from the range 0x80 to 0x9F is equivalent to an ESC followed by the
original code minus 0x40.