#include - оптимальное использование директивы

[Исбанни]

Да хоть тыщщу устройств - главное, что каждому можно задать уникальный в сети адрес. У меня же работало.
Пайпы - это просто дополнительные виртуальные приёмники. Одно физическое устройство может проходить в списке сети под разными адресами.
У передатчика выставляете в TX и RX (для приёма подтверждения) адрес pipe0 RX приемника, к которому собираетесь отправить, и - отправляете, получаете обратно подтверждение. Другой передатчик может так же направить данные этому же приемнику на pipe0 аналогичным образом. А третий передатчик может выставить у себя TX и RX адрес pipe1 того же приёмника и отправить данные приемнику на его виртуальный канал pipe1.
У передатчика адреса TX и RX должны быть одинаковы именно для приёма подтверждения от приёмника. Потому что приёмник в фазе отправки подтверждения автоматически ставит в пакет адрес того передатчика, от которого он принял
То есть, как бы подумайте и поймите организацию сети.

[parovoZZ]

Да я уже думал. Допустим, есть датчик - слушатель/контроллер подсети. К нему привязаны 7 датчиков. У всех у них PIPE0 и PIPE1 имеют одинаковые адреса. Рядышком сидит ещё такой же слушатель со своими датчиками и со своими адресами PIPE. И всем этим заправляет центральный контроллер, который слушает контроллеры подсетей. И им бы тоже аппаратно отправлять квитанции, да не получается - адреса у них разные на прием. Второй момент - перенос датчиков или изменение радио обстановки. Как быть с адресами? Менять на лету? И третий момент. Батареечным датчикам нечего эфир слушать - отправил пакет и умолк. Так батареек не напасешься.))) А я хочу выйти на 5 лет от литиевой комп. батарейки при выходе в эфир раз в десять минут.
А вообще, nRF24 -говно. Если между нами, девочками =)

[Easyrider83]

Вам надо научиться разделять протоколы на уровни. На нижнем уровне железо - чип, драйверы. Здесь вы решаете проблему с гарантированной доставкой и таймаутом. На следующем уровне адреса - кто кому чего шлет. Еще выше - ваши данные. Когда нижние уровни уже обеспечены, вам совершенно наплевать, кто и как будет эти данные отправлять. Важны уже непосредственно сами данные. А организация сети - не более, чем слой протокола.

[parovoZZ]

Вам надо научиться разделять протоколы на уровни. На нижнем уровне железо - чип, драйверы. Здесь вы решаете проблему с гарантированной доставкой и таймаутом. На следующем уровне адреса - кто кому чего шлет. Еще выше - ваши данные. Когда нижние уровни уже обеспечены, вам совершенно наплевать, кто и как будет эти данные отправлять. Важны уже непосредственно сами данные. А организация сети - не более, чем слой протокола.

Ну а я про что =) Мне на аппаратном уровне такие mac адреса не нужны. Адреса будут выше - в пакетах. По типу модбаса.

[Исбанни]

А вообще, nRF24 -говно.

-- Вы любите кошек?
-- Нет.
-- Да вы просто не умеете их готовить!

Это к тому, что вы чето малость невкурили в тему и неправильно подбираете инструменты под задачу, да и вообще задача наверно че-то где-то как-то не так. nRF24L01 в режиме постоянного приема жрет немало так. Да еще и МК вы видимо выбираете не самый экономный. И ваши "5 лет на литии" наврядли вам гарантированы.

А НЕ между нами говоря, nRF24 - очень даже хороший и недорогой инструмент для простой организации сети. Вы просто не до конца прочли мануал или не до конца его поняли.
Помимо адресов, там есть настраиваемый радиочастотный канал, который физически будет изолировать разные сегменты сети. К есть инструментарий по обнаружению перегрузки радиочастотного канала.
И вы всё-таки так и не захотели понять принципов адресации. Хотя я кажется вполне нормально описал, да и в даташите написано доходчиво.
У меня же всё работало без вопросов. Да и многие люди строят на этих nRF датчики для "умного дома". Таких датчиков и сборщиков инфы в сети - десятки, сети поделены на сегменты, и всё шикарно работает.

Чисто передающие nRF на датчиках могут кратковременно включаться в эфир раз в 10 минут и снова отключаться с потреблением менее микроампера. А вот принимающий nRF в условиях постоянного прослушивания эфира будет жрать свои около 10 мА.

[Easyrider83]

У меня nRF24L01 с Bluetooth работают в телефонах на андроид и iOS ))) От батарейки 2016 до 3 лет.

[parovoZZ]

К есть инструментарий по обнаружению перегрузки радиочастотного канала.

Да, вот только он показывает, есть ли несущая на частоте приема или нет. Уровень несущей никак не отображает.

Помимо адресов, там есть настраиваемый радиочастотный канал, который физически будет изолировать разные сегменты сети. К есть инструментарий по обнаружению перегрузки радиочастотного канала.
И вы всё-таки так и не захотели понять принципов адресации. Хотя я кажется вполне нормально описал, да и в даташите написано доходчиво.

Мне проще выставить всем одинаковые адреса и в путь. Батареечные датчики сеть не слушают, датчики/исполнительные устройства на толстом проводе всегда на востре.
Разнос по частоте - идея хороша. Но если датчик перенести физически в другой частотный диапазон, датчик как это поймёт? Передача 20 байт информации на скорости 2 Мбит занимает не так уж и много времени. чтобы беспокоиться о коллизиях. Это не лора, где передача пакета занимает целую вечность. Но в лоре разрулить частотное разнесение проще - инструментарий позволяет.

[Исбанни]

А уровень несущей тут и не нужен. Перегрузки частотой канала определить по числу сбойных пакетов, в nRF есть два счётчика для этого.

[parovoZZ]

Перегрузки частотой канала определить по числу сбойных пакетов, в nRF есть два счётчика для этого.

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

[parovoZZ]

А в прерывании по приему байта SPI вы уже будете как-то разруливать остальное.

Получается, что я из одного прерывания прыгаю в другое? Не, тогда буду сливать status и следить за флагами в цикле. МК же надо чем-то занять между прерываниями и опросом кнопок))