RS232: Difference between revisions
Jump to navigation
Jump to search
m (→windows) |
|||
Line 8: | Line 8: | ||
/dev/ttyUSB0 | /dev/ttyUSB0 | ||
'''status''': '''working''' out of the box | |||
=== windows === | === windows === | ||
Line 17: | Line 17: | ||
* finding out what COM port the usb adapter ended up might be tricky, you can use a tool like "Keyspan Serial Assistant" | * finding out what COM port the usb adapter ended up might be tricky, you can use a tool like "Keyspan Serial Assistant" | ||
'''status''': '''working''' after some massaging of the code | |||
== rs232 over ip == | == rs232 over ip == |
Revision as of 19:22, 25 July 2019
here i will track some things regarding rs232 emulation, and perhaps fix things while at it Gpz (talk) 19:29, 25 July 2019 (CEST)
using a real RS232 port
linux
/dev/ttyUSB0
status: working out of the box
windows
- the windows driver understands various options passed in the so called "mode string" after a colon after the ports name
COMx[:][baud=b][parity=p][data=d][stop=s][to={on|off}][xon={on|off}][odsr={on|off}][octs={on|off}][dtr={on|off|hs}][rts={on|off|hs|tg}][idsr={on|off}]
- finding out what COM port the usb adapter ended up might be tricky, you can use a tool like "Keyspan Serial Assistant"
status: working after some massaging of the code
rs232 over ip
linux
windows
piping to an external program
linux
windows
TODO
- whether the "UP9600" (daniel dallmann) hack is being used seems to depend on the baudrate(?). this should be a seperate option
driver issues
handling of DTR and RTS seems to be completely missing. rs232dev_set_status, rs232dev_get_status, rs232dev_set_bps apparently are not called by the layer above