Код (для проводного варианта)
https://bitbucket.org/onivan/brags/s...in.c?at=master
Все блоки управляются МК Atmega8.
Сейчас продумываю оптимальный алгоритм связи между блоками.
Практически мне достаточно передавать 1 байт, мне главное скорость, но намного больше -- надежность.
Передавать мне нужно всего 1-2 бита:
- от центрального блока какой светодиод зажечь - красный или зеленый (одновременно по игре они не включаются).
- от блоков команд только состояние одной кнопки.
Железную часть я уже изготовил, теперь занялся разработкой прошивки, поэтому изучаю все библиотеки для этого радиомодуля, смотрю, как лучше его использовать. Предварительно, для проверки работоспособности, в каждый блок залил тестовые прошивки. Вроде бы все блоки передают и принимают. Как везде советуют, припаял конденсаторы (47мФ) прямо к + и - модулей (на фотке еще их нету).
Сначала я думал построить систему так:
- база PRX ESB + ack with payload.
- все блоки команд в режиме PTX
- с постоянной частотой все PTX передают свое состояние и в ответ с пейлоадом получают команды.
Но потом понял, что наверное, так не получится: слишком сложно, и пакеты от разных блоков могут теряться, невозможность работы такой системы с большой частотой для достижения быстрой реакции системы.
В проводном варианте МК просто следит не изменилось ли состояние на любом из 4-х входах одного порта (PORTD). И затем уже выделяет на каком именно (ссылка на соотв. строку кода:
https://bitbucket.org/onivan/brags/s...=master#cl-478).
В беспроводном варианте я хочу просто заменить регистр порта переменной, оставив всю остальную логику неизменной. Перед каждым игровым циклом подсистема радио будет заполнять эту переменную состоянием кнопок от всех блоков, как если бы они были подключены по проводам к 4-м пинам МК.
Сейчас я думаю о такой схеме:
- все блоки работают в режиме PRX
- не знаю, что лучше: включать или нет w_ack_payload ?
- все работают на одной трубе, а номер комманды кодировать в передаваемых пакетах.
- или для каждой команды своя труба?
Каждый блок переходит в режим PTX в следующих случаях:
- как только какая-то команда жмет на кнопку, база, по прерыванию на полученный от этого блока пакет, переходит в режим PTX и передает всем блокам сменить состояние светодиодов.
- на базе ведущий игры меняет режим игры и также передает всем блокам сменить состояние светодиодов соответственно.
- номер команды, нажавшей кнопку первой, закодирован в пакете (или в номере трубы, если использовать разные трубы).
Главное, что может быть плохо, это если несколько комманд нажмут кнопки почти одновременно, то пакет от первой команды может не дойти или дойти позже. Правда, это не критично если разница будет в несколько миллисикунд. Но, если задержки будут более заметными, то для этой команды красный светодиод засветится з видимой задержкой, что вызовет законную претензию, что система нечестно определила кто первый нажал.
Как это разрулить? Об этом я сейчас и думаю.
Вариант 1:
База в режиме PTX по очереди передает пакеты с кодами о состоянии светодиодов на все блоки команд с подтверждением, а все блоки в режиме PRX в ответ отсылают свое состояние кнопок. Если какой-то блок не отзывается, он помечается как неучавстующий в игре (такое может быть, что игра проводится между 2-мя или 3-мя командами). Или предусмотреть возможность настройки перед игрой количества команд. Но если получится, что связь с одними блоками будет лучше, чем с другими и от них пакеты будут приходить реже?
Еще проблемы этого варианта:
- нажатия фиксируются не одновременно для всех.
- может произойти, что в одно и то же время база передает запрос о состоянии и один из блоков также передает.
Вариант 2:
- все блоки (и база, и блоки кнопок) ожидают в режиме PRX
- как только какая-то команда нажимает кнопку, она посылает всем блокам и базе (все работают на одной трубе) пакет о том, что произошло нажатие кнопки. Остальные блоки, получив этот пакет не могут перейти в режим передачи до тех пор, пока от базы не поступит пакет с кодом соответствующей комманды разрешающей это. При этом база получив этот же пакет посылает пакет о том, какие светодиоды зажечь.
Здесь, в принципе, та же проблема: не все боки могут принять этотпакет.
Во всем этом меня волнует надежность. Как сделать чтобы гарантированно был обмен закодированными инструкциями в нужной (честной) последовательности с достаточно большой скоростью реакции?
Я думаю, что нужно также подумать о том, чтобы периодически (раз в секудну или чаще?) база пинговала все блоки и соответственно зажигала красный светодиод у себя, если какой-то блок не откликается.
Пожалуйста, поделитесь опытом работы с этими радимодулями применительно к этой задаче. По какому пути мне пойти?
Я так понимаю, что нужно время от времени перезапускать модули или загружать в них конфигурацию, которая может слететь, например от наводок.
Просмотрел эту тему на сколько смог (в режиме 40 постов на страницу). Если пропустил, где подобное обсуждалось, прошу ткнуть носом.
Или может есть подобный проект, в котором можно подсмотреть код такого обмена? Я на разых опенсорс репах типа github и bitbucket просмотрел много проектов, но подходящего не увидел. Может пропустил.
Фотки базового блока и блоков команд:
Re: Кто-нибудь работал с RF модулями nRF2401A?
нужна помощь
