Sending via Uart

RE: Sending via Uart

Nelson — Mon, 12 Jan 2015 11:42:37 GMT

May I know how do you put second parameter into the function of app_uart_init? Because there using "NULL" for non-FIFO situation.

RE: Sending via Uart

kagislason — Tue, 18 Nov 2014 10:47:16 GMT

The app_uart_fifo library solved this issue, thanks for the assistance!

RE: Sending via Uart

Asbjørn — Fri, 14 Nov 2014 15:09:38 GMT

Yes, I think I may have made it even more confusing with the 6 byte buffer comment. That's a receiver buffer. If you switch the uart driver you use there's a different uart driver implementation with built in fifo. So if you go in the source folder and app_common and use the driver name "app_uart_fifo.c" you'll find the exact same function calls as you are using, but implemented with fifo to buffer both tx and rx UART. Then you should be able to write to the uart as you are trying to do.

RE: Sending via Uart

kagislason — Thu, 13 Nov 2014 11:54:54 GMT

The board goes to the NO_MEM error immediately after sending the first byte, because the UART_READY event has not been enabled yet. The app_uart_put(uint8_t byte); function writes the byte to the m_tx_byte buffer but there is no space for the next byte as the board has not finished writing the previous byte. I can't really see how the buffering works here and it seems like the code in the app_uart library is not working up to specification ? I understand that I am trying to push bytes to the app_uart_put function too fast but if the board has a 6 byte buffer my problem should not appear when trying to send byte number 2 ? Thanks for taking the time to follow this through, I appreciated it!

RE: Sending via Uart

kagislason — Thu, 13 Nov 2014 11:50:13 GMT

Using nRFgo Studio I can program the N5 chip and currently running s110 v7 there.

I am all up for rewriting the Uart example, and I only used that for base in my project. What I don't like is changing the SDK as it might give problems later in the production if/when we decide to use a newer SDK from Nordic and then changes can easily be forgotten.

In the current scenario I am using the app_uart library from Nordic which is giving me this headache, I could ofcourse just write a wrapper send function which solves this buffer issue but I feel like there should be a simpler solution. With the logical analyser I tested the sending part again (I tested with buffer sizes in the app_uart init function both 2 and 6 bytes for rx/tx). The CTS line is held low the entire time so there should be no restriction in sending characters from the PC.

RE: Sending via Uart

Asbjørn — Wed, 12 Nov 2014 13:33:06 GMT

I do see the concern that you don't want to modify the UART example, but here you are writing faster than you are sending and you have to take care not to overflow the TX buffer. So the wait operation should improve the situation as you see. How are the flow control pins behaving during this? Are you getting feedback indicating that the UART is ready to send more?

SIDENOTE: I might have side tracked you since you have problems with the TX buffer and I was talking about the receiver buffer. Just to clarify I would like to follow up anyways. If you have nRF51822 with the G0 version mentioned above I would recommend you to try out your setup on that one to see if the extra buffer size would solve your issue.

I'm not sure which version of the nRF51422 that Dynastream are using/have used on their N5 modules, but it could potentially be an elder version of this module you have with a first revision of the nRF51422. This could be easily identified by whether or not you are able to program softdevice on the module or not. The first version of the nRF51422 had the ANT softdevice/stack hardcoded onto ti. If you can program a different softdevice to the module, you have revision 2 of the chip and the additional UART buffer.

RE: Sending via Uart

kagislason — Tue, 11 Nov 2014 15:18:26 GMT

The Uart will be more than sufficient for the amount of data that needs to be transferred between the devices. There was a decision in the project to use Uart for the communication which cannot be changed at this point. The communication works as long as I take care not to send the data too fast but but I feel that is a bad hack and could be optimized more.

RE: Sending via Uart

Nguyen Hoan Hoang — Tue, 11 Nov 2014 15:12:17 GMT

The LPC1769 can go up to 921600. Since you plan to put on the same PCB, why not try with SPI or I2C. It can be faster than UART.

RE: Sending via Uart

kagislason — Tue, 11 Nov 2014 14:58:53 GMT

Not the fastest but currently using 460800

RE: Sending via Uart

kagislason — Tue, 11 Nov 2014 14:45:27 GMT

Currently using the N5 chip from Dynastream which is based on the nRF51422. I did not find which revision they are basing their chip on but I did also try the same with other Nordic evaluation kits (using the corresponding libraries of course) with no luck. I have a few evaluation kits from Nordic (both 51822 and 51422, e.g. PCA10001, PCA10003 and more) and also the N5 chip from Dynastream (M8CB based on nRF51422) which I could also test this on if necessary.

The end product will be the N5 chip communicating over UART to a LPC1769 from NXP. Using the LPC as the main processing unit and the N5 chip for BLE communication in the platform.

To simplify things I am currently testing this against my PC using a UB232R serial module and a logical analyzer.

RE: Sending via Uart

Nguyen Hoan Hoang — Tue, 11 Nov 2014 14:40:36 GMT

Have you tried to set the fastest baud rate ? The default of the library is pretty slow.

RE: Sending via Uart

Asbjørn — Tue, 11 Nov 2014 14:27:16 GMT

Which version of the nRF51822 are you using. There was an increase in the UART buffers between revision 1 and revision 2 of the chip from 2 byte to 6 bytes.

nRF51822 QFAAC0 is first revision. nRF51822 QFAAG0 is second revision.

You have at least two nRF51822 or are you planning on having two different UART chips talking to each other? What's the setup you are actually looking for?

RE: Sending via Uart

kagislason — Tue, 11 Nov 2014 11:28:16 GMT

Unfortunately this did not help me. The setup of the Uart and the sending of characters is the same I have tried, however to simplify things I am sending the characters straight through the app_uart_put function without any app schedulers. I need to be able to send the data very fast as this will serve as a inter PCB communication channel.

RE: Sending via Uart

kagislason — Tue, 11 Nov 2014 11:12:15 GMT

Hi, in the end these chips will be on the same PCB. Currently testing this with a UB232R module to the PC, I am also monitoring the traffic using a logical analyser and the data output is as expected.

My headache comes from the way the board sends the data, it seems like the channel is clogging up when trying to send the characters too fast. I have been able to temporarily fix this issue by putting a 20us delay between sending of each character or simply spinning an empty loop until the UART is ready again.

RE: Sending via Uart

Blake — Mon, 10 Nov 2014 21:59:48 GMT

Assuming you are using USB to connect via UART, I suggest plugging into a PC and monitoring the UART output. Unix screen (aperiodic.net/.../man:window_types can do this.

Once you are sure the data being output is in the format you expect, you can integrate.

RE: Sending via Uart

Nguyen Hoan Hoang — Mon, 10 Nov 2014 21:37:13 GMT

There is another UART example from this blog you may try embeddedsoftdev.blogspot.ca/.../ehal-nrf51.html