Problem to read on a serial port

unix

    Next

  • 1. Usual conventions writing network programs?
    I started writing my first 'serious' network oriented application. I started it from scratch in C++, writing socket classes, my-application-specific classes etc. Now, planning client-server communication - when/where/how send/receive, what would be the commands, what would be the organization etc. - I thought there must be a standard way for doing such things, something like convention or the very best algorythm and similar. I mean, many people were writing network-oriented programs, they certainly found the best solution for, say, standard problems. I wander if there are documents on this subject, where can they be found? I appreciate every reference, thanks.
  • 2. nftw question
    Hi, I'm using nftw to walk a file tree (/proc), looking for child processes of my program's process. I'd like kill all children of my process, and all children of their children, etc. My question is, is it ok to use nftw to find all the children, and recursively call ntfw to find the grandchildren, and so on, to kill them all?
  • 3. howto stretch an image with SDL
    Hi, i'm trying to load a background, which is a tile, but how do you let it draw to the entire screen? or stretch it? I tried using SDL_BlitSurface and changing the width and height variables returned by IMG_Load from SDL_Image but that doesn't work. Or it works, but just changes the surface coordinates. I'm trying to build a simple game, and need to have a scrolling background. I'm assuming a tile is the way to go, for a simple background, and then stretch it. Any help is welcome thx atv
  • 4. dbx debugging problem
    Hi, I'm running IRIX 6.5 and dbx 7.3.4. I'm trying to use dbx to attach to an already running process with dbx -p XXXXX However I get: Cannot open /proc on Process XXXXX where XXXXX is the process id of my program. Has anyone run into this before? Thanks
  • 5. sigprocmask() behavior
    Hello, When sigprocmask() is used to unblock a previously blocked signal, and there is a pending signal of that type, does the signal handler get executed? Synchronously within sigprocmask(), before it returns? (My Linux system seems to behave that way, but I want to be sure; and I can't make out from X/Open specs). What exactly happens with pending signals when they are unblocked? Thanks, D.

Problem to read on a serial port

Postby collinm » Fri, 01 Apr 2005 01:02:14 GMT

hi

i need to read from a  serial port (c programming)

we use a sixnet Mini-VersaTRAK mIPm
 http://www.**--****.com/ 

under bash:
~ # stty -a </dev/ttyS2
speed 9600 baud; rows 0; columns 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^U; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
-ixoff -iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke


i send a command via serial port to a led display (alpha sign
communications)

void ledDisplayExist()
{
    char msg[]={'\0', '\0', '\0', '\0', '\0', '\1', 'Z', '0', '0',
'\2', 'H', 'A', '\4'  };
    int length = sizeof(msg);
    writeopen(msg, length);
    readopen();
}

i write msg with this function:

int writeopen(char msg[], int size)
{
    printf("write\n");
    int fd1;
    int wr;
    fd1 = open(ledisplay, O_RDWR | O_NOCTTY | O_NDELAY );
    if (fd1 == -1)
        fprintf(stderr, " %s open_port: Unable to open %s\n",
strerror(errno), ledisplay);
    else
    {
        fcntl(fd1, F_SETFL, 0);
        wr=write(fd1, msg, size);
        if (wr < 0)
            fputs("write() of n bytes failed!\n", stderr);
        close(fd1);
    }
    return (fd1);
}

i try to read with this function:

int readopen()
{
    printf("read\n");
    int fd1;
    int rd;
    char buff[255];
    fd1 = open(ledisplay, O_RDWR | O_NOCTTY | FNDELAY );
    if (fd1 == -1)
        fprintf(stderr, "%s open_port: Unable to open %s\n",
strerror(errno), ledisplay);
    else
    {
        fcntl(fd1, F_SETFL, FNDELAY);
        printf(" Port 1 has been sucessfully opened and %d is the file
descriptor\n",fd1);
        rd=read(fd1, buff, 20);
        printf(" Bytes recieved are %d \n",rd);
        close(fd1);
    }
    return (fd1);
}

that return always return me:  Bytes recieved are -1 (i write without
problem, the problem is the read)

any idea?

thanks


Re: Problem to read on a serial port

Postby Jens.Toerring » Fri, 01 Apr 2005 02:07:38 GMT

ollinm < XXXX@XXXXX.COM > wrote:











First thing I would definitely avoid is closing the file descriptor
for the serial port between writing and reading. The other side may
interpret this as meaning that you aren't interested in getting a
reply.

Then there are a lot of possible problems, which you may already have
carefully checked, but I list them anyway, perhaps you overlooked one
of them:

1) Why do you call fcntl() on the file descriptor? And why do you
use FNDELAY in open() while O_NONBLOCK probably would be more
portable? Shouldn't be the fcntl() command be e.g.

fcntl( fd1, F_SETFL, ( fcntl( fd1, GETFL ) & ~ O_NONBLOCK ) );

if you want to switch off non-blocking mode?

2) What is the value of errno after the failed write() call? It might
give you some indication of what's going wrong.

3) Are you sure the serial port is correctly set up for the communication
with the device? There is a huge number of possible settings and
lots of things can go wrong. Obviously, you don't set up the serial
port at all after you open the file. If you're very lucky the settings
are just what the other side expects, but you really can't rely on that.
Did you check the man page for tcsetattr(3)? Admittedly, it's a lot
to learn, but in the end you will have to anyway. Did you ever manage
to communicate with the device with some other program?

One thing I don't like about the serial port settings you posted at
the start is that it seems to be in canonical mode. While this mode
is fine when there's a terminal or something similar at the other end,
it doesn't look good with a device where you seem to exchange binary
data. Some bytes won't make it to the other side (and back) at all in
canonical mode, and things are line buffered. And since you never send
a '\n' I wouldn't be surprised if none of the data you write ever make
it to the other end of the line and get stuck in the internal buffer
of the serial port driver (even though read() returns no failure, but
that's ok, since it found something that took care of the data).

What's what the device expects? From a quick look at the User Manual
it looks as if the device has two serial ports with different numbers
of lines connected, so it's possible that both need different
settings, especially for the control lines...

Getting the communication parameters wrong is probably the most common
reason for failures to exchange data, so you should check them very
careful.

4) Did you make sure the cable is ok? I.e. all the required lines are
there, you're not using a null-modem cable when you need a normal
one or vice versa, have all lines low resistance?

Sorry for asking more questions than providing answers...

Regards, Jens
--
\ Jens Thoms Toerring ___ XXXX@XXXXX.COM
\__________________________ http://www.toerring.de

Re: Problem to read on a serial port

Postby collinm » Fri, 01 Apr 2005 03:13:37 GMT



ok changed that, now in my function i do a write and a read...

void writereadopen(char msg[], int size)
{

int fd1;
int wr;
int rd;
fd1 = open(ledisplay, O_RDWR | O_NOCTTY | O_NDELAY );
if (fd1 == -1)
fprintf(stderr, " %s open_port: Unable to open %s\n",
strerror(errno), ledisplay);
else
{
fcntl(fd1, F_SETFL, 0);
wr=write(fd1, msg, size);
if (wr < 0)
fputs("write() of n bytes failed!\n", stderr);
else{
char buff[20];
printf("write\n");
rd=read(fd1, buff, 20);
printf(" Bytes recieved are %d \n",rd);
}
}
close(fd1);
}

i see the write message... but that seem to wait



all code i checked on the web have that, i'm a newbie with seria
programming


i remove fcntl(fd1, F_SETFL, 0);
and i put
fcntl( fd1, F_SETFL, ( fcntl( fd1, F_GETFL ) & ~ O_NONBLOCK ) );

i see the write message... but that seem to wait




i write on serial port without problem... i only have problem when i
read

communication
serial
settings
that.
lot
manage

i'm able to write on the serial port... i send some command to
initialize the led display, another to send message...

i need to read on the led display because we want to know if what we
send to the led display is ok....

our solution is to send a command and after we read this command...

at

waht i need to change to use another mode?

end,
binary
in
send
make
buffer
but
Manual
numbers

i need to send a special command to the led display if i want to read
something about it

with: char msg[]={'\0', '\0', '\0', '\0', '\0', '\1', 'Z', '0', '0',
'\2', 'F', '&', '\4' };

with this string, i ask to led display to send me the day of the week
...

the led display is suppose to send me something like

\0 \0 \0 \0 \0 \1 0 \3 \3 \2 E & 6 \03 00A6 \4

\0 = null
\1 = start of header character
0 = response code
\3 = sign of the actual address
\2 = start of text character
E = is the read special function
& = read day of week
6 = stands for friay
\03 = end of text character
00A6 = checksum
\4 end of transmission character


common
very

ya, we use time since week without problem... we have a bash file who
write every x time to the led display (who use this cable)

no problem :) , you are the expert


Re: Problem to read on a serial port

Postby Jens.Toerring » Fri, 01 Apr 2005 03:51:04 GMT

ollinm < XXXX@XXXXX.COM > wrote:






Fine;-)


What does that sentence mean? Do you mean that you get some reaction
from the device, i.e. some LED starts blinking or whatever, when you
send data? Please remember that I have no real idea what that device
does nor what you can see;-)



Well, I don't understand what you try to do there. You might try to
switch back to blocking mode (one always should open serial ports
in non-blocking mode since otherwise the program may get stuck in
the open() call), but I don't know what you try. Did you copy it
from a place where one could have a look?






Sorry, I meant to write "read()" in that sentence but managed to f.ck
up... So, what's errno after the failed read()? E.g. if you're still
in non-blocking mode read() will return immediately if there are no
data available. And when your device is a bit slow answering than
that could easily happen. In that case errno would be set to EAGAIN,
so you know what happened. Perhaps sleeping for a few milliseconds
before trying to read will solve your problem (if it does you then
should call select() before you read() to insure it can't happen).
Other possibilities involve that your program received a signal be-
fore anything was read etc.



I guess I should interpret this that you had some working communication
with the device using a bash script. Then you are lucky in that at the
moment the settings for the serial port are what the device expects and
as long nothing changes them it will continue to work. But to make your
program reliable you will have to always insure that the settings are
ok. Did your bash script also manage to read from the device? And did
you try the same commands or maybe something that didn't involve
binary data (i.e. data only from the range between space and the '~')?

As the next steps I probably would try to figure out why you call
fcntl(). I don't know what you might be doing by resetting the
flags completely - it might differ from system to system. Next step
would involve checking errno after the failed read() call. The
result might be instructive.
Regards, Jens
--
\ Jens Thoms Toerring ___ XXXX@XXXXX.COM
\__________________________ http://www.toerring.de

Re: Problem to read on a serial port

Postby collinm » Fri, 01 Apr 2005 04:22:45 GMT



the command i send to led display don't display nothing on it...
when the led display receive this command, it know that it must send
something...




ya no problem:

http://www.scorec.rpi.edu/~oklaas/tempMeasurement/
http://www.scs.carleton.ca/~barbeau/Courses/SETP/KISS/linux_serial.txt


i remove the function:

void writereadopen(char msg[], int size)
{
int fd1;
int wr;
int rd;
fd1 = open(ledisplay, O_RDWR | O_NOCTTY | O_NDELAY );
if (fd1 == -1)
fprintf(stderr, " %s open_port: Unable to open %s\n",
strerror(errno), ledisplay);
else
{
wr=write(fd1, msg, size);
if (wr < 0)
fputs("write() of n bytes failed!\n", stderr);
else{
char buff[20];
printf("write\n");
rd=read(fd1, buff, 20);
fprintf(stderr, "%s", strerror(errno));
printf(" Bytes recieved are %d \n",rd);
}
}
close(fd1);
}

get the same thing




Resource temporarily unavailable Bytes recieved are -1


E.g. if you're still

i do a sleeping a few second but the result is the same:

Resource temporarily unavailable Bytes recieved are -1


(if it does you then

who
communication

if we reboot the machine, there are a script who setup the serial port
no other program or script change that

and
your
no, with the bash script we only write

And did
'~')?

i get: Resource temporarily unavailable Bytes recieved are -1


Re: Problem to read on a serial port

Postby Jens.Toerring » Fri, 01 Apr 2005 06:40:35 GMT

ollinm < XXXX@XXXXX.COM > wrote:




So you actually don't know if anything arrived at the device. Don't
be mislead by the fact that write() returns with something that looks
like success - if the settings for the serial port aren't what you
need read() may just have passed the data to the driver for the serial
port, but that didn't pass them on to the other side, for example
because it's in canonical mode and only transmits when it has a whole
line, i.e. either there was a '\n' in the data or the serial port
got closed (was this why you closed it after the write() and before
trying to read()?).




They didn't help much, since I didn't find what FNDELAY actually is
supposed to mean - unfortunately what happens there seems to be rather
system dependend and especially calling fcntl() with F_SETFL and 0
doesn't look right since it resets all flags, not just the O_NDELAY.

I am also somewhat suspicious of the claim that read() should return
0 when in non-blocking mode and there are no data. I would expect
it to return -1 and errno being set to EAGAIN. But I could of course
be dead wrong and others here will hopefully correct me.

And usually, I don't see any reason to switch to blocking mode at all
since it then gets a lot more difficult to recover if the device on
the other side is dead, so instead I use select() with a proper time-
out and then read() once select() me tells there's something to read.
Always looked to me like the simplest way to go. But YMMV...






That would be EAGAIN. As far as I know when the serial port is in non-
blocking mode it's supposed to return from read() immediately, data or
not data. And when there were none, you get errno set to EAGAIN. One
reason might be that the device on the other side never received any-
thing and thus doesn't know that you're waiting for a reply;-) But
the texts you mentioned above seem to think differently, i.e. that
you in that case should get a return value of 0 - but which you
don't get...


And you don't know if what you did write arrived at the other
side at all, do you? Again, having write() return does _not_
guarantee that everything has been transmitted. If you have e.g,
a terminal on the other side you would switch the serial port to
canonical mode which (beside other things like erasing characters
followed by a DEL character) buffers data until it got an end of
line character. And if your serial port is in canonicial mode
(and I would expect it to be that when you boot the machine)
and you send characters that could be control characters these
might get interpreted already by the serial port driver and never
make it to the other side. Moreover, if there isn't a '\n' and
you don't close the serial port data will stay in the buffer on
_your_ side.

Also, when you do a

echo -e "some data" > /dev/ttyS0

then a lot of things happen:
1) device file is opened
2) data are sent to the device (without a '\n') at the end
3) device file is closed

If you even then have no 100% safe indication that something happens
on the other side (some real physical evidence, not just that echo
seemed to be successful) then I definitely wouldn't use the assumption
that something did arrive at the other side. Do you have a communication
tester for the serial port, i.e. normally a small box you can plug in
between the computer and the device and which has some LEDs that indi-
cate traffic on the lines? If there

Re: Problem to read on a serial port

Postby floyd » Fri, 01 Apr 2005 20:05:49 GMT



Unfortunately neither of those are particularly good examples of
serial port coding.  There are several problems with the second
one in particular, which seems to be the one you have used as an
example to base your code on.

Read those for the information they provide, but don't use the code!

In the first one there is a reference to the Linux HOWTO...  which
should be used in the same way as those two, for information only
and not for coding examples.

However, the other reference given is *really* *good*:

   http://www.**--****.com/ ~mike/serial/serial.html

I don't know of a single error in that entire document.  It is *the*
URL to pay attention to.  Unfortunately it doesn't have code examples
that will help you much.

I've put several "terminal programs" as serial port programming
examples on my web site.  These are more or less a match for the
discussion in the Linux serial port programming HOWTO, without
(I hope) all of the coding errors and bugs.

     http://www.**--****.com/ 

These programs are configured to talk to a modem, but changing
them to talk to virtually any serial device is relatively easy.
There are five different versions of the same program, using
different methods for accessing the serial port:

 term_async.c:   Single process using asynchronous interrupts.
 term_select.c:  Single process using select().
 term_canon.c:   Forked processes using canonical mode input.
 term_fork.c:    Forked processes using raw mode input.
 term_thread.c:  Pthreads and raw mode input.

I would suggest that you *not* attempt to use either the async or
threaded examples.  The easiest to use is probably the one calling
select().

It would be interesting to see your entire program.  It's
probably too big to post the whole thing, but perhaps you could
put it on a web site?

-- 
Floyd L. Davidson           < http://www.**--****.com/ ;
Ukpeagvik (Barrow, Alaska)                          XXXX@XXXXX.COM 

Re: Problem to read on a serial port

Postby Jens.Toerring » Fri, 01 Apr 2005 20:57:13 GMT











What do you think about the

  fcntl(fd, F_SETFL, 0);

Wouldn't that also clear out other flags than O_NDELAY, which
might have unintended effects (at least I don't know if there's
a consensus between systems which flags exist at all and which
get influenced by fcntl())? So, shouldn't one use e.g.

fcntl(fd, F_SETFL, fcntl( fd, F_GET_FL ) & ~ O_NDELAY );

to explicitely only reset the non-delay flag? Also, I didn't find
'FNDELAY' in POSIX, so wouldn't it be better to use O_NDELAY? Or
is there some magic involved with the use of 'FNDELAY'?

Another thing I am not sure about is what read() is supposed to
return in non-blocking mode when no data are available. Is it
really true that read() should return 0 in that case and not -1
with errno being set to EAGAIN? Is this something specific to
the serial port (I wouldn't expect a 0 return value when e.g.
reading from a normal file or a pipe in that case because it
would be impossible to distinguish it from a closed pipe)?

                                  Regards, Jens
-- 
  \   Jens Thoms Toerring  ___   XXXX@XXXXX.COM 
   \__________________________   http://www.**--****.com/ 

Re: Problem to read on a serial port

Postby Geoff Clare » Fri, 01 Apr 2005 22:01:23 GMT

 XXXX@XXXXX.COM  wrote, on Thu, 31 Mar 2005:


In the general case the get-and-set method should always be used.
According to POSIX fcntl(fd, F_SETFL, 0) would turn off O_APPEND,
O_NONBLOCK, O_SYNC, O_DSYNC and O_RSYNC if any of them were set.
Implementations could also have additional non-standard flags for
use with fcntl F_[GS]ETFL (such as O_NDELAY) which would be
turned off if they were set.

However, if you know for sure that other flags were not set when
the fd was opened, and have not been set since, then
fcntl(fd, F_SETFL, 0) should work fine to turn off only the
flags you know are set.


Neither FNDELAY nor O_NDELAY are in POSIX.  It is best to use
O_NONBLOCK.


The zero return is the historical behaviour with O_NDELAY, and the
fact that it is broken-by-design (because it can't be distinguished
from EOF) is the reason POSIX invented O_NONBLOCK to replace O_NDELAY.
When O_NONBLOCK is used read() must indicate that no data are
available by returning -1 and setting errno to EAGAIN.

-- 
Geoff Clare < XXXX@XXXXX.COM >


Re: Problem to read on a serial port

Postby Jens.Toerring » Fri, 01 Apr 2005 22:28:54 GMT










Thanks for the clarification! I actually always was wondering WTF
the difference between O_NDELAY and O_NONBLOCK is supposed to be
and started to think of them as the same thing. So you may have
spared me some future trouble;-)

                                   Regards, Jens
-- 
  \   Jens Thoms Toerring  ___   XXXX@XXXXX.COM 
   \__________________________   http://www.**--****.com/ 

Re: Problem to read on a serial port

Postby collinm » Sat, 02 Apr 2005 01:15:46 GMT




ok i will read it

ya no problem, you can get the file:
 http://www.**--****.com/ 


Re: Problem to read on a serial port

Postby floyd » Sat, 02 Apr 2005 05:45:04 GMT




...


FNDELAY is BSD, while O_NDELAY came from SYSV. Because there was
no consistant standard for implementation, and variations existed
on different platforms, POSIX adopted O_NONBLOCK to provide a well
defined portable standard.


On Linux, all of O_NDELAY, FNDELAY and O_NONBLOCK are exactly the
same.  Grepping in /usr/include turns up these two defines in
/usr/include/bits/fcntl.h,

    #define O_NDELAY     O_NONBLOCK
    #define FNDELAY      O_NDELAY

Which can indeed be a problem if the code is ported to various
other flavors of unix.  On some (Solaris being one example I've
seen referenced) they are slightly different.  And of course how
they differ changes between implementations too.

-- 
Floyd L. Davidson           < http://www.**--****.com/ ;
Ukpeagvik (Barrow, Alaska)                          XXXX@XXXXX.COM 

Re: Problem to read on a serial port

Postby Jens.Toerring » Sat, 02 Apr 2005 06:34:56 GMT












Having used Linux exclussively when dealing with the serial port may
have helped my confusion;-) (and I always opted to only use O_NONBLOCK
since it seemed like the right thing...) While I read the man pages
for other systems I have access to, things always remained a bit hazy,
and especially the business with having read() return 0 when in non-
blocking mode when no data are available was rather counterintuitive.
But I guess I now got the complete picture. Thanks, Floyd and Goeff!

                                  Regards, Jens
-- 
  \   Jens Thoms Toerring  ___   XXXX@XXXXX.COM 
   \__________________________   http://www.**--****.com/ 

Re: Problem to read on a serial port

Postby floyd » Sat, 02 Apr 2005 08:51:12 GMT

collinm" < XXXX@XXXXX.COM > wrote:

Great! I'll only comment on the configuration code, and
wait until you get that working before we get into how to
read/write to the serial port.

I would suggest changing your Makefile a little...

CC= /opt/cross-ppc/bin/powerpc-855-linux-gnu-gcc-3.3
DEFS=
PROGNAME= led_display
INCLUDES=
#LIBS= -lsxiodb -lsxio

STRIP=/opt/cross-ppc/bin/powerpc-855-linux-gnu-strip

GCC_WARN = -Wcast-align -Wcast-qual -Wmissing-prototypes \
-Wshadow -Wnested-externs -Wstrict-prototypes \
-Waggregate-return
GCC_OPTIM = -O2
GCC_SYMTAB = -ggdb
GCC_ANSI = -std=c99
GCC_PEDANT = -pedantic
GCC_FLAGS = $(GCC_WARN) $(GCC_OPTIM) $(GCC_SYMTAB) $(GCC_ANSI) $(GCC_PEDANT)

DEFINES= $(INCLUDES) $(DEFS)
CFLAGS= -W -Wall $(DEFINES) $(GCC_FLAGS)

That will generate more warning messages, all of which should be
fixed.

In the code itself...

Use prototypes, and valid function declarations. For example,
you have "main ()", which should be "main (void)".

Function restoreSerialPortDevice() is unused, and that
functionality need not be implemented.

I would arrange your main() function to call functions:

int readConfig(void)
get environment variables
print error messages
return status

int portOpen(char *ledisplay)
open the serial port
print error messages
return file descriptor or -1

int portConfig(int fd)
configure the serial port
print error messages
return file descriptor or -1

int ledConfig(int fd)
configure the led display device
print error messages
return file descriptor or -1

int ledCommand(int fd)
command the led display device
print error messages
return file descriptor or -1

Note that none of the above ever close the serial port unless
there is a failure. Depending on how you want this program to
work, you can loop different subsets of the above list to get
the results you want. For example, with a one-shot program
there is no need for a loop at all. For a daemon program, and
particularly if it is only sporatically activated, you might
want to close the port after the ledCommand() function, and then
loop the entire set every time, and leave the port closed
between commands. Buy if there are many commands given in a
short period of time, there is no point in closing the serial
port between each of them.

Your ledConfig function might look something like this, where
each function is passed an open file descriptor, and returns
a true/false status.

int ledConfig(int fd)
{
int rtrn = 0;

rtrn = softReset(fd);

if (!rtrn) {
rtrn = clearMemory(fd);
if (!rtrn) {
rtrn = displayInitMsg(fd);
if (!rtrn) {
rtrn = setupMemory(fd);
if (!rtrn) {
rtrn = enableSpeaker(fd);
}
}
}
}
return rtrn;
}

Here is an example function to open the serial port:

/*
* Open a serial port, disregarding Carrier Detect Status
*
* Returns file descriptor, or -1 on error.
*/
int
portOpen(char *device)
{
int fd, oldflags;

/* O_NONBLOCK allows open when DCD line is not active */
if (-1 != (fd = open(device, O_RDWR | O_NONBLOCK))) {

/* clear O_NONBLOCK to allow read() to block */
if ((-1 != (oldflags = fcntl(fd, F_GETFL, 0))) &&
(-1 != fcntl(fd, F_SETFL, oldflags & ~O_NON

Re: Problem to read on a serial port

Postby collinm » Sun, 03 Apr 2005 04:30:27 GMT



ok i changed my makefile


it's done


it's done


it's done


ok it's done



it's done

it's done



it's done



i will try to read... and give you feedback soon...

right now, i seem to have a little problem with

analyzeFilename...

the function display correctly the file name....
filename: B_L2_HLD_GRN_NOR_Run_Counter.txt

but when i display p, i get only ..
i don't understand... anyway i will check that

the modified file are available at:
http://www.laboiteaprog.com/led_display.c


Similar Threads:

1.Problem with read() function and Serial port reads.

Hi,
        Dose someone know whether it's possible to set up the read()
function to read from a serial port a specific number of bytes and ONLY
return after the specific number of bytes have been read? I've got some
code working fine reading bytes from the port but it will return after
it read everything that in the buffer and not the number of bytes I
wanted. e.g.

Transmitting device transmits 89 bytes
-> Read function called to read 89 bytes from port
-> Read returns with 30 bytes
-> then 45 bytes (Upon next call)
-> then 14 bytes (Upon next call).

The problem this is causing me is that I have to reassemble the original
message stream. Kinda annoying. Works fine under Win2K.

Thanks for any suggestions

Regards

Mark

-- 
mark

2.Serial port problems - mkdev serial crashes

I'm trying to get an application talking to the COM2 port on OSR5 but
I'm running into some problems. mkdev serial crashes whenever I select
COM2 from the list of COM ports.  The application is communicating
using a null modem cable. I'm able to log in via a terminal however
which suggests that the port is working.  The application that I'm
trying to use does not need to enabled logins.  I would like to set
baud rate of the port but since I cannot use mkdev serial then  I
cannot do that.

Is there a way to set the baud rate, parity and so on without using the
serial manager?  I keep getting a hardware framing error from the app -
I assumed that the COM 2 is set to the default 9600 baud rate and the
app is also using 9600,1 stop bit, and No parity. hardware/software
control is also FALSE.

3.Serial port programming C++ - detect serial ports on linux

4.Send traffic from one serial port out to another serial port

Hi,

We've got a system where we need to occasionally in effect link two
serial ports together on our system which is running linux.

Scenario

 (/dev/ttyS1)    <radio> --- rs232 -- [linux system] --- rs232 --
<terminal> (/dev/ttyS0)

Normally the terminal talks to the linux system which sends traffic if
needed to the radio. However for certain situations we need to make
sure any traffic on /dev/ttyS0 is sent straight out on /dev/ttyS1 and
vice-versa with no alterations etc.

On a stock distribution (debian) I can't see an easy way to accomplish
this short of using socat.

Anyone got any ideas?

5.serial port on v490 and Serial port on StorEdge 3510

Just wonder how to connect  V490's serial port to StorEdge 3510's
serial port?
as the serial port on v490 is a RJ45 connection. and the serial port
on 3510 is DB9.  How to connect this two together? What adapter and
cable should be used?

Thanks!

6. [PATCH 7/9] MN10300: Allocate serial port UART IDs for on-chip serial ports [try #6]

7. [PATCH 4/6] MN10300: Allocate serial port UART IDs for on-chip serial ports [try #4]

8. [PATCH 4/6] MN10300: Allocate serial port UART IDs for on-chip serial ports [try #5]



Return to unix

 

Who is online

Users browsing this forum: No registered users and 58 guest