Реклама на сайте English version  DatasheetsDatasheets

KAZUS.RU - Электронный портал. Принципиальные схемы, Datasheets, Форум по электронике

Новости электроники Новости Литература, электронные книги Литература Документация, даташиты Документация Поиск даташитов (datasheets)Поиск PDF
  От производителей
Новости поставщиков
В мире электроники

  Сборник статей
Электронные книги
FAQ по электронике

  Datasheets
Поиск SMD
Он-лайн справочник

Принципиальные схемы Схемы Каталоги программ, сайтов Каталоги Общение, форум Общение Ваш аккаунтАккаунт
  Каталог схем
Избранные схемы
FAQ по электронике
  Программы
Каталог сайтов
Производители электроники
  Форумы по электронике
Помощь проекту

Микроконтроллеры, АЦП, память и т.д Темы касающиеся микроконтроллеров разных производителей, памяти, АЦП/ЦАП, периферийных модулей...

 
Опции темы
Непрочитано 17.05.2018, 11:06  
Исбанни
Прописка
 
Регистрация: 21.04.2018
Сообщений: 174
Сказал спасибо: 1
Сказали Спасибо 66 раз(а) в 53 сообщении(ях)
Исбанни на пути к лучшему
По умолчанию Re: #include - оптимальное использование директивы

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

Последний раз редактировалось Исбанни; 17.05.2018 в 11:21.
Исбанни вне форума  
Непрочитано 17.05.2018, 15:22  
parovoZZ
Почётный гражданин KAZUS.RU
 
Регистрация: 15.11.2010
Сообщений: 2,379
Сказал спасибо: 338
Сказали Спасибо 328 раз(а) в 253 сообщении(ях)
parovoZZ на пути к лучшему
По умолчанию Re: #include - оптимальное использование директивы

Да я уже думал. Допустим, есть датчик - слушатель/контроллер подсети. К нему привязаны 7 датчиков. У всех у них PIPE0 и PIPE1 имеют одинаковые адреса. Рядышком сидит ещё такой же слушатель со своими датчиками и со своими адресами PIPE. И всем этим заправляет центральный контроллер, который слушает контроллеры подсетей. И им бы тоже аппаратно отправлять квитанции, да не получается - адреса у них разные на прием. Второй момент - перенос датчиков или изменение радио обстановки. Как быть с адресами? Менять на лету? И третий момент. Батареечным датчикам нечего эфир слушать - отправил пакет и умолк. Так батареек не напасешься.))) А я хочу выйти на 5 лет от литиевой комп. батарейки при выходе в эфир раз в десять минут.
А вообще, nRF24 -говно. Если между нами, девочками =)
parovoZZ вне форума  
Непрочитано 17.05.2018, 15:33  
Easyrider83
Гуру портала
 
Аватар для Easyrider83
 
Регистрация: 27.10.2008
Адрес: ЕС
Сообщений: 10,835
Сказал спасибо: 919
Сказали Спасибо 4,308 раз(а) в 2,573 сообщении(ях)
Easyrider83 на пути к лучшему
По умолчанию Re: #include - оптимальное использование директивы

Вам надо научиться разделять протоколы на уровни. На нижнем уровне железо - чип, драйверы. Здесь вы решаете проблему с гарантированной доставкой и таймаутом. На следующем уровне адреса - кто кому чего шлет. Еще выше - ваши данные. Когда нижние уровни уже обеспечены, вам совершенно наплевать, кто и как будет эти данные отправлять. Важны уже непосредственно сами данные. А организация сети - не более, чем слой протокола.
Easyrider83 вне форума  
Сказали "Спасибо" Easyrider83
parovoZZ (17.05.2018)
Непрочитано 17.05.2018, 18:28  
parovoZZ
Почётный гражданин KAZUS.RU
 
Регистрация: 15.11.2010
Сообщений: 2,379
Сказал спасибо: 338
Сказали Спасибо 328 раз(а) в 253 сообщении(ях)
parovoZZ на пути к лучшему
По умолчанию Re: #include - оптимальное использование директивы

Сообщение от Easyrider83 Посмотреть сообщение
Вам надо научиться разделять протоколы на уровни. На нижнем уровне железо - чип, драйверы. Здесь вы решаете проблему с гарантированной доставкой и таймаутом. На следующем уровне адреса - кто кому чего шлет. Еще выше - ваши данные. Когда нижние уровни уже обеспечены, вам совершенно наплевать, кто и как будет эти данные отправлять. Важны уже непосредственно сами данные. А организация сети - не более, чем слой протокола.
Ну а я про что =) Мне на аппаратном уровне такие mac адреса не нужны. Адреса будут выше - в пакетах. По типу модбаса.
parovoZZ вне форума  
Непрочитано 17.05.2018, 18:47  
Исбанни
Прописка
 
Регистрация: 21.04.2018
Сообщений: 174
Сказал спасибо: 1
Сказали Спасибо 66 раз(а) в 53 сообщении(ях)
Исбанни на пути к лучшему
По умолчанию Re: #include - оптимальное использование директивы

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

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

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

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

Последний раз редактировалось Исбанни; 17.05.2018 в 18:49.
Исбанни вне форума  
Непрочитано 17.05.2018, 19:03  
Easyrider83
Гуру портала
 
Аватар для Easyrider83
 
Регистрация: 27.10.2008
Адрес: ЕС
Сообщений: 10,835
Сказал спасибо: 919
Сказали Спасибо 4,308 раз(а) в 2,573 сообщении(ях)
Easyrider83 на пути к лучшему
По умолчанию Re: #include - оптимальное использование директивы

У меня nRF24L01 с Bluetooth работают в телефонах на андроид и iOS ))) От батарейки 2016 до 3 лет.
Easyrider83 вне форума  
Непрочитано 18.05.2018, 13:43  
parovoZZ
Почётный гражданин KAZUS.RU
 
Регистрация: 15.11.2010
Сообщений: 2,379
Сказал спасибо: 338
Сказали Спасибо 328 раз(а) в 253 сообщении(ях)
parovoZZ на пути к лучшему
По умолчанию Re: #include - оптимальное использование директивы

Сообщение от Исбанни Посмотреть сообщение
К есть инструментарий по обнаружению перегрузки радиочастотного канала.
Да, вот только он показывает, есть ли несущая на частоте приема или нет. Уровень несущей никак не отображает.

Сообщение от Исбанни Посмотреть сообщение
Помимо адресов, там есть настраиваемый радиочастотный канал, который физически будет изолировать разные сегменты сети. К есть инструментарий по обнаружению перегрузки радиочастотного канала.
И вы всё-таки так и не захотели понять принципов адресации. Хотя я кажется вполне нормально описал, да и в даташите написано доходчиво.
Мне проще выставить всем одинаковые адреса и в путь. Батареечные датчики сеть не слушают, датчики/исполнительные устройства на толстом проводе всегда на востре.
Разнос по частоте - идея хороша. Но если датчик перенести физически в другой частотный диапазон, датчик как это поймёт? Передача 20 байт информации на скорости 2 Мбит занимает не так уж и много времени. чтобы беспокоиться о коллизиях. Это не лора, где передача пакета занимает целую вечность. Но в лоре разрулить частотное разнесение проще - инструментарий позволяет.
parovoZZ вне форума  
Непрочитано 18.05.2018, 14:51  
Исбанни
Прописка
 
Регистрация: 21.04.2018
Сообщений: 174
Сказал спасибо: 1
Сказали Спасибо 66 раз(а) в 53 сообщении(ях)
Исбанни на пути к лучшему
По умолчанию Re: #include - оптимальное использование директивы

А уровень несущей тут и не нужен. Перегрузки частотой канала определить по числу сбойных пакетов, в nRF есть два счётчика для этого.
Исбанни вне форума  
Непрочитано 18.05.2018, 15:44  
parovoZZ
Почётный гражданин KAZUS.RU
 
Регистрация: 15.11.2010
Сообщений: 2,379
Сказал спасибо: 338
Сказали Спасибо 328 раз(а) в 253 сообщении(ях)
parovoZZ на пути к лучшему
По умолчанию Re: #include - оптимальное использование директивы

Сообщение от Исбанни Посмотреть сообщение
Перегрузки частотой канала определить по числу сбойных пакетов, в nRF есть два счётчика для этого.
Я так понял, что счетчики сбрасываются при удачном завершении сеанса.
parovoZZ вне форума  
Непрочитано 19.05.2018, 01:29  
parovoZZ
Почётный гражданин KAZUS.RU
 
Регистрация: 15.11.2010
Сообщений: 2,379
Сказал спасибо: 338
Сказали Спасибо 328 раз(а) в 253 сообщении(ях)
parovoZZ на пути к лучшему
По умолчанию Re: #include - оптимальное использование директивы

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

Закладки
Опции темы

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
OLED ssd1306 + STM32f030f4 miwutka Песочница (вопросы новичков) 195 07.01.2019 15:38
AVR Studio + CVAVR: директивы #include SwanSwan AVR 2 30.10.2016 18:50
Светодиоды "Straw Hat" - оптимальное использование mikesmith Отвлекитесь, эмбеддеры! 10 09.03.2014 02:28
usb cdc pic18f14k50 gromovi Proteus, KiCAD и другие ECAD 9 21.04.2013 15:31
В какой программе компелить код (подключение #include ) FedorChek Микроконтроллеры, АЦП, память и т.д 4 04.05.2009 20:00


Часовой пояс GMT +4, время: 21:58.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot