XBEE Прозрачный режим связи - PullRequest
0 голосов
/ 02 октября 2019

Я использую плату STM32F411RE NUCLEO для создания ячеистой сети Zigbee. Я купил Zigbee Dev. Комплект для понимания устройств.

Вначале я использовал программное обеспечение XCTU от Digi для настройки устройств. После всего, что у меня хорошо работало, я попытался связаться с моей платой NUCLEO через UART с устройством Zigbee.

Чтобы войти в режим AT-команд, я должен отправить «+++» через UART.

Вот как CUBEMX сгенерировал мою инициализацию UART

static void MX_USART1_UART_Init(void)
{
  huart1.Instance = USART1;
  huart1.Init.BaudRate = 9600;
  huart1.Init.WordLength = UART_WORDLENGTH_8B;
  huart1.Init.StopBits = UART_STOPBITS_1;
  huart1.Init.Parity = UART_PARITY_NONE;
  huart1.Init.Mode = UART_MODE_TX_RX;
  huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE;
  huart1.Init.OverSampling = UART_OVERSAMPLING_16;
  if (HAL_UART_Init(&huart1) != HAL_OK)
  {
    Error_Handler();
  }
}

Я написал первую функцию для входа в режим AT-команд. В main.ci включен мой заголовок, в котором хранится моя функция.

#include <XBEE_AT_CMD.h>

Внутри цикла while я вызываю свою функцию следующим образом, передавая huart1.

while (1)
{
 if( AT_enter_CMDmode(&huart1) == 1 )
 {
    printf("OK \n");
 }
 else
 {
    printf("failed entering CMD mode \n");
 }
 HAL_Delay(1000);
}

Функция, которую она сама выглядитнравится. Он просто отправляет "+++" Zigbee. После этого я получаю ответ.

int AT_enter_CMDmode(UART_HandleTypeDef *huart)
{
    char receive[3];
    HAL_UART_Transmit(huart,(uint8_t*)"+++", 3, 100);
    HAL_UART_Receive(huart, (uint8_t*)receive, 3, 100);
    if( strcmp(receive,OK) == 0 )
    {
        return 1;
    }
    else
    {
        return 0;
    }   
}

После того, как я вхожу в режим AT-команд, отправив «+++», устройство отвечает «OK». Но иногда это работает. Я попытался применить некоторые задержки, потому что в Таблице говорится, что вы должны установить защитное время до и после входа в командный режим. Иногда я получаю ответ, который похож на конкретный «ОК», но без возврата каретки в конце или два «О» и один «К». Когда я ставлю точку останова после HAL_UART_Receive(huart, (uint8_t*)receive, 3, 100);, я вижу разные ответы от устройства.

Ответ 1: "\ rOK"

Ответ 2: "\ r"

Ответ 3: "O"

Ответ 4: "OOK"

ответ, который я ищу, это "OK \ r"

Похоже, что есть проблема с синхронизацией UART, может быть? Правильно ли я передал обработчик UART в функцию? Такое чувство, что я неправильно читаю UART, но не уверен.

Ответы [ 2 ]

0 голосов
/ 04 октября 2019

Вы находитесь на правильном пути с вашим анализом, но ваша главная проблема заключается в том, что вам нужно правильно кадрировать , чтобы получить согласованные ответы с "OK \ r \ n""каждый раз.

И вам нужно изменить код на обрабатывать все возможные коды окончательного результата . Поскольку ваш код теперь такой, вы ожидаете только OK, поэтому, если модем вернет ERROR, ваш код выйдет из синхронизации / возможно зависнет, когда вы расширите свой код для выполнения чего-то более полезного, чем цикл тестирования, который у вас есть в настоящее время.

0 голосов
/ 02 октября 2019

Чтобы войти в командный режим, вам фактически (по умолчанию) требуется 1 секунда «тихого времени» (без отправки байтов), затем «+++» и затем еще одна секунда тихого времени. Поэтому вам нужно подождать не менее секунды, прежде чем вы увидите ответ «ОК».

Вы также должны кодировать свой обработчик, чтобы прочитать столько байтов, сколько доступно, чтобы вы не получили буферизованные данные. .

Я бы настоятельно рекомендовал разрабатывать ваш код в режиме API, а не в прозрачном режиме. Режим API отправляет фреймы данных, которые включают AT-команды (поэтому вам не нужно входить в командный режим), и позволяет отправлять данные нескольким узлам в сети (прозрачный режим использует регистры для установки одного адресата).

Digi предоставляет хост-библиотеку с открытым исходным кодом на C (среди других языков), которую вы сможете интегрировать в ваше оборудование. Вы можете протестировать и создать прототип в Windows или Linux / macOS.

...