Serial interrupt losing character (overrun error) due to MQX bookkeeping taking too long? sometime the serial ISR spent up to 6.8ms to complete. Any one has exeperienced this issue?

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Serial interrupt losing character (overrun error) due to MQX bookkeeping taking too long? sometime the serial ISR spent up to 6.8ms to complete. Any one has exeperienced this issue?

1,121件の閲覧回数
precisionman
Contributor I

is there _int_disable() somewhere in MQX that preempting the serial ISR to complete in timely manner?

0 件の賞賛
返信
2 返答(返信)

963件の閲覧回数
precisionman
Contributor I

Sorry, let me correct the problem:

I have imcoming serial characters at 9600baud, so I expect that there is roughly one interrupt  per millisecond. However, ocasionally I dont get an interrupt until 6.8ms later.

Other higher interrupts realistically cannot spend that much time in its ISR and not letting serial ISR to run. I did not see any _int_disable() _int_enable() loop that could use up that much time. I am stumped.

please help.


0 件の賞賛
返信

963件の閲覧回数
Cdn_aye
Senior Contributor I

Tim, there are a lot of discussions on this in the forum; I posted a similar problem. David Seymour  has replied to my question and this could help you. He also posted his code.

The problem as you have noted is that you may miss characters, one thing to do is do and fstatus check to see if a character is present, this is non blocking. Then do a _time_delay_ticks of n ticks and a read the stream with a non blocking read. This is a bit lame because it is non deterministic. Or if you want the irq system, trigger a message on the first irq to send a message to a task that does the read after doing a system wait. The disadvantage is you need to assume how long the stream is, which is related to how long to delay for. This method is really hit or miss and non deterministic which is a problem for a real time system. We are considering RS-485 to solve the problem.

Regards

Robert Lewis

0 件の賞賛
返信