UART Stopping

RE: UART Stopping

RK — Fri, 11 Dec 2015 16:45:56 GMT

I think you ought to be able to just hammer the thing into the ground constantly without any kind of wait and it shouldn't hang on you. So if it does hang, it sounds like a bug to me and it shouldn't do it.

'wait after fail' is how the API was designed to be used and is much lower power and generally less brutal way to do it so you should do that anyway as you are doing.

So my slightly unhelpful take on it is that if it hangs when you just call it repeatedly without waits thats buggy, however if it works when used in a more anticipated way using waits when the uart reports it's not yet ready before trying again, that's how it was designed to work and you should be pretty confident using it that way; as well as it just being a good power-saving practice.

RE: UART Stopping

Mark J — Fri, 11 Dec 2015 16:34:49 GMT

Sorry - misread on my part. Understand the differences. We have also added the sd_app_evt_wait() after the while condition and this is what made the difference for us. So, I guess what I am left understanding is that without the sd_app_evt_wait(), we were "banging" the uart and that caused our issue and is expected behaviour.

RE: UART Stopping

RK — Fri, 11 Dec 2015 16:23:49 GMT

well actually no - that's not what the code I posted does - mine does not bang on the uart, If the call returns NRF_SUCCESS then it processes, else it does an app event wait and only then tries again. So it loops, throttled by events, until it gets a character.

That's different from the other two possibilities your original message allows (since you didn't post any code) which are

just call app_uart_get() in a loop constantly until it returns NRF_SUCCESS. That's what I describe as 'banging' the uart.
call app_uart_get() and then always follow it with sd_app_evt_wait() whatever it returns, which is what your original message hints you're actually doing.

1 is pretty brual, should work, but not great practice. 2. has more waits than needed but will return shortly after a new input. What I posted attempts to follow the documentation of the function and wait only when necessary.

RE: UART Stopping

Mark J — Fri, 11 Dec 2015 16:11:54 GMT

The while loop enclosing the app_uart_get() call ... just as you have shown it and just as it is shown in countless examples. "if the call returns something other than success you bang on it again and try to get it again in tight loop?" ... isn't that what "while( app_uart_get( .. ) != NRF_SUCCESS )" does?

RE: UART Stopping

RK — Fri, 11 Dec 2015 07:05:15 GMT

"staying in the while loop"

What while loop? There's a whole range of ways you could have written it. Are you saying you're just banging repeatedly on the uart trying to get a character, if the call returns something other than success you bang on it again and try to get it again in tight loop?

RE: UART Stopping

Mark J — Fri, 11 Dec 2015 06:19:53 GMT

Thank you RK for replying.

app_uart_get() is just reading byte for byte as all examples show. In this specific case, it appeared to be returning with a result other than NRF_SUCCESS and staying in the while loop (before we added sd_app_evt_wait() as shown in examples and in your reply above). This has to be the case as sd_app_evt_wait() calls have fixed our issue. What we are really trying to understand is why the addition of sd_app_evt_wait() makes a difference. This is important to us so that we can understand if our issue has been resolved. To clarify, after adding the sd_app_evt_wait() call - the UART no longer seems to stop. We would just like to understand why or how the addition of this call makes a difference to feel comfortable that the issue is completely resolved.

RE: UART Stopping

RK — Thu, 10 Dec 2015 01:30:46 GMT

What is app_uart_get() doing before you add the app event waits? Is it returning an error code or not returning at all or what? The documentation for that function tells you that if there's no character to read then it returns an error code and will generate an event when a byte comes in. The event coming in would trigger sd_app_evt_wait() to return so I can see how putting them in might be working, however what you should be doing is reading the character, if one is returned, processing it, if it's an error returned, then use sd_app_event_wait()

while( app_uart_get( .. ) != NRF_SUCCESS )
    sd_app_evt_wait()
// process your character here

more like that