How to send sensor data using AT commands to a device using Uart in segger embedded studio

[Rajbir Singh]

Hi, I am new to NRF and segger embedded studio.

So I want to send temperature sensor data connected with nrf52840 DK to the Murata1_SC  device using UART.

The data will be sent using AT Commands.

So how to send AT Commands in Segger embedded studio.

Thank you for the help in advance.

[Rajbir Singh]

#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include "app_uart.h"
#include "app_error.h"
#include "nrf_delay.h"
#include "nrf.h"
#include "bsp.h"
#include "nrf_uart.h"

#define UART_TX_BUFF_SIZE 128
#define UART_RX_BUFF_SIZE 128

#define UART_HWFC APP_UART_FLOW_CONTROL_DISABLED

void uart_err_handle(app_uart_evt_type_t * p)
{
  

}

int main(void)
{
  uint32_t err_code;

  bsp_board_init(BSP_INIT_LEDS);
  
  const app_uart_comm_params_t com_params = 
   {
    RX_PIN_NUMBER,
    TX_PIN_NUMBER,
    RTS_PIN_NUMBER,
    CTS_PIN_NUMBER,
    UART_HWFC,
    false,
    NRF_UART_BAUDRATE_115200
    };

  APP_UART_FIFO_INIT(&com_params, UART_RX_BUFF_SIZE, UART_TX_BUFF_SIZE, uart_err_handle, APP_IRQ_PRIORITY_LOWEST, err_code);

  APP_ERROR_CHECK(err_code);
  
  printf("Hello PC from Nordic Device!!!\r\n");
  
  while(true)
  {
    uint8_t cr;

    while(app_uart_get(&cr) != NRF_SUCCESS);//wait here for the character from pc
    if(cr == 'o')
    {
      bsp_board_leds_on();
      printf("Leds are ON\r\n");
    }
    if(cr == 'f')
    {
      bsp_board_leds_off();
      printf("Leds are OFF\r\n");
    }
  }
}

[Rajbir Singh]

I have seen this code

uart_putstring((uint8_t*)"AT\r");
nrf_delay_ms(2000);
uart_putstring((uint8_t*)"AT+CMGF=1\r");
       nrf_delay_ms(2000);
uart_putstring((uint8_t*)"AT+CMGS=\"8919242248\"\r");
   nrf_delay_ms(2000);
   uart_putstring((uint8_t*)"test\r");
          nrf_delay_ms(2000);
          app_uart_put((char)0x1A);   ///used (uint8_t) 26 also but no response..
                 nrf_delay_ms(1000);

in this link, where someone is saying to wait for the response, so how can i do that.

[awneil]

that is really bad code - it is making the classic mistake of using blind delays.

[Rajbir Singh]

yes, he has put a delay after every command.

So could you please help with this.

I just want a basic format to send the commands.

Here is the code I have created till now

#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include "app_uart.h"
#include "app_error.h"
#include "nrf_delay.h"
#include "nrf.h"
#include "bsp.h"
#include "nrf_uart.h"


#define UART_TX_BUF_SIZE 256                         /**< UART TX buffer size. */
#define UART_RX_BUF_SIZE 256                         /**< UART RX buffer size. */

/* When UART is used for communication with the host do not use flow control.*/
#define UART_HWFC APP_UART_FLOW_CONTROL_DISABLED

void uart_error_handle(app_uart_evt_t * p_event)
{
    if (p_event->evt_type == APP_UART_COMMUNICATION_ERROR)
    {
        APP_ERROR_HANDLER(p_event->data.error_communication);
    }
    else if (p_event->evt_type == APP_UART_FIFO_ERROR)
    {
        APP_ERROR_HANDLER(p_event->data.error_code);
    }
}

 void uart_putstring(const uint8_t *str) 
{
       uint32_t err_code;

       uint8_t len = strlen((uint8_t *)str);

       for (uint8_t i = 0; i < len; i++) 
       {

         err_code = app_uart_put(str[i]);

         APP_ERROR_CHECK(err_code);
       }
}


/**
 * @brief Function for main application entry.
 */
int main(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,
          UART_HWFC,
          false,

          NRF_UART_BAUDRATE_115200

      };

    APP_UART_FIFO_INIT(&comm_params,
                         UART_RX_BUF_SIZE,
                         UART_TX_BUF_SIZE,
                         uart_error_handle,
                         APP_IRQ_PRIORITY_LOWEST,
                         err_code);

    APP_ERROR_CHECK(err_code);

     //printf("Hello PC from Nordic Device!!!\r\n");

 //Commands to send data to murata_1sc
     uart_putstring((uint8_t*)"AT\r");
     app_uart_put((char)0x0A);
 }

[awneil]

For text strings, use 'char' rather than uint8_t - then you won't have to keep casting.

Although it should work, that's a grossly over-complicated way of sending a string.

void uart_putstring(const char *str) 
{
       uint32_t err_code;

       while( str ) 
       {
            err_code = app_uart_put( str++ );

            APP_ERROR_CHECK(err_code);
       }
}

that's standard textbook stuff - not specific to Nordic.

Why do you do this:

uart_putstring((uint8_t*)"AT\r");
app_uart_put((char)0x0A);

instead of just:

uart_putstring((uint8_t*)"AT\r\n");

But note that you shouldn't be putting a LF on the end of an AT Command anyhow - the command terminator is just CR:

https://www.avrfreaks.net/comment/2209136#comment-2209136

Study this thread:

https://www.avrfreaks.net/forum/atmega128a-get-response-string-sim900

also:

https://www.avrfreaks.net/comment/2212181#comment-2212181

EDIT

And note the links to  V.250 - the ITU standard which formalises the so-called "AT Command" structure:

https://www.avrfreaks.net/comment/1205711#comment-1205711

https://en.wikipedia.org/wiki/Hayes_command_set

[Rajbir Singh]

Thanks for the help, I have read the threads and got some information, but I have multiple commands to send and have to wait for their responses.

.First, send a command and then wait for a response.

Could you please tell me how much timeout should I keep for waiting for the response

send_AT_Command();

timeout();

if (received_srting == actual_string)

{

print(received_srting);

}

else

{

print("ERROR",received_srting);

}

send_AT_Command()

timeout()

.

.

.

.

.

so on.............

I think this will the format, but I don't know how to write in Segger

Please help me with the format.

[awneil]

Rajbir Singh said:

how much timeout should I keep for waiting for the response

That will depend on the command - you will have to study the module documentation and/or contact the manufacturer for support on that.

Things that require interaction over the network will obviously take longer than things which simply report local status.

Pay attention to commands which can give one (or more) intermediate response(s) before a final response.

Again, study the module documentation for details.

This is where experimenting by sending commands manually helps ...

 

please remember how to properly post source code:

[awneil]

Sorry - I accidentally hit the 'Report as abusive button' - and can't see any way to cancel it.