Linux Writes to serial at incorrect speed

mike_canada · 07-09-2019, 09:38 PM

My question is a bit similar to this one:

https://www.linuxquestions.org/quest...arbage-936622/

In my code, I have two file handles open. One for writing data to serial and One for reading data from serial. I used the same serial settings as the poster in the above question except I didn't use
CRTSCTS flag because my microcontroller hardware doesn't use flow control. I also didn't use the BAUDRATE flag because the compiler wouldn't compile it.

But I'm trying to get data flowing at a high speed. It seems to be ok at 19.2Kbps but I want 57.6Kbps and when I ran strace on my code, I get this:

Code:

open("/dev/ttyS0", O_RDONLY|O_NOCTTY|O_SYNC) = 3 <0.000109>
open("/dev/ttyS0", O_WRONLY|O_NOCTTY|O_SYNC) = 4 <0.000013>
sync()                                  = 0 <0.015698>
write(4, "@"..., 1)                     = 1 <0.000027>
write(4, "020102030000000000000000000002"..., 30) = 30 <0.000008>
write(4, "\n"..., 1)                    = 1 <0.000006>
sync()                                  = 0 <0.008830>
ioctl(3, TCFLSH, 0x2)                   = 0 <0.000012>
ioctl(4, TCFLSH, 0x2)                   = 0 <0.000049>
read(3, "\2?\3 "..., 4)                 = 4 <0.001097>
close(3)                                = 0 <0.000016>
close(4)                                = 0 <0.000045>

The only way the numbers make sense in triangle brackets is when I issue sync(). The microcontroller does put out correct data but the PC is timing it all wrong. Is there some way I can make it where the write function itself is the delayed function, because in my hardware setup, at 57.6Kbps speed, it should take about 173 microseconds to send out a byte. In the strace log above, it takes an average of 450 nanoseconds which doesn't make sense.

Is there a way to fix this? or is there a specialized linux serial driver I could use that can help me fix this? I tried fopen() in the past but got no better results.

Or what could even be better, is if theres a way I can put in a command to cause the entire system to lock up except the program until the serial I/O occurs then unlock the entire system.

business_kid · 07-11-2019, 06:12 AM

This could actually be messy.

REAL rs232 used fixed I/O & interrupts, used +/- 5V, and never went above 115,200 baud. I'll bet you haven't got that. Please detail what you have. There was also serial controller chips (Through hole & probably long obsolete). The MAX232 was one that springs to mind. It actually made a -5V rail from the +5V one. IIRC, rs232 hardware always reserved the right to slow itself down if it wasn't getting through. So although you set a high speed it may choose a slower one. How you interrogate the hardware is beyond me. IIRC, there was a byte received and you got the signal (pin high or low) and could read it.

Your wise course would be to try for a lib or a python module or something which looked after all this. And whoever chose rs232 to do anything is a serious case. Are you working in a museum?

mike_canada · 07-11-2019, 05:35 PM

Quote:

Originally Posted by business_kid

This could actually be messy.

REAL rs232 used fixed I/O & interrupts, used +/- 5V, and never went above 115,200 baud. I'll bet you haven't got that.

My computers do have the real RS232 port. Its just messy in the software land. I found out that linux isn't as real-time as DOS but on the other hand, DOS doesn't support alot of devices or applications.

Quote:

There was also serial controller chips (Through hole & probably long obsolete). The MAX232 was one that springs to mind.

And my hardware uses that exact IC. MAX232 with 1uF MLCC capacitors for the charge-pumps and a 10uF electrolytic for the reservoir capacitor.

I find it odd tho that when I run the screen program I get successful output from my hardware every time, but when I run my own code, that's when I have problems. Maybe the screen program uses different calls to access the port but I'm not sure.

Quote:

Your wise course would be to try for a lib or a python module or something which looked after all this. And whoever chose rs232 to do anything is a serious case. Are you working in a museum?

I'm doing a major project which eventually will become a business. Yes RS232 is old technology, but along with old comes lower prices and lower replacement costs should parts break. In fact, I even use fully-made radio modules that also require a uart running at 9600bps to setup.

In the meantime, I'm gonna find a good used mini-computer and install the lightest-weight linux that at least comes with the kernel, a shell, apache, RS232 driver and network driver. I don't care about X.

michaelk · 07-11-2019, 06:24 PM

The MAX232 is just a driver chip i.e. converts TTL to RS-232 signals. What real hardware UART you are using and operating system interrupt latency would determine the max baud rate. I know I played with 115.2 Kbps but it has been awhile.

True, linux is not a real time system unless you are running a RT kernel or a low latency kernel. I would think that 57.6Kps is possible.

Have you looked at any programming howtos?
http://tldp.org/HOWTO/Serial-Program...WTO/index.html

business_kid · 07-12-2019, 02:02 PM

I did a bit of RS232 & linux in my day, too. Linux multitasks, so cannot be entrusted with timing duties. Industrial PCs will do it, but they're mired in the last millenium.