Hi. I have been working on writing a small rs232 driver like minicom for months. I am almost there, I have the interrupt service routine running, I can read() ok. However when I write(), it returns the number of characters written, 1, but nothing is actually written out the port.

I researched termios, and they say that serial port programming is really messy in linux/unix.

I am probably not setting up the port parameters correctly, or my write() function is not doing what it is supposed to. As I said, write() is returning successful.

Other comm programs run ok (picocom & gtkterm) on my hardware. I am running knoppix/debian on an ancient computer. I saw other guys using slackware.

any suggestions?

thanks...........don

Nobody ought to program serial ports anymore, imho. Most boxes only have one, there's only 115k baud on offer, and they are the easiest thing to blow. Laptops don't have earth, they have 0V, and someone brings one along and plugs it in sooner or later. 0V is brought to earth by your serial port circuitry and things are never the same after that :-(.

Check that that hasn't happened to you already - make sure other programs can write to your serial port. Are you writing under GPL? There's plenty out there already - copy it or call the appropriate library

Not sure what you mean by "Nobody ought to program serial ports anymore", There are still plenty of specialized devices plus most embedded single board computers use RS-232 for their console.

By read ok do you mean you can receive characters from another device? Without seeing your code it is difficult to suggest anything.

I am going to suggest this thread be moved to programming.

Edit:
Actually, I assume this thread is related to your chess board thread and consider it a duplicate post.

Moved: This thread is more suitable in Programming and has been moved accordingly to help your thread/question get the exposure it deserves.

I would imagine that the write() is putting the character in the send buffer, but depending on how the UART is set up, it may not actually send the character until you tell it to. I'd be looking into that possibility if I were you.

Look at the fildes and the line control functions.

I have not implemented serial port IO on Linux, but I have worked with serial ports on other systems. Anyone who uses the phrase "simple serial port interface" has not actually tried it.

I am writing this from memory. You should look at the standard to be sure which signals are inputs and which ones are outputs.

I assume your serial port is configured as DTE. Most computer serial ports are configured that way.

The DTE may require DSR and CTS before it will transmit on the TD serial line. You will be able to write one or two characters into the device as it loads the transmit buffer and possibly the transmit shift register. But without the enabling flow control, the port will not transmit. Then it will not accept any more characters.

You may be able to get past this by building a loop back plug to connect RTS to CTS. You may also want to loop back TD to RD. You may need to assert DCD by connecting it to the looped back RTS to enable the serial receiver.

You may find that it just simply works when you connect it to an external device. You may need a null modem if the other device is also DTE.

One nice feature of the old RS-232 signaling, which used DTL logic levels, is that connecting a driver to a driver does not damage the equipment. It won't work, of course, but it won't damage the drivers. That is NOT necessarily true with RS-422/RS-485 differential connections.

The IOCTL (I/O control) functions were provided to handle the "out of band signaling" functions to do things like set baud rates and configure and detect status of the control lines on RS-232 serial ports. The original PC had circuitry to over ride the auto enables on the serial port transmitter and receiver. Legacy systems still have all that stuff in the North Bridge chip where all the old ISA stuff still resides.

You may be able to add serial ports by reconfiguring and building a new kernel. That worked pretty well back in Slackware 9.x. That may also be a reference for driver source code.

This is for another device, an ARM based vision system.
I shelved that chessboard problem for now.
Yes I am receiving characters under interrupt control.
It doesn't hang the port or the process and closes cleanly.
I can post the code tomorrow. It is late.
thanks........don
code posted below

Yes I had fried the ground pin on another job doing just that.
I need a program to capture jpegs from a microcontroller. Most of the freeware I found was very hard to understand and modify for my use. I am finding that code was very cryptic for a bare metal guy like myself. What library are you talking about?
thanks.............don

here is a man that knows his hardware!
Yes this is a simple interface, I have written about 20 drivers in the old days when I was a corporate slave. It is a major headache in linux. the cts/rts signaling I will check the flags for.
As for DTE, this works with picocom and gtkterm fully. I am probably overwriting a flag that I should not.
As for ioctl, that looks scary for a linux noob like me.
thanks.........don

Yes. that is probably what is happening. I have tried flushing and draining after every write() call to no avail. The line control flags are much more difficult to figure out. Much harder than the UART h/w it is servicing......

here it is.
120 lines in a single file.
it should not be difficult to follow as I like to keep things simple.
mucho thanks for everyone's interest....don

Attached Files

serirq7.txt (4.4 KB, 29 views)

I assume this was intended to provoke some heartfelt comments...

I'm glad I didn't take your attitude before programming all the serial ports that I have over the years. That would have left a lot of stuff unused, only because it has a serial interface.

I don't think there are many cases, if any at all, where programming of serial ports has caused problems that are electrical in nature. You are correct that misuse of the electrical connections between serial ports can cause mishap, I would be hard pressed to imagine any similar mishap caused by bad programming.

I agree, also, that the [RS-232] serial interface is nearing the end of its life. However, there will be good reason to interface computers to serial devices for many years to come, and many of those computers are going to run Linux. I think one could argue that Linux will eventually become the principle OS for supporting serial devices, if it isn't already.

Linux has the unfortunate position of using serial ports in applications for which the OS did not intend they be used. Linux, inheriting from Unix, intended serial ports to be used primarily as interfaces to terminals and modems. Since this was the primarly purpose behind the RS-232 specification, it made quite a bit of sense. Today, serial terminals are little used, but the OS support for serial ports is still highly oriented to that application. More often than not, we use serial ports these days to talk to 'devices', often smart devices that do a particular thing but need some easy way to provide input and output. In virtually all such cases, the application of the serial port is a corruption of the RS-232 spec, although in most cases it still works well enough for its purpose. I mention all of this, because it is sometimes helpful to understand the background for why a particular behavior or standard exists.

As is my custom in replying to questions about serial ports, I recommend to the original poster that he consult three good online references:

Serial HOWTO
Serial Programming HOWTO
Serial Programming Guide for POSIX Operating Systems

--- rod.

theNbomer is quite right.
Most micro devices have an rs232 interface.
I think it will never die because USB is complicated and overkill for most microcontrollers.

I got the serial program working btw........don
I'll attach the code in my next post. thanks

You got it right Arthur! The RTS/CTS bit was enabled. I should have known. It was the last of many hurdles. Thanks, I was hung up on a Linux serial driver for 4 months!!! I agree with your opinion of Linux serial i/o. It is a major pain. I will post it for anyone to use/hack on their project. There are a few more serial & interrupt references in it that provided useful code snippets.

Is slackware better for bare metal programming?

thanks all............don

Attached Files

tte.c.txt (6.4 KB, 23 views)

1 members found this post helpful.

yep. I had the same problem with my Kaypro 2X.