Console problem update
Thomas Doerfler
Thomas.Doerfler at imd-systems.de
Fri Nov 5 16:11:54 UTC 2004
Etienne,
I would say Head>Tail is a legal situation, and only
one character is pending in the buffer.
But: rawInBufDropped is 773, meaning that some time
before you lost three quarter of a kilobyte of
data...
You really should increase your buffer size, what do
you think?
If you are using fread and friends, this part of
newlib will find, that it is talking to a tty, and
therefore line buffering is enabled. Please keep in
mind, that the "f*" layer of newlib knows nothing
about termios settings... So this layer will wait,
until a whole text line has been entered (terminated
with a \n" or the f* internal buffer is full. Only
then data will be given back to the calling
function. This is definitively not what you want.
By the way, the corresponding output functions might
also fill transmit data into an internal buffer
until an "\n" or a fflush call is detected.
So once again my hint: DO NOT USE THE "f*" I/O
functiosn for an interactive protocol
implementation.
wkr,
Thomas.
> Hi Thomas,
> I made sure that flow control wasn't used and surprise, it works some
> more! But not very much more... Still a LOT of problem. But the problem
> seems to have shifted to somewhere else.
>
> Informations:
>
> 1) I can't use fread (I know you told me to use read, but my last try
> gave me no difference so for now I'll keep it). It hang in the semaphore
> again. The best I can get is one character. BUT, if I use fgetc to get
> the characters one at a time and clearerr(sender) at each loop, I can
> easily get my 1024 bytes packets.
>
> 2) Take a look at the tty structure now.
>
> $14 = {forw = 0x0, back = 0x0, refcount = 3, major = 1, minor = 0, isem
> = 436273159, osem = 436273160, cbuf = 0x80d542a4 "", ccount = 0, cindex
> = 0, column = 0, read_start_column = 0, termios = {c_iflag = 8450,
> c_oflag = 4294967230, c_cflag = 2237, c_lflag = 32768, c_line = 0 '\0',
> c_cc =
> "\003\034\177\025\004\n\001\000\021\023\032\000\022\017\027\026\000\000"
> }, vtimeTicks = 100, rawInBuf = {theBuf = 0x80d543fc "", Head = 62, Tail
> = 61, Size = 128, Semaphore = 436273162}, rawInBufSemaphoreOptions = 0,
> rawInBufSemaphoreTimeout = 100, rawInBufSemaphoreFirstTimeout = 0,
> rawInBufDropped = 773, rawOutBuf = {theBuf = 0x80d543b0
> "ansfer...\r\n\r\nC\006C", '\006' <repeats 11 times>, "f.Size =
> 128\r\nPress a key to begin tr", Head = 27, Tail = 27, Size = 64,
> Semaphore = 436273161}, t_dqlen = 0, rawOutBufState = rob_idle, device =
> {firstOpen = 0x1792 <console_first_open>, lastClose = 0x17ee
> <console_last_close>, pollRead = 0, write = 0x16c8
> <console_interrupt_write>, setAttributes = 0x1718
> <console_set_attributes>, stopRemoteTx = 0x173a
> <console_stop_remote_tx>, startRemoteTx = 0x1766
> <console_start_remote_tx>, outputUsesInterrupts = 1}, flow_ctrl = 1,
> lowwater = 64, highwater = 96, rxTaskId = 0, txTaskId = 0, t_line = 0,
> t_sc = 0x0, tty_snd = {sw_pfn = 0, sw_arg = 0x0}, tty_rcv = {sw_pfn = 0,
> sw_arg = 0x0}, tty_rcvwakeup = 0}
>
> Head is bigger than Tail... Is it an indication of a buffer overrun of
> some sort?
>
> The rawInBufDropped seems quite high at 773. It means I lost 773
> characters along the way? Strange. And not very good.
>
>
>
>
>
>
>
>
> -----Message d'origine-----
> De : Thomas Doerfler [mailto:Thomas.Doerfler at imd-systems.de]
> Envoyé : 5 novembre, 2004 09:56
> À : Etienne Fortin; rtems-users at rtems.com
> Objet : RE : RE : RE : Console problem update
>
>
> Etienne,
>
> a baud rate difference of 2% is still tolerable, as
> fas as I know. And you would be well below.
>
> I just had another look into the data structure
> snapshot you sent this morning (last night...). To
> my suprise, the "flow_ctrl" fiels is non-zero. The
> value 512 means, that the "input is controlled with
> XON/XOFF protocol". Maybe you should try to clear
> the "IXON" and "IXOFF" flags in the c_iflag field of
> termios settings?
>
> wkr,
> Thomas.
>
>
> > Hi Thomas,
> > Yes, the buffer is empty. But, it shows that at least 1161 characters
> > were received. After that, termios thinks there's no more data
> > received or it lost sync or something else.
> >
> > I said before that my baudrate is really 9630 and not 9600. The
> > computer is 9600. Do you think that can be the problem?
> >
> > Etienne
> >
> >
> >
> > -----Message d'origine-----
> > De : Thomas Doerfler [mailto:Thomas.Doerfler at imd-systems.de]
> > Envoyé : 5 novembre, 2004 02:23
> > À : Etienne Fortin
> > Objet : RE : RE : Console problem update
> >
> >
> > Etienne,
> >
> > from the data you sent, the input and output buffer really is
> > "empty", (for rawInBuf and rawOutBuf, "Head" and "Tail" have the
> > same values) but I guess you already saw this.
> >
> > Which BSP are you using? Is it possible your console driver
> > interrupt gets stuck, when there is a receive and transmit
> > interrupt pending at the same time?
> >
> > wkr,
> > Thomas.
> >
> >
> > > Hi Thomas,
> > > Yes a VERY nasty problem... It must have something to do with my
> > > comprehension and the way I implemented the console driver... But, I
>
> > > was able to make a lot of other things work before (I mean, the
> > > balance of
> > > RTEMS) and I got nasty problem with RTEMS before. But that one is
> > > special. Its so stupid! And I hate to work with transfer protocol.
> You
> > > know you'll be able to make it work, you just don't know when...
> > >
> > > Anyway, here's the snapshot of the rtems_termios_tty structure when
> > > the semaphore get stuck.
> > >
> > > $2 = {forw = 0x0, back = 0x0, refcount = 3, major = 1, minor = 0,
> > > isem
> >
> > > = 436273159, osem = 436273160, cbuf = 0x80d542a4 "}", ccount = 0,
> > > cindex = 0, column = 0, read_start_column = 0, termios = {c_iflag =
> > > 9474, c_oflag = 4294967230, c_cflag = 2237, c_lflag = 32768, c_line
> =
> > > 0 '\0', c_cc =
> > >
> > "\003\034\177\025\004\n\001\000\021\023\032\000\022\017\027\026\000\00
> > 0"
> > > }, vtimeTicks = 100, rawInBuf = {theBuf = 0x80d53a98 "", Head =
> > > 1161, Tail = 1161, Size = 2048, Semaphore = 436273162},
> > > rawInBufSemaphoreOptions = 0, rawInBufSemaphoreTimeout = 100,
> > > rawInBufSemaphoreFirstTimeout = 0, rawInBufDropped = 0, rawOutBuf =
> > > {theBuf = 0x80d543b0 "ransfer...\r\n\r\nC\006C.\r\nrawInBuf.Size =
> > > 2048\r\nPress a key to begin t", Head = 17, Tail = 17, Size = 64,
> > > Semaphore = 436273161}, t_dqlen = 0, rawOutBufState = rob_idle,
> > > device
> > =
> > > {firstOpen = 0x17a2 <console_first_open>, lastClose = 0x17ea
> > > <console_last_close>, pollRead = 0, write = 0x16dc
> > > <console_interrupt_write>, setAttributes = 0x172c
> > > <console_set_attributes>, stopRemoteTx = 0x174e
> > > <console_stop_remote_tx>, startRemoteTx = 0x1778
> > > <console_start_remote_tx>, outputUsesInterrupts = 1}, flow_ctrl =
> > > 512, lowwater = 64, highwater = 96, rxTaskId = 0, txTaskId = 0,
> > > t_line = 0, t_sc = 0x0, tty_snd = {sw_pfn = 0, sw_arg = 0x0},
> > > tty_rcv = {sw_pfn =
> > 0,
> > > sw_arg = 0x0}, tty_rcvwakeup = 0}
> > >
> > > As you can see, I "hardwired" the rawInBuf to be 2048 characters in
> > > size. And surprisingly enough, the Head is at offset 1161. This mean
>
> > > that I received the first 130 bytes packet (init packet) and some
> part
> >
> > > of the first data packet. But for some reason, termios lost sync and
> > > lost all the next characters, stucking the semaphore and giving me
> > > headaches :)
> > >
> > > What do you think???
> > >
> > > And by the way, you can't imagine how glad I am to have help from
> > > all
> > > of you on RTEMS forum.
> > >
> > > Etienne Fortin
> > > Sensio
> > >
> > >
> > >
> > > -----Message d'origine-----
> > > De : Thomas Doerfler [mailto:Thomas.Doerfler at imd-systems.de]
> > > Envoyé : 4 novembre, 2004 16:09
> > > À : Etienne Fortin; rtems-users at rtems.com
> > > Cc : rtems-users at rtems.com
> > > Objet : RE : Console problem update
> > >
> > >
> > > Etienne,
> > >
> > > can you provide a snapshot of the termios data structures when your
> > > console input gets stuck? What values do the buffer pointers have
> > > for the raw input buffer?
> > >
> > > What baud rate are you using currently?
> > >
> > > What happens, if you write a simple application with two tasks, one
> > > sending a 1K buffer to the console, one receiving it, and putting
> > > the console into loopback mode (with a nice little wire between pin
> > > 2 and 3 of your serial connector)? Does it also hand in that case?
> > >
> > > You really seem to have a nasty problem there...
> > >
> > > I have been using termios code for machine interfaces back with
> > > RTEMS version 4.0.0, and I never had similar problems...
> > >
> > > wkr,
> > > Thomas.
> > >
> > >
> > > > I don'T know why I tought that even after releasing the sempahore,
>
> > > > I was still stuck in the idle thread. To the contrary! Forcing the
>
> > > > release of the semaphore make the task continue to execute code
> > > > and
> > I
> > > > eventually get out of the code with an error (that's ok since the
> > > > semaphore was forced to be released so no valid data is there
> > > > waiting)...
> > > >
> > > > The question now is why the code is not notified of new
> > > > characters.
> > > > Is
> > >
> > > > it possible that the termios code, being designed for "human"
> > > > interraction (at least I presume), can't cope with sustained
> > > > binary data transfer and so I lost data and eventually the
> > > > semaphore is struck waiting for characters that will never come?
> > > > Is it possible?
> > > >
> > > > Etienne Fortin
> > > > Sensio
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Message d'origine-----
> > > > De : Joel Sherrill <joel at OARcorp.com>
> > > > [mailto:joel.sherrill at OARcorp.com]
> > > >
> > > > Envoyé : 4 novembre, 2004 15:21
> > > > À : Etienne Fortin
> > > > Cc : rtems-users at rtems.com
> > > > Objet : Re: Console problem update
> > > >
> > > >
> > > > Etienne Fortin wrote:
> > > > > Hello all, its me again, the console guy :)
> > > > >
> > > > > Little update for the ones that have an interest, or wish to
> > > > > help
> > > > > me on that matter.
> > > >
> > > > Is your interrupt an RTEMS ISR or a raw one directly connected to
> > > > hardware? If you do not go through the RTEMS ISR wrapper, you
> will
> > > > NEVER schedule out of an interrupt.
> > > >
> > > > Also are you sure you are geting the serial port interrupts?
> > > >
> > > > > I tricked RTEMS to release the semaphore at each clock tick to
> > > > > make sure the semaphore was the problem. And surprise surprise!
> It
> >
> > > > > still hang in the idle thread!!!!!!!!!
> > > > >
> > > > > Theory: My task/scheduler/... config is fu***d up. Anyone here
> > > > > thinks it can be possible? For what I know of the problem so
> > > > > far, it
> > seems
> > > > > that as soon as the idle thread is entered, no other thread ever
> > > gets
> > > > > executed... Really seems a config problem to me...
> > > > >
> > > > > Idea someone?
> > > > >
> > > > > Etienne Fortin
> > > > > Sensio
> > > > >
> > > >
> > > >
> > > > --
> > > > Joel Sherrill, Ph.D. Director of Research &
> Development
> > > > joel at OARcorp.com On-Line Applications Research
> > > > Ask me about RTEMS: a free RTOS Huntsville AL 35805
> > > > Support Available (256) 722-9985
> > > >
> > > >
> > >
> > > --------------------------------------------
> > > IMD Ingenieurbuero fuer Microcomputertechnik
> > > Thomas Doerfler Herbststrasse 8
> > > D-82178 Puchheim Germany
> > > email: Thomas.Doerfler at imd-systems.de
> > > PGP public key available at: http://www.imd- systems.de/pgp_keys.htm
> > >
> > >
> >
> > --------------------------------------------
> > IMD Ingenieurbuero fuer Microcomputertechnik
> > Thomas Doerfler Herbststrasse 8
> > D-82178 Puchheim Germany
> > email: Thomas.Doerfler at imd-systems.de
> > PGP public key available at: http://www.imd- systems.de/pgp_keys.htm
> >
> >
>
> --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler Herbststrasse 8
> D-82178 Puchheim Germany
> email: Thomas.Doerfler at imd-systems.de
> PGP public key available at: http://www.imd- systems.de/pgp_keys.htm
>
>
--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
email: Thomas.Doerfler at imd-systems.de
PGP public key available at: http://www.imd-
systems.de/pgp_keys.htm
More information about the users
mailing list