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

FIFO -First In First Out. То есть по нашему это очередь. На стороне модуля стоит чип который по запросу выдает по байту все 64 байта. Так же и заполняет по запросу.

Для начала нужно 2 тестовых стенда с модулями собраными правильно. Электроника должна быть нормальной. У мк и у модуля должны быть одинаковые лог. уровни а значит и питание 3.3В.

Когда все соберете, сделайте програму которая просто заливает регистры - инициализирует и потом считайте их по USART. Если все записалось и прочиталось правильно - продолжайте дальше.

Вот для передачи пример:

Код (Text):

1. void pkgsend(unsigned char len,unsigned char *data)
2. {
3.     unsigned char i;
4. reg_write(0x52,0x80,0x00); // обнуляем
5. modetx();                        //  переходим в режим записи
6. reg_write(0x52,0x80,0x00);  // еще раз обнуляем по совету астора темы
7.  
8.     SS=0; //  активизируем деятельность девайса
9.     delay_us(1);  
10.         spi(0x50);   //reg80  передаем модулю команду на прием даных
11.         spi(len);    //за тем туда же передаем длину пакета
12.        
13.        for(i=0;i<len;i++)   //отправить пакет в цыкле пихаем данные из своего масива
14.        {
15.         spi(data[i]);
16.        }
17.  
18.        SS=1; // дизактивируем модуль  
19. }//end SendPkg

Для чтения аналогично. Я пишу на CVAVR когда закончу протокол могу выложить все если будет интересно.

 

Код (Text):

1.     void CTr24a::PkgSend(unsigned char len,unsigned char *data)
2.     {
3.         write(0x52,0x8000);
4.         ModeTransmit();
5.  
6.         MySpi.SS_ON(SS);
7.         _delay_us(1);
8.         MySpi.send(0x50);   //reg80
9.         MySpi.send(len);    //длина пакета
10.         unsigned char i;
11.         for(i=0;i<len;i++)      //отправить пакет
12.         {
13.             MySpi.send(data[i]);
14.         }
15.  
16.  
17.         MySpi.SS_OFF(SS);
18.     }//end SendPkg

Сбрасывать нужно только один раз. И сбрасывать нужно до TX.

 

У меня были проблемы не с указателем на голову буфера, а с электроникой. Взял мегу8 а потом уже понял что не все меги на пониженом питании работают на кварцах частоты ниже максимльной. Короче нужна микросхема Atmega8A A-это признак универсальности. и стоит в полтора раза дешевле своей Л версии. теперь ошибок 0 + ЦРЦ апаратное пока без сбоев. правда еще тестов на стойкость особо не проводил.

 

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

 

Вот и я пишу на CVAVR. Причем тут USART? модуль вроде общается в внешним миром по SPI ? Согласование уровней и человеческое питание - это святое. Буду пытаться подружить 2 модуля TR24P

Valeri4, в Вашей функции reg_write(а,б,в); за что отвечают соотв. параметры? Можно глянуть ваши коды в CVAVR? тогда, думаю, многие вопросы сами отвалятся.

Значит мы предварительно задаем длину пакета (это вместе со служебной информацией, или только количество байт полезной информации входит в понятие длина пакета в сем устройстве?)

 

Через USART я смотрю на компьютере как идет обмен информацией между модулями- очень удобно.

Моя функция ни чем не отличается от функции a9d, просто переделана под другой компилятор. Но если хотите вот код:

Код (Text):

1. // Send register to SPI.
2. void reg_write(unsigned char rf_com, unsigned char rf_hb, unsigned char rf_lb){                      
3. SS      = 0;                    // SS low  (active)
4.  
5. spi(rf_com);            // command send
6. delay_us(2);
7. spi(rf_hb);             // high byte send
8. delay_us(2);
9. spi(rf_lb);             // low byte send
10. delay_us(2);
11. SS      = 1;                    // SS high  (nonactive)    
12. }

Самое интересное это настроить SPI как надо. Там в генераторе кода нужно выбрать Polarity-low, Phase -Cycle half, Master, MSB -Mode 1 у меня частота 2МГц.

нет, насколько я понял служебная информация в фифо не попадает и мы до нее доступа не имеем. Только пакет условленной длины.(Програмный ЦРЦ это уже не служебная информация)

 

Что за байт rf_com? Адрес регистра? Выходит, регистры 16 битные?

 

rf_com это адрес регистра в который будем записывать/считывать. В трансивере регистры 16битные а в микроконтроллере 8 битные и SPI 8битный вот и приходится писать старший и младший байт регистра.

 

a9d, у меня вопрос.
Есть короче передатчик и приемник. передатчик вещает пакеты с равными интервалами времени. Приемник их ловит. все хорошо, ошибок нет.
Я поставил скрамблер,фек2/3 и апаратное црц.
Провожу тесты на надежность. кладу передатчик в железную коробку - пакеты не принимаются. Потом вынимаю из коробки и ложу рядом с приемником - и всеравно не возобновляется передача. В режиме приема есть цыкл типа

Код (Text):

1.  while((TXRX!=1)&&(get_state()!=0)&&(f<2000))

где если раньше 2с не исполняется одно из цсловий то перехожу в идл и сбрасываю фифо. Ну а потом опять в режим приема.
Короче связь возобновляется только если ресетнуть передатчик!!! приемник ресетить бесполезно. Как так может быть?

 

Спрошу здесь.
Подключил tr24p к STM32, начал исследования.
Накопились вопросы.

Везде пишут, что последовательность для передачи должна быть такая: сбросил указатель FIFO в начало, включил режим передачи, затем записал данные в буфер. Далее ждем флаг PKT_FLAG и состояния idle.

Совершенно точно выяснил, что PKT_FLAG на моих модулях, сразу перебрасывается из 0 в 1, даже если данные еще не переданы. В 0 этот флаг у меня после этого вообще не переходит, даже если передача окончилась и модуль перешел в состояние idle.


Теперь самое интересное про переход в состояние idle. Если данные слать в буфер после включения режима передачи, то автоматически модуль в состояние idle не переходит, хотя все утверждают (и дока тоже, что должен). Если я сначала пишу данные в буфер, а потом врубаю передачу, то все ОК. Некоторое время висит режим TX а затем спустя примерно 1us переходит в режим idle. Конечно попробую еще убрать нафиг все задержки, которые рекомендуют в доках и примерах кодов, может просто я не успеваю данные до начала трэйлера перекинуть в буфер, поэтому модуль и не хочет передавать, а тупо висит в режиме TX. Это я проверю еще.

a9d утверждает в своих исследованиях, что надо сначала включать режим TX а затем слать данные. Но даже в его коде я вижу задержки (_delay_ms), которые МЕГЕ на 8Мгц и при его скорости SPI не позволят записать данные в буфер FIFO до начала передачи трэйлера. На STMке я попробую точно выяснить граничную частоту, там запас по штатной тактовой частоте с огромным запасом.

Но собственно вопрос вот какой. У кого флаг PKT_FLAG реально сам устанавливается в 1 после окончания передачи, а в момент, когда передача еще не окончена, держится в 0. Причем вы реально меряли на практике (например в цикле счетчик какой крутили), что сначала он держится в 0 некоторое время а затем переходит в 1 по окончании TX? И в какой момент времени он назад в 0 сбрасывается? У меня этот флаг в режиме TX показывает откровенную лажу. И только по переходу кристалла из режима TX в режим IDLE я могу получить информацию об окончании передачи. А флаг так и держится в 1 всегда, даже если я запускаю второй пакет на передачу. Ну то есть, в ноль не переходит после начала новой передачи.

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

 

Скорей всего ты напортачил с подключением модуля. Твой модуль жрет намного больше энергии чем TR24A. Скорей всего у тебя просаживается напряжение. Если у тебя стабилизатор не может дать 300-400ma то и возится с передачей смысла нет. Замкни стабилизатор через резистор и измерь ток/напряжение.

Перед отправкой данных модуль нужно перевести в режим TX и выждать технологическую задержку. Модуль мгновенно не меняет режимы. PKT_FLAG работает как надо. Если не заметил то в коде он именно вертится в цикле. И он действительно некоторое время вертится а после выставляется.

 

по поводу тока. У меня все ок. Собран импульсник потенциально на 2 ампера, ST1S10PHR. Я его испытывал, там все хорошо работает. Просадок нет. Дроссель конечно на ток до 750ма поставил а не на 2А, но и этого достаточно.

Ога заметил, с твоего кода порт на STM32 писал. А ты считал сколько циклов он прокручивается там? Так вот - нисколько он там не крутится. У меня по крайней мере. Вылетает на первой-же проверке.

По поводу технологических задержек.
Ну вот давай так считать. МЕГА у тебя на 8Мгц работает. То есть 1 команда 125 нс в идеале. технологические задержки по 120 - 500 нс нужны. И кроме того скорость передачи 1мб/сек у трансмиттера. То есть данные ты должен запихать туда со "свистом" до того как трейлер начнет в эфир уходить. Ты смотрел на свой цикл записи данных в ассемблерном коде? Там паразитных команд до фига компилятор наставит и без дополнительных задержек. Я у себя понизил тактовую до 24 Мгц, и на фиг выкинул все лишние задержки (не все конечно, но многие из первоначального кода). И даже при этом модуль инициализируется, регистры пишет, читает от туда, все без ошибок. Вот если я втыкаю 70Мгц, вот тут я начинаю видеть проблемы с отсутствием аппаратных задержек, причем явно.

Ну собственно говоря, после выкидывания задержек, теперь я вижу, что модуль стал успевать мои данные схватывать и после перехода в TX. Затем держит режим передачи, затем переходит в idle после передачи. Разница между пред заполнением буфера и пост заполнением, как раз составляет примерное время на передачу байтов в буфер. То есть реальность сошлась с расчетом. Но флаг PKT все равно показывает лажу. То есть после сброса он в нуле, при передачи первого пакета встает в 1, затем там уже торчит перманентно. Ну то есть я его всяко пытаюсь отловить и до перехода в TX и сразу после того как TX врубаю, и после записи первого байта в буфер. Ну торчит падла в 1 все тут.

Я это все к тому, что хотел его на прерывания повесить, но пока не могу этого сделать из за такого странного поведения. Хотя наверное, как проверю режим RX сегодня- завтра, так таки и воткну его на прерывание по всем фронтам и посмотрю по счетчикам что там реально происходит.

И вот я реально не верю, что есть разница между тем, чтобы писать данные до перехода в TX или после. По косвенным признакам что так, что эдак разницы никакой нет. Ну RX испытания покажут. Может я и не прав, пока на 100% утверждать не берусь. Результаты тестов конечно здесь выложу.

 

Все я там проверял. В цикле он крутится до выставления флага.
Зачем, что то ты вообще считаешь. В порте под авр четко указаны задержки. Они взяты не из потолка.

Ничего подобного. Сначала тех задержка а после отправка данных на скорости 1 мбит.

Какое вообще отношение имеет значение частоты мк к продолжительности тех. задержке???

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

Гмм. И так можно понять. Трансивер не успевает за микроконтроллером. Поэтому нужны тех задержки. Продолжительность их указанна в даташите.

Вешал я его на прерывание. Особого выигрыша это не дает. Оправданно использовать прерывание только если мк спит.

Про "паразитные команды" вообще ничерта не понял. Компилятор все хорошо оптимизирует.
Да и вообще непонятно, как ты под арм написал более "оптимальный" цикл. Также непонятно как ты в арм определяешь эти "паразитные команды". Если там команда и какая-то есть, то это еще не означает что она выполняется.

ГГГ. Насмешил. Не верь. Кроме большого выигрыша в пропускной способности и возможности передавать большие пакеты а также небольшой экономии энергии....абсолютно ничего не дает)))

 

Да я не о тех. задержке, которая в регистрах настраивается, речь вел. Ладно забудь, проехали.

Команды не паразитные, а обслуживающие СИ-код. Напиши цикл на сях, посмотри, что компилятор наставил. По моим наблюдениям AVR компилятор для С не очень хорошо заточен под систему команд AVR. Ну или наоборот. Почти всегда я могу написать под АВР код на асме более оптимально, чем его компилятор генерит. В STM32 дела обстоят лучше. Система команд логично ложится под СИ код. Просто напиши пару вложенных 32-х разрядных циклов на сях и покомпиляй под AVR и под АРМ. сравни ассемблерный код, сразу все видно.

Теперь по поводу выполнится, не выполнится. Я ставлю ассемблерные врезки и все выполняется. Предсказатель в Cortex ядре не настолько продвинут, как его хочет производитель представить. Обмануть на ассемблере его всегда можно. Так что с задержками аппаратными у меня все в порядке.

Ну ладно а теперь по результатам вчерашних ночных бдений

Запустил передатчик, запустил приемник. За 2 часа добился связи. Антенны - просто куски проводов и похоже это все равно , что антенн просто нет. На расстоянии 20 см связь устойчивая, далее с потерями. Есть у меня wi-fi антенны мануфактурные 3 штуки и SMA угловые разъемы. Попробую вкорячить их прямо на модули. Надеюсь они согласованные с 50 Ом выходами модуля. Не ясно еще как регулировать мощность передатчика, буду методом тыка пытаться это выяснять.

И вот какой вопрос к тебе. Там у тебя переменная swallow пишется в 7-ой регистр. Я чего-то по доке не врублюсь на фиг оно надо. Понятно что на частоту влияет. Но мне чего-то формула расчета не ясна, если swallow используется. А без этого swallow будет работать или нет? Там вроде в доке написано что можно по тупому 2402 + №канала в младшие биты 7 ого регистра писать.

 

Ага все компиляторы идентичные))) В этом месте нужно начать холивар))) Да и более оптимальная система команд в арм это еще один холивар)) Давай сравнивать x86 и с51. Это ж почти идентичные архитектуры. А главным признаком сравнения будет компилятор нонейм.

Этой херней максимум выиграешь пару микросекунд но потеряешь читабельность и стабильность кода. Также значительно ухудшиться переносимость кода.

Открою тебе секрет. Антенна это и есть кусок проволоки. Их главное точно изготовить.

Напиши в сапорт спирит он. Они еще никому не отвечали.

 

Ну это субъективно. Мне так нравится. Другим способом добиться задержки в 50 nsec нет никакой возможности.

Спасибо, открыл глаза на сущность Забыл про согласование мне поведать еще.

Они и мне не ответили, я думаю они просто не знают как там это все работает. Надо в elan писать.

Ну а ты то нафига в swallow девятку пихаешь по умолчанию? Вот с какой целью это надо? Я эту фичу только в твоем коде вижу. Все другие примеры по тупому 0 туда пишут и тем счастливы.

 

Элан тоже не отвечает.
Это дефолтное значение для частоты кристалла 12Мгц . Все другие его затирают а после еще и удивляются почему у них динамическое переключение каналов не работает правильно.

 

Воткнул wi-fi антенны в tr24p. Промучился 2 часа, эффекта - ноль. 30 см дальность связи максимум. Затем случайно решил проверить куда идут недокументированные TXV, RXV. Оказалось на базы к транзисторам через резюки по 10 КОм. Короче, парни, у кого tr25p показывает дальность в 20 см у меня для вас новость. Китайцы забыли рассказать в документации, что TXV, RXV это не выходы, а входы. TXV - врубает оконечный усилитель мощности, а RXV врубает похоже RF усилитель на входе. Эти входы надо подключить к контроллеру и включать/выключать режимы приема и передачи этими входами. 1- вкл, 0 - выкл.

Короче, добавил проводов, включил. Думал включать TX перед передачей и выключать сразу после нее. Здесь нас ждет похоже еще один дебильный китайский сюрприз. Оконечник TX выходит на режим номинальной мощности примерно через 500 млс. RX врубается практически без задержек. То есть пользоваться этой поделкой как трансмиттером по нормальному не получится.

Ну вообщем, TXV я врубил на постоянку и провел первые испытания на дальность в квартире.

Передатчик засунул под шкаф в дальний угол, с приемником ходил по всей квартире. Работал без коррекции FEC + RAW data + CRC. Длина тестового пакета 10 байт. Мест, где бы не было уверенного приема я не нашел. Проверял по диагонали через 3 комнаты, даже в бачек от унитаза и в ванную запихивал. Ошибок в приеме не наблюдаю. Шаманств с подбором поляризации путем изменения позиционирования не трэбо. Работает при любой ориентации антенн. На открытом воздухе буду проводить испытания завтра, если найду подходящий второй аккумулятор. Жрет этот отстойник в режиме TX непрерывно 70мА. Какая-то хрень греется не по детски среди той рассыпухи, что на плате напаяли.

Доведу испытания до конца, но скорее всего закрою тему с этой китайской поделкой. Буду смотреть в сторону RFM22-433, там хоть и дороже в 2 раза, зато без сюрпризов.

a9d, скажи какие режимы надо включить в регистре 48, чтобы оптимально пакеты доходили? И scrambler ты выключил или пользуешь? Какие длины преамбулы, синхрослова и трэйлера у тебя оптимальные получились? Расскажи какие ставить, я поставлю и проверю дальность на открытом воздухе и поставим точку на этом tr24p.

 

Чем тебя дефолтные настройки не устраивают???
А вообще перед тем как задавать таки вопросы сначала погугли эти определения. Скремблер вообще отношения к качеству передачи не имеет.

Трансивер tr24p наверняка работает как надо. То что у тебя неполучается это частный случай.

 

Тест на дальность по сути ничего не дает. Сегодне макс. длина 20м, завтра будет 12м изза РЧ помех соседних 2.4ГГц устройств. Куда лутше и удобнее пробовать надежность в металической коробке с крышкой.
Я пробовал таким методом- связь действительно есть и нормальная. Правда иногда если коснутся передатчика то он виснет, пока так и не разобрался, просто обмотал плату целофаном на время тестирования.

И еще очень важным оказалось заземлить все земляные выводы (и по бокам) платы модуля.