I am trying to run a python app which controls sevomotors. There is no handshaking, just a bit bang from pin 3 of the DB9 straight into a PIC.

There is nothing showing on the oscilloscope: it's just flatlining.
I do a dmesg grep | tty and get nothing at all showing.

I've done:
sudo setserial ttyS0 autoconfig
mknod -m 660 /dev/ttyS0 c 4 64 # base address 0x03f8
/sbin/MAKEDEV -v ttyS0
Still nothing shows up on a dmesg

Until I run gtkterm. At which point I can press keys to my hearts content and the scope shows me pretty square waves.
But as soon as I close gtkterm, I've lost ttyS0.

This app apparently works for other people, but that doesn't help me a lot.

I'm running Mint Katya 2.6.38-13 on a Dell Latitude D430, connected to a docking station with a COM1 serial DB9 connector attached, and the BIOS is happy with COM1 active (as proved by gtkterm)

The app is attached as a text file.

So how do I get the computer to permanently see ttyS0, or what would I change in the app so that it will work?
I have python-serial installed, just don't really know what else do.


Anyone got any ideas?

Thank you in anticipation..

Fitch.

Dani AI

Generated

As discovered, the serial device is present and the line behaves while gtkterm holds it open, and is correct that the device node and BIOS look normal. That pattern usually means the kernel/driver is fine but something in userspace or line-control state is different when the terminal is opened versus when the Python app runs, or there is a hardware-level mismatch.

Recommended checks and quick tests (watch the scope while doing these):

  • Check device ownership/group and any stale lockfiles under /var/lock.
  • See which process holds the port with lsof or fuser and compare while gtkterm is open and closed.
  • Compare the serial line settings with stty when gtkterm is open vs closed.
  • Temporarily stop serial-probing daemons (ModemManager, brltty, etc.) while testing.
  • Run a minimal pySerial test that explicitly sets baud and toggles DTR/RTS to see whether that reproduces the gtkterm behavior:
import serial
s = serial.Serial('/dev/ttyS0', 9600, timeout=1)
s.setDTR(True)
s.setRTS(True)
s.write(b'hello')
s.flush()
s.close()

Hardware caution: DB9 pin 3 is an RS-232 TX line with negative/positive voltage swings, not a 0–5V TTL output. Driving a PIC directly from the DB9 can damage the MCU. Use a proper RS-232-to-TTL level shifter (MAX232 or a USB-TTL adapter) or isolation before connecting to a PIC.

Suggested troubleshooting order: stop probe daemons, clear stale locks and confirm permissions, compare stty settings with and without gtkterm, run the minimal pySerial test while observing the scope, and verify proper voltage-level conversion is present. Those steps will separate a userspace/line-control issue from a hardware-voltage problem.

Recommended Answers

All 2 Replies

Well, at least you know that the port does work. Sorry but I'm not a Python programmer, so I can't tell you if there is a problem with the code. In any case, you should NOT have needed to create the device node for /dev/ttyS0 - that should by default be auto-configured by the OS for the COM1 port on your system. Do make sure (again) that the COM ports are enabled in the BIOS.

FWIW, I've used a lot of serial ports with a lot of Linux systems, and never saw this sort of problem. :-(

Do make sure (again) that the COM ports are enabled in the BIOS.

No problem.
I can echo directly to the chip just by "echo blah blah > ttyS0", which means ttyS0 is now permanently seen, so the port works fine, just something amiss between Mint and Python.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.