Autobaud, Автоматическое определение скорости Usart. Опции

[Ruslan Konovalov]

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

Алгоритм следующий:
Ногу PD0 и PD2 нужно замкнуть.
1) Устанавливаем внешнее прерывание (INT0) на захват спадающего фронта.
2) Прерывание произошло, устанавливаем внешнее прерывание (INT0) на захват восходящего фронта,
устанавливаем счетчик Timer1 на отсчет времени.
3)Прерывание произошло, останавливаем таймер, запрещаем внешнее прерывание.
4)Подсчитываем битрайт, и задерживаемся(delay_us()) до конца данного байта.
5)Настраиваем скорость усарта и принимаем данные.

Испытания проводил на Mega8, 16Mhz, на скоростях от 9600-210000.
Главные условия, чтобы младший бит первого байта посылки был равен 1.
Прием начинается со 2-го байта. Грубо говоря 1-й байт нужен для синхронизации.
Также реулизована возможность засыпания процессора. Если это не нужно, просто закомментируйте
#define SLEEP.

В принципе пока все устраивает, просто хотел узнать Ваше мнение.

Вопрос:
Теоретически после того как определили битрайт(это в конце старт-бита) нужно
сделать delay_us() равный: 1bit time*8(до начала стоп бита), а уже потом
устанавливать битрайт. Но вреальности принимается ерунда.
Но если написать следущее:

Код

  for(n=0; n < (char)baudrate-1; n++) delay_us(1);//Ничего не делаем до начала следующего байта
  for(n=0; n < (char)baudrate-1; n++) delay_us(1);

То все работает.
Эта задержка примерно равна 2-м битам.
Мне так кажется что пока я дохожу до этого момента, проходит время равное 6-ти битам.


Вот сам код:

Код

#include <ioavr.h>
#include <inavr.h>
#include "USART.h"


//********************************************************************************
**********
#define SLEEP

unsigned static char state;
unsigned int baudrate;


#pragma vector = INT0_vect
__interrupt void OnCapt()
{
  if(0==state)//Перехват падения фронта
   {
     state = 1;
     MCUCR |= (1<<ISC01) | (1<<ISC00); //Установка прерывания по восходящему фронту      
     TCNT1H=0;//Обнуляем таймер                
     TCNT1L=0;
     TCCR1B|=(0<<CS12) |(0<<CS11) | (1<<CS10);//Запускем таймер 1 без делителя  
   }
  else if(state==1)//Перехват подъема фронта
   {    
     state = 2;        
     baudrate = TCNT1L;
     baudrate |= (int)TCNT1H<<8;
     TCCR1B&=~((0<<CS12) |(0<<CS11) | (1<<CS10));//Запрещяем таймер      
     MCUCR &= ~((1<<ISC01) | (1<<ISC00));//Запрещяем захват по фронту
     GICR &= ~(1<<INT0);//Запрещаем прерывание по захвату      
   }
}

unsigned int Usart_autobaud(void)
{
  unsigned char n;
  
  state=0;
  MCUCR |= (1<<ISC01) | (0<<ISC00);  //Установка прерывания по спадающему фронту
  GICR |= (1<<INT0); //Разрешение прерывания    

#ifdef SLEEP
  MCUCR |= (1<<SE); //Разрешаем режим сна до первого внешнего прерывания
  asm("sleep");
  MCUCR &= ~(1<<SE); //Запрещаем режим сна до первого внешнего прерывания
#endif  
  
  while(state != 2); //Ждем окончание старт бита(восходящий фронт)
  
   //Определяем битрайт  
  baudrate = (baudrate>>3)-1; //baudrate=(baudrate/8)-1    
  for(n=0; n < (char)baudrate-1; n++) delay_us(1);//Ничего не делаем до начала следующего байта
  for(n=0; n < (char)baudrate-1; n++) delay_us(1);
  return baudrate;        
}
//********************************************************************************
**********



void main( void )
{  
DDRD =  0x00;
PORTD = 0x00;
DDRB =  0x00;
PORTB = 0x00;
DDRC =  0x00;
PORTC = 0x00;

#ifdef SLEEP
  MCUCR |= (0<<SM2)|(0<<SM1)|(0<<SM0);//Режим сна Idle
#endif
  
  USART0_init();//Инициализируем уарт  
  
   __enable_interrupt();
   delay_s(1);

  while(1)
  {        
   USART0_set_speed(Usart_autobaud()); //Определяем битрайт и устанавливаем скорость
   UCSRB |= (1 << RXCIE)| (1 << RXEN); //Разрешаем прием и прерывание усарта  
   while(!USARTBuffSize);          //Ждем конца приема данных  
   UCSRB &= ~((1 << RXCIE) | (1 << RXEN)); //Запрещаем прием и прерывание усарта      
   USART_SEND_STR(UsartBuff, USARTBuffSize+1);    
   USARTBuffSize = 0;  
  }

}

И еще вопрос.
В даташите написано, что пробуждение от сна по внешнему прерыванию разрешено во всех режимах.
Но у меня прерывание происходит только в режиме сна Idle.
Что я делаю не так ?

Сообщение отредактировал Ruslan Konovalov - Oct 13 2008, 12:24

[GDI]

Теоретически после того как определили битрайт(это в конце старт-бита) нужно
сделать delay_us() равный: 1bit time*8(до начала стоп бита), а уже потом
устанавливать битрайт.

А зачем вообще ждать, почему нельзя сразу установить скорость уарта?

Но вреальности принимается ерунда.

Что конкретно принимается? может там происходит ошибка кадрирования и ее надо просто сбросить?

[Ruslan Konovalov]

А зачем вообще ждать, почему нельзя сразу установить скорость уарта?
Что конкретно принимается? может там происходит ошибка кадрирования и ее надо просто сбросить?

Я тоже так думаю.
Но как это устранить ?

[GDI]

А не надо устранять, просто сбросьте ошибку, а протокол надо применить с подтверждением. В результате ошибки первая датаграмма не будет правильно принята и устройство не ответит или ответит ошибкой(на уже определенной скорости), на что передающая сторона должна повторить передачу пакета и далее обмен пойдет уже правильно.

P.S. В качестве бреда... можно первый байт принять софтово и подставить его в буфер...

[Ruslan Konovalov]

А не надо устранять, просто сбросьте ошибку, а протокол надо применить с подтверждением. В результате ошибки первая датаграмма не будет правильно принята и устройство не ответит или ответит ошибкой(на уже определенной скорости), на что передающая сторона должна повторить передачу пакета и далее обмен пойдет уже правильно.

P.S. В качестве бреда... можно первый байт принять софтово и подставить его в буфер...

Ксожаление нет возможности изменить протокол.
Протокол без подтверждения.
Просто устройство отсылает мне пакет, а я должен его принять.
Первый байт - начало пакета. Он мне известен. Так что не важно что 1-й байт не принимается.
Главное чтобы со второго байта все принималось корректно.

[SasaVitebsk]

У меня:
1) не задействовано дополнительных ног (это для AVR ни к чему)
2) без разницы что идёт первым символом (в смысле какой нулевой бит 0 или 1)
3) На частоте 7372800 безошибочное восстановление инфы до 115200.

У меня может ошибаться UART лишь в том случае если в символе 1 перепад (например 5 мл. =0, потом =1). Это изза того, что восстановление скорости осуществляется по первому байту.
Но принципиально, если бы такая задача стояла, то я бы мог полностью восстановить данные. То есть в таком случае ждал бы первого "вменяемого" символа.

[Ruslan Konovalov]

У меня:
1) не задействовано дополнительных ног (это для AVR ни к чему)
2) без разницы что идёт первым символом (в смысле какой нулевой бит 0 или 1)
3) На частоте 7372800 безошибочное восстановление инфы до 115200.

У меня может ошибаться UART лишь в том случае если в символе 1 перепад (например 5 мл. =0, потом =1). Это изза того, что восстановление скорости осуществляется по первому байту.
Но принципиально, если бы такая задача стояла, то я бы мог полностью восстановить данные. То есть в таком случае ждал бы первого "вменяемого" символа.

1) Если не секрет, давайте код в студию, вдруг кому нибудь пригодится(например мне)
2) По вашему алгоритму не получится проснуться из режима спячки.
А для меня это желательно.

Мне кажется разница между Вашим и моим алгоритмом в том что я использую внешние прерывания а Вы

Код

while(!(PIND&(1<<PD0)));//Ждем падение фронта
...
while((PIND&(1<<PD0)));//Ждем подъем
...

[SasaVitebsk]

1) Если не секрет, давайте код в студию, вдруг кому нибудь пригодится(например мне)

Это я сделать не могу

2) По вашему алгоритму не получится проснуться из режима спячки.
А для меня это желательно.

Да. Мне это было не нужно. Для этого действительно необходимо дополнительно Int задействовать

Мне кажется разница между Вашим и моим алгоритмом в том что я использую внешние прерывания а Вы

Нет ну это просто принцип измерения длительности импульса. Это к самому алгоритму не имеет никакого отношения.

Алгоритм ваш и мой отличается как телега от мерседеса. Поскольку ничего сверхестественного в нём нет, я его просто сел и выдумал подходя к решению данной задачи. Иными словами я его нигде не заимствовал. Просто смотрел как восстанавливает посылку модем US Robotics Courier. Задумался как это можно сделать, проанализировал и получил результат.

Я не знаю так ли делает модем от US Robotics, но я делал след. образом.
1) записывал все длительности импульсов в память.
2) на лету выделял найменьший импульс, а также найменьшую разность
3) на лету определял "текущий прогнозируемый конец байта"
4) по окончанию байта определял скорость, переводил записаное в нужные биты и преобразовывал в байт, переинициализировал UART.

Скорость сбрасывал по след признакам:
1) Конец команды
2) Таймер неактивности
3) Снятие готовности терминала

[rezident]

Я не знаю так ли делает модем от US Robotics, но я делал след. образом.
1) записывал все длительности импульсов в память.
2) на лету выделял найменьший импульс, а также найменьшую разность
3) на лету определял "текущий прогнозируемый конец байта"
4) по окончанию байта определял скорость, переводил записаное в нужные биты и преобразовывал в байт, переинициализировал UART.

В модеме autobaud detect реализовать проще, т.к. там заранее известно, что команда с префикса AT начинается. А вот как предлагается реализовывать это же самое на MSP430. Automatic Baud Rate Detection on the MSP430

[Палыч]

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

Э-э-э-э... Может, толком не искали? Например, у Atmel'а - это добро выложено. Ну, например, в исходниках к AVR914. Это - то, что сходу нашёл... Думаю, что эта функция у них качует от примера к примеру: скорость определяется по первому символу (символ U - код символа 55h).

[Ruslan Konovalov]

Э-э-э-э... Может, толком не искали? Например, у Atmel'а - это добро выложено. Ну, например, в исходниках к AVR914. Это - то, что сходу нашёл... Думаю, что эта функция у них качует от примера к примеру: скорость определяется по первому символу (символ U - код символа 55h).

Я нашел этот аппноут. Но там на ассемблере. На си найти не удалось.

[Палыч]

Я нашел этот аппноут. Но там на ассемблере. На си найти не удалось.

Ассемблер применять - религия не позволяет? Впрочем, можно переложить и на С. Точность, правда, пострадает...

[Ruslan Konovalov]

Ассемблер применять - религия не позволяет? Впрочем, можно переложить и на С. Точность, правда, пострадает...

Я религиозный.
Для меня ассемблер глухой лес к сожалению.

А вообще кто нибудь работал с режимами сна ?

[SasaVitebsk]

В модеме autobaud detect реализовать проще, т.к. там заранее известно, что команда с префикса AT начинается. А вот как предлагается реализовывать это же самое на MSP430. Automatic Baud Rate Detection on the MSP430

Я это делал тоже для модема, но это отговорка. На самом деле модем восстанавливает все символы, которые может восстановить. В частности, описанный мной курьер восстанавливает ~ 99% символов. Можете проверить. Мой модем восстанавливает практически так же. Я не пробовал соревноваться.

[sf9]

Господа электронщики, как определять скорость USARTa в случае,когда мы знаем,какой именно байт должен быть принят - дело понятное. Практически у каждого производителя МК есть статья с алгоритмом,который сводится к тому,что просто сравниваем,какой байт получился на приёме с табличными значениями и определяем скорость.

ВОПРОС: какой алгоритм должен быть при autobaudrate,если из канала мы получаем произвольные данные и не можем предсказать,что именно. Т.е. могут быть,как все нули, так и все единицы и пр.

Sasa из Vitebsk Вы попытались описать данный алгоритм,но не совсем ясно,как он работает.
Может у кого есть ещё какие-нибудь идеи?????

[Maik-vs]

Господа электронщики, как определять скорость USARTa в случае,когда мы знаем,какой именно байт должен быть принят - дело понятное. Практически у каждого производителя МК есть статья с алгоритмом,который сводится к тому,что просто сравниваем,какой байт получился на приёме с табличными значениями и определяем скорость.

ВОПРОС: какой алгоритм должен быть при autobaudrate,если из канала мы получаем произвольные данные и не можем предсказать,что именно. Т.е. могут быть,как все нули, так и все единицы и пр.

Sasa из Vitebsk Вы попытались описать данный алгоритм,но не совсем ясно,как он работает.
Может у кого есть ещё какие-нибудь идеи?????

Ну так поставьте себя на место UARTa. Вот в линии нулевой уровень. Долго. Так долго, что даже длиннее байта на скорости 100 бод. И вдруг перепад. Это начался старт-бит. Дальше остаётся только мерить время между перепадами и соображать, где бит, где байт, где пауза (если есть!) - после неё будет старт-бит.
Заметьте, что задачка распадается на две: когда на борту есть кварц и вы можете прикинуть длительность принятых бит к стандартному ряду скоростей, или когда есть RC генератор и вы не знаете, сколько, образно говоря, тиков таймера пойдёт на бит при скорости 9600.
Ну и, конечно, "произвольные данные" должны быть ограничены требованиями протокола. Не представляю себе полностью неопределённый поток - разве что когда подслушиваешь кого-нибудь
Кстати, очень интересно было нарваться на поток данных без пауз, по RS485. Отлично принималось, начиная с произвольного нулевого бита в байте, и при изменении полярности - тоже, всего лишь с инверсией!

[ARV]

в принципе, для абсолютно неизвестного потока данных можно долго слушать линию, замеряя длительность всех сигналов и выбирая наименьший - это и будет длителность одного бита - по ней скорость и восстанавливать... хотя все равно возникает другая сложность - определение длины кадра - 8 бит данных или 9...

[SasaVitebsk]

Sasa из Vitebsk Вы попытались описать данный алгоритм,но не совсем ясно,как он работает.
Может у кого есть ещё какие-нибудь идеи?????

В моём посте абсолютно подробно, по пунктам расписано. Я не привязываюсь к конкретному байту. Я восстанавливаю любой.
При этом надо понимать, что есть байты которые (за 1 байт) не могут быть восстановлены. Надеюсь это понимает каждый?

Для Maik-vs, в линии изначально 1 и старт-бит приходит 0. Далее если вы распишете например байт 0xf0(на 115200), то вы поймёте, что он может быть 0xf0 на 115200, или 0xfc на 57600 или 0xfe на 28800 или 00 на 230400.

[singlskv]

ВОПРОС: какой алгоритм должен быть при autobaudrate,если из канала мы получаем произвольные данные и не можем предсказать,что именно. Т.е. могут быть,как все нули, так и все единицы и пр.

Для начала надо понять что для произвольного входного потока понадобятся от
1 до ~9-11 байт входного потока для первоначальной синхронизации,
если вас устроит синхронизация по такой последовательности, тогда можно обсуждать дальше...

[singlskv]

...

Уточнение, для совсем произвольного входого потока(это когда промежутки между байтами
неопределенные), скорее всего нужно как минимум ~ 20байт для первоначальной синхронизации,
а дальше только один вопрос, а оно надо... ???

[SasaVitebsk]

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

Если рассматривать, что принимается посылка, то есть сначала линия неактивна и вот пошёл первый байт, то тогда я описал ситуацию, правда я там немного ошибся - ну да ладно. Это не принципиально. Главное что существуют символы где будет один импульс. В этом случае нельзя достоверно по одному байту определить скорость. Но таких символов очень мало. Примерно 99% будут восстановлены грамотно. Если же стоит задача полностью определить 100% символов, то выход - полностью программный анализ входного протокола. Я уверен, что на скорости >=8МГц при том, что однокристалка будет занята этой задачей, я бы восстановил любую многобайтовую посылку от 300 бод до 115200.

[singlskv]

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

Для непрерывного потока как раз все просто, Вы забываете в своем анализе что
всегда стартовый бит это переход 1->0 а стоповый наоборот.
ну и нужно конечно успет накопить статистику(может за 1 байт а может и за 20)

[SasaVitebsk]

Для непрерывного потока как раз все просто, Вы забываете в своем анализе что
всегда стартовый бит это переход 1->0 а стоповый наоборот.
ну и нужно конечно успет накопить статистику(может за 1 байт а может и за 20)

Только есть шанс необнаружить этот стоп бит а засинхронизароваться посреди байта и благополучно принимать послудующую инфу неправильно. Здесь как раз тема была. Парень передавал 55 а получал что угодно в зависимости от удачности врезания.

[sf9]

Я тоже считаю,что для определения скорости на лету с полным восстановлением данных и без байта синхронизации - задача под rs232 практически нерешаема.

Так,для самоуспокоения,хотел посоветоваться,может кто-то знает путь решения задачи.
Всё-равно,спасибо всем за идеи.

[Maik-vs]

Для Maik-vs, в линии изначально 1 и старт-бит приходит 0. Далее если вы распишете например байт 0xf0(на 115200), то вы поймёте, что он может быть 0xf0 на 115200, или 0xfc на 57600 или 0xfe на 28800 или 00 на 230400.

Я это понимаю, про f0 - fc - fe. Насмотрелся . А про 0 и 1 приучен не говрить, лучше уж говорить в терминах уровней "высокий-низкий". Потому что когда работал с ТТЛ и ЭСЛ, д аещё и интерфейсы - тады ой.

[singlskv]

Только есть шанс необнаружить этот стоп бит а засинхронизароваться посреди байта и благополучно принимать послудующую инфу неправильно. Здесь как раз тема была. Парень передавал 55 а получал что угодно в зависимости от удачности врезания.

Я имел в виду что скорость потока за ~20 байт мы можем выяснить гарантированно.
Для синхронизации конечно нужны паузы в потоке или достаточно длительное накопление
статистики и сдвиги на 1 бит до получения потока с правильными
стоп битами(наименьший % ошибок кадра).

[ae_]

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

Формат передачи 8-N-1, неприрывная серия байт:
0x55 @ speed 1x ничем не отличается от 0x0F @ speed 5x
0xF8 @ speed 1x -//- от 0xCE @ speed 2x
0x08 @ speed 1x -//- от 0x80 @ speed 2x
Т.е. нельзя выяснить скорость произвольного потока ни за 20 байт, а вообще нельзя, если в нём встречаются только две длительности нулей и единиц - 1/1, 2/3, 1/5, как в приведённых выше примерах.

[singlskv]

Т.е. нельзя выяснить скорость произвольного потока ни за 20 байт, а вообще нельзя, если в нём встречаются только две длительности нулей и единиц - 1/1, 2/3, 1/5, как в приведённых выше примерах.

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

[galjoen]

Делал автобауд для USART и для CAN (AT90CAN128). Подобно тому, как писал SasaVitebsk.
Отличие в том, что у меня процессор был занят, и пришлось использовать входы захвата таймеров. Один захватывал фронт, другой спад (прерывание от обоих). Получалась длительность нуля или единицы. Далее, по заранее рассчитанной таблице, прибавлял баллы накопителям (одному или нескольким), соответствующим скоростям от 1200 до 115200 бод. Причём, если длина соответствовала скорости неточно - баллов добавлял меньше (SasaVitebsk, а как вы дейсвовали в таком случае?). Скорость считалась определённой, когда один из накопителей переполнялся. Какой первым переполнился - такая и скорость. Конечно я согласен, что можно найти такие данные на которых данный алгоритм проколется, но в реальности я с этим не сталкивался.
Кстати в случае CAN такой алгоритм (ну несколько модифицированный) всегда безошибочно срабатывает с 1й посылки.

[Джеймс]

Скачайте с gaisler.com библиотеку grlib-gpl
Там как как раз в DSU UART есть автоопределение

[SasaVitebsk]

Тоже сталкнулся с такой байдой. Точно получить неудавалось, и ошибка иногда накапливалась. Но я делал по другому. Я сразу сравнивал с табличной величиной и прибавлял правильную, а не измеренную величину.

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