Re: Serial port programming

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I am trying to send escape sequences using the attached small C
> program, but it does not work.

"It does not work" is not a useful problem report.  What _does_ happen?
Does it run apparently successfully but the LCD does not respond?  Does
it hang?  Does it error?  At the extreme end, does the system panic?

> Is anything worng with that program?

>       fd = open("/dev/dtyU0", O_RDWR);
> 
>       if (fd < 1)
>               err(1, "open");

Depending on how you run the program, you could get a spurious error
here.  Specifically, if open() returns 0, which is a success return.
Usually, this is a can't-happen, because most ways of running will have
stdin already open, but nothing you've said excludes the possibility
that you're using one of the few methods that can run it with stdin
closed.

>       tty.c_cflag = (CS8 | CLOCAL);

kenh pointed out that CREAD is clear here.  This _shouldn't_ matter,
since you're not reading, but it's possible that the driver does not
correctly handle the case of writing without CREAD turned on.

I'd suggest setting c_cc[VMIN] and c_cc[VTIME] as well.  The
cfmakeraw() I have at ready hand does not touch them.  Again, this
shouldn't matter because you're not reading, but might.

>       cmd[0] = 0xfe;
>       cmd[1] = 0x47;
>       cmd[2] = 0x01;
>       cmd[3] = 0x01;
>       if (write(fd, cmd, 4) != 4)
>               err(1, "write cmd", n);

There is a possibility of spurious error here if some but not all of
the command is sent.  This is not an error condition for write(), but
you treat it as though it were.  (Of course, if the misbehaviour isn't
an error here, then this isn't the problem.)

Also, the octet sequence you're sending here is not what I would
usually call an "escape sequence" - you've made sure that sequence is
correct, I trust?

>       write(fd, "LCD text text                       ", 20);

I note that the string in this write is substantially longer than 20
bytes.  This is not really an error, but if you thought otherwise it
may indicate something went wrong at some wetware level.  It's also not
error-checked, though that is _probably_) not what's wrong.

As kenh also pointed out, it's possible the error is somewhere other
than this program, such as the cabling.  Depending on the failure mode
you're seeing, this may or may not be a plausible explanation.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B