OpenThread otJoinerStart никогда не истекает

Я пытаюсь интегрировать дочерний элемент OpenThread с существующим приложением на TI CC2652R1, и у меня возникают проблемы с попыткой присоединиться/создать сеть Thread. В настоящее время у меня есть внешнее событие, которое вызывает функцию для присоединения и запуска OpenThread. Ниже приведен фрагмент этой функции, относящейся к соединению:

    bool is_commissioned = otDatasetIsCommissioned(OtStack_instance);
    otJoinerState joiner_state = otJoinerGetState(OtStack_instance);
    if(!is_commissioned && (OT_JOINER_STATE_IDLE == joiner_state)){
        otError error = otIp6SetEnabled(OtStack_instance, true);
        error = otThreadSetEnabled(OtStack_instance, true);
        error = otJoinerStart(OtStack_instance, "PSK", NULL, "Company", "Device", "0.0.0", NULL, joiner_callback, NULL);
    }

otJoinerStart, кажется, никогда не разрешается, потому что обратный вызов присоединителя никогда не вызывается, а дополнительные вызовы моей функции присоединения показывают, что состояние присоединителя равно OT_JOINER_STATE_DISCOVER, а экземпляр OpenThread говорит, что он инициализирован. Есть ли способ установить время ожидания обратного вызова столяра? Я просмотрел документацию и не смог узнать, как устанавливается время ожидания присоединения.

Спасибо


openthread
person melonchucker    schedule 27.04.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Присоединение устройства Thread к сети Thread предполагает, что у вас запущена сеть Thread и есть активный уполномоченный с EUI64 и PSK присоединяющегося. Убедитесь, что они настроены, прежде чем пытаться вызвать эту функцию для присоединения. Также полезно иметь сниффер, работающий на канале сети Thread, чтобы убедиться, что комиссионер или присоединяющий маршрутизатор отвечают правильно.

Присоединение к потоку выполняется при активном сканировании всех доступных каналов на странице 0 IEEE 802.15.4. Время отправки запроса присоединения и время ожидания присоединения на каждом канале не настраиваются сразу. Однако эти активные сканирования обычно завершаются в течение нескольких секунд. Ваш обратный вызов присоединителя должен вызываться с условием неудачного присоединения, если в течение примерно 5 секунд нет доступных присоединяющих маршрутизаторов.

Примеры в репозитории OpenThread на github написаны в стиле nortos. Любой код приложения запускается в тасклете, а основной цикл вызывает только две функции; тасклеты процессов и драйверы процессов. В TI SDK мы используем TI-RTOS, и вы, похоже, основывали свой код на этих примерах. Как правило, OtStack_Task обрабатывает OpenThread и интерфейс драйвера платформы; но взаимоблокировки в многопоточной системе могут возникать.

Вы можете использовать ROV в CCS или IAR для проверки состояния ядра и объектов RTOS. В CCS с активным сеансом отладки выберите; Tools >> Runtime Object View. Затем проверьте, не блокирует ли задача стека семафор API. Или если прикладная задача загружает процессор. Это может быть связано с несопряженной блокировкой/разблокировкой на семафоре API, или задача приложения может находиться в активном ожидании.

Сразу же я не вижу ничего плохого в размещенном фрагменте кода.

person Seth Rickard    schedule 29.04.2020
comment
Спасибо за разъяснения по поводу примера TI-RTOS. Я не знал, что каждый вызов OpenThread API нужно блокировать/разблокировать на стороне кода приложения. - person melonchucker; 01.05.2020