www.open-tager.ru

Извиняюсь, перебью интересную дискуссию...

Подумал, а если передавать данные "бинарной строкой"?
То есть


Повязка будет предельно "тупой" - получила по ИК нолик - отправила по BT нолик. Получила "1" - передала "1".
Как только зафиксировано окончание приема пакета по таймауту - передаем возврат коретки - \r.
Без всякого анализа содержимого пакета.

И ещё - разделение по разным контроллерам приема ИК пакета и формирование "выстрела" позволит по иному реализовать прием ИК пакета в повязке, ибо больше нет нужды генерировать прерывания с удвоенной частотой несущей TSOP (f0).
Поэтому пусть таймер считает микросекунды и генериться будут только прерывания по переполнению счетчика таймера.
А в прерывания INT0 можно по спаду обнулять счетчик таймера, а по фронту проверять, сколько микросекунд длился импульс (проверив при этом, не было ли переполнения счетчика).
Передачу по UART можно сделать так, как было первоначально реализовано, но плохо работало из-за частых прерываний таймера, генерирующих "выстрел".
То есть передача символов из буффера по UART будет происходить полностью через прерывания UART-а.

Зы А ещё у нас сегодня снег выпал!

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

Так и надо, ещё позаботится чтобы работало в обе стороны. Оцифровывать надо с дискретизацией около 100мкс или ещё быстрее.




Разрешение официальное нужно для хороших отношений к пользователям самоделок на официальных мероприятиях, а для избежания ответственности - трудности вообще нет.

_________________
"За 2 месяца максимум можно чертёж сделать, еще за 3 фундамент." (c) Номернабис

Хороший вариант. А еще можно передавать дополнительные символы : H - получен маркер начала пакета , E - ошибка при приеме , T - таймаут приема бита.
Тогда правильно принятый пакет будет выглядеть так

А на приемной стороне контроллер ждет символа "Н", и пока он не пришел все остальное игнорирует. А когда получен Н - сдвигает биты в буфере (заодно и считает их количество). Если во время приема пришел символ "Е" - то снова переходит в режим ожидания, если пришел "Т" - то передать в обработку.

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

Ну как будто мозг мне просканировали!
Только при получении символа ошибки "Е" воспроизведем звук "пуля рядом просвистела".

Тут что интересного получается - можно не дожидаться, пока будет принят весь ИК пакет целиком, а начинать передачу по БТ как только старт-бит принят.

Посчитал маленько, интересно получается.
Скорость UART 9600 кБит/c
На оправку одного байта требуется (вместе со служебными символами) 10 бит.
То есть время оправки одного символа (1/9600)*10=1,04 миллисекунды.
Прием по ИК одного бита длится не менее 1200 микросекунд (вместе с паузой), то есть чуть больше 1 миллисекунды - 1,2 если точно.
То есть пока идет прием второго бита из ИК пакета можно (теоретически) успеть передать по БТ значение первого, и так далее.

Ну и мусор (пока не принят старт-бит) можно и на повязке отсеивать.

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

Ещё WiFi модуль

MRF24WB0MA

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

А как быть с прерываниями UART?
Ведь они не должны мешать передаче ИК пакета.
Запрещать их на время выстрела?
А не потеряем символы?
Кто в курсе, как работает аппаратный UART на Atmega - есть какой-никакой приемный буфер?
Или не успел забрать символ до прихода следующего - все, потерял?

Или разрешить прерывания таймера в прерывании UART?

Так что в варианте "не универсальной" повязки (данные с повязки получает контроллер тага) желательно минимизировать трафик (как минимум во время игры).
В "универсальной" (когда по дополнительному контроллеру и с той и с другой стороны) - нет вопросов.

Я чего подумал - в протоколе в выстреле передается 14 бит данных.
В двух байтах -16 бит.
А давайте ка используем первый бит байта для его нумерации.
То есть у первого байта первый бит = 0, у второго = 1.
И мы их не спутаем!
А повязке нужно будет только упаковать принятый "выстрел" должным образом в два байта и передать.
Таг словит эти байты, найдет первый и вытащит 14 бит данных.

Ещё раз уточню, что речь о "не универсальной" повязке.

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

кто вам мешает поставить STM32 и вовсю пользовать DMA? никаких проблем с отправкой данных - кинул контролеру DMA адрес переменной/буфер, и забыл об этом. DMA сам все передаст.

Дойдем и до STM32 - всему свое время.
Переход на новый, принципиально другой камень - это может и год занять до рабочего прототипа.
А тут железо готово, только в прошивку функционал добавить.
Так что задача сейчас другая стоит - наиболее эффективно использовать то, что уже есть.

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!

есть долго работали с AVR - перейти на stm32 займет не более недели-двух. Даташиты внятные, камень мощный. Сам на него пересел по работе, только из-за кучи интерфейсов и навороченного DMA. Ну да ладно.

Да кто спорит то?
Хотя про две недели это вы хватанули!
А печатку развести и изготовить (заказать в производство)?
Делать только будут 14 дней.
А код портировать?
А со средой разработки и программаторами разобраться?
Заказать ещё надо этот программатор...
Не менее полугода до первого теста!

А с тем, что уже практически готово, что сделать - в долгий ящик задвинуть?
Когда результат можно уже через неделю-другую иметь?
Да и печатки заводские есть в немалом количестве...

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!