Kinetis MicrocontrollersのトピックRe: UART Data coming in faster than I expect - K10

UART Data coming in faster than I expect - K10

ignisuti — Fri, 09 Mar 2012 11:20:46 GMT

I'm creating a UART driver and had intially disabled the FIFO buffers at first. I was only receiving the first of 5 bytes of data.

I eventually decided to try and enable the FIFO buffers and find that ALL of the expected 5 bytes are present during my first interrupt.

How can this be if I'm running my core clock at 100MHz? My MCU should be fast enough to get the interrupt after the first byte, pull the byte out of the buffer, increment the counter, and then go about it's business long before the 2nd byte arrives. Am I wrong here?

Note: I'm using UART 1.

Re: UART Data coming in faster than I expect - K10

ignisuti — Fri, 09 Mar 2012 12:14:58 GMT

Also... I'm using baud rate of 115200.

Re: UART Data coming in faster than I expect - K10

rhyttr — Fri, 09 Mar 2012 17:59:26 GMT

I had same problem before, cause i do something delay (eg. printf) in interrupt, so the next interrupt can not trigger

just remind you

Re: UART Data coming in faster than I expect - K10

mjbcswitzerland — Fri, 09 Mar 2012 20:12:11 GMT

Have you tried changing the receive watermak register setting to configure how many bytes need to be received before an interrupt is generated?

Regards

Mark

Re: UART Data coming in faster than I expect - K10

ignisuti — Fri, 09 Mar 2012 22:33:32 GMT

Hi guys. Thanks for the suggestions.

I removed all printf statements from my interrupt to test, but that did not correct things.

Also, I have my RXWATER set to 1.

What else can I check?

Re: UART Data coming in faster than I expect - K10

comsosysarch — Sat, 10 Mar 2012 00:20:24 GMT

Do you have any very large temprorary variables declared inside the ISR?

Re: UART Data coming in faster than I expect - K10

ignisuti — Sat, 10 Mar 2012 02:37:45 GMT

Nope...

Now, I did come across something that looks suspect. There are a lot of printf commands processing in the background which the debugger is using to show data in the CW 10.2 terminal.

Those printf commands seem to be super slow. I can watch the text being typed in the terminal.

Maybe that's blocking/delaying so much that my interrupt isn't triggering fast enough... Any thoughts on this theory?

Re: UART Data coming in faster than I expect - K10

TomE — Thu, 15 Mar 2012 10:56:12 GMT

> Any thoughts on this theory?

The first time I say a debugger connected through the debug port with a window showing the results of "printf()" I had no idea how it could be doing that, so I looked further.

For this system (a long time ago on an MPC860) the debugger setup "secretly" put a breakpoint on a function deep in the printing code. The embedded printing code printed to a named ram-based buffer then called the function with the breakpoint on it. The CPU *STOPPED*, the debugger special-cased that breakpoint to mean "don't tell the user, just read the buffer, show in the window and then continue".

All this debugger interaction took a long time - like 1/2 second or more. With the CPU halted for all that time it can't do anything "real time".

is your one doing the same thing? If you need any "real time response" you can't have any of this sort of debugging. it may be time to replace it with printing to a real buffered and interrupt driven serial port, to a network connection, a file system or to a HUGE RAM-based print buffer that you look at later.

Tom

Re: UART Data coming in faster than I expect - K10

ignisuti — Mon, 19 Mar 2012 19:53:56 GMT

TomE,

Yes, that sounds exactly like what's going on. I was seeing huge BLOCKING delays in the neighborhood of seconds.