termios problem

[Angelo Fraietta]

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
>>problem.
>>
>>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:
>>
>>>Hello Angelo,
>>>Thursday, August 08, 2002, 2:23:30 AM, you wrote:
>>>AF> Did you ever find the problem to this? I am having a similar
>>>problem now
>>>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:
>>>>>HARDWARE: MC68MH360
>>>>>RTEMS: RTEMS-4.5.0
>>>>>BSP: m68k
>>>>>
>>>My test is not correct. It calls printf function from timer's
>>>service
>>>routine. It is wrong. Because timer's routine is called from
>>>interrupt
>>>handler. If you need to output some debug info from isr, you must
>>>use
>>>printk. I have no problems with RTEMS-4.5.0 on MC68MH360, now. Our
>>>system based on RTEMS works about four months uninterruptedly. But
>>>we
>>>use RTEMS on pc386 for test's purpose only.
>>>
>>--
>>Angelo Fraietta
>>
>>PO Box 859
>>Hamilton NSW 2303
>>
>>Home Page
>>
>>http://www.users.bigpond.com/angelo_f/
>>
>>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)
>>
>

-- 
Angelo Fraietta

PO Box 859
Hamilton NSW 2303

Home Page


http://www.users.bigpond.com/angelo_f/

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...
URL: <http://lists.rtems.org/pipermail/users/attachments/20020811/ef6b7f13/attachment.html>