Acceleport adapters lose input bytes, specifically byte 0xff and any following it. This happens at :
- Fedora release 13 (Goddard) kernel 2.6.33.3-85 - with AccelePort 16em
- and also at ASP Linux 12 kernel 2.6.22.9-91 - with Acceleport 8r 920.
Every time when byte 0xff arises in input stream, it is dropped by the driver together with the byte which follows this, so I don’t see these two bytes in received data.
There were slight differences, so I made all settings (which I can) of Digi port like ttyS0. Result is the same - byte 0xff and the following are lost.
> What driver version are you using?
dgap-1.3-19.src.rpm. I also tried releases 16 trough 18.
> Do the characters display within dpa.dgap when monitoring the serial data?
Sorry, there is no program dpa.dgap, and no notion in docs, and I don't understand what monitoring do You mean.
I You are in doubt about my program: I have simply cross-connected Rx and Tx on two ports (5 and 7, to be exact), and then made:
cat file2 &
cat test test >/dev/ttya05
Binary file “test” contains all byte codes from 00 to ff. And output file “file2” lacks bytes ‘ff’ with one byte following these.
An actual 0xff in the data is reported as 0xff 0xff, so an 0xff
followed by an 0xff is in fact an 0xff of data.
If IGNBRK is set, a break condition detected on input is ignored that is, not put on the input queue and therefore not read by any process.
If IGNBRK is not set and BRKINT is set, the break condition will flush the input and output queues, and if the terminal is the controlling terminal of a foreground process group, the break condition will generate a single SIGINT signal to that foreground process group. If neither IGNBRK nor BRKINT is set, a break condition is read as a single 0x00, or if PARMRK is set, as 0xff 0x00 0x00.
If IGNPAR is set, a byte with a framing or parity error (other than
break) is ignored.
If PARMRK is set, and IGNPAR is not set, a byte with a framing or parity error (other than break) is given to the application as the three-byte sequence 0xff 0x00 X, where 0xff 0x00 is a two-byte flag preceding each sequence and X is the data of the byte received in error. To avoid ambiguity in this case, if ISTRIP is not set, a valid byte of 0xff is given to the application as 0xff 0xff. If neither PARMRK nor IGNPAR is set, a framing or parity error (other than break) is given to the application as a single byte 0x00."
If you continue to experience problems with this, I recommend obtaing an strace and contacting Digi Tech. Support.