www.open-tager.ru

открытый лазертаг форум
Текущее время: 29 мар 2024, 17:20

Часовой пояс: UTC + 3 часа [ Летнее время ]


Реклама

Правила форума


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



Начать новую тему Ответить на тему  [ Сообщений: 169 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8, 9, 10 ... 17  След.
Автор Сообщение
 Заголовок сообщения: Re: Умный датчик. Smart sensor.
СообщениеДобавлено: 01 янв 2017, 20:50 
Не в сети
Старожил

Зарегистрирован: 18 мар 2015, 13:19
Сообщений: 574
Откуда: Нижний Новгород
Предлагаю дальнейшие технические детали обсуждать лично, через ВКонтакте или по скайпу. Писать такие посты много времени отнимает


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Умный датчик. Smart sensor.
СообщениеДобавлено: 01 янв 2017, 20:55 
Не в сети
Аксакал форума
Аватар пользователя

Зарегистрирован: 12 авг 2011, 16:55
Сообщений: 7514
Откуда: Барнаул, Алтайский край (не путать с республикой Алтай) :-)
Цитата:
Вы правда считаете, что в вашем коде, который в 2 раза длиннее (300 строк против 150), с неправильными отступами, без API и огромным количеством вложенных if-ов в обработчике прирываний пионер разберется быстрее?


Да.
Нифига Ваш код не короче!
А ну ка все задействованные функции HAL - в студию! :)

то не "прототип кода" - это кусочек рабочего кода!
Все там (откуда скопипастил) есть, и копирование в промежуточный буфер тоже - в соответствующей задаче.
Код РАБОЧИЙ - точка! ;) :)

Похоже - мы о разных таймаутах говорим! :)
Я о таймауте приема пакета - 15 uS (признак окончания приема пакета).

Вы, вероятно - имеете ввиду разницу во времени между приемами пакетов?

Это у меня тоже обрабатывается, но пока тут не скажу как. ;)

Цитата:
В упор не виду противоречия. Какие предложения отвергаются? Всё переделать, чтобы было как у вас в прототипе?


Давайте поставим ws2812 - таймеры Вы не сэкономите, как выяснилось (я использую один канал, вы - 3 канала), и на две ножки тратите больше.

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


Последний раз редактировалось Pingvin 01 янв 2017, 21:18, всего редактировалось 3 раз(а).

Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Умный датчик. Smart sensor.
СообщениеДобавлено: 01 янв 2017, 21:07 
Не в сети
Старожил

Зарегистрирован: 18 мар 2015, 13:19
Сообщений: 574
Откуда: Нижний Новгород
Pingvin писал(а):
Это не "прототип кода" - это урезаный кусочек рабочего кода!
Все там есть, и копирование в промежуточный буфер тоже.
Код РАБОЧИЙ - точка!

Я прошу прощения, если где-то выразился слишком резко.
В том коде, который Вы выложили на форум, копирования нет. Есть только один буффер:
Код:
volatile uint8_t zone3_rx_buffer[ZONE_RX_BUFFER_SIZE];    //Буффер ИК-приемника

Другого кода я не видел. Обсуждать его не берусь. И от этих споров про таймеры я, признаться, подустал.

Думаю, к концу новогодних праздников успею сделать юзабельный смарт-сенсор (не считая промышленных плат). Сегодня доделаю прототип кода для работы с протоколом, в течение ближайших дней ещё будет, что обсудить)


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Умный датчик. Smart sensor.
СообщениеДобавлено: 01 янв 2017, 21:13 
Не в сети
Аксакал форума
Аватар пользователя

Зарегистрирован: 12 авг 2011, 16:55
Сообщений: 7514
Откуда: Барнаул, Алтайский край (не путать с республикой Алтай) :-)
Давайте - сначала описание протокола!
А потом уже код. ;) :)
Чтобы не заниматься "реверс-инженерингом" пытаясь выковырять протокол из исходников.
Я все равно буду реализовывать по своему...

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


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Умный датчик. Smart sensor.
СообщениеДобавлено: 01 янв 2017, 21:32 
Не в сети
Старожил

Зарегистрирован: 18 мар 2015, 13:19
Сообщений: 574
Откуда: Нижний Новгород
Прошу, не редактируйте так сильно посты, пишите лучше новые! Я только отвечу на старый, он уже совсем другой! :)

Pingvin писал(а):
Да.
Нифига Ваш код не короче!
А ну ка все задействованные функции HAL - в студию! :)

Это не смешно :) Хотя если "пионер" (или комсомолец) собирается модифицировать HAL для своих нужд, пожалуй придется разбираться в HAL :) Для того, чтобы понять, как я декодирую сигнал, достаточно знать, что делают две (ДВЕ!) функции из HAL. Это, кстати, написано в коде HAL в комментарии перед каждой функцией очень подробно. И не обязательно быть гуру CMSIS и знать, какие бывают флаги прирываний. Кроме того, перенести на любой другой таймер этот код можно за минуту.

Pingvin писал(а):
Похоже - мы о разных таймаутах говорим! :)
Я о таймауте приема пакета - 15 uS (признак окончания приема пакета).

Именно об этом. Правда у меня число там другое, но - не суть.

Pingvin писал(а):
Цитата:
В упор не виду противоречия. Какие предложения отвергаются? Всё переделать, чтобы было как у вас в прототипе?

Давайте поставим ws2812 - таймеры Вы не сэкономите, как выяснилось, но на две ножки тратите больше.

Давайте прикрутим. Мне без разницы. Я лишь предлагаю поддерживать оба. Ножек и каналов хватит в любом случае, даже если декодировать сигнал четырехканальным таймером, как у Вас, а не одноканальным, как у меня. И останется ещё на "легкий таггер", как хочет LTagKirov.

А если делать оба диода - то я начну с обычных. А Вы - со смарт, если хотите.

Pingvin писал(а):
Давайте - сначала описание протокола!
А потом уже код. ;) :)
Чтобы не заниматься "реверс-инженерингом" пытаясь выковырять протокол из исходников.
Я все равно буду реализовывать по своему...

Нет проблем. Буду рад услышать предложения по командам для протокола. Свои мысли я высказал где-то выше.
Хотите - делайте по-своему, но я пытаюсь реализовать протокол абстрактно от железа, так вы сможете использовать его на CMSIS и SPL.
Как выкачу прототип, опишу.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Умный датчик. Smart sensor.
СообщениеДобавлено: 02 янв 2017, 21:33 
Не в сети
Старожил

Зарегистрирован: 18 мар 2015, 13:19
Сообщений: 574
Откуда: Нижний Новгород
Одна из самых сложных задач решена: однопроводной протокол заработал. Эмулятор повязки на компьютере успешно общается с датчиком. Обращается к нему по адресу и получает из датчика данные, принятые по ИК, если такие имеются.

Теперь набросок протокола, вернее его начало.

Название я пока оставил SSP - Smart Sensor Protocol, потому что в коде уже много где такая аббревиатура.

1. Физический уровень:
Полудуплексный UART. Но можно и другой интерфейс. Все устройства по-умолчанию слушают линию, если не передают в данный момент. Приемник читает входящий поток в буффер. Принятые данные постоянно анализируются, и если они выглядят, как валидный пакет, происходит его обработка. Приемник сбрасывается по таймауту. Это для защиты от наводок и для горячего подключения.

2. Канальный+сетевой уровень:
Пакет = заголовок пакета + аргумент команды (если есть).
Ответный пакет (если предполагается) может передаваться без задержки сразу же.

Определения типов данных и структуры заголовока (выдержка из кода):
Код:
typedef uint16_t SSP_Address;
typedef uint16_t SSP_Command;
typedef uint8_t SSP_Argument_Size;

#pragma pack(push, 1)

typedef struct {
   SSP_Command command;
   SSP_Address target;
   SSP_Argument_Size size;
} SSP_Header;

#pragma pack(pop)

#define SSP_BROADCAST_ADDRESS           ((SSP_Address) 0xFFFF)
#define SSP_MASTER_ADDRESS              ((SSP_Address) 0xFFF0)

Тут, я думаю, все очевидно. Заголовок пакета содержит идентификатор команды, адрес получателя и размер аргумента команды (ноль, если аргумента нет).
Адресация: у каждого сенсора свой индивидуальный двухбайтовый адрес (зачем два байта, почему не хватит одного - напишу позднее). Есть широковещательный, SSP_BROADCAST_ADDRESS == 0xFFFF. Команды, посланные на SSP_BROADCAST_ADDRESS, принимают все датчики.
У повязки всегда конкретный адрес, SSP_MASTER_ADDRESS = 0xFFF0. Гарантируется, что ни у одного датчика такого никогда не будет.

Что конкретно должен сделать датчик, определяется кодом команды (SSP_Header.command) и её аргументом, который идет после заголовка. Гарантируется, что ни один датчик не передает данные по своей инициативе, а только в ответ на пакет-запрос, адресованный лично ему. Широковещательные пакеты не могут запрашивать данные, а могут лишь менять состояние датчиков (например: всем зажечь красный).

Товарищи, есть ли какие-то вопросы и возражения?

3. По прикладному уровню, а также подробнее об адресах и их генерации напишу пост позже. Тогда и обсудим конкретный пересень команд.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Умный датчик. Smart sensor.
СообщениеДобавлено: 02 янв 2017, 22:27 
Не в сети
Аксакал форума
Аватар пользователя

Зарегистрирован: 27 ноя 2011, 00:22
Сообщений: 1569
Откуда: Україна
Что будет если первый байт будет по каким-то причинам утерян? Адрес получателя будет воспринят как команда, аргумент - как адрес, и т.д. ?
Мне кажется надо использовать протокол с старт/стоповыми ограничителями пакета. Ну и какую-то примитивную проверку целостности пакета я бы тоже прикрутил. Хоть обычную сумму байт, хоть по ХОR-у.

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


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Умный датчик. Smart sensor.
СообщениеДобавлено: 02 янв 2017, 23:47 
Не в сети
Старожил

Зарегистрирован: 18 мар 2015, 13:19
Сообщений: 574
Откуда: Нижний Новгород
Pacifist писал(а):
Что будет если первый байт будет по каким-то причинам утерян? Адрес получателя будет воспринят как команда, аргумент - как адрес, и т.д. ?
Мне кажется надо использовать протокол с старт/стоповыми ограничителями пакета. Ну и какую-то примитивную проверку целостности пакета я бы тоже прикрутил. Хоть обычную сумму байт, хоть по ХОR-у.

На данный момент проверка валидности пакета происходит по следующим критериям:
1. Пакет не короче заголовка. Иначе не валидный.
2. Длина пакета == длине заголовка + размеру аргумента, указанному в заголовке. Иначе не валидный.
3. Адрес получателя корректный (либо мой, либо - широковещательный)

Если потеряется байт-другой, то маловероятно, что условия 2 и 3 одовременно смогут выполнится. Для этого нужно, чтобы случайно правильными оказалось аж 3 байта (2 адрес + 1 длина аргумента). Думаю, контрольная сумма здесь уже излишняя мера. Остается ещё ситуация, когда команда или аргумент команды изменится из-за наводок, а адрес и размер аргумента останутся прежними. Считаете, стоит добавить для такого случая сумму?

Стартовые и стоповые байты не получится использовать, поскольку через протокол будет передаваться пакет, принятый по ИК, а в нем могут оказаться любые байты :(


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Умный датчик. Smart sensor.
СообщениеДобавлено: 03 янв 2017, 00:00 
Не в сети
Аксакал форума
Аватар пользователя

Зарегистрирован: 27 ноя 2011, 00:22
Сообщений: 1569
Откуда: Україна
Alexies писал(а):
Pacifist писал(а):
Что будет если первый байт будет по каким-то причинам утерян? Адрес получателя будет воспринят как команда, аргумент - как адрес, и т.д. ?
Мне кажется надо использовать протокол с старт/стоповыми ограничителями пакета. Ну и какую-то примитивную проверку целостности пакета я бы тоже прикрутил. Хоть обычную сумму байт, хоть по ХОR-у.

На данный момент проверка валидности пакета происходит по следующим критериям:
1. Пакет не короче заголовка. Иначе не валидный.
2. Длина пакета == длине заголовка + размеру аргумента, указанному в заголовке. Иначе не валидный.
3. Адрес получателя корректный (либо мой, либо - широковещательный)

Если потеряется байт-другой, то маловероятно, что условия 2 и 3 одовременно смогут выполнится. Для этого нужно, чтобы случайно правильными оказалось аж 3 байта (2 адрес + 1 длина аргумента). Думаю, контрольная сумма здесь уже излишняя мера. Остается ещё ситуация, когда команда или аргумент команды изменится из-за наводок, а адрес и размер аргумента останутся прежними. Считаете, стоит добавить для такого случая сумму?

Стартовые и стоповые байты не получится использовать, поскольку через протокол будет передаваться пакет, принятый по ИК, а в нем могут оказаться любые байты :(


ИМХО лучше не создавать устройства, в которых потом приходится думать "а не совпадёт ли команда с адресом устройства" и т.д. Потому что мало ли... Вы пока полагаетесь на быструю передачу сообщений с известной длинной и достатоно большим интервалом между ними.
Но ведь возможна ситуация что вполне скоро кто-то решит из вашего проводного сенсора сделать беспроводный и прикрутит к нему какой-то ЮАРТ-мост типа НС-06. А у него уже есть свои лаги. Он насобирает запросов и отправит их слейву одной пачкой. Если не засветится какой-то светодиод - фиг с ним. А если потеряется ИК пакет - будут игроки бить морды друг-другу и кричать "читер" :).
Это так, лирика. Как разработчик видит своё устройство - так он его и сделает :)

Alexies писал(а):
...Стартовые и стоповые байты не получится использовать, поскольку через протокол будет передаваться пакет, принятый по ИК, а в нем могут оказаться любые байты :(
Так я том же. Рассмотрите ситуацию когда пакет начал приниматься не строго с начала. Данные идут чистым бинарником, то есть любой байт может быть принят как начало пакета, а любой мусор наводками либо коллизия на шине - как его продолжение. Помните гипотезу про печатные машинки, обезьян и "войну и мир" ? :)
Если я бы сегодня делал протокол повязки - то запихнул бы сам пакет в Base64, а любые 2 символа, которые в нём не используются использовал как старт/стоповые.

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


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Умный датчик. Smart sensor.
СообщениеДобавлено: 03 янв 2017, 10:34 
Не в сети
Аксакал форума
Аватар пользователя

Зарегистрирован: 12 авг 2011, 16:55
Сообщений: 7514
Откуда: Барнаул, Алтайский край (не путать с республикой Алтай) :-)
Pacifist писал(а):
Что будет если первый байт будет по каким-то причинам утерян? Адрес получателя будет воспринят как команда, аргумент - как адрес, и т.д. ?
Мне кажется надо использовать протокол с старт/стоповыми ограничителями пакета. Ну и какую-то примитивную проверку целостности пакета я бы тоже прикрутил. Хоть обычную сумму байт, хоть по ХОR-у.

Согласен

Alexies писал(а):

Стартовые и стоповые байты не получится использовать, поскольку через протокол будет передаваться пакет, принятый по ИК, а в нем могут оказаться любые байты :(


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

Ну например, чтобы передать содержимое одного байта информации в шестнадцатеричном виде потребуется два символа.
255 = "FF"
И ввести служебные символы, которые вне диапазона 0-9, A-F
И никогда мы их не перепутаем с данными.


Ну если не охота переходить на символьно-оринтированный протокол, надо такую преамбулу сделать, вероятность появления которой в потоке данных близка к нулю.

Ниже протокол, который я использую в Андроид-приложениях.


Вложения:
Protocol.jpg
Protocol.jpg [ 55.51 KiB | Просмотров: 8093 ]

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


Последний раз редактировалось Pingvin 03 янв 2017, 11:55, всего редактировалось 2 раз(а).
Вернуться наверх
 Профиль  
 
Показать сообщения за:  Сортировать по:  
Начать новую тему Ответить на тему  [ Сообщений: 169 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8, 9, 10 ... 17  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8


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

Найти:
Перейти:  
cron
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB