UART API Explanation & FiFo

RE: UART API Explanation & FiFo

venerley — Wed, 07 Feb 2018 14:32:23 GMT

Sadly, without more doco, I think the learning curve it too steep, I will waste hours frustratingly thrashing. I'll get some thing working on a per character basis using my own parser first. Then once I know what I am doing I can incorporate the nordic higher level functionality offered by either the UART Driver or nrf_cli_uart into later versions.

RE: UART API Explanation & FiFo

venerley — Wed, 07 Feb 2018 13:15:24 GMT

Thanks, that does sound useful. I think I have just found some example code too: /nordic/nRF5_SDK_13.0.0_04a0bfd/examples/peripheral/cli

RE: UART API Explanation & FiFo

jakub — Wed, 07 Feb 2018 13:06:39 GMT

I was hoping you can use CLI to meet this request:
" I know that my data stream starts with character Y and when good is of a certain length X and is terminated by <CR><LF>. Therefore I would simply like the UART (supporting code/Library) to accumulate into a buffer, once Y has arrived and to send me an event when I have X bytes at which point I can check for <CR><LF>"

You can define a command that starts with Y, and a callback that will be executed if one will call this command.

RE: UART API Explanation & FiFo

venerley — Wed, 07 Feb 2018 12:32:30 GMT

@jakub please tell what additional value I would gain using nrf_cli instead of “UART Driver”

RE: UART API Explanation & FiFo

venerley — Mon, 05 Feb 2018 09:01:59 GMT

been working on other parts of the project. Will get back to the UART this week.

RE: UART API Explanation & FiFo

venerley — Mon, 05 Feb 2018 08:59:29 GMT

thanks for putting this on my radar.

RE: UART API Explanation & FiFo

ketil — Mon, 05 Feb 2018 08:01:34 GMT

Hi again, and thank you for the feedback. I will pass it on to the relevant parties. Did you manage to get the UART Driver working for your application?

RE: UART API Explanation & FiFo

jakub — Fri, 02 Feb 2018 22:15:31 GMT

Maybe you can try NRF_CLI module? Looks will fit your needs.

RE: UART API Explanation & FiFo

venerley — Fri, 02 Feb 2018 21:42:48 GMT

Hi Ketil I hope the new website permits me enough characters to say everything! I don’t believe a new UART API is required, just the existing one be made more understandable (faster) through some additional documentation.

My objective is to create a parser which reads a UART stream from a sensor. The parser determines the validity level and if the threshold is reached the stream is parsed, the required data extracted and transmitted via BLE. I will be using a proprietary profile.

I know that my data stream starts with character Y and when good is of a certain length X and is terminated by <CR><LF>. Therefore I would simply like the UART (supporting code/Library) to accumulate into a buffer, once Y has arrived and to send me an event when I have X bytes at which point I can check for <CR><LF>

Alternatively I would like to be the UART (Library) to accumulate into a buffer and send me an event when <LF> has arrived at which point I can check the correct amount of data that has arrived.

The application only needs to act when the required data has arrived. Looking at the example code the programming module appears to require that the application look at every character that arrives. The examples "uart" and "ble_app_uart" both process a character at a time (this is the impression given), which conflicts with the requirement for a large FIFO buffers.

Looking at the “UART module” documentation it would appear to work on a byte at a time. After further research I discovered the “UART Driver” which appears a better match for my programming module described above, in that the App can be notified when the require amount of data has been received. To my knowledge there is no example code for the “UART Driver”.

I could have saved lots time if both these; “UART module” & “UART Driver” had been presented in a higher level document together with matching application scenarios for which they could provide a solution.

Apple produces documentation, where a hierarchical approach is taken starting with application scenarios and then decomposing down to API’s. It's about ensuring the developer makes best use of their time enabling them to identifying which API's are going to contribute to their solution and this is efficiently achieved by providing context.

Hope this helps - now to try out the "UART Driver"!!

RE: UART API Explanation & FiFo

ketil — Wed, 31 Jan 2018 12:04:32 GMT

It would be very much appreciated if you could post some examples of what your ideal UART API would look like. I will pass this information on to the developers.

RE: UART API Explanation & FiFo

venerley — Wed, 31 Jan 2018 07:36:58 GMT

Hi Matt and thanks for your comments, no doubt I will end up following your suggestion. I suspect its a company cultural thing. The Nordic folks already understand how this stuff works inside and out consequently the pain of getting up to speed has passed for them, or is short lived as they can talk the creator of the API directly!

The UART functionality seems comprehensive and I would like to architect my code efficiently, from the top down rather than hacking from the bottom up and getting very frustrated in the process. I need to create a parser on the data from the UART and I would like todo this optimally in terms of memory & cpu.

It looks like there is no alternative; I will have to start the process of inefficient hacking and then start posting questions.

RE: UART API Explanation & FiFo

Matt — Wed, 31 Jan 2018 02:10:50 GMT

People will simply ignore your rant. Why don't you table your "higher" (<--- whatever that means) level API here so that the good Nordic folks have something concrete to chew on?