Ранее мы определились с возможностями 1W-IR сети и со способом передачи информации по ней. Пришло время определиться с форматом посылки (кадром сообщения), посредством которой устройства будут взаимодействовать между собой. Это очень важный и ответственный вопрос, так как формат посылки фактически определит, как будет функционировать сеть в целом.
Тайминги и состав посылки выглядит так:
Посылка состоит из отдельных частей:
1 Пилот – это последовательность из 4 периодов. По умолчанию пилот должен передать биты в следующей последовательности 0 > 0 > 1 > 0 (то есть третий, референтный период должен быть единичным). Если необходимо сделать пилот более длительный (например, для того чтобы дать время приемному устройству выйти из спящего режима) допустимо первые два периода увеличивать вплоть до 10мС. Третий период обязательно должен быть длительностью единицы — он используется как референтное значение в алгоритме.
2 Сразу после пилота, без пауз, начинается передача 4 служебных бит. Это поле используется для идентификации типа посылки (передача данных, запрос данных, информационное сообщение …)
3 Адрес — один байт. Идентифицирует номер устройства которое передает сообщение (или номер устройства для которого сообщение передается). Очевидно, устройств может быть не более 255 (скорей всего и того меньше — некоторые адреса будут использованы в служебных целях)
4 Далее идут 16 бит (2 байта) данных. Тут без вариантов – в одном байте даже показания градусника толком не передашь.
5 Далее 8 бит — циклический избыточный код – CRC8. В виду того, что передача по IR-каналу будет подвержена помехам (IR-пульты, слепые устройства сети, импульсные помехи освещения …) без контроля целостности посылки никак не обойтись. Дабы не изобретать велосипед вариант CRC8 будет позаимствован у 1-wire сети Dallas (полином 0x31).
6 Последним идет один импульс окончания посылки. Он нужен лишь для того, чтобы отобразить длительность последнего бита сообщения.
Всего сообщение состоит из 41 импульса. Длина пакета, в среднем — 33мС.
Ethernet пока трогать не планирую — есть много других интересных идей которые стоят в очереди и дожидаются пока ими займутся.
Извиняюсь, что вопрос не совсем по теме. А планируете ли Вы описать связь контроллера с ПК через Ethernet. И если да, то как скоро. Просто очень интересно и нужно.
http://tuxotronic.org/wiki/protocol/linkbell — возможно будет полезно?
Это то, над чем я ломаю голову в данный момент. Конечно без некоторого упрощения не обойтись.
Проблему с несколькими однотипными устройствами, я думаю, придется решать следующим образом. Чтобы не организовывать двусторонние переговоры устройств между собой, устройства кроме своего типа будут передавать в сеть и определенный номер-идентификатор который, по предварительной договоренности, будет сообщать о том как воспринимать это устройство. Каждый участник сети принимает все сообщения от всех устройств и сам решает (исходя из идентификатора посылки) нужно ему это сообщение или нет и как его использовать.
Например, для градусника этот номер можно идентифицировать по расстоянию:
1 — температура в рабочей зоне(например температура паяльника);
2 — температура на рабочем месте (например температура корпуса устройства);
3 — температура в комнате
4 — температура за пределами комнаты (на улице)
— чем больше номер тем больше удаление …
Если дисплеев в сети несколько, каждый дисплей будет принимать информацию от всех градусников и каждому конкретному дисплею придется решать, что он будет отображать.
Этот вопрос — ключевой вопрос сети и, фактически, его решение определит как будет функционировать сеть. Жду Вашего участия! >> http://www.forum.getchip.net/viewtopic.php?f=8&t=17
Не совсем понятно как например один из трех термометров будет знать, на какой из трех дисплеев ему посылать информацию? Что, каждое устройство настраивать на этапе прошивки? Или вводить специальные команды и настраивать устройства «на лету», типа «ты — термометр, и ты должен отправлять данные по адресу такому-то!» ? Тогда не понятно как например двухстрочный дисплей будет знать какую строку он получил и куда ее выводить? Или тоже настраивать его типа «данные с этого адреса помещай вот сюда»? Или так и запланировано, а я просто туплю?
Для сообщений небольшой длины CRC8 хватает за глаза! CRC16 практически не улучшит распознавание ошибок.
Только их надо сделать разными.
В данном случае это именно пилот сигнал 🙂
Приветствую. А случаи бывают разные, бывает и так. Что помеховая обстановка на обьекте та еще. Либо у клиента серьезные требования к надежности, а необходимости в высокой скорости нет. В связи с этим интересно было бы иметь два варианта. На CRC8, и на CRC16. С тем, что бы был выбор. Надо большую скорость, и экономичность — CRC8. Надо высокую надежность — а вот уже и готов, и есть под рукой вариант на CRC16.
Ну пилот, пилотом. Но обычно их называют старт стоп биты. Но идея хорошая, подстройка по частоте во время передачи по пилот сигналу — это гут.
Импульс окончания передачи, на самом деле, ее не оканчивает. Он нужен лишь для того, чтобы «показать» длительность последнего информационного периода.
Передача будет считаться оконченной если длительность паузы (периода) будет больше 10-16 мС — это нужно для того, чтобы принимать одним кодом и посылки сети и посылки пультов. Да, знаю, слегка через одно место, но зато экономно.
P.S. А может и вправду сделать окончание пилотной последовательностью? Подумаю …
ИМХО вместо одиночного импульса окончания передачи. Нужно то-же использовать пилот сигнал. Иначе из-за помех пропустите и устройство будет ждать продолжение сигнала.