|
SLP - последовательный протокол, Еще один велосипед |
|
|
|
 |
Ответов
|
Oct 5 2008, 14:53
|

Местный
  
Группа: Свой
Сообщений: 226
Регистрация: 2-06-06
Пользователь №: 17 720

|
как-то все сложно и запутанно, какие-то stuff-коды и т.п... я сделал проще - полудуплексный протокол с пакетами переменной длины и станд. заголовком :
заколовок пакета:
u16 packet_size - размер (включая CRC), u8 node_from - адрес узла-отправителя, u8 node_to - адрес узла-получателя, u16 cmd - команда/тип пакета, ......... - данные пакета, индивидуальные для каждой команды, u16 crc - к.с. пакета (так как нет никакого стаффинга, считается на лету при приеме/передаче каждого байта).
10 старших бит команды отведены для типа устройства, если равны 0 - команда универсальная, должна поддерживаться всеми устройствами (напр. получение текущего статуса устройства, проверка прохождения данных, получение информации о устройстве - тип, версия п.о., серийный номер, размер приемного буфера и т.д.), младшие 6 бит - собственно код команды.
есть библ. на С на контроллеров (прием/передача встраиваются в преорывания RX,TX, плюс прерывание таймера для контроля тайм-аута приема и паузы перед передачей отв. пакета, вся обработка - в осн.цикле по флагам готовности пакета), библ. на Питоне для приема/передачи/расшифровки пакетов.
|
|
|
|
|
Oct 5 2008, 15:51
|
Гуру
     
Группа: Участник
Сообщений: 3 928
Регистрация: 28-03-07
Из: РФ
Пользователь №: 26 588

|
Цитата(umup @ Oct 5 2008, 14:53)  u16 crc - к.с. пакета (так как нет никакого стаффинга, считается на лету при приеме/передаче каждого байта). Да, CRC считается только от данных, без учета стаффинга, поэтому тоже "на лету". packet_size - зло. Я долго бился над его оптимизацией, а теперь, отказавшись, понимаю, что без него все гораздо прямее. node_from - вот с этим вопрос открыт. Пока нет необходимости, поэтому не могу привести случаи, когда оно могло бы пригодиться. В большей степени кажется необходимым иметь не адрес мастера, а адрес шины, с которой получили пакет, для возможности маршрутизации. Маршрутизация уже сейчас напрашивается, хоть по-идее не является необходимой для сабжевого типа шин.
|
|
|
|
|
Oct 5 2008, 16:45
|

Местный
  
Группа: Свой
Сообщений: 226
Регистрация: 2-06-06
Пользователь №: 17 720

|
Цитата(Огурцов @ Oct 5 2008, 18:51)  packet_size - зло. Я долго бился над его оптимизацией, а теперь, отказавшись, понимаю, что без него все гораздо прямее. а как контролировать завершение приема пакета ? сравнивать к.с. для каждого байта ? Цитата node_from - вот с этим вопрос открыт. Пока нет необходимости, поэтому не могу привести случаи, когда оно могло бы пригодиться. В большей степени кажется необходимым иметь не адрес мастера, а адрес шины, с которой получили пакет, для возможности маршрутизации. Маршрутизация уже сейчас напрашивается, хоть по-идее не является необходимой для сабжевого типа шин. модет пригодится, например для мульти-мастерной сети
|
|
|
|
|
Oct 5 2008, 17:19
|
Гуру
     
Группа: Участник
Сообщений: 3 928
Регистрация: 28-03-07
Из: РФ
Пользователь №: 26 588

|
Цитата(umup @ Oct 5 2008, 16:45)  а как контролировать завершение приема пакета ? сравнивать к.с. для каждого байта ? Дыкть, специально для этого символ предусмотрен - Slp_packet_end. А вот Вы как обнаруживаете начало пакета, тот байт, в котором packet_size ? Что будете делать, если пакет придет наполовину, как начало следующего ловить ? Цитата(umup @ Oct 5 2008, 16:45)  модет пригодится, например для мульти-мастерной сети Так наверно мастрера сами разберутся, кто какие запросы отправлял и будут ловить предназначенные им ответы. Шина общая и запросы по-любому должны идти друг за другом, а не одновременно, и ответы не перепутаются, даже если запросы будут одинаковые но от разных мастеров.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|