nRF24L01+ : побеждаем модуль.

и в каком месте вы видите тут ожидание приема данных? - нет тут такого. Эта функция пролетает насквозь, независимо от того, есть данные или нет.
Вы на прошлой странице писали, что новичок и даже не представляете, как это ожидание оформить в коде. Так чего ж вы в библиотеку полезли? Что за странная привычка у новичков - чуть что - искать ошибки в библиотеках, а не в своем коде? Библиотеки в большинстве своем написаны достаточно продвинутыми программистами - и обкатаны тысячами пользователей. И если у всех все работает, а у вас нет - то где ошибка, как вы думаете?

 

А что там может быть не понятно? Чтобы снять флаги прерываний, на их место необходимо записать "1". Одновременно поднимается нога IRQ (только если сняты все прерывания, по которым нога IRQ опускается). Чтобы понять, что произошло, необходимо вычитать регистр статуса. Он ВСЕГДА лезет ПЕРВЫМ при начале обмена с трансивером. Не понимаю, зачем вымучивать убогую библиотеку, если вся работа с этим трансивером помещается в 10-15 строк? Без библиотеки этот трансивер можно настроить очень изящно. Каждая труба там настраивается индивидуально.

 

Паровоз, неужели ты не видишь, что "не по Сеньке шапка" ? Какие регистры, какие прерывания? Человек обычную задержку по приему данных взвести не может...Не пудри ему мозги
Его задача решается в рамках ардуино-кода в 3-4 строчки.

 

ra0wx
вот вам псевдокод, как очистить экран спустя секунду после прихода последнегно пакета данных:

Код (C++):

static unsigned long last_read_time =0;

if ( radio.available()) {
  // .... принимаем данные

// запоминаем время приема
   last_read_time = millis();
}
else {
if (millis() - last_read_time > 1000) {   // если прошло больше 1 сек
  // очищаем экран
}
}

 

Вы совершенно правы, библиотека не причем.Все заработало как надо.Большое спасибо за помощь.

 

Здравствуйте!
Подскажите, как правильно реализовать на Ардуино следующую схему:
Один передатчик на NRF24 и десять приемников. Требуется отправка массивов данных с передатчика на приемники, чтоб приемники могли как-то идентифицировать "свои" массивы, подтверждали прием данных, и чтоб передатчик отслеживал наличие приемников в сети. Хотя бы с интервалом в пару секунд.

 

Сделать так можно - но через дерзкий хак. По дефолту только 6 приемников.

 

"Дерзкий хак" заключается в правке библиотеки или как? ) Согласен снизить число приемников до восьми! )
А RFM69 не упростит задачу?

 

Я делал так, у меня неичего не заморачивается на библиотеке, всё работает на одном канале, я просто в первом байте посылаю номер передающего. Правда у меня наоборот, много передатчиков и 1 приёмник, но никто не мешает и наоборот.

 

Вообще без библиотеки.

 

Все надо делать ручками.

 

Естественно, что можно. И можно даже по-разному - изящно и не очень.

 

Так можно, но не очень понятно, как в таком случае получать подтверждения о доставке от восьми-десяти приемников.

 

через адресацию приемников. На nRF24 это происходит прозрачно, но только до 6 каналов. В остальных чипах ручками. Но большинство из них в режиме приема поддерживает нативную адресацию (только 1 канал), что несколько может упростить задачу. В общем, читай даташиты на трансиверы от TI, Silabs и прочих. Я их пересказывать не собираюсь.

 

Подскажите решение.

У меня один главный блок и шесть передатчиков.

Каждый передатчик стучится к главному блоку, кидает свою инфу и
через ASK получает данные от главного блока (через W_ACK_PAYLOAD).

Проблема в том что согласно даташита можно использовать только три канала (pipe) для передачи.
Как обойти это ограничение ?

 

Почему три канала? Все шесть. Там ограничение следующего характера. ACK пакет кладется в FIFO буфер для передачи. Места там только под три ACK пакета. Вариант следующий - если речь не идет про энергосбережение, то в пакет ACK можно положить инфу сразу для всех передатчиков. Максимальная длина сообщения - 32 бита. А передатчики сами уже выберут из пакета информацию для себя.

 

6 передатчиков, у каждого свой адрес.
один приемник.

Когда приемник получил инфу и шлет назад АСК с данными, он шлет их по определённому адресу, значит и дойдут эти данные только в один передатчик. Как остальные передатчики увидят этот АСК пакет с данными ?

Собственно, так и происходило, при включении больше чем 3 передатчика инфа к приёмнику уходила, а вот возвращалась только к 3-м приёмникам.

W_ACK_PAYLOAD
1010 1PPP

Used in RX mode.
Write Payload to be transmitted together with
ACK packet on PIPE PPP. (PPP valid in the
range from 000 to 101). Maximum three ACK
packet payloads can be pending. Payloads with
same PPP are handled using first in - first out
principle. Write payload: 1– 32 bytes. A write
operation always starts at byte 0.

------------------

Сейчас быстренько переписал в таком виде :
6 передатчиков с одинаковым адресом
1 приемник
передатчик среди данных шлет свой номер.
приемник отвечает АСК + инфа для всех передатчиков.

передатчик принимает АСК со всеми данными и использует только инфу, которая предназначена именно ему.

Работает, но хотелось бы разобраться с первым вариантом.

 

в следующем сеансе связи, когда отправят пакет и будут ждать в ответ квитанцию ACK/

Так вроде разобрались - места в FIFO буфере только 3 банка.

nRF24 - замечательная микра, но только там, где она уместна. Если хочется чего-то более изысканного, то есть гораздо более настраиваемые трансиверы. Но всё придется делать ручками.

 

Главный модуль делает
W_ACK_PAYLOAD+0 , плюс данные
W_ACK_PAYLOAD+1, плюс данные
W_ACK_PAYLOAD+2, плюс данные
W_ACK_PAYLOAD+3 , плюс данные
W_ACK_PAYLOAD+4, плюс данные
W_ACK_PAYLOAD+5, плюс данные

Ожидается что данные сохраняются и когда следующий передатчик постучится в приемнику ,тот ему отправит аск с данными.

Но модуль, насколько я понимаю, может хранить PAYLOAD только для ТРЕХ каналов ,и когда четвертый передатчик стучится к приемнику ,тот ему в ответ не передает ничего или передает АСК без данных, тут я не знаю точно.

Четвертый передатчик не может получить АСК+PAYLOAD ему не предназначенные.

 

Вся посылка ACK ответа может уместиться в 32 бита? Если да, то данные необходимо распределить по тайм-слотам. То бишь первые байты для первого передатчика, вторые байты для второго. В этой схеме два недостатка:
1. Слишком длинная посылка
2. В случае, если данные переменной длины, то неиспользуемые биты придётся забивать нулями вместо сжатия информации.