Hi,
Are the functions implemented in drv_uart and uart_app even related to each other? I noticed that uart_app implements only some simple functions. Can someone please explain to me the differences between these implementations? Can I freely call the functions from either of them? Are they any different from the blocking point of view?
-vala
App_uart or app_uart_fifo uses nrf_drv_uart. The FIFO (or buffer, not to be confused with the uart peripheral FIFO) in app_uart_fifo is implemented with the app_fifo module.
You should not used app_uart functions and nrf_drv_uart functions in the same project unless you know exactly what you are doing.
I am also very confused by these two implementations. I am trying to port an application using s110 6 with SDK 8 to the latest SoftDevice and SDK that can be supported by the nRF51822. Boy have there been changes!
In the original project there was only need for initialization, simple_uart_put, and an interrupt handler. The interrupt hander was defined in the arm_startup asm file. The original project used that interrupt handler in its main.c. Now it seems that the nrf_driver_uart uses that same damn interrupt, causing a conflict. I took an example thermometer from the latest version and am moving that to my health device implementation (a pulse ox). It has that nrf_driver_uart along for the ride. Can I just get rid of it and use the app_uart methods?
How does one come to terms with this confusion? The documentation is all over the place and is no help at all.
I changed the name of the interrupt handler that I used to something else since the NRF driver was using that name. In the s110 sdk 8 I guess the NRF driver did not use that name. But SDK 12.3.1 for s130 does. Wont be able to test my solution until I deploy it on a production device. But at least it builds.
The interrupt handler name should be UART0_IRQHandler() if the handler should be called when an interrupt is triggered. If this was the name of your handler and you changed it, the UART handling in your old application will/may not work anymore.
If I use that name the linker fails as the name is also defined in nrf_driver_uart.c here
#if UART0_ENABLED
void UART0_IRQHandler(void)
{
CODE_FOR_UARTE_INT
(
UART0_INSTANCE_INDEX,
uarte_irq_handler(NRF_UARTE0, &m_cb[UART0_INSTANCE_INDEX]);
)
CODE_FOR_UART
(
uart_irq_handler(NRF_UART0, &m_cb[UART0_INSTANCE_INDEX]);
)
}
#endif
How should I deal with that? Turn off UART0?
Do you need to use the UART driver for anything, or are you fine with how the UART implementation you already have works?
If it works, there is no need to change it. You can then disable/remove the UART driver from the project.
Then how do I initialize it? In the old 8.0.0 SDK with s110 v6 there was a simple_uart_init() and then it used simple_uart_put() and simple_art_get() and the UART0_IRQHandler which I found only defined in the asm file.
In the s130 SDK 12.3.1 I could not find a simple analog to this setup/initialization but the NRF driver came into play. I can't test anything I write yet since the UART is only used on the production device - that is how the nrf51822 gets pulse rate and SpO2 data from the sensor module.
Then how do I initialize it? In the old 8.0.0 SDK with s110 v6 there was a simple_uart_init() and then it used simple_uart_put() and simple_art_get() and the UART0_IRQHandler which I found only defined in the asm file.
In the s130 SDK 12.3.1 I could not find a simple analog to this setup/initialization but the NRF driver came into play. I can't test anything I write yet since the UART is only used on the production device - that is how the nrf51822 gets pulse rate and SpO2 data from the sensor module.
As far as I can see, the simple_uart implementation in SDK 7.x.0 and below does not use interrupts. It just uses blocking while-loops to wait for events. Are you sure that the UART implementation you use are unmodified from the SDK, and not something custom?
SDK v8.0.0 also does not include this simple_uart implementation, and this SDK version also did not support S110 v6.0.0, so there seems to have been done some migration in your project.
In theory, you could copy the simple_uart implementation from the old SDK and use it as-is, but I would recommend that you rather get familiar with app_uart(_fifo) and switch to this. It is shown in the UART Example how to setup and use this library.
I am well aware of the example. I ended up doing this in my init function
err_code = app_uart_init(&comm_params,
NULL,
UART0_IRQHandler_New,
APP_IRQ_PRIORITY_LOW);
where I used the modified name of the UART0_IRQHandler so building would succeed. What I don't know is if it works. I won't know that until I flash the production device versus the DK.
I know the UART0_IRQHandler works in the old code (it IS a poll as I get signaled then I have to do a simple_uart_get(&data) to get the data). The down side is that flash writes DONT work in the old version but they DO work in the new version.
Ok, I see what you are doing now. The handler you pass to app_uart_init is not an interrupt handler, it is an event handler, where you should handle events passed from the library to the application. An example event handler is shown in the UART example and on this page. The name of this handler can be whatever you want, as the library will call the function you pass to the init function.
Note that if you want to send more than one byte at a time, you need to use the app_uart_fifo implementation. Initialization should also be done through the macros APP_UART_INIT/APP_UART_FIFO_INIT to be safe.
Jorgen, that init function was taken from the UART example (that you referenced) earlier, as it was the closest mapping I could get to the original. In the UART example the event handler was for errors. But you are correct, it is an event handler as it was in the original 'simple_uart_* model.
I am bound to the original as the sensor MCU is pre-specified and out of my hands - I can't change it. As it is it appears to send only one byte at a time. What I am hoping is that my code using the latest version of SoftDevice that can be supported on the nRF51822 (which works on the DK) will work when I flash the nrf51822 sitting on the YJ-14001-NRF51822 board of this production device. The only difference is that on the DK I use a button push to simulate what the sensor will send me via UART.
I have made it simpler for myself by using just sd_* calls for all BTLE functionality (including bonding) and flash writes. Everything works using s110 on the production device EXCEPT for the sd_flash_write(). Using s130 in the DK the flash write also works.
The other fear I have is that the old code uses a p10001 board and the DK uses a p10028. I am hoping the p10028 code will be compatible with the YJ-14001-NRF51822, at least on the level we are using it (the UART PINS appear to be the same....).
You can check the compatibility matrices for relations between Development HW and chip revision, chip revision and SDKs and SoftDevices support, and you can compare the chip on your production board towards nRF51822 IC revisions and variants.