UART read timeout

[roymessinger]

In searching for answer for this subject, I've found this link, and this is exactly what I'm looking for (reply of lpcware) but nevertheless, I still don't understand what are my options?

I'm sending chars through UART to an application. Whether it will get there, that is what I want to check. For example, if the comm. cable was disconnected right in the middle of the transport, obviously, I don't want the app or K64 (working with K64) to wait forever...

Any ideas on how to implement it?

I've read about PIT and LPTMR timers but I need them to work in parallel, and not as a delay, but rather after every char I receive, start the timer again and wait for the next char. If did not receive the 'closing char' and timeout finished - error.

But I'm pretty new with ARM, and I prefer not working with RTOS, or any other OS for this matter, so how do I make it work in parallel?

Any ready-made functions on the SDK2.0 for this matter?

[roymessinger]

Ok, Mark. Thank you very much.

a. What will the UART RX interrupt be in charge of? Where do I find info/example on UART RX interrupt?

b. Isn't the UART polling example in the SDK 2.0 has the UART RX interrupt embedded? Because when I click something in the computer via the terminal (in this example) I immediately see it in the terminal (like echo)...

b. In the sdk 2.0 there are 5 examples of UART. I've spent few hours but got lost regarding the different variations of UART, especially the interrupt versions. Can you explain when do I use each UART interrupt example?

I mean, 3 versions of interrupt exist. When do i use the ring buffer (rb)? What is the diff between uart_interrupt_transfer_frdm_k64 and uart_interrupt_frdm_k64?

Thanks.

[mjbcswitzerland]

Hi

1. UART Rx interrupt triggers when there is a character available in the input buffer (rx character reception).

2. Polling usually means that SW is spinning on the same flag that is used to trigger an interrupt but doesn't actually use an interrupt (essentially it is a blocking method). This technique is usually restricted to simple examples for students that don't yet understand interrupts or by tasks under pre-emptive operating systems but is generally also a very poor choice since it doesn't guarantee that no overruns can occur (and reception lost). Generally polling would never be used in real designs (interrupt or DMA driven is more suitable). Probably the example that you are referring to doesn't do anything else so will always react quickly; if you add other work it may stop working correctly.

3. I don't know the SDK examples - I use
http://www.utasker.com/docs/uTasker/uTaskerUART.PDF
which also allows complete simulation to avoid any misunderstanding and much faster learning and project development.
Ring buffers are basically used to allow interrupt driven reception to collect a number of characters (buffer reception) without the higher level application needing to read quickly to avoid input overrun.

If you need to base work on SDK 2.0 it may be better to post in the SDK forum which is specific to the library: https://community.nxp.com/community/kinetis/kinetis-software-development-kit

Regards

Mark

For quality K64 references see:
http://www.utasker.com/kinetis/FRDM-K64F.html
http://www.utasker.com/kinetis/TWR-K64F120M.html
http://www.utasker.com/kinetis/TEENSY_3.5.html

[mjbcswitzerland]

Hi

I don't really understand exactly what you want to do but I am quite sure that you just need two interrupts:
One timer interrupt and the UART Rx interrupt.

You start the HW timer (PIT etc.) and mark that you are waiting for either it or an Rx interrupt.

Your code can continue doing whatever it wants to do and the two interrupt handlers (whichever one arrives first) then conclude whether there was a timeout of whether there was reception before it occurred. If there is UART reception it can kill the HW timer that is operating or restart it ready for the next reception.

Although you don't want to use an OS, a simple OS will usually contain SW timers that do the same without needing to know interrupt details and so with little effort.

Regards

Mark