angelo_f at bigpond.com
Sun Aug 11 04:40:28 UTC 2002
I think the essence of the problem lies in the fact that failing UART is
not a 16550 while the one in the BSP is. It is not that big a drama for
me because the problem only occurs on the machine I am using as a
simulator and not my embedded target (it is a very old 386dx).
If I really wanted to, however, I could run a pseudo watchdog on the
task when it starts the transmit, and if it does not return, the
watchdog task could flush the buffer. Alternatively, there could be some
sort of mechanism in the driver that acertains how long it has been
waiting for the UART interrupt that notifies it that the Tx buffer is
empty. This, however, would probably mean more overhead for something
that would not normally occur.
Alternatively, there could be a different device driver for the PC386
BSP that could be defined in the rtems_driver_address_table
Device_drivers as a MACRO
I personally don't think is is worth worrying about too much and I am
happy to live with it.
Joel Sherrill wrote:
>Angelo Fraietta wrote:
>>I have found the problem.
>>The PC that I am using is a very old PC, which I think is not using a
>>16550 UART and probably not full duplex. Everything worked fine at
>>most times, however, if data was received at the same time, the Tx
>>seemed to get lost, and so the transmit function never returned.
>Is there a real way to fix this without kludging something or is this
>an ugly thing that must just be lived with. :(
>>I overcame this by setting the retry time-out in the application that
>>communicates with my RTEMS device to a slower speed. This overcame the
>>I want to say, however, the problem did not occur on my embedded
>>device (DIMMPC) because I think the UART is full duplex.
>>Andrew N. Maximov wrote:
>>>Thursday, August 08, 2002, 2:23:30 AM, you wrote:
>>>AF> Did you ever find the problem to this? I am having a similar
>>>AF> on the pc386
>>>>>There is some problems with termios. System hangs after I try
>>>>>to output to console more than 64 characters. My configuration:
>>>My test is not correct. It calls printf function from timer's
>>>routine. It is wrong. Because timer's routine is called from
>>>handler. If you need to output some debug info from isr, you must
>>>printk. I have no problems with RTEMS-4.5.0 on MC68MH360, now. Our
>>>system based on RTEMS works about four months uninterruptedly. But
>>>use RTEMS on pc386 for test's purpose only.
>>PO Box 859
>>Hamilton NSW 2303
>>There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
>>There are those who seek knowledge to be known by others - that is VANITY
>>There are those who seek knowledge in order to serve - that is LOVE
>> Bernard of Clairvaux (1090 - 1153)
PO Box 859
Hamilton NSW 2303
There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
Bernard of Clairvaux (1090 - 1153)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users