Serial Port Emulation

sironitomas · 2010-10-12 06:36:28

Hi forks, I'm working on a (PIC) project that will send some data to my linux box, using RS232. In the computer, I'm developing the software that will be monitoring that data. Since my box doesn't have a serial port, I'm looking for a way to test the software until I get a machine with serial port.

Is there any way to do something like this?

cat data >> /dev/ttyS0

where ttyS0 and ttyS1 are virtual devices connected together, and my software getting the data coming from ttyS1.

Any ideas? Thanks in advance!

Last edited by sironitomas (2010-10-12 07:15:05)

Stebalien · 2010-10-12 12:16:09

If you only need one direction: Create a fifo and read/write from/to the same file. (mkfifo)
If you need two directions, You could create two fifos but your code would need to be changed.
This is not the best solution but it is the only one that I can think of.

Last edited by Stebalien (2010-10-12 12:19:41)

ewaller · 2010-10-12 17:25:44

How about pseudo terminal pairs? ( man pts )

Readers digest version: You can create two devices in the /dev tree that are connected to each other. You can open one as your 'serial' device from your program and can open the paired device in a program of your choice (like gtkterm)
You can also create an simulator of the pic application and use that. In a really cool world, develop and run your target in an emulator, and map the serial port to the other end of the pts pair, and run both pieces of code on your box simultaneously without the need for target hardware at all.

Cyrusm · 2010-10-12 18:08:01

on a side note, have you checked to see if your motherboard has the COM1 pinout? even if the box doesn't have a serial port, the motherboard will frequently have the pinout for the serial port (same holds true for the parallel port). Of course this doesn't hold true for all motherboards, but I think it would be worth your time to take a look. if you have the pins you can buy an external serial port for like $3US.

sironitomas · 2010-10-12 22:53:37

@Cyrusm: That's a good option, but I have to test this software before the hardware is done.
@ewaller: I think that's what I was I looking for. It's kind of tricky but I'm reading how to get it working.
@Stebalien: I don't know if the software would behave equally in presence of a real port.

Thanks!

ewaller · 2010-10-12 23:12:13

sironitomas wrote:

@Cyrusm: ...I think that's what I was I looking for. It's kind of tricky but I'm reading how to get it working.
...

The man page I referenced talks about the 'New' way of doing this, and you are right -- there is some magic to it. The man page does allude to the 'old' or previous way of doing this in which there are persistent pairs of files in /dev. These don't require the handles / unlocks described in the documentation.

I have used the older method on Arch Linux, but I do not remember the specifics as to how to set it up. It has to do with loading a kernel module, but memory fails me as to which module, and how to tell it how many port pairs to instantiate.

Give me a few hours to get home, help the kids with their homework, and sit down with my system and I'll work it out.

ewaller · 2010-10-13 02:20:18

I checked on the 'old' way.

The plus side is there are none of the required calls to grantpt or unlockpt.

The minus side is that it is not a kernel module but rather is an option that must be compiled into the kernel. One specifies the number of pairs in the kernel .config file and is fixed at compile time. This option is not turned on in the Arch kernel configuration.

How do you feel about compiling a kernel ?? (It really is not that bad, of course I am a refugee from Gentoo so I am a wee bit biased)

sironitomas · 2010-10-13 02:37:05

ewaller wrote:

I checked on the 'old' way.
The plus side is there are none of the required calls to grantpt or unlockpt.
The minus side is that it is not a kernel module but rather is an option that must be compiled into the kernel. One specifies the number of pairs in the kernel .config file and is fixed at compile time. This option is not turned on in the Arch kernel configuration.
How do you feel about compiling a kernel ?? (It really is not that bad, of course I am a refugee from Gentoo so I am a wee bit biased)

I couldn't get it working. So far, I have this http://pastebin.com/gqRZxuUu but when I try to send data to that pts (through echo), I get some nasty symbols. So, compiling a kernel is not a bad option... What would be the advantages of not-calling grantpt or unlockpt in the old way?

ewaller · 2010-10-13 03:38:45

sironitomas wrote:

... What would be the advantages of not-calling grantpt or unlockpt in the old way?

It makes it really easy to use existing programs without modification. You could open one of the two files using tools like gtkterm or minicom. Using the "new" method, these programs have to be modified for the grantpt / unlockpt sequence.

Actually, one can use separate instances of these programs to open both of the paired files and you can communicate between the two programs.

The aforementioned serial communication programs handle asynchronous / simultaneous I/O.

Your code looks like it opens the port correctly, and then immediately tries to read from it. If I understand the pts mechanism, the opening of /dev/ptmx causes a new file node to magically appear in /dev/pts. At that point, another program may open that file and establish a link to the first program.

Your code looks like it tries to read the file and then closes the handle, but I don't see where an external program could open the port and then send data. I think that at the least, the program needs to open the port, and then wait for data to arrive. You could then launch this program followed by the program at the other end of the link.

Edit: I take that back, I see you are using getchar, so you are waiting for it. Let me ponder this...

Last edited by ewaller (2010-10-13 03:41:41)

ewaller · 2010-10-13 03:51:11

Ah... You did not allocate memory for the buffer :

...
char *dato;
...
getchar();
...    
error = read(fd,dato,4);

But you never initialized that which dato points to.
Try:
char dato[4] instead of char *dato
This allocates space for the buffer and initializes *dato to point to the buffer

Last edited by ewaller (2010-10-13 03:51:50)

sironitomas · 2010-10-13 04:26:57

ewaller wrote:

Try:
char dato[4] instead of char *dato

You are right, I've put that and now I get different symbols. I think the program itself works, but I'm sending the data to the port in a bad way. Actually I'm doing

echo [something] >> /dev/pts/[port assigned]

Is that right?

Or, the mistake is somewhere in the code, I don't know. I tried changing the buffer size but it doesn't seem to make a difference.

Thank you anyway for the supporting!

ewaller · 2010-10-13 05:04:01

I think you will find this is always false and destroys the value of error

if (error = 0)

So, even if the function returned null, you miss the error and print the contents of the buffer into which no data have been placed.

Also, the example I gave allocated four bytes. That is the maximum number of bytes that read will return -- but read does not zero terminate the buffer. So: make the buffer 5 characters, read at most 4 characters, and put a zero at the end of the buffer prior to using %s. It might be better to iterate over the buffer up to the number of characters received and print those chars out one at a time.

sironitomas · 2010-10-13 07:10:10

ewaller wrote:

I think you will find this is always false and destroys the value of error
if (error = 0)

Oohh, that was a big inadvertence, but now it's been corrected. Fortunately (and not), the read function was working fine, so no errors were unnoticed.

Respect to the other: I've made the buffer bigger, read 4 characters and put the zero in dato[4], then shown them in the screen, but they are still ugly symbols. There must be a reason for this. I'll keep on playing tomorrow morning...

toofishes · 2010-10-13 13:40:03

Have you looked at socat? It does all sorts of crazy stuff, and I think it has serial port support.

ewaller · 2010-10-13 14:54:28

sironitomas wrote:

echo [something] >> /dev/pts/[port assigned]

Any chance you are sending unicode?

ewaller · 2010-10-13 15:01:21

toofishes wrote:

Have you looked at socat? It does all sorts of crazy stuff, and I think it has serial port support.

Interesting. I had never heard of it socat. At first glance it looks like something that could make my life a lot easier. I think I'll be learning a new tool this weekend ;-)

sironitomas · 2010-10-13 16:01:12

toofishes wrote:

Have you looked at socat? It does all sorts of crazy stuff, and I think it has serial port support.

Hey, I just found this http://goo.gl/DMCM and think it's interesting. It could work in my code. I'll try later and then tell you what happens.

Last edited by sironitomas (2010-10-13 16:05:17)

sironitomas · 2010-10-14 02:10:51

It is working with the socat method! The only problem is that when I put the read function (and printf) into a while, the program doesn't receive data anymore... What could be the issue?

nomorewindows · 2010-12-08 00:26:37

I haven't used socat yet, but I have used ser2net, which allows access to the serial port over telnet. But I'm trying to find out if there is something that works in linux so that the linux box that has the serial port can be used in a program directly like virtual serial port on a computer that doesn't have any serial ports. Socat looks like it could do some damage, wondering what combinations of arguments I would use to make that happen.
-----------------------
Nvm, the socat man pages were sufficient enough, I found that I don't need to use the ssh part, just the TCP4 argument. Linux is so neat when I don't have to reprogram everything!!

Last edited by nomorewindows (2010-12-08 03:26:27)

Arch Linux

#1 2010-10-12 06:36:28

Serial Port Emulation

#2 2010-10-12 12:16:09

Re: Serial Port Emulation

#3 2010-10-12 17:25:44

Re: Serial Port Emulation

#4 2010-10-12 18:08:01

Re: Serial Port Emulation

#5 2010-10-12 22:53:37

Re: Serial Port Emulation

#6 2010-10-12 23:12:13

Re: Serial Port Emulation

#7 2010-10-13 02:20:18

Re: Serial Port Emulation

#8 2010-10-13 02:37:05

Re: Serial Port Emulation

#9 2010-10-13 03:38:45

Re: Serial Port Emulation

#10 2010-10-13 03:51:11

Re: Serial Port Emulation

#11 2010-10-13 04:26:57

Re: Serial Port Emulation

#12 2010-10-13 05:04:01

Re: Serial Port Emulation

#13 2010-10-13 07:10:10

Re: Serial Port Emulation

#14 2010-10-13 13:40:03

Re: Serial Port Emulation

#15 2010-10-13 14:54:28

Re: Serial Port Emulation

#16 2010-10-13 15:01:21

Re: Serial Port Emulation

#17 2010-10-13 16:01:12

Re: Serial Port Emulation

#18 2010-10-14 02:10:51

Re: Serial Port Emulation

#19 2010-12-08 00:26:37

Re: Serial Port Emulation

Board footer