This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Thread messages problem.
- To: "Jonathan Larmour" <jlarmour at redhat dot com>
- Subject: RE: [ECOS] Thread messages problem.
- From: <felixwong at i-technologies dot cc>
- Date: Wed, 31 Oct 2001 14:41:38 +0800
- Cc: "Ecos-Discuss" <ecos-discuss at sources dot redhat dot com>
My problem is quite strange. There is no $T thread messages if I display nothing at all to
the EB40 board /dev/ser0. And when I using single step in debugging, the program run
as it is expected. All debug messages display fine, except the full line of message will display
after I single stepped 2 or 3 lines. This may due to the reason that characters in the UART
transmission queue are pending for interrupts to sent.
Sometimes the $T message appear after I step through a single diag_printf or fprintf
(to /dev/ser1) function in my own program. The parameters passed to diag_printf are all
valid, they are consistent when sometimes they can be printed.
The most probable case is the interrupt stack. As I didn't use or write any interrupt related
code yet, so I am write to ask if anybody else met the similar problem when dumping many
diag_printf info on the terminal.
My case involves 2 file objects open/access at the same time.
Here is the sample code (modified from hello.c) that can duplicate my symptom.
"hello1.c" = source code.
"ser0.log" = /dev/ser0 terminal capture.
"ser1.log" = /dev/ser1 terminal capture.
Note that the thread message problem appear may not appear in SOME of the runs.
Each run I (1) disconnect (2) reset EB40 (3) run.
When you modified the "hello1.c" that print messages with display to "ser0" only, and then
with display to "ser1" only, the thread message didn't appear.
Anything wrong with the program?
FW.
hello1.c
ser0.log
ser1.log