Инфа по трансиверу TR24

Тема в разделе "WASM.ELECTRONICS", создана пользователем a9d, 3 фев 2010.

  1. a9d

    a9d New Member

    Публикаций:
    0
    Регистрация:
    26 апр 2006
    Сообщения:
    234
    Адрес:
    Zimbabwe
    Все операции со сменой режима работы должны выполнятся в секции кода в которой запрещены прерывания. Если смена режима работы трансиввера пройдет не корректно, то трансиввер перейдет в запрещенное состояние. Из запрещенного состояния можно вывести только путем сброса.
     
  2. drleavsy

    drleavsy New Member

    Публикаций:
    0
    Регистрация:
    25 дек 2010
    Сообщения:
    4
    Прошу прощение а9d за глупый вопрос: Sleep(500) - это значит отправить его спать на 500 мс, а потом разбудить ? У тебя в классе есть такие паблик функции ModeSleep(), и ModeIdle() , какая разница между Sleep и Idle состояниями, насколько я понял Idle нужен для того чтобы показать трансиверу что все содержимое пакета уже загружено в ФИФО буфер трансивера, а слип нужен чтобы сэкономить энергию между передачей или приемом пакетов.

    И еще один вопрос: в мануале сказано, что есть 2 основных режима: когда контроллер управляет длинной пакета и когда фреймер управляет длиной пакета, я например понял что нежелательно отправлять пакеты больше чем 63 байта , есть ли смысл в таком случае контролировать эту длину?
     
  3. a9d

    a9d New Member

    Публикаций:
    0
    Регистрация:
    26 апр 2006
    Сообщения:
    234
    Адрес:
    Zimbabwe
    Слеп и Идл это разные вещи. Скорость перехода в них очень различается.
    Sleep это функция ОС scmRTOS.

    Я в доке писал четко. Что размер пакета ограничен 64 байтами. Отправлять длинные пакеты накладно. Там нужно следит за скоростью заполнения буфера трансиввера.
     
  4. drleavsy

    drleavsy New Member

    Публикаций:
    0
    Регистрация:
    25 дек 2010
    Сообщения:
    4
    в твоем коде a9d я увидел что ты используешь для SS сигнала - вывод PC5 на Атмеге8 , вместо PB2 , для этого есть какая то особенная причина или ты просто выбрал первый попавшийся пин?
     
  5. a9d

    a9d New Member

    Публикаций:
    0
    Регистрация:
    26 апр 2006
    Сообщения:
    234
    Адрес:
    Zimbabwe
    Для SS может использоваться любой вывод. Но вывод SS микроконтроллера должен быть настроен на выход, это уже особенность работы мег.
     
  6. a9d

    a9d New Member

    Публикаций:
    0
    Регистрация:
    26 апр 2006
    Сообщения:
    234
    Адрес:
    Zimbabwe
    Только, что заметил большой косяк. Все версии исходников которые были выше, не правильные.
    В них не работает двухсторонний обмен.
    Как это исправить ХЗ. В доках ни слова о том как очистить буффер.
     
  7. a9d

    a9d New Member

    Публикаций:
    0
    Регистрация:
    26 апр 2006
    Сообщения:
    234
    Адрес:
    Zimbabwe
    Исходники подправил.
    Также выкинул все ненужные функции. От RSSI пришлось отказаться. Я так и не понял как его нужно считывать.

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

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

    Код (Text):
    1. void CProtocol::init(unsigned char _addr)
    На входе Адрес трансивера.

    Код (Text):
    1.     //принять пакет
    2.     //на выходе:
    3.     // -1 - пакет не принят
    4.     //  0 - принят отклик
    5.     //  len - длина пакета
    6.     unsigned char CProtocol::read(unsigned char addr_read, //От кого ждать пакет.
    7.                                   unsigned char *data)     //буффер для считывания
    На входе. Адрес и буфер.
    Если задать адрес 0xFF, то это означает принимать от всех но только те пакеты которые предназначаются только этому устройству.
    Применимо когда к одному устройству могут обращаться многие.

    Код (Text):
    1.     //отправить пакет данных
    2.     //на выходе:
    3.     // -1 - если пакет не отправлен
    4.     //  0 - пакет отправлен
    5.     unsigned char CProtocol::send(unsigned char addr_send,   //Кому
    6.                                   unsigned char len,         //Размер пакета
    7.                                   unsigned char *data,       //Данные
    8.                                   unsigned char type,        //Тип пакета,7й бит - сподтверждением или нет 6й бит - отклик или нет
    9.                                   unsigned char reliability, //С подтверждением или без
    10.                                   unsigned char prog_crc)    //Использовать программное CRC
    Если задать адрес 0xFF, то посылку примут все кто ждал данные от этого устройства.
    Применимо когда одно устройство отсылает одни и те же данные многим.

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

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

    Код (Text):
    1.     //type
    2.     //0b00000000
    3.     //  |_______ 1-с подтверждением 0-без подтверждения
    4.     //   |______ 1-отклик           0-посылка
    5.     //    |_____ 1-программное CRC  0-без программного CRC
    Примеры программ:

    Сервер
    Код (Text):
    1. //  Отправка одного пакета с подтверждением
    2.     unsigned char out[63]; //TX
    3.     unsigned char in[63];  //RX
    4.     unsigned char len; //длинна сообщений
    5.  
    6.     MyPr.init(1);
    7.  
    8.     while(1)
    9.     {
    10.         MyPr.send(0xFF,63,out,0,1,1);
    11.         Sleep(5);
    12.         len=MyPr.read(2,in);
    13.         MyUart.sendByte(len);
    14.     }
    Клиент
    Код (Text):
    1. //  Прием пакета
    2.         unsigned char len;
    3.  
    4.         MyPr.init(2);
    5.  
    6.         while(1)
    7.         {
    8.             len=MyPr.read(0xFF,out);
    9.         }
    Сервер
    Код (Text):
    1. //  Запросить данные
    2.     unsigned char out[63]; //TX
    3.     unsigned char in[63];  //RX
    4.     unsigned char len;  //длинна сообщений
    5.  
    6.     MyPr.init(1);
    7.  
    8.     while(1)
    9.     {
    10.         do //отправлять запрос пока не придет подтверждение его получения
    11.         {
    12.             //Отправить запрос
    13.             MyPr.send(2,5,out,1,1,1);
    14.             Sleep(5);
    15.             len=MyPr.read(2,in);
    16.         }while(len!=0);
    17.  
    18.         Sleep(10);          //ждем посылку
    19.         len=MyPr.read(2,in);
    20.  
    21.         if(len!=0xFF)
    22.         {
    23.             for(char i=0;i<len;i++)
    24.             {
    25.                 MyUart.sendByte(in[i]);
    26.             }
    27.         }
    28.     }
    Клиент
    Код (Text):
    1. // Ожидаем запрос данных и отсылаем данные
    2.  
    3.         unsigned char len;
    4.  
    5.         MyPr.init(2);
    6.  
    7.         while(1)
    8.         {
    9.             do
    10.             {
    11.                 len=MyPr.read(1,out);
    12.             }while(len==0xFF);          //ожидаем запрос
    13.  
    14.             Sleep(5); //ждем пока принимающая сторона перейдет в режим RX
    15.  
    16.             if((out[2]&0b00011111)==1)
    17.             {
    18.                 for(char i=3;i<10;i++)
    19.                 {
    20.                     out[i]=i;
    21.                 }
    22.                 MyPr.send(1,10,out,1,0,1);
    23.             }
    24.         }
    А дальше все зависит от фантазии)))
    Как дойдут руки напишу нормальную доку с примерами.
     
  8. Gennady1960

    Gennady1960 New Member

    Публикаций:
    0
    Регистрация:
    1 фев 2011
    Сообщения:
    4
    Привет!

    Вопрос по tr24a - на что влияют коэфф. усилиления, расположенные в регистрах 0 и 9?
    Я ставил минимальные и максимальные значения - результат не поменялся. Даже с увеличением их связь ухудшается.
     
  9. a9d

    a9d New Member

    Публикаций:
    0
    Регистрация:
    26 апр 2006
    Сообщения:
    234
    Адрес:
    Zimbabwe
    Я не знаю. Документации об этих регистрах нет.
     
  10. Gennady1960

    Gennady1960 New Member

    Публикаций:
    0
    Регистрация:
    1 фев 2011
    Сообщения:
    4
    А что показывает RSSI? и в какой момент его надо считывать? Если в тот, как в твоей процедуре чтения, то получается следующее:
    - если рядом лежат - не больше 4 единиц,
    - на 5 метрах - вообще 0
     
  11. a9d

    a9d New Member

    Публикаций:
    0
    Регистрация:
    26 апр 2006
    Сообщения:
    234
    Адрес:
    Zimbabwe
    Долго с ним возился после забил. Оно работает как то непонятно.
     
  12. Gennady1960

    Gennady1960 New Member

    Публикаций:
    0
    Регистрация:
    1 фев 2011
    Сообщения:
    4
    Чисто комментарий к Вашей программе - когда во время приема анализируется длина пакета, то перед выходом при длине, не соответствующей условиям, нужно SS поднять в верхнее.
     
  13. a9d

    a9d New Member

    Публикаций:
    0
    Регистрация:
    26 апр 2006
    Сообщения:
    234
    Адрес:
    Zimbabwe
    Вау. Ты первый кто нашел ошибку)))
     
  14. Gennady1960

    Gennady1960 New Member

    Публикаций:
    0
    Регистрация:
    1 фев 2011
    Сообщения:
    4
    Просто я все переписал на asm под pic18f
     
  15. Efimov

    Efimov New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2011
    Сообщения:
    9
    Всем привет.
    Прикупил парами TR24A, TR24F и TR24P.
    Начал с TR24A. Прицепил к своей отладочной плате на PIC18F4680.
    Согласование уровней:
    все линии от PIC к TR24 через делитель 1кОм/2кОм.
    линия от TR24 к PIC через пару инверторов 1533ЛН2.
    Линии флагов пока не трогаю.
    PIC работает с внутренним 8МГц генератором. Отладочную информацию передаёт через MAX232 на 57600. Пишу на С в MPLab.
    Работа с TR24 сразу предполагается пока что под программный SPI.
    В итоге: При включении питания сбрасываю TR24, выдерживаю времена, считываю все регистры. Которые не равны нулю отправляю на терминал.
    h30 = h5800 h31 = hC00А h32 = h9628 h33 = h8300 h38 = h4407
    h39 = hB000 h52 = h003A
    Картина всё время одна и таже. Содержимое соответствует значениям по умолчанию.
    Вопросы.
    1. Почему остальные регистры читаются нулями?
    2. Что дальше. Рекомендации......
     
  16. a9d

    a9d New Member

    Публикаций:
    0
    Регистрация:
    26 апр 2006
    Сообщения:
    234
    Адрес:
    Zimbabwe
    А ты инициализировал трансивер? Вот если после инициализации все регистры равны нулю, то это уже есть гдето косяк.
     
  17. Efimov

    Efimov New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2011
    Сообщения:
    9
    после сброса трансивера регистры предустанавливаются по умолчанию сами, не должны ли так читаться ?
     
  18. dimka11

    dimka11 New Member

    Публикаций:
    0
    Регистрация:
    9 фев 2011
    Сообщения:
    7
    Всем привет!
    Efimov
    Судя по даташиту большинство регистров по умолчанию не нули!

    a9d
    Не подскажите если на приемник придет два подряд пакета, а первый я еще не успел считать, то как в данной ситуации поступит приемник? Он их объеденит? или выдаст как два разных пакета?
     
  19. a9d

    a9d New Member

    Публикаций:
    0
    Регистрация:
    26 апр 2006
    Сообщения:
    234
    Адрес:
    Zimbabwe
    После приема пакета трансивер переходит в режим простоя. В этом режиме пакеты не принимаются.
    В такой ситуации будет принят только один пакет, а второй потеряется.

    До инициализации кадра, регистры передатчика будут содержать нули. Проведи уже наконец то инициализацию.
    От дефолтных значений все равно толку нет.
     
  20. Efimov

    Efimov New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2011
    Сообщения:
    9
    Очередной шаг совершён.
    К отладочной плате подключены паралельно два трансивера. Разнесены выводы MISO и SS.
    Флаги пока не использую. Инициализирую оба, после чего регистры читаются из обоих одинаково правильно (что записал при инициализации, то и прочёл), за исключением 6-го регистра (0400 и 2000).