I need to send data to a hardware device over serial port. I'm using a program called serial port tool for os x.
After I connect to the device there is a form box where I can type data to send. I have no idea how to format the data.
Here is an excerpt from the manual for the device.
"The Net Manager Command structure consists of one start byte, one command byte, five bytes of data, and a one byte checksum. Each message packet is formatted as follows:"
an example command is:
Byte0=30 Byte1=7 Byte2=5 Byte3=1 Byte4=2 Byte5=0 Byte6=245
How do I type that into the form box in serial port tool?
Thanks,
Seth
Does the "serial port tool" you're using come with any documentation?
Assuming the "form box" is expecting printable characters, what you're looking for is a way to input an arbitrary byte value. For example, there might be a mechanism that lets you use an octal or hexadecimal escape sequence (such as \036 or \24).
Related
I have a piece of software running on concurrent DOS 3.1, which I emulate with QEMU 5.1.
In this program, there are several options to print data. The problem is that the data arriving to my host does not correspond to the data sent.
the command to start qemu:
qemu-system-i386 -chardev file,id=imp0,path=/path/to/file -parallel chardev:imp0 -hda DISK.Raw
So the output sent on parallel port of my guest is redirected to /path/to/file.
When I send the charactère 'é' from CDOS:
echo é>>PRN
The code page used on CDOS is Code Page 437, and in this charactere set, the charactère é is represented by 0x82, but on my host, instead, I receive the following:
cp437 é -> 0x82 ---------> host -> x1b52 x017b x1b52 x00
So I tried something else. I wrote the charactère 'é' in a file, and sent the file with nc.exe (from brutman and libmtcp), and with nc, the value stays 0x82.
So my question, what happen when I send my data to virtual parallel port? When does my data get transformed? Is it the parallel port on Concurrent DOS? Is it the QEMU? I can't figure out how to send my data through LPT1 properly.
I also tried this:
qemu-system-i386 -chardev socket,id=imp0,host=127.0.0.1,port=2222,server,nowait -parallel chardev:imp0 -hda DISK.Raw
I can read the socket fine, but same output as when I write in a file, the é get transformed to x1b52 x017b x1b52 x00.
The byte sequence "1B 52 01 7B 1B 52 00" is using Epson FX-style printer escape sequences (there's a reference here). Specifically, "1B 52 nn" is ESC R n which selects the international character set, where character set 0 is USA and 1 is France. So the sequence as a whole is "Select French character set; print byte 0x7b; select US character set". In the French character set for this printer standard, 0x7B is the e-acute é.
This is almost certainly the CDOS printer driver assuming that the thing on the end of PRN: is an Epson printer and emitting the appropriate escape sequences to output your text on that kind of printer.
OK, so i finally figured it out... After hours of searching where this printer.sys driver could be, or how to remove it, no Concurrent DOS, the setup command is "n". And of course, it is not listed in the "help" command...
Anyway, in there you can setup your printer, and select "no conversion" for the port you want. And it was actually on Epson MX-80/MX-100.
So thanks to Peter's answer, you led me to the right path !
I'm using STM32 discovery board to communicate to a device that takes ASCII commands.
I use HAL_UART_TRANSMIT_IT to send data, that works fine.
I want to send ASCII command XM3 to the device. When I use virtual port programs as realterm, I just click on ascii and put the baudrate, databitc etc etc and when I type in XM3 and click on +CR it send the command and it works fine, if CR is not included it doesent work.
When I try to do that from my MCU I use this code and it does not work, any ideas how to send ASCII commands in C via serial port?
char txD[3]="XM3";
__HAL_UART_ENABLE_IT(&huart1, UART_IT_TC);
HAL_UART_Transmit_IT(&huart1, (uint8_t *)txD ,3);
When I send this to realterm it shows XM3 but when I send this to the device nothing happens.
I need to know how I send XM3 and a CR to the device.
If you send the command via Realterm and check the +CR option, Realterm does append a Carriage Return, i.e. ASCII Code 13.
In order to reproduce this behavior in your code, you should define the command as follows:
char txD[4]="XM3\r";
Respectively, if the receiver also expects to receive a Newline, i.e. ASCII Code 10, you should define it as follows:
char txD[5]="XM3\r\n";
I am using Go for a project and am transmitting data to an embedded device via the serial port (ttyusb). During fast and "large" transfers I've noticed that the transmitted data did not match the values I'd wanted to send.
I've tried various available libraries, in the end they all read and write using syscalls. So I've attached a Logic Analyzer to see what's going on.
Then I noticed that the data mismatch in the output had a clear pattern: Instead of sending my data the serial port would interleave my data with the following values:
0x55, 0x53, 0x42, 0x53, 0x70, 0x02
Followed by zeros (0x00). In total 22 Bytes. The total number of bytes transmitted via the serial line did match the number of bytes I wanted to write > so essentially my data was masked with these 22 Byte-Blocks. The weird thing is that I can translate those bytes to ASCII
0x55, 0x53, 0x42, 0x53, 0x70 = "USBSp"
Now my Question is: Can't I send arbitrary data (HEX values) over the serial port or are there some control characters that I should be aware of that would make the serial port send out Identity information or the like?
[EDIT]: Additional Information:
Host is MacOS running Go v1.10; tried with go.bug.st/serial.v1 and github.com/tarm/serial, various communication settings (bitrate etc.)
Target is nRF52840 preview development kit, using Nordic nRF5 SDK v12.3.0_d7731ad (not the newest, I know, but the only one supporting other boards too). Using app_uart_x API
you have to configure the serial port. the settings for both devices for baud rate, start/stop bits, ... have to match. then there are libraries in go like https://github.com/jacobsa/go-serial that enable standard serial port communication with that you can also use any hex values.
i can not say why the USBSp is sent because you did not post any code and gave no information what libraries you use. very likely this is not generated by the kernel module and instead by higher layer software because the kernel module used is usb-serial and USBSp does not appear in the source code :
https://elixir.bootlin.com/linux/v4.0/source/drivers/usb/serial/usb-serial.c
also not in kernel module ftdi-sio ( if you use ftdi chip )
https://elixir.bootlin.com/linux/v4.0/source/drivers/usb/serial/ftdi_sio.c
and also not in https://elixir.bootlin.com/linux/v3.3/source/drivers/usb/core/urb.c
Recently I have been trying to save list of hostnames from captured DHCP packets. I have found out, every DHCP hostname (option 12) should have form defined in RFC 1035. So if I understand it correctly, hostname should be encoded in 7-bit ASCII and have other restrictions like:
- name should not start with digit and should omit some forbidden characters.
Almost every device I have encountered in packets fulfill this constraint, but not Windows devices (Vendor ID MSFT 5.0). IMHO Windows DHCP client takes computer (mobile) name and fill it in hostname option.
Problem occurs, when computer name is set for example to "Lukáš-PC". Wireshark display this hostname as Luk\240\347-PC. (240 and 347 are numbers in octal). To see for myself I have printed values in packets with printf("%hhu", c) (C language).
á = 160
š = 231
IMHO I think this is simple char variable overflow. I tried deduce original value from overflow value, but I haven't found any relation between character and known encodings. So my questions are:
Is there any way to convert these values back to original?
If yes, what was original character encoding, when overflow happened?
Thanks.
Default char is usually signed, and extends to int when passed to a variadic function. To ensure that it is printed unsigned, use printf("%hhu", c) or printf("%d", (unsigned char)c);.
The correct encoding is impossible to know because it depends on each system's settings.
Note that any compliant systems MUST encode names according to RFC 3490, but Windows seems to enjoy violating standards.
The characters á and š that you are seing are encoded using code page 852 (Latin-2 - Central European languages).
Unfortunately there is no simple way how you can figure out the encoding used only by looking at DHCP requests. In principle the DHCP client can use any code page it wants. If you are working in a private/controlled network, then it is probably safe to assume the all clients are using the same code page and explicitly encode the strings using that particular code page.
I have a modbus device I am trying to communicate with using an ethernet to RS485 device. I'm not sure whether the device uses modbus ASCII or RTU.
I am trying to format a request to a device with address 1. The command code is 11h. I'm not sure I'm formatting the request properly
Here is the string I am using for ASCII - ":010B000000000C\x0D\x0A"
Here is the hex I'm using for RTU: "\x01\x0B\x00\x00\x00\x00\x0B\xA4"
When I send this command it is echoed back but I'm not getting responses. I've been through the modbus documentation and I think I have the correct byte structure. I'm wondering if I'm encoding it right for ruby?
It turned out my ethernet to RS485 device wasn't capable of the correct timing for modbus. Once I purchased a new unit the ascii strings worked.
Are you sure the checksum should be written in pure bytes, not in ASCII? I mean, try to send :010B000000000C0D0A instead of :010B000000000C\x0D\x0A.
Also, you wrote that the command is 11h - for my understanding it is 0x11 (hex), and you are sending 0x0B. Or the command is 11 (dec)?