www.open-tager.ru http://www.open-tager.ru/forum/ |
|
Умный датчик. Smart sensor. http://www.open-tager.ru/forum/viewtopic.php?f=5&t=4949 |
Страница 7 из 17 |
Автор: | Alexies [ 01 янв 2017, 20:50 ] |
Заголовок сообщения: | Re: Умный датчик. Smart sensor. |
Предлагаю дальнейшие технические детали обсуждать лично, через ВКонтакте или по скайпу. Писать такие посты много времени отнимает |
Автор: | Pingvin [ 01 янв 2017, 20:55 ] |
Заголовок сообщения: | Re: Умный датчик. Smart sensor. |
Цитата: Вы правда считаете, что в вашем коде, который в 2 раза длиннее (300 строк против 150), с неправильными отступами, без API и огромным количеством вложенных if-ов в обработчике прирываний пионер разберется быстрее? Да. Нифига Ваш код не короче! А ну ка все задействованные функции HAL - в студию! то не "прототип кода" - это кусочек рабочего кода! Все там (откуда скопипастил) есть, и копирование в промежуточный буфер тоже - в соответствующей задаче. Код РАБОЧИЙ - точка! Похоже - мы о разных таймаутах говорим! Я о таймауте приема пакета - 15 uS (признак окончания приема пакета). Вы, вероятно - имеете ввиду разницу во времени между приемами пакетов? Это у меня тоже обрабатывается, но пока тут не скажу как. Цитата: В упор не виду противоречия. Какие предложения отвергаются? Всё переделать, чтобы было как у вас в прототипе? Давайте поставим ws2812 - таймеры Вы не сэкономите, как выяснилось (я использую один канал, вы - 3 канала), и на две ножки тратите больше. |
Автор: | Alexies [ 01 янв 2017, 21:07 ] |
Заголовок сообщения: | Re: Умный датчик. Smart sensor. |
Pingvin писал(а): Это не "прототип кода" - это урезаный кусочек рабочего кода! Все там есть, и копирование в промежуточный буфер тоже. Код РАБОЧИЙ - точка! Я прошу прощения, если где-то выразился слишком резко. В том коде, который Вы выложили на форум, копирования нет. Есть только один буффер: Код: volatile uint8_t zone3_rx_buffer[ZONE_RX_BUFFER_SIZE]; //Буффер ИК-приемника Другого кода я не видел. Обсуждать его не берусь. И от этих споров про таймеры я, признаться, подустал. Думаю, к концу новогодних праздников успею сделать юзабельный смарт-сенсор (не считая промышленных плат). Сегодня доделаю прототип кода для работы с протоколом, в течение ближайших дней ещё будет, что обсудить) |
Автор: | Pingvin [ 01 янв 2017, 21:13 ] |
Заголовок сообщения: | Re: Умный датчик. Smart sensor. |
Давайте - сначала описание протокола! А потом уже код. Чтобы не заниматься "реверс-инженерингом" пытаясь выковырять протокол из исходников. Я все равно буду реализовывать по своему... |
Автор: | Alexies [ 01 янв 2017, 21:32 ] |
Заголовок сообщения: | Re: Умный датчик. Smart sensor. |
Прошу, не редактируйте так сильно посты, пишите лучше новые! Я только отвечу на старый, он уже совсем другой! Pingvin писал(а): Да. Нифига Ваш код не короче! А ну ка все задействованные функции HAL - в студию! Это не смешно Хотя если "пионер" (или комсомолец) собирается модифицировать HAL для своих нужд, пожалуй придется разбираться в HAL Для того, чтобы понять, как я декодирую сигнал, достаточно знать, что делают две (ДВЕ!) функции из HAL. Это, кстати, написано в коде HAL в комментарии перед каждой функцией очень подробно. И не обязательно быть гуру CMSIS и знать, какие бывают флаги прирываний. Кроме того, перенести на любой другой таймер этот код можно за минуту. Pingvin писал(а): Похоже - мы о разных таймаутах говорим! Я о таймауте приема пакета - 15 uS (признак окончания приема пакета). Именно об этом. Правда у меня число там другое, но - не суть. Pingvin писал(а): Цитата: В упор не виду противоречия. Какие предложения отвергаются? Всё переделать, чтобы было как у вас в прототипе? Давайте поставим ws2812 - таймеры Вы не сэкономите, как выяснилось, но на две ножки тратите больше. Давайте прикрутим. Мне без разницы. Я лишь предлагаю поддерживать оба. Ножек и каналов хватит в любом случае, даже если декодировать сигнал четырехканальным таймером, как у Вас, а не одноканальным, как у меня. И останется ещё на "легкий таггер", как хочет LTagKirov. А если делать оба диода - то я начну с обычных. А Вы - со смарт, если хотите. Pingvin писал(а): Давайте - сначала описание протокола! А потом уже код. Чтобы не заниматься "реверс-инженерингом" пытаясь выковырять протокол из исходников. Я все равно буду реализовывать по своему... Нет проблем. Буду рад услышать предложения по командам для протокола. Свои мысли я высказал где-то выше. Хотите - делайте по-своему, но я пытаюсь реализовать протокол абстрактно от железа, так вы сможете использовать его на CMSIS и SPL. Как выкачу прототип, опишу. |
Автор: | Alexies [ 02 янв 2017, 21:33 ] |
Заголовок сообщения: | Re: Умный датчик. Smart sensor. |
Одна из самых сложных задач решена: однопроводной протокол заработал. Эмулятор повязки на компьютере успешно общается с датчиком. Обращается к нему по адресу и получает из датчика данные, принятые по ИК, если такие имеются. Теперь набросок протокола, вернее его начало. Название я пока оставил 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. По прикладному уровню, а также подробнее об адресах и их генерации напишу пост позже. Тогда и обсудим конкретный пересень команд. |
Автор: | Pacifist [ 02 янв 2017, 22:27 ] |
Заголовок сообщения: | Re: Умный датчик. Smart sensor. |
Что будет если первый байт будет по каким-то причинам утерян? Адрес получателя будет воспринят как команда, аргумент - как адрес, и т.д. ? Мне кажется надо использовать протокол с старт/стоповыми ограничителями пакета. Ну и какую-то примитивную проверку целостности пакета я бы тоже прикрутил. Хоть обычную сумму байт, хоть по ХОR-у. |
Автор: | Alexies [ 02 янв 2017, 23:47 ] |
Заголовок сообщения: | Re: Умный датчик. Smart sensor. |
Pacifist писал(а): Что будет если первый байт будет по каким-то причинам утерян? Адрес получателя будет воспринят как команда, аргумент - как адрес, и т.д. ? Мне кажется надо использовать протокол с старт/стоповыми ограничителями пакета. Ну и какую-то примитивную проверку целостности пакета я бы тоже прикрутил. Хоть обычную сумму байт, хоть по ХОR-у. На данный момент проверка валидности пакета происходит по следующим критериям: 1. Пакет не короче заголовка. Иначе не валидный. 2. Длина пакета == длине заголовка + размеру аргумента, указанному в заголовке. Иначе не валидный. 3. Адрес получателя корректный (либо мой, либо - широковещательный) Если потеряется байт-другой, то маловероятно, что условия 2 и 3 одовременно смогут выполнится. Для этого нужно, чтобы случайно правильными оказалось аж 3 байта (2 адрес + 1 длина аргумента). Думаю, контрольная сумма здесь уже излишняя мера. Остается ещё ситуация, когда команда или аргумент команды изменится из-за наводок, а адрес и размер аргумента останутся прежними. Считаете, стоит добавить для такого случая сумму? Стартовые и стоповые байты не получится использовать, поскольку через протокол будет передаваться пакет, принятый по ИК, а в нем могут оказаться любые байты |
Автор: | Pacifist [ 03 янв 2017, 00:00 ] |
Заголовок сообщения: | Re: Умный датчик. Smart sensor. |
Alexies писал(а): Pacifist писал(а): Что будет если первый байт будет по каким-то причинам утерян? Адрес получателя будет воспринят как команда, аргумент - как адрес, и т.д. ? Мне кажется надо использовать протокол с старт/стоповыми ограничителями пакета. Ну и какую-то примитивную проверку целостности пакета я бы тоже прикрутил. Хоть обычную сумму байт, хоть по ХОR-у. На данный момент проверка валидности пакета происходит по следующим критериям: 1. Пакет не короче заголовка. Иначе не валидный. 2. Длина пакета == длине заголовка + размеру аргумента, указанному в заголовке. Иначе не валидный. 3. Адрес получателя корректный (либо мой, либо - широковещательный) Если потеряется байт-другой, то маловероятно, что условия 2 и 3 одовременно смогут выполнится. Для этого нужно, чтобы случайно правильными оказалось аж 3 байта (2 адрес + 1 длина аргумента). Думаю, контрольная сумма здесь уже излишняя мера. Остается ещё ситуация, когда команда или аргумент команды изменится из-за наводок, а адрес и размер аргумента останутся прежними. Считаете, стоит добавить для такого случая сумму? Стартовые и стоповые байты не получится использовать, поскольку через протокол будет передаваться пакет, принятый по ИК, а в нем могут оказаться любые байты ИМХО лучше не создавать устройства, в которых потом приходится думать "а не совпадёт ли команда с адресом устройства" и т.д. Потому что мало ли... Вы пока полагаетесь на быструю передачу сообщений с известной длинной и достатоно большим интервалом между ними. Но ведь возможна ситуация что вполне скоро кто-то решит из вашего проводного сенсора сделать беспроводный и прикрутит к нему какой-то ЮАРТ-мост типа НС-06. А у него уже есть свои лаги. Он насобирает запросов и отправит их слейву одной пачкой. Если не засветится какой-то светодиод - фиг с ним. А если потеряется ИК пакет - будут игроки бить морды друг-другу и кричать "читер" . Это так, лирика. Как разработчик видит своё устройство - так он его и сделает Alexies писал(а): ...Стартовые и стоповые байты не получится использовать, поскольку через протокол будет передаваться пакет, принятый по ИК, а в нем могут оказаться любые байты Так я том же. Рассмотрите ситуацию когда пакет начал приниматься не строго с начала. Данные идут чистым бинарником, то есть любой байт может быть принят как начало пакета, а любой мусор наводками либо коллизия на шине - как его продолжение. Помните гипотезу про печатные машинки, обезьян и "войну и мир" ? Если я бы сегодня делал протокол повязки - то запихнул бы сам пакет в Base64, а любые 2 символа, которые в нём не используются использовал как старт/стоповые. |
Автор: | Pingvin [ 03 янв 2017, 10:34 ] | ||
Заголовок сообщения: | Re: Умный датчик. Smart sensor. | ||
Pacifist писал(а): Что будет если первый байт будет по каким-то причинам утерян? Адрес получателя будет воспринят как команда, аргумент - как адрес, и т.д. ? Мне кажется надо использовать протокол с старт/стоповыми ограничителями пакета. Ну и какую-то примитивную проверку целостности пакета я бы тоже прикрутил. Хоть обычную сумму байт, хоть по ХОR-у. Согласен Alexies писал(а): Стартовые и стоповые байты не получится использовать, поскольку через протокол будет передаваться пакет, принятый по ИК, а в нем могут оказаться любые байты Решается использованием символьно-ориентированного протокола. Такой протокол работает на Аскете и Армаде для обмена по блютус. Да - время передачи увеличится, зато парсить можно "на лету", не дожидаясь получения всего пакета (не критичен к большим лагам). Ну например, чтобы передать содержимое одного байта информации в шестнадцатеричном виде потребуется два символа. 255 = "FF" И ввести служебные символы, которые вне диапазона 0-9, A-F И никогда мы их не перепутаем с данными. Ну если не охота переходить на символьно-оринтированный протокол, надо такую преамбулу сделать, вероятность появления которой в потоке данных близка к нулю. Ниже протокол, который я использую в Андроид-приложениях.
|
Страница 7 из 17 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |