Console problem update
Etienne Fortin
etienne.fortin at sensio.tv
Fri Nov 5 15:01:23 UTC 2004
Hmmmm, quite interesting... I assumed that by default no flow control
was used... The problem is I put a breakpoint in termios.c where the
XON/XOFF characters should be sent and the breakpoint is never reached.
I'll clear c_iflag and test.
Thanks a lot,
Etienne
-----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
More information about the users
mailing list