app_uart_get() and app_uart_put()

Hi,

I want to use the functions app_uart_get() and app_uart_put() to communicate between the computer and NRF52840.

But when I type a string on the computer, the app_uart_get() function doesn't seem to receive it.

I'm using Segger Embedded Studio, the function app_uart_PUT()  is the same. What should I do?

Parents
  • Hello,

    But when I type a string on the computer

    Which program are you using for this?
    Are you seeing any output from the nRF in your serial terminal at all?

    I'm using Segger Embedded Studio, the function app_uart_PUT()  is the same. What should I do?

    Please show examples of how you have used these functions in your code, if possible. You can use the insert -> Code option here on DevZone when sharing code.

    Best regards,
    Karl

  • Thanks for your response, Karl.

    I hid some of the code that wasn't important. It goes like this:

    #include <stdbool.h>
    #include <stdint.h>
    #include <stdio.h>
    #include <stdlib.h>
    
    #include "acc_integration.h"
    
    #include "acc_hal_definitions.h"
    #include "acc_hal_integration.h"
    #include "acc_rss.h"
    #include "acc_service.h"
    #include "acc_service_envelope.h"
    #include "acc_version.h"
    
    #include "sdk_config.h"
    #include "nrf_delay.h"
    #include "nrf_uart.h"
    #include "app_error.h"
    #include "nrf.h"
    #include "bsp.h"
    #include "nrf_uarte.h"
    #include "nrf_gpio.h"
    #include "nrf_drv_gpiote.h"
    #include "app_uart.h"
    #include "board_xm122.h"
    
    #define APP_UART_ENABLED 1
    #define APP_FIFO_ENABLED 1
    #define APP_UART_DRIVER_INSTANCE 0
    #define  UART_TX_BUF_SIZE 256
    #define  UART_RX_BUF_SIZE 256
    
    
    void uart_event_handler(app_uart_evt_t * p_event)
        	{
        		uint8_t c;
        		if(p_event->evt_type==APP_UART_COMMUNICATION_ERROR)
        			{
            				APP_ERROR_HANDLER(p_event->data.error_communication);
        			}
        		else if (p_event->data.error_code)
        			{
            				APP_ERROR_HANDLER(p_event->data.error_code);
        			}
    		else if (p_event->evt_type==APP_UART_DATA_READY)
        			{
    				app_uart_get(&c);
            				printf("the char received over uart is: %c\n",c);
        			}
        		else if (p_event->evt_type==APP_UART_TX_EMPTY)
        			{
            				printf("data is transmitted");
        			}
    	}
    
    void uart_config(void)
    	{
        		uint32_t err_code;
        		const app_uart_comm_params_t comm_params =
        			{
            				RX_PIN_NUMBER,
            				TX_PIN_NUMBER,
            				RTS_PIN_NUMBER,
            				CTS_PIN_NUMBER,
            				APP_UART_FLOW_CONTROL_DISABLED,
            				false,
            				NRF_UARTE_BAUDRATE_115200
        			};
    
    
    APP_UART_FIFO_INIT(&comm_params,UART_RX_BUF_SIZE,UART_TX_BUF_SIZE,uart_event_handler,APP_IRQ_PRIORITY_LOW,err_code);
    APP_ERROR_CHECK(err_code);
    
    	}
    
    int acconeer_main(int argc, char *argv[]);
    int acconeer_main(int argc, char *argv[])
    	{
    	
    		uart_config();
    
            		while(1)
    			{
    			}
    
    
    	}
    

    When I downloaded the program into the chip, the computer's serial tool showed an error:

    Then I tried to input some characters, such as "111", "1223", etc. in the serial port tool of the computer terminal, but it didn't work.

    What should I do, please?

  • Hello Jimmy,

    Thank you for your patience with this. The summer holiday season has begun here in Norway, and so the forum is operating at reduced capacity.

    Jimmyh said:
    My ultimate goal is to do RS485 communication. I heard that RS485 communication is based on serial communication. So I want to implement serial communication first.

    Please keep in mind that we do not have any supported drivers for this available, so you will have to implement a driver for this yourself. I unfortunately do not have any knowledge working with RS485 personally, so I am not aware of any requirements or modifications you will need to do in order for this to work.

    Jimmyh said:
    I would like to share my sdK.config.h with you. But it looks a bit wordy.I hope it's easy for you to read.

    Thanks, no problem - the trick is to read only the relevant parts :) 
    I notice that you have both GPIOTE_ENABLED and NRFX_GPIOTE_ENABLED defined in your sdk_config.h file. You should make sure to remove the legacy GPIOTE_ENABLED define from your sdk_config.h since this will cause apply_old_config to overwrite your NRFX_* configurations. This is true for all the peripherals and legacy *_ENABLED defines in the sdk_config.h file.

    The error message you got earlier indicates that flow control is used, but it seems to me like it should not be used in your UART configuration.
    Are you using the GPIOTE elsewhere in your program? Did you have a look through the example code that I linked, to see if there are any discrepancies between the FIFO UART usage there, and yours?

    Best regards,
    Karl

  • Hi Karl,

    I think I know what the problem is.

    Are you using the GPIOTE elsewhere in your program?

    Actually, I don't know. There are a lot of Settings in this project that I can't understand. But that's okay. I'll just do what I have to do.

    Did you have a look through the example code that I linked, to see if there are any discrepancies between the FIFO UART usage there, and yours?

    Of course, that's what the tutorial video is all about. I didn't quite understand some of it, but I did exactly what they did.

    I found the problem by doing the following:

    I noticed that in the sample project I used, there was some initialization code in front of the main function that I had overlooked. When I commented them all out, THE NRF52840 and the computer could communicate back and forth normally. I thought there was some kind of code conflict. So I started commenting them out, one by one, to find conflicting code.

    Finally, I found that communication became normal when I commented out the function NRF_LOG_DEFAULT_BACKENDS_INIT().

    I don't know why. But when I comment it out, I won't be able to use printf () anymore.

    Do you know why these two pieces of code conflict? And is it possible to use printf as well?

    Best regards,

    Jimmy

  • Hello again, Jimmy

    Thank you for your patience with this. The summer holiday season has begun here in Norway, and so the DevZone forum is operating at reduced capacity for the next couple of weeks.

    Jimmyh said:

    Finally, I found that communication became normal when I commented out the function NRF_LOG_DEFAULT_BACKENDS_INIT().

    I don't know why. But when I comment it out, I won't be able to use printf () anymore.

    Do you know why these two pieces of code conflict? And is it possible to use printf as well?

    Well done on the debugging of this!
    I took another look in your sdk_config.h file, and it seems that you have enabled both NRF_LOG_BACKEND_UART_ENABLED and NRF_LOG_BACKEND_RTT_ENABLED, which is likely causing troubles, since you are attempting to use the UART for both logging and app_uart.
    My recommendation here would be to set NRF_LOG_BACKEND_UART_ENABLED 0, and leave NRF_LOG_BACKEND_RTT_ENABLED 1, so that you can see your NRF_LOG_* and prinft() statements in your RTT terminal(either the standalone Segger RTT Viewer desktop application or the SES Debug terminal).

    Jimmyh said:
    There are a lot of Settings in this project that I can't understand. But that's okay.
    Jimmyh said:
    that's what the tutorial video is all about. I didn't quite understand some of it,

    Please do not hesitate to ask if there is anything unclear or that you do not understand - either here, or you could open another ticket if the issue diverges from your original issue - we're happy to help!

    Best regards,
    Karl

  • Hi Karl,

    There is another problem that bothers me about serial communication.

    In the example, app_uart_get () and app_uart_put () both transfer data as a single byte. Every time a byte such as an "s" is received by NRF52840, an interrupt is generated.

    But sometimes the DATA the PC sends is not just a byte, maybe a string of characters like "start".

    I have an if statement in my code to determine if the received string is needed. So my problem is how to combine the bytes received by app_uart_get () into a character array.

    I tried putting each byte received into a predefined character array in the interrupt of the app_uart_put () function. One problem with this is that I don't know if the data for the RX pin has been transferred, i.e. there is no flag to indicate when there is no data transfer for the RX pin. I don't know when to stop assigning to that predefined character array. Because if I don't stop, every time I receive the data, it's going to be in the same array. But I want to separate them one at a time.

    If the description of my problem is not clear enough, please do not hesitate to point out my shortcomings.Thanks.

    Jimmy

  • Hello again, Jimmy

    Jimmyh said:
    There is another problem that bothers me about serial communication.

    Does this mean that you previous issue has been resolved, and that you are now able to communicate through UART-BLE->BLE-UART back and forth between your devices as expected?

    Jimmyh said:
    But sometimes the DATA the PC sends is not just a byte, maybe a string of characters like "start".

    There are certain byte values of the ASCII table that do not correspond to alphabetical characters directly, but instead corresponds to control characters / commands - please see the lower byte values.
    You Serial Terminal on your PC might be sending these control characters 'behind the scenes', or for example at the end of a string to denote the end of the sending.

    Jimmyh said:
    I don't know when to stop assigning to that predefined character array. Because if I don't stop, every time I receive the data, it's going to be in the same array. But I want to separate them one at a time.

    You could use a special character to terminate your string - i.e to indicate the end of the string, so that your device will shift to another buffer. C strings are terminated by the null character.
    You can see that the unmodified application already does a similar thing by checking for the control characters "\n" or "\r" to see if the whole sending is received over UART before it starts sending it over BLE.

    Best regards,
    Karl

Reply Children
No Data
Related