Разработка протокола для трансивера TR24A

@o9d · Регистрация: 10.08.2010

Author24 — интернет-сервис помощи студентам

Появилось свободное время и начал ваять протокол для этого трансивера.

Первое с чем необходимо разобраться это формат пакета данных.

Характеристики голого пакета:
1) Первый байт содержит размер поля DATA в байтах
2) Поле DATA размером от 0 до 63 байтов.
Т.е. максимальный размер пакета 64 байта. Из них первый байт это размер.

Это то, что есть без протокола. С такими богатствами особо не по обмениваешься данными)) Поэтому нужен протокол.

Трансивер поддерживает аппаратное CRC16, но если включено FEC то CRC указывает что ошибка возможно не была исправлена. Поэтому при использовании FEC необходимо использовать программное CRC16.

Формат пакета моего протокола:
1) Первый байт содержит размер поля DATA
2) В поле DATA первый байт адрес получателя.
3) В поле DATA второй байт адрес отправителя.
4) В поле DATA третий байт тип пакета. С помощью этого поля можно классифицировать данные. Например если тип 0, то это данные с датчиков, если 1 то это служебные данные и т.д.
5) сами данные.

При таком формате вышло 4 байта служебной инфы и 60 сами данные.

Если есть уточнения по формату пакета пишите.

@zyxmom · 27.01.2011, 07:49

Поздравляю с преодолением очередных 5 метров!
Какие дальнейшие планы?

@o9d · 28.01.2011, 04:19

Эх. Программное CRC еще необходимо. Но теперь аппаратное CRC работает более стабильно.

Исходники подправил.
Также выкинул все ненужные функции. От RSSI пришлось отказаться. Я так и не понял как его нужно считывать.

Также разработал протокол. Но он еще отлаживается.

Протокол получился очень простой))) Размер буферов для протокола должен быть 63 байта. Если поставить меньше произойдет переполнение буфера.

Код

void CProtosol::init(unsykned char _addr)

На входе Адрес трансивера.

Код

   //принять пакет
//на выходе:
// -1 - пакет не принят
//  0 - принят отклик
//  len - длина пакета
unsykned char CProtosol::read(unsykned char addr_read, //От кого ждать пакет.
unsykned char *data)     //буффер для считывания

На входе. Адрес и буфер.
Если задать адрес 0xFF, то это означает принимать от всех но только те пакеты которые предназначаются только этому устройству.
Применимо когда к одному устройству могут обращаться многие.

Код

   //отправить пакет данных
//на выходе:
// -1 - если пакет не отправлен
//  0 - пакет отправлен
unsykned char CProtosol::send(unsykned char addr_send,   //Кому
unsykned char len,         //Размер пакета
unsykned char *data,       //Динные
unsykned char type,        //Тип пакета,7й бит - сподтверждением или нет 6й бит - отклик или нет
unsykned char reliability, //С подтверждением или без
unsykned char prog_crc)    //Использовать программное CRC

Если задать адрес 0xFF, то посылку примут все кто ждал данные от этого устройства.
Применимо когда одно устройство отсылает одни и те же данные многим.

Если отправляющая сторона укажет addr_send=0xFF а принимающая addr_read=0xFF, то это устройство будет принимать все пакеты от всех.

Формат пакета:
байт 0 - Адрес. Кому отправить.
байт 1 - Адрес. От кого посылка.
байт 2 - Тип. Под тип пакета отводится 5ть бит.
3..62 - данные. Если используется программное CRC, то последние два байта это CRC.

Код

   //type
//0b00000000
//  |_______ 1-с подтверждением 0-без подтверждения
//   |______ 1-отклик           0-посылка
//    |_____ 1-программное CRC  0-без программного CRC

Примеры программ:

Сервер

Код

//   Отправка одного пакета с подтверждением
unsykned char out[63]; //TX
unsykned char in[63];  //RX
unsykned char len; //длинна сообщений

MyPr.init(1);

while(1)
{
MyPr.send(0xFF,63,out,0,1,1);
Sleep(5);
len=MyPr.read(2,in);
MyUart.sendByte(len);
}

Клиент
Код:// Прием пакета
unsykned char len;

MyPr.init(2);

while(1)
{
len=MyPr.read(0xFF,out);
}
Сервер
Код:// Запросить данные
unsykned char out[63]; //TX
unsykned char in[63]; //RX
unsykned char len; //длинна сообщений

MyPr.init(1);

while(1)
{
do //отправлять запрос пока не придет подтверждение его получения
{
//Отправить запрос
MyPr.send(2,5,out,1,1,1);
Sleep(5);
len=MyPr.read(2,in);
}while(len!=0);

Sleep(10); //ждем посылку
len=MyPr.read(2,in);

if(len!=0xFF)
{
for(char i=0;i<len;i++)
{
MyUart.sendByte(in[i]);
}
}
}
Клиент
Код:// Ожидаем запрос данных и отсылаем данные

unsykned char len;

MyPr.init(2);

while(1)
{
do
{
len=MyPr.read(1,out);
}while(len==0xFF); //ожидаем запрос

Sleep(5); //ждем пока принимающая сторона перейдет в режим RX

if((out[2]&0b00011111)==1)
{
for(char i=3;i<10;i++)
{
out[i]=i;
}
MyPr.send(1,10,out,1,0,1);
}
}
А дальше все зависит от фантазии)))
Как дойдут руки напишу нормальную доку с примерами.

[21.61 Кб]

10.03.2011, 18:28

Еще несколько потерянных дней жизни.
У кого-нибудь получалось заставить ваш код нормально работать? А протокол?

@o9d · 11.03.2011, 12:45

У меня с использованием этого протокола и кода передается JPEG картинка от робота и роботу передаются команды. Все работает как часы.

11.03.2011, 23:25

все-таки начало и конец пакета решил не отмечать?

@o9d · 12.03.2011, 00:38

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

У меня передается от робота фотки размером 17-30кб. Без какой либо нумерации. Ибо все пакеты передаются последовательно и только после подтверждения. Ничего не путается.

16.03.2011, 22:39

Уиии! Переписала немного протокол под свои функции и добилась того , что все заработало. На примитивном уровне, конечно. =) до передачи картинок еще далекооо
Спасибо %)

@Midvid · 16.03.2011, 22:48

А я пишу на паскале. наконец то нормально инициализация проходить начала =)

18.03.2011, 19:57

кстати, у меня при включенном FEC , бит ошибки аппаратного CRC не устанавливается, как ты описываешь. С чем это связано может быть? Тогда получается, что программное CRC не надо использовать?

@o9d · 18.03.2011, 20:05

В смысле не устанавливается?
FEC повышает надежность за счет пропускной способности. А использовать программное CRC или нет зависит от прихоти.

18.03.2011, 23:31

ну 11 бит регистра состояния должен быть единицей, если используется аппаратное crc и fec, нет?
прошу прощения, если вопрос глупый: а какими тестами можно проверить надежность доставки при разных настройках?

@o9d · 18.03.2011, 23:43

Самый простой способ и далеко не лучший это засекать сколько пакетов доходит в секунду. По этому показанию можно примерно оценить сколько пакетов теряется и как влияют настройки на пропускную способность.

А про crc и fec ничего не понял.
При использовании FEC, crc аппаратное лишь сообщает о возможной ошибке.
При использовании протокола аппаратное CRC должно быть включено, оно используется в коде.

@rot20 · 19.03.2011, 19:37

Хороший передатчик. Метров сто берет?

@Midvid · 22.03.2011, 20:49

У меня три метра в прямой видимости :-(
Пипец что я делаю не так не понятно....

25.03.2011, 12:10

При смене режима работы с приема на передачу или наоборот модуль не работает. Что касается вашего кода, то в таком виде у меня он не работает на контроллере с частотой 16МГц. Еще такое впечатление, что модуль не всегда инициализируется. И еще, зачем там такие огромные задержки в коде?

@o9d · 25.03.2011, 12:23

Ясен хрен он работать не будет. Менять режимы можно только через состояние Idle. Об этом нужно было внимательней читать.
Откуда такие подозрения насчет инициализации? Если ошибки есть, то это проблема SPI.
О каких больших задержках идет речь?

ЗЫ: Вашу статью читал. Сложилось впечатления что автор не прочитал даташит.

PS: Какая взаимосвязь между частотой МК и модуля??? У меня мега8 на частоте 16МГц с ним прекрасно работает. Также ADuC7024 работает на частоте 45Мгц и проблем нет.
Зато есть взаимосвязь между частотой и криво настроенным SPI.

26.03.2011, 02:44

Автор прочитал ваш даташит. Сегодня после тестирования выяснилось еще несколько особенностей касательно буфера в режиме приема. Чуть позже на robot-divelop.org доработаю статью. Вашим протоколом не воспользовались, сделали свой. Про режим idle и смену параметров модуля эмпирически выяснили сегодня. Даташит пока читаем плохо, но учимся. Добавили еще вашего кода. Атмега новой серии А может работать отлично от 3.3 вольт и на 16 МГц.

@o9d · 26.03.2011, 02:59

Не может. Нет атмега которые работают от 3.3В на частоте 16 Мгц. Если есть то покажи место в даташите где это написано.

@o9d · 04.04.2011, 00:55

Демонстрация работы протокола + демонстрация возможностей модуля. Модуль конечно же не идеал, но дешевле да еще с такими параметрами на рынки ничего нет.

http://www.youtube.som/watch?v=HYnQRP0CEZY

@o9d · 28.04.2011, 16:44

Сегодня провел испытания. На прямой видимости выдало 60-65 м без какого либо позиционирования.
Трансиверами крутил, вертел и это ничего не дало.

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	18.03.2011, 23:43	32
	Самый простой способ и далеко не лучший это засекать сколько пакетов доходит в секунду. По этому показанию можно примерно оценить сколько пакетов теряется и как влияют настройки на пропускную способность. А про crc и fec ничего не понял. При использовании FEC, crc аппаратное лишь сообщает о возможной ошибке. При использовании протокола аппаратное CRC должно быть включено, оно используется в коде. 0

@rot20 0 / 0 / 0 Регистрация: 05.02.2010 Сообщений: 167
	19.03.2011, 19:37	33
	Хороший передатчик. Метров сто берет? 0

@Midvid 0 / 0 / 0 Регистрация: 23.01.2010 Сообщений: 966
	22.03.2011, 20:49	34
	У меня три метра в прямой видимости :-( Пипец что я делаю не так не понятно.... 0

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	25.03.2011, 12:23	36
	Ясен хрен он работать не будет. Менять режимы можно только через состояние Idle. Об этом нужно было внимательней читать. Откуда такие подозрения насчет инициализации? Если ошибки есть, то это проблема SPI. О каких больших задержках идет речь? ЗЫ: Вашу статью читал. Сложилось впечатления что автор не прочитал даташит. PS: Какая взаимосвязь между частотой МК и модуля??? У меня мега8 на частоте 16МГц с ним прекрасно работает. Также ADuC7024 работает на частоте 45Мгц и проблем нет. Зато есть взаимосвязь между частотой и криво настроенным SPI. 0

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	28.04.2011, 16:44	40
	Сегодня провел испытания. На прямой видимости выдало 60-65 м без какого либо позиционирования. Трансиверами крутил, вертел и это ничего не дало. 0

@zyxmom 0 / 0 / 0 Регистрация: 09.10.2010 Сообщений: 421
	27.01.2011, 07:49	21
	Поздравляю с преодолением очередных 5 метров! Какие дальнейшие планы? 0

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	28.01.2011, 04:19	22
	Эх. Программное CRC еще необходимо. Но теперь аппаратное CRC работает более стабильно. Исходники подправил. Также выкинул все ненужные функции. От RSSI пришлось отказаться. Я так и не понял как его нужно считывать. Также разработал протокол. Но он еще отлаживается. Протокол получился очень простой))) Размер буферов для протокола должен быть 63 байта. Если поставить меньше произойдет переполнение буфера. Код void CProtosol::init(unsykned char _addr) На входе Адрес трансивера. Код //принять пакет //на выходе: // -1 - пакет не принят // 0 - принят отклик // len - длина пакета unsykned char CProtosol::read(unsykned char addr_read, //От кого ждать пакет. unsykned char data) //буффер для считывания На входе. Адрес и буфер. Если задать адрес 0xFF, то это означает принимать от всех но только те пакеты которые предназначаются только этому устройству. Применимо когда к одному устройству могут обращаться многие. Код //отправить пакет данных //на выходе: // -1 - если пакет не отправлен // 0 - пакет отправлен unsykned char CProtosol::send(unsykned char addr_send, //Кому unsykned char len, //Размер пакета unsykned char data, //Динные unsykned char type, //Тип пакета,7й бит - сподтверждением или нет 6й бит - отклик или нет unsykned char reliability, //С подтверждением или без unsykned char prog_crc) //Использовать программное CRC Если задать адрес 0xFF, то посылку примут все кто ждал данные от этого устройства. Применимо когда одно устройство отсылает одни и те же данные многим. Если отправляющая сторона укажет addr_send=0xFF а принимающая addr_read=0xFF, то это устройство будет принимать все пакеты от всех. Формат пакета: байт 0 - Адрес. Кому отправить. байт 1 - Адрес. От кого посылка. байт 2 - Тип. Под тип пакета отводится 5ть бит. 3..62 - данные. Если используется программное CRC, то последние два байта это CRC. Код //type //0b00000000 // \|_______ 1-с подтверждением 0-без подтверждения // \|______ 1-отклик 0-посылка // \|_____ 1-программное CRC 0-без программного CRC Примеры программ: Сервер Код // Отправка одного пакета с подтверждением unsykned char out[63]; //TX unsykned char in[63]; //RX unsykned char len; //длинна сообщений MyPr.init(1); while(1) { MyPr.send(0xFF,63,out,0,1,1); Sleep(5); len=MyPr.read(2,in); MyUart.sendByte(len); } Клиент Код:// Прием пакета unsykned char len; MyPr.init(2); while(1) { len=MyPr.read(0xFF,out); } Сервер Код:// Запросить данные unsykned char out[63]; //TX unsykned char in[63]; //RX unsykned char len; //длинна сообщений MyPr.init(1); while(1) { do //отправлять запрос пока не придет подтверждение его получения { //Отправить запрос MyPr.send(2,5,out,1,1,1); Sleep(5); len=MyPr.read(2,in); }while(len!=0); Sleep(10); //ждем посылку len=MyPr.read(2,in); if(len!=0xFF) { for(char i=0;i<len;i++) { MyUart.sendByte(in[i]); } } } Клиент Код:// Ожидаем запрос данных и отсылаем данные unsykned char len; MyPr.init(2); while(1) { do { len=MyPr.read(1,out); }while(len==0xFF); //ожидаем запрос Sleep(5); //ждем пока принимающая сторона перейдет в режим RX if((out[2]&0b00011111)==1) { for(char i=3;i<10;i++) { out[i]=i; } MyPr.send(1,10,out,1,0,1); } } А дальше все зависит от фантазии))) Как дойдут руки напишу нормальную доку с примерами. [21.61 Кб] 0

ditphy_mykht
	10.03.2011, 18:28	23
	Еще несколько потерянных дней жизни. У кого-нибудь получалось заставить ваш код нормально работать? А протокол?

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	11.03.2011, 12:45	24
	У меня с использованием этого протокола и кода передается JPEG картинка от робота и роботу передаются команды. Все работает как часы. 0

Otyo
	11.03.2011, 23:25	25
	все-таки начало и конец пакета решил не отмечать?

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	12.03.2011, 00:38	26
	Т.е начало и конец передачи? После небольших раздумий я пришел к выводу, что в этом нет особого смысла. Если пользователю необходимо ввести нумерацию пакетов, то ему ничто не мешает для этого выделить пару байтов в начале пакета. У меня передается от робота фотки размером 17-30кб. Без какой либо нумерации. Ибо все пакеты передаются последовательно и только после подтверждения. Ничего не путается. 0

Otyo
	16.03.2011, 22:39	27
	Уиии! Переписала немного протокол под свои функции и добилась того , что все заработало. На примитивном уровне, конечно. =) до передачи картинок еще далекооо Спасибо %)

@Midvid 0 / 0 / 0 Регистрация: 23.01.2010 Сообщений: 966
	16.03.2011, 22:48	28
	А я пишу на паскале. наконец то нормально инициализация проходить начала =) 0

Otyo
	18.03.2011, 19:57	29
	кстати, у меня при включенном FEC , бит ошибки аппаратного CRC не устанавливается, как ты описываешь. С чем это связано может быть? Тогда получается, что программное CRC не надо использовать?

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	18.03.2011, 20:05	30
	В смысле не устанавливается? FEC повышает надежность за счет пропускной способности. А использовать программное CRC или нет зависит от прихоти. 0

Otyo
	18.03.2011, 23:31	31
	ну 11 бит регистра состояния должен быть единицей, если используется аппаратное crc и fec, нет? прошу прощения, если вопрос глупый: а какими тестами можно проверить надежность доставки при разных настройках?

ditphy_mykht
	25.03.2011, 12:10	35
	При смене режима работы с приема на передачу или наоборот модуль не работает. Что касается вашего кода, то в таком виде у меня он не работает на контроллере с частотой 16МГц. Еще такое впечатление, что модуль не всегда инициализируется. И еще, зачем там такие огромные задержки в коде?

ditphy_mykht
	26.03.2011, 02:44	37
	Автор прочитал ваш даташит. Сегодня после тестирования выяснилось еще несколько особенностей касательно буфера в режиме приема. Чуть позже на robot-divelop.org доработаю статью. Вашим протоколом не воспользовались, сделали свой. Про режим idle и смену параметров модуля эмпирически выяснили сегодня. Даташит пока читаем плохо, но учимся. Добавили еще вашего кода. Атмега новой серии А может работать отлично от 3.3 вольт и на 16 МГц.

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	26.03.2011, 02:59	38
	Не может. Нет атмега которые работают от 3.3В на частоте 16 Мгц. Если есть то покажи место в даташите где это написано. 0

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	04.04.2011, 00:55	39
	Демонстрация работы протокола + демонстрация возможностей модуля. Модуль конечно же не идеал, но дешевле да еще с такими параметрами на рынки ничего нет. http://www.youtube.som/watch?v=HYnQRP0CEZY 0