0

Coding a app using serial port, when debugging, I have been compelled to work with low level (link control) protocol. And here my problems begun. Sniffer gives me values: IOCTL_SERIAL_SET_BAUD_RATE 80 25 00 00 means baud rate 9600. Well, 00 c2 01 00 means 115200. How is it possible to guess it? IOCTL_SERIAL_SET_TIMEOUTS 32 00 00 00 05 00 00 00 00 00 00 00 60 09 00 00 00 00 00 00 - what does this mean? What is the value? What is the range of admissible values? I had read MSDN - "Setting Read and Write Timeouts for a Serial Device", for example. Blah-blah-blah, but no any value. What to read? How to understand sniffer data? And how to control it?

Олег Сидоров
  • 641
  • 2
  • 8
  • 20
  • 1
    These driver IO control codes are well documented. It just shows a raw dump of the buffer passed to DeviceIoControl(). For IOCTL_SERIAL_SET_TIMEOUTS you can tell from the MSDN article that it needs a SERIAL_TIMEOUTS structure. Click through and you see it has 5 fields, each 4 bytes long. So 20 bytes total. The machine is little endian so the first field takes the 32 00 00 00 bytes or 0x00000032. So you know that ReadIntervalTimeout is 50. There are friendlier sniffers around, you get what you pay for. – Hans Passant Sep 27 '17 at 12:02
  • Thanks a lot! the answer is helpfull indeed! – Олег Сидоров Sep 27 '17 at 13:07
  • And one more thing.. I am trying to develop my app using Google GO language. I use https://github.com/jacobsa/go-serial library to work with serial port. This library has only simple settings - bits, parity, InterCharacterTimeout and MinimumReadSize. With some devices it works well. But with other ones I have troubles at link control layer - datagram fragmentation and so on. Can anybody advice me a good GO library, which is able to control low level layer? It would be good to control if the buffer full or empty, to control fragmentation etc. – Олег Сидоров Sep 27 '17 at 13:28
  • It is entirely normal, serial port are byte-oriented devices and don't know beans about "datagrams". Not unlike TCP. Figuring out when you have received the full response is up to you and a library never helps, devices invariably provide a way to detect it. A very simple and common one is a unique byte that indicates the end of the response, like '\n'. There are others. – Hans Passant Sep 27 '17 at 13:43

0 Answers0