Интерфейс для связи блоков?

@morvym_yorki · Регистрация: 18.04.2010

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

Какой интерфейс лучше выбрать для связи блоков внутри робота?

SPI - быстро, но сложно реализовать мультимастер, нужно тянуть CSы
I2C - медленнее (или нет?), нативный мультимастер
CAN - знаю, что такое существует, но не знаю, насколько применимо и есть не во всех чипах

RS-232.. ну он немного не для того вроде.

робот будет представлять несколлько отдельных плат, связанных шлейфами либо мезонин, контроллеры STM32, возможно где-то STM8 или AVR.

Сам пока склоняюсь к I2C, но может сообщество переубедит?

@dsodir · 24.02.2011, 00:01

y2s.. и скорость у него до 400 кГц (по стандарту). А реально больше 20 кГц нафиг не надо. 20 кГц это примерно 2 Килобайта/сек.

@o9d · 24.02.2011, 00:06

UART и SPI самые простые.
На UART ставишь мультиплексор/демультиплексор и вешай сколько хочешь модулей. При этом код обмена будет очень простой.
На SPI код будет немножко сложней, но при этом скорость обмена намного выше.

24.02.2011, 01:08

Сообщение от morvym_yorki

SPI - быстро, но сложно реализовать мультимастер, нужно тянуть CSы

Это не страшно. Проблемы чаще в другом. Например, когда нужно передать не один байт, а несколько, особенно считать их с ведомого. Надо каким-то образом обеспечивать готовность данных в буфере ведомого до того, как их считает мастер, и их своевременное обновление. Я пробовал 2 варианта: с линией подтверждения готовности - неудобно при нескольких слэвах, и вводом пауз ожидания мастеру, на время, гарантирующее обработку и готовность слэва, - замедляет обмен, правда, не сильно.

I2C - медленнее (или нет?), нативный мультимастер

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

RS-232.. ну он немного не для того вроде.

Самый простой и довольно удобный протокол, требующий минимума отвлечения контроллера на обработку. Кроме отправки и приема байта, причем буферированного и потому не очень критичного по времени, ничего особого делать не надо. Многие контроллеры аппаратно поддерживают режим с адресацией (с использованием бита паритета).

Сам пока склоняюсь к I2C, но может сообщество переубедит?

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

Сообщение от o9d

На UART ставишь мультиплексор/демультиплексор и вешай сколько хочешь модулей. При этом код обмена будет очень простой.

Нифига не надо. Обьединяем у всех прием на одну линию, цепляем к ней через диоды передатчики, и общаемся по одному проводу хоть с десятком модулей. Используем адресацию, мастером - центральный контроллер, остальные передают только когда он разрешит. Другой вариант - также с адресацией, но мастером может быть любой. Это сложнее, нужно отслеживать коллизии.
Можно и без адресации, просто у каждого модуля будет своя подгруппа команд, с которыми он работает. Чужие команды просто игнорируются. Проще, чем с адресацией, но требует отслеживания вместо только адресных байтов, как минимум кодов команд. В общем то тоже не проблема.
При небольших расстояниях скорость RS232 можно сделать хоть 256 КБод. Но я не вижу смысла задирать скорость - у меня команды и сообщения в роботе короткие, до 8 байт, вполне достаточно и 9600 Бод - тогда в основном прерывании по таймеру 1mS я только проверяю готовность приема и передачи и выставляю флаги, обработку же их делаю в главном цикле (он проворачивается примерно за 250мкс). Прерывания от USORT в этом случае не нужны.

@o9d · 24.02.2011, 01:20

Я пробовал подцепить на одну линию через диоды два устройства. Нифига они не заработали. Это даже в протеусе не работает.

Прерывания кстати еще как нужны. Проводил тесты. Один байт прозевать без прерывания очень просто.

@dsodir · 24.02.2011, 01:21

Много мороки с реализацией ведомого.

Если чисто программно то да. А аппаратный довольно прост в обращении.

24.02.2011, 01:49

Сообщение от o9d

Я пробовал подцепить на одну линию через диоды два устройства. Нифига они не заработали. Это даже в протеусе не работает.

В Протеусе много чего не работает... "Монтажное И" в цифровой технике 70х-80х годов было обычным делом. Специально для этого чуть ли не половину логики с открытым коллектором делали.
У передатчиков USORT при СТОПе на выходе - 1, после сброса, до инициализации портов - высокоомное состояние (вход), так что проблем быть не должно. Просто прием (линию связи) подтянуть к питанию через резистор. Передатчики при стартовой полярности через диод тянут ее к 0.

Прерывания кстати еще как нужны. Проводил тесты. Один байт прозевать без прерывания очень просто.

При скорости 9600 Бод байт передается минимум за 1041,6666... микросекунды. Прерывания от таймера у меня идут через 1000мкс, так что при отсутствии задержек прерывания таймера пропусков быть не должно. Сам же обработчик - короткий. Главный цикл между тиками 1мс успевает провернуться 3-4 раза. Пока проблем не было. Можно конечно и прерывания USORT использовать, тем более что у PIC не надо толкать регистры в стек, обработчики получаются короткими. Переслал байт, выставил флаг... Можно и по прерываниям.
В режиме с адресацией будет использоваться прерывание по приходу адресного байта. Его надо будет проверить, и при совпадении адреса разрешить прием следующих байт, до следующего адресного байта. При несовпадении до следующего адресного байта все игнорируется. В режиме с адресацией передается старт, 8бит адреса, бит паритета, стоп, итого = 11бит, при скорости 9600 байт будет передаваться 1145,83 мкс.

24.02.2011, 01:55

[QUOTE="dsodir"][QUOTE="Цитата:[/QUOTE]

Много мороки с реализацией ведомого.

Если чисто программно то да. А аппаратный довольно прост в обращении. Я тоже так думал. Это когда он в часах или в памяти. А попробуйте реализовать его в контроллере. Одно название, что аппаратный. Все равно весь процесс надо чуть ли не побитно отслеживать.
Вот USORT - тот аппаратный. Кинул байт в передатчик, считал с буфера приемника принятый, и больше ничего... А с I2C ведомому дофига чего делать нужно. И в библиотеках функций для ведомого тоже нет, только для мастера. Надо как на ассемблере все расписывать.

@o9d · 24.02.2011, 02:09

Первоначально я схему собрал на диодах и у меня ничего не заработало. Проверил ее в протеусе и там тоже ничего не заработало.
Поэтому на транзисторах слепил мультиплексор/демультиплексор. Теперь все работает как часы. И без всякой адресации. Только нужно выделить пины для выбора канала. Код при этом выходит очень простой.

У меня также в проекте используется PIC контроллер. Я в нем как раз работу с UART сделал на прерываниях. Динные у меня передаются на скорости 115к. Для меня простои на приеме и передачи данных критичны.
Да и написать один обработчик прерывания UART по моему проще чем постоянно проверять флаг состояния. Там всего то пару строк кода на Си.

24.02.2011, 02:44

Сообщение от o9d

Да и написать один обработчик прерывания UART по моему проще чем постоянно проверять флаг состояния. Там всего то пару строк кода на Си.

А что должен делать этот обработчик? Ведь наша задача - не просто принять или отправить байт. Надо принять или отправить команду или пакет из нескольких байт, или принять пакет или команду, проверить на достоверность, декодировать, и так далее. В любом случае это в обработчик прерывания не засунешь, иначе на время приема пакета будет заблокирована работа всех остальных задач главного цикла. У меня же проверяется приемник, есть принятый байт - он считывается с приемника в буфер, ставится флаг наличия принятого байта. Когда в главном цикле обработчик приема видит этот флаг, он производит соответствующие действия, и в случае, например, успешного завершения приема команды, выставляет соответствующмй флаг, по которому уже дешифратор команд, в свою очередь, декодирует ее, и делает нужные действия или выставляет соответствующие флаги для выполнения этой команды, и так далее. Все вертится быстро, и задачи выполняются хоть и с разделением времени, но практически параллельно, не мешая друг другу. Достаточно лишь вовремя переслать байт и выставить флажок.

@o9d · 24.02.2011, 02:51

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

Код

void interrupt()
{
if (PIR1.RCIF == 1)
{
pktIn[j]=RCREG; //Read usart RX reg
j++;

PIR1.RCIF=0 ; //Clear flag

if(j==4) //комманда принята
{
j=0;
cmdState=1;         //комманда принята
}
}
}

Вот и весь обработчик. Под ОС scmRTOS код выглядит еще проще. Там для подобных вещей есть месседжи.

24.02.2011, 03:17

Сообщение от o9d

У меня также в проекте используется PIC контроллер. Я в нем как раз работу с UART сделал на прерываниях.

У PIC все прерывания сидят на одном векторе. И все равно вам придется в векторе этого прерывания проверять, что его вызвало. То есть проверять те же флаги USORT, таймера, портов, внешнего прерывания, АЦП, (до десятка и более причин прерываний). Даже если у вас будет отдельный обработчик для прерывания USORT, все равно он должен будет вызываться из основного вектора. И никакой экономии это не дает. Но чем больше прерываний задействовано, тем больше проверок, тем больше раздувается обработка прерывания.
Поэтому я предпочитаю как можно меньше использовать прерывания. Хотя бы те, без которых можно обойтись. И сам обработчик прерывания должен быть как можно короче. Зато и сами прерывания ни на что не влияют, и главный цикл быстро вертится.
Достаточно редкие и некритичные события (USORT, одометры), и без прерываний прекрасно обрабатываются. Да и задирать скорость USORT я смысла не вижу. Если команда в несколько байт поступает не чаще раза в секунду, а то и в несколько секунд, зачем мне гнать их на 115кбод? А радиоканал так у меня вообще на 1200 работает... (на 600 - вообще без потерь, но при 16мгц кварце меньше 1200 не выставить).
Вот у меня весь обработчик прерывания:

Код

procedure Int_Timer0;
begin
if cnt_1 > 0 then Dec(cnt_1);  {- таймер для }
if cnt_2 > 0 then Dec(cnt_2);  {- таймер для АЦП}
if pauza > 0 then Dec(pauza);  {- таймер для ПРД RS232}
if tim_aut > 0 then Dec(tim_aut); {- таймер для ПРМ RS232}
PORTC := PORTC xor $01;           {- Звук!}
if cnt_10 = 1 then
begin
if T_sound > 0 then Dec(T_sound);// Таймер продолжительности звука.
if DWL_2 > 0 then Dec(DWL_2);    // Время работы оставшееся ДВ_ЛЕВ
if DWP_2 > 0 then Dec(DWP_2);    // Время работы оставшееся ДВ_ПРАВ
end;
if cnt_10 = 0 then cnt_10 := 10 else Dec(cnt_10); {- таймер для двигателей}
if UART1_Data_Ready() = 1 then
begin
if SSP_1.6 = 1 then received_byte := UART1_Read()  // - очистка приемника, если идет своя передача.
else Sost_Prm.6 := 1; // Есть принятый байт с R232
end;
INTCON.2 := 0;   //clear T0IF
end;

//==== interrupt =====
procedure interrupt;
begin
if (T0IF <> 0) then Int_Timer0;
end;
//===================

Там куча программных таймеров, и пара строчек для приемника USORT.

Код

  if UART1_Data_Ready() = 1 then
begin
if SSP_1.6 = 1 then received_byte := UART1_Read()  //  - очистка приемника, если идет своя передача.
else Sost_Prm.6 := 1; // Есть принятый байт с R232
end;

Только и делов. Ничем не сложнее вашего.

@o9d · 24.02.2011, 03:33

Прерывание UART срабатывает только тогда когда данные есть. В случае с таймером, это прерывание будет постоянно вызываться и постоянно будет происходить ненужная проверка.
Приоритеты прерывания в PIC распределяются программно. Т.е. если поставить обработку наиболее частого прерывания в самом верху, то ненужны проверки производится не будут.
В армах аналогичная ситуация, но там ведь никто не городит uart на таймерах.

Чем выше скорость приема/передачи тем меньше расходуется времени на эту процедуру. Также следует помнить, что по мимо текущего существует и еще другой контроллер который ждет отклика или еще чего нибудь. Задержка в одном контролере приводит к задержке во всей системе.

Моя платформа умеет(уже) выполнять команды в стиле "ехать вперед/назад на ХХ расстояние", "повернуть на определенный градус", "вернуть текущее состояние платформы".
Чем чаще происходит опрос датчиков тем точнее будет определяться расстояние и угол поворота. Также скорость реакции повышается на события. У меня помимо отслеживания пути и угла, происходит проверка на столкновение и на наличие земли под ногами.

24.02.2011, 12:28

Сообщение от o9d

Прерывание UART срабатывает только тогда когда данные есть. В случае с таймером, это прерывание будет постоянно вызываться и постоянно будет происходить ненужная проверка.

Так таймер 1мс у меня крутится постоянно. На нем реализована куча програмных таймеров, для формирования всех временных интервалов программы. Когда - то я им еще и часы с календарем попутно делал, (сейчас проще отдельные поставить). И такая скорость опроса некоторых событий, в том числе и USORT при скоростях до 9600, вполне достаточна. Робот же за 1 мс продвинется максимум на 0,2-0,3 мм, куда уж точнее... Между тиками таймера у контроллера есть время, достаточное для выполнения около 4-5 тысяч команд (при 16 или 20МГц), главный цикл, например, ходового контроллера, успевает провернуться 4 раза.
Кроме того, у меня не один контроллер, а куча, и каждый реализует свой, функционально завершенный, круг задач, обмениваясь минимумом информации более высокого уровня с другими.

В армах аналогичная ситуация, но там ведь никто не городит uart на таймерах.

У меня же не арм... Кроме того, я не фанат одной идеи, где что удобнее, то и использую. И USORT у меня не на таймере, а аппаратный, по таймеру я проверяю только наличие принятого байта. И кручу программные задержки.

Чем выше скорость приема/передачи тем меньше расходуется времени на эту процедуру.

А вот тут как раз наоборот. Время обработки прерывания от USORT и считывания байта постоянно, независимо от скорости. Значит, чем чаще приходят быйты, тем больше затрачивается времени на их обработку.
Другое дело, что при разумном выборе скорости затраты времени на USORT достаточно малы и при моем способе. Некритично, одну сотую процента или несколько сотых процента времени контроллера оно займет.

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

При правильном распределении функций между контроллерами этого не должно быть. Получит, например, ходовой контроллер команду изменить скорость, или начать движение, или остановиться, на несколько миллисекунд раньше или позже - роли не играет. А жизненно важные ситуации он совместно с контроллером бамперов обрабатывает сам, с максимальным приоритетом.
Или контроллер башни получит команду на включение подсветки или поворот башни на миллисекунду позже... Какие в этом проблемы? Все относительно, и без задержек в многозадачной системе не обойтись. Другое дело, насколько они критичны. Не обязательно доводить все до абсолюта, есть реальные, не такие уж и высокие, требования.

Чем чаще происходит опрос датчиков тем точнее будет определяться расстояние и угол поворота.

Опять же, до определенного предела. Как я уже писал, за миллисекунду мой робот сдвинется максимум на 0,2мм. За это время одометры опрашиваются в главном цикле 4 раза. Изменение же состояния датчиков одометров происходит намного реже. Если я их буду опрашивать раз в микросекунду или по прерыванию от них - ничего точнее не станет. Есть понятие "Разумная достаточность", сильно упрощающее решение многих задач. Нет смысла добиваться точности выше той, что, например, обеспечивается примененным одометром (числом его секторов на оборот колеса), и люфтами механизма (если датчик одометра не на самом колесе).

Цитата:

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

У меня проверкой пола, столкновений, и ближайших (до 20см) помех движению, вообще занимается выделенный контроллер бамперов. И ходовой контроллер самостоятельно принимает решение о прекращении движения в критических случаях, независимо от команд центрального, лишь докладывая ему о причине невозможности выполнения команды.
В общем, все зависит в большей степени от распределения функций и задач между контроллерами, а не от скорости обмена между ними. Следует стремиться к их независимости и завершенности в пределах выполняемой задачи, взаимодействуя только на достаточно высоком уровне. Сказал центральный ходовому "вперед 50см, влево 10см", или "Ехать 60см по азимуту -10 градусов", со скоростью 80%, - остальное ходовой должен делать сам, причем независимо от того, колесами он вертит, гусеницами ворочает, или ногами топает. Ходовому решать, какой коэффициент ШИМ какому движку сделать, какую полярность подать на двигатель, и сколько срабатываний с какого одометра отсчитать. Центрального же это не касается. Он дал команду, и должен получить лишь информацию, что она выполнена, или причину невыполнения и текущий статус.

@svs39 · 24.02.2011, 13:55

Сообщение от o9d

UART и SPI самые простые.
На UART ставишь мультиплексор/демультиплексор и вешай сколько хочешь модулей. При этом код обмена будет очень простой.

а rs485 почему не вспомните- я им польэуюсь- физический уровень очень даже оптимален- скорость, простота, помехоустойчивость

24.02.2011, 15:22

Сообщение от svs39

а rs485 почему не вспомните- я им польэуюсь- физический уровень очень даже оптимален- скорость, простота, помехоустойчивость

Для малых расстояний (в данном случае между модулями робота) RS485 не имеет особых преимуществ перед обычным RS232, даже с ТТЛ уровнями. Но требует установки микросхем сопряжения и управления ими. Богу - богово. RS485 имеет смысл только на длинных линиях (для высоких скоростей).
Для межмодульного обмена, особенно на небольших (9600 - 19200 и менее) скоростях, при соблюдении некоторых элементарных правил, вполне достаточно RS232 с логическими уровнями. Даже при однопроводных интерфейсах, как у меня. А если нужна скорость (также при малых расстояниях) - есть SPI, I2C.

@o9d · 24.02.2011, 19:37

У меня же не арм... Кроме того, я не фанат одной идеи, где что удобнее, то и использую. И USORT у меня не на таймере, а аппаратный, по таймеру я проверяю только наличие принятого байта. И кручу программные задержки.

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

А вот тут как раз наоборот. Время обработки прерывания от USORT и считывания байта постоянно, независимо от скорости. Значит, чем чаще приходят быйты, тем больше затрачивается времени на их обработку.
Другое дело, что при разумном выборе скорости затраты времени на USORT достаточно малы и при моем способе. Некритично, одну сотую процента или несколько сотых процента времени контроллера оно займет.

Для того чтобы обработать сообщение его нужно принять полностью/отправить полностью. Чем выше скорость отправки/приема тем меньше на это будет расходоваться времени.
Между скоростью и количеством отправляемых байтов нет никакой взаимосвязи. При любой скорости чем чаще будут приходить байты, тем больше будет расходоваться времени на обработку.

При правильном распределении функций между контроллерами этого не должно быть. Получит, например, ходовой контроллер команду изменить скорость, или начать движение, или остановиться, на несколько миллисекунд раньше или позже - роли не играет. А жизненно важные ситуации он совместно с контроллером бамперов обрабатывает сам, с максимальным приоритетом.
Или контроллер башни получит команду на включение подсветки или поворот башни на миллисекунду позже... Какие в этом проблемы? Все относительно, и без задержек в многозадачной системе не обойтись. Другое дело, насколько они критичны. Не обязательно доводить все до абсолюта, есть реальные, не такие уж и высокие, требования.

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

Опять же, до определенного предела. Как я уже писал, за миллисекунду мой робот сдвинется максимум на 0,2мм. За это время одометры опрашиваются в главном цикле 4 раза. Изменение же состояния датчиков одометров происходит намного реже. Если я их буду опрашивать раз в микросекунду или по прерыванию от них - ничего точнее не станет. Есть понятие "Разумная достаточность", сильно упрощающее решение многих задач. Нет смысла добиваться точности выше той, что, например, обеспечивается примененным одометром (числом его секторов на оборот колеса), и люфтами механизма (если датчик одометра не на самом колесе).

Есть датчики на которых прохлопать событие очень легко. Также это важно при работе с трансиверами. Это может привести к потере нескольких кб/с.

В rs485 вообще не вижу смысла. С такимже успехом можно использовать эзернет.

24.02.2011, 20:41

Сообщение от o9d

Удобства не вижу, идет только усложнение.

Хозяин - барин. Хочет - моется, хочет - парится. Кому что...

Для того чтобы обработать сообщение его нужно принять полностью/отправить полностью. Чем выше скорость отправки/приема тем меньше на это будет расходоваться времени.

Это только в том случае, если прием и обработка сообщения выполняются монопольно, полностью занимая контроллер. Я же всегда использую многозадачность, и в моем случае это совершенно не влияет. В процессе приема пакета параллельно выполняются и другие задачи. Само же обнаружение и пересылка очередного байта с приемника в буфер сообщения - всего лишь несколько команд. И неважно время приема пакета в целом, суммарное потраченное программой время на него почти не зависит от скорости канала.

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

У меня скорость радиоканала 1200 бод. Длина пакета команды 8 байт. Перед пакетом после включения несущей передатчика даю паузу 100мс для стабилизации АРУ приемника. Также даю небольшую задержку перед выключением несущей после конца пакета. Итого полное врмя передачи команды получается порядка 180 мс. +-1мс никакой роли не играет. Куда мне спешить? А команды передаются достаточно высокого уровня, и не критичны по времени. В реальном времени работают модули самого робота, и достаточно автономно. Зачем мне высокая пропускная способность, для передачи 8 байт раз в несколько секунд, а то и минут? Для видео у меня отдельный радиоканал в телекамере. При желании я могу подмешивать часть информации и в видеосигнал, если будет такая необходимость. Как в отдельные строки, так и по каналу звука.

Есть датчики на которых прохлопать событие очень легко.

Такие датчики у меня обрабатываются не через канал, а непосредственно контроллером. Иногда выделенным (как например 12 датчиков бампера).

Также это важно при работе с трансиверами. Это может привести к потере нескольких кб/с.

Ну, у меня - в радиоканале 1200бод, пакет 8 байт. Не более 5 пакетов-сообщений в секунду. Куда мне cпешить - то?
Будет более приличный трансивер - так у него будет большой встроенный буфер. Нет проблем...

@o9d · 24.02.2011, 21:10

Это только в том случае, если прием и обработка сообщения выполняются монопольно, полностью занимая контроллер. Я же всегда использую многозадачность, и в моем случае это совершенно не влияет. В процессе приема пакета параллельно выполняются и другие задачи. Само же обнаружение и пересылка очередного байта с приемника в буфер сообщения - всего лишь несколько команд. И неважно время приема пакета в целом, суммарное потраченное программой время на него почти не зависит от скорости канала.

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

У меня скорость радиоканала 1200 бод. Длина пакета команды 8 байт. Перед пакетом после включения несущей передатчика даю паузу 100мс для стабилизации АРУ приемника. Также даю небольшую задержку перед выключением несущей после конца пакета. Итого полное врмя передачи команды получается порядка 180 мс. +-1мс никакой роли не играет. Куда мне спешить? А команды передаются достаточно высокого уровня, и не критичны по времени. В реальном времени работают модули самого робота, и достаточно автономно. Зачем мне высокая пропускная способность, для передачи 8 байт раз в несколько секунд, а то и минут? Для видео у меня отдельный радиоканал в телекамере. При желании я могу подмешивать часть информации и в видеосигнал, если будет такая необходимость. Как в отдельные строки, так и по каналу звука.

Подобное имеет смысл при небольших объемах информации.У меня совершенно противоположная ситуация. По радиоканалу передается еще и видеопоток.

Трансиверы кода принимают пакет переходят в режим простоя. Даже если сообщение будет короткое. Как обстоят дела с UART удлинителями не знаю.

24.02.2011, 21:40

Сообщение от o9d

А каким это образом прерывания мешают работе других задач?

Я этого не говорил.

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

А чего ради у меня контроллер простаивает?
Главный цикл крутится постоянно, просматривая состояния задач по флажкам, и выполняя нужные действия. Ни одна задача монопольно не выполняется, все по кусочкам. Глянул флаг наличия байта на приеме, есть - скинул его в буфер сообщения, инкрементировал счетчик байт, побежал дальше. В другом месте принятый байт проверяется по некоторым критериям, и выставляются флаги начала или конца команды. Если команда принята полностью, декодер команды ее проанализирует, сделает нужные действия, выставит флажки для других задач. Все непрерывно крутится и выполняется. Процессор никогда не простаивает и ничего не ждет. Эленентарщина... Уже четверть века программы своих контроллеров по такому принципу строю. Все успевают. Сейчас главный цикл ходового крутится с периодом около 250 мкс, обрабатывая все свои задачи. И бамперы, и энкодеры, и движки, и контроль батареи, и одометры, и многое другое.

Подобное имеет смысл при небольших объемах информации.У меня совершенно противоположная ситуация. По радиоканалу передается еще и видеопоток.

Ну, я не валю все яйца в одну корзину... Радиоканал (315МГц) у меня для команд и телеметрии.
Видео, - причем несжатое, телевизионное, - на ~1125 МГц, само по себе. Друг другу не мешают, разнос частот почти четырехкратный. Видео идет непрерывно (если включено контроллером башни), передатчик командного канала работает кратковременно. В основном идет контроль приема.
Межконтроллерный обмен у меня с радиоканалом не связан. Сейчас радиоканал - в ходовом контроллере, потом уйдет в центральный, когда тот будет готов. В центральном будет Мега 128 с 2 USORT, один - на радиоканал, второй возможно буду использовать для межконтроллерного обмена. Или SPI. Пока не определился, закладываю и то и то. Ходовой с бамперами сейчас общается по SPI.
Башню пока отлаживаю в автономе, через ее USORT, и СОМ порт компьютера. Наверное с ходовым башню пока связывать не буду, заведу их сразу в центральный.

@morvym_yorki 0 / 0 / 0 Регистрация: 18.04.2010 Сообщений: 598
		1
	Интерфейс для связи блоков? 23.02.2011, 23:57. Показов 26236. Ответов 28 Метки нет (Все метки) Какой интерфейс лучше выбрать для связи блоков внутри робота? SPI - быстро, но сложно реализовать мультимастер, нужно тянуть CSы I2C - медленнее (или нет?), нативный мультимастер CAN - знаю, что такое существует, но не знаю, насколько применимо и есть не во всех чипах RS-232.. ну он немного не для того вроде. робот будет представлять несколлько отдельных плат, связанных шлейфами либо мезонин, контроллеры STM32, возможно где-то STM8 или AVR. Сам пока склоняюсь к I2C, но может сообщество переубедит? 0

@dsodir 0 / 0 / 0 Регистрация: 28.09.2010 Сообщений: 4,283
	24.02.2011, 00:01	2
	y2s.. и скорость у него до 400 кГц (по стандарту). А реально больше 20 кГц нафиг не надо. 20 кГц это примерно 2 Килобайта/сек. 0

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	24.02.2011, 00:06	3
	UART и SPI самые простые. На UART ставишь мультиплексор/демультиплексор и вешай сколько хочешь модулей. При этом код обмена будет очень простой. На SPI код будет немножко сложней, но при этом скорость обмена намного выше. 0

SWK
	24.02.2011, 01:08	4
	Сообщение от morvym_yorki SPI - быстро, но сложно реализовать мультимастер, нужно тянуть CSы Это не страшно. Проблемы чаще в другом. Например, когда нужно передать не один байт, а несколько, особенно считать их с ведомого. Надо каким-то образом обеспечивать готовность данных в буфере ведомого до того, как их считает мастер, и их своевременное обновление. Я пробовал 2 варианта: с линией подтверждения готовности - неудобно при нескольких слэвах, и вводом пауз ожидания мастеру, на время, гарантирующее обработку и готовность слэва, - замедляет обмен, правда, не сильно. I2C - медленнее (или нет?), нативный мультимастер Много мороки с реализацией ведомого. Приходится контролировать каждый шаг, сложновато реализуется, прилично грузит ведомый контроллер... RS-232.. ну он немного не для того вроде. Самый простой и довольно удобный протокол, требующий минимума отвлечения контроллера на обработку. Кроме отправки и приема байта, причем буферированного и потому не очень критичного по времени, ничего особого делать не надо. Многие контроллеры аппаратно поддерживают режим с адресацией (с использованием бита паритета). Сам пока склоняюсь к I2C, но может сообщество переубедит? Попробуйте реализовать ведомого. Если получится нормально и просто - может и подойдет. Я после первой попытки решил пока отложить на время... Сообщение от o9d На UART ставишь мультиплексор/демультиплексор и вешай сколько хочешь модулей. При этом код обмена будет очень простой. Нифига не надо. Обьединяем у всех прием на одну линию, цепляем к ней через диоды передатчики, и общаемся по одному проводу хоть с десятком модулей. Используем адресацию, мастером - центральный контроллер, остальные передают только когда он разрешит. Другой вариант - также с адресацией, но мастером может быть любой. Это сложнее, нужно отслеживать коллизии. Можно и без адресации, просто у каждого модуля будет своя подгруппа команд, с которыми он работает. Чужие команды просто игнорируются. Проще, чем с адресацией, но требует отслеживания вместо только адресных байтов, как минимум кодов команд. В общем то тоже не проблема. При небольших расстояниях скорость RS232 можно сделать хоть 256 КБод. Но я не вижу смысла задирать скорость - у меня команды и сообщения в роботе короткие, до 8 байт, вполне достаточно и 9600 Бод - тогда в основном прерывании по таймеру 1mS я только проверяю готовность приема и передачи и выставляю флаги, обработку же их делаю в главном цикле (он проворачивается примерно за 250мкс). Прерывания от USORT в этом случае не нужны.

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	24.02.2011, 01:20	5
	Я пробовал подцепить на одну линию через диоды два устройства. Нифига они не заработали. Это даже в протеусе не работает. Прерывания кстати еще как нужны. Проводил тесты. Один байт прозевать без прерывания очень просто. 0

@dsodir 0 / 0 / 0 Регистрация: 28.09.2010 Сообщений: 4,283
	24.02.2011, 01:21	6
	Много мороки с реализацией ведомого. Если чисто программно то да. А аппаратный довольно прост в обращении. 0

SWK
	24.02.2011, 01:49	7
	Сообщение от o9d Я пробовал подцепить на одну линию через диоды два устройства. Нифига они не заработали. Это даже в протеусе не работает. В Протеусе много чего не работает... "Монтажное И" в цифровой технике 70х-80х годов было обычным делом. Специально для этого чуть ли не половину логики с открытым коллектором делали. У передатчиков USORT при СТОПе на выходе - 1, после сброса, до инициализации портов - высокоомное состояние (вход), так что проблем быть не должно. Просто прием (линию связи) подтянуть к питанию через резистор. Передатчики при стартовой полярности через диод тянут ее к 0. Прерывания кстати еще как нужны. Проводил тесты. Один байт прозевать без прерывания очень просто. При скорости 9600 Бод байт передается минимум за 1041,6666... микросекунды. Прерывания от таймера у меня идут через 1000мкс, так что при отсутствии задержек прерывания таймера пропусков быть не должно. Сам же обработчик - короткий. Главный цикл между тиками 1мс успевает провернуться 3-4 раза. Пока проблем не было. Можно конечно и прерывания USORT использовать, тем более что у PIC не надо толкать регистры в стек, обработчики получаются короткими. Переслал байт, выставил флаг... Можно и по прерываниям. В режиме с адресацией будет использоваться прерывание по приходу адресного байта. Его надо будет проверить, и при совпадении адреса разрешить прием следующих байт, до следующего адресного байта. При несовпадении до следующего адресного байта все игнорируется. В режиме с адресацией передается старт, 8бит адреса, бит паритета, стоп, итого = 11бит, при скорости 9600 байт будет передаваться 1145,83 мкс.

SWK
	24.02.2011, 01:55	8
	[QUOTE="dsodir"][QUOTE="Цитата:[/QUOTE] Много мороки с реализацией ведомого. Если чисто программно то да. А аппаратный довольно прост в обращении. Я тоже так думал. Это когда он в часах или в памяти. А попробуйте реализовать его в контроллере. Одно название, что аппаратный. Все равно весь процесс надо чуть ли не побитно отслеживать. Вот USORT - тот аппаратный. Кинул байт в передатчик, считал с буфера приемника принятый, и больше ничего... А с I2C ведомому дофига чего делать нужно. И в библиотеках функций для ведомого тоже нет, только для мастера. Надо как на ассемблере все расписывать.

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	24.02.2011, 02:09	9
	Первоначально я схему собрал на диодах и у меня ничего не заработало. Проверил ее в протеусе и там тоже ничего не заработало. Поэтому на транзисторах слепил мультиплексор/демультиплексор. Теперь все работает как часы. И без всякой адресации. Только нужно выделить пины для выбора канала. Код при этом выходит очень простой. У меня также в проекте используется PIC контроллер. Я в нем как раз работу с UART сделал на прерываниях. Динные у меня передаются на скорости 115к. Для меня простои на приеме и передачи данных критичны. Да и написать один обработчик прерывания UART по моему проще чем постоянно проверять флаг состояния. Там всего то пару строк кода на Си. 0

SWK
	24.02.2011, 02:44	10
	Сообщение от o9d Да и написать один обработчик прерывания UART по моему проще чем постоянно проверять флаг состояния. Там всего то пару строк кода на Си. А что должен делать этот обработчик? Ведь наша задача - не просто принять или отправить байт. Надо принять или отправить команду или пакет из нескольких байт, или принять пакет или команду, проверить на достоверность, декодировать, и так далее. В любом случае это в обработчик прерывания не засунешь, иначе на время приема пакета будет заблокирована работа всех остальных задач главного цикла. У меня же проверяется приемник, есть принятый байт - он считывается с приемника в буфер, ставится флаг наличия принятого байта. Когда в главном цикле обработчик приема видит этот флаг, он производит соответствующие действия, и в случае, например, успешного завершения приема команды, выставляет соответствующмй флаг, по которому уже дешифратор команд, в свою очередь, декодирует ее, и делает нужные действия или выставляет соответствующие флаги для выполнения этой команды, и так далее. Все вертится быстро, и задачи выполняются хоть и с разделением времени, но практически параллельно, не мешая друг другу. Достаточно лишь вовремя переслать байт и выставить флажок.

	24.02.2011, 21:40

Опции темы

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	24.02.2011, 02:51	11
	Обработчик прерывания записывает данные в массив. В дальнейшем уже эти данные обрабатывается когда это удобно. При этом код выходит элементарный, не нужно задумываться о распределении времени, ни один байт не теряется. Код void interrupt() { if (PIR1.RCIF == 1) { pktIn[j]=RCREG; //Read usart RX reg j++; PIR1.RCIF=0 ; //Clear flag if(j==4) //комманда принята { j=0; cmdState=1; //комманда принята } } } Вот и весь обработчик. Под ОС scmRTOS код выглядит еще проще. Там для подобных вещей есть месседжи. 0

SWK
	24.02.2011, 03:17	12
	Сообщение от o9d У меня также в проекте используется PIC контроллер. Я в нем как раз работу с UART сделал на прерываниях. У PIC все прерывания сидят на одном векторе. И все равно вам придется в векторе этого прерывания проверять, что его вызвало. То есть проверять те же флаги USORT, таймера, портов, внешнего прерывания, АЦП, (до десятка и более причин прерываний). Даже если у вас будет отдельный обработчик для прерывания USORT, все равно он должен будет вызываться из основного вектора. И никакой экономии это не дает. Но чем больше прерываний задействовано, тем больше проверок, тем больше раздувается обработка прерывания. Поэтому я предпочитаю как можно меньше использовать прерывания. Хотя бы те, без которых можно обойтись. И сам обработчик прерывания должен быть как можно короче. Зато и сами прерывания ни на что не влияют, и главный цикл быстро вертится. Достаточно редкие и некритичные события (USORT, одометры), и без прерываний прекрасно обрабатываются. Да и задирать скорость USORT я смысла не вижу. Если команда в несколько байт поступает не чаще раза в секунду, а то и в несколько секунд, зачем мне гнать их на 115кбод? А радиоканал так у меня вообще на 1200 работает... (на 600 - вообще без потерь, но при 16мгц кварце меньше 1200 не выставить). Вот у меня весь обработчик прерывания: Код procedure Int_Timer0; begin if cnt_1 > 0 then Dec(cnt_1); {- таймер для } if cnt_2 > 0 then Dec(cnt_2); {- таймер для АЦП} if pauza > 0 then Dec(pauza); {- таймер для ПРД RS232} if tim_aut > 0 then Dec(tim_aut); {- таймер для ПРМ RS232} PORTC := PORTC xor $01; {- Звук!} if cnt_10 = 1 then begin if T_sound > 0 then Dec(T_sound);// Таймер продолжительности звука. if DWL_2 > 0 then Dec(DWL_2); // Время работы оставшееся ДВ_ЛЕВ if DWP_2 > 0 then Dec(DWP_2); // Время работы оставшееся ДВ_ПРАВ end; if cnt_10 = 0 then cnt_10 := 10 else Dec(cnt_10); {- таймер для двигателей} if UART1_Data_Ready() = 1 then begin if SSP_1.6 = 1 then received_byte := UART1_Read() // - очистка приемника, если идет своя передача. else Sost_Prm.6 := 1; // Есть принятый байт с R232 end; INTCON.2 := 0; //clear T0IF end; //==== interrupt ===== procedure interrupt; begin if (T0IF <> 0) then Int_Timer0; end; //=================== Там куча программных таймеров, и пара строчек для приемника USORT. Код if UART1_Data_Ready() = 1 then begin if SSP_1.6 = 1 then received_byte := UART1_Read() // - очистка приемника, если идет своя передача. else Sost_Prm.6 := 1; // Есть принятый байт с R232 end; Только и делов. Ничем не сложнее вашего.

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	24.02.2011, 03:33	13
	Прерывание UART срабатывает только тогда когда данные есть. В случае с таймером, это прерывание будет постоянно вызываться и постоянно будет происходить ненужная проверка. Приоритеты прерывания в PIC распределяются программно. Т.е. если поставить обработку наиболее частого прерывания в самом верху, то ненужны проверки производится не будут. В армах аналогичная ситуация, но там ведь никто не городит uart на таймерах. Чем выше скорость приема/передачи тем меньше расходуется времени на эту процедуру. Также следует помнить, что по мимо текущего существует и еще другой контроллер который ждет отклика или еще чего нибудь. Задержка в одном контролере приводит к задержке во всей системе. Моя платформа умеет(уже) выполнять команды в стиле "ехать вперед/назад на ХХ расстояние", "повернуть на определенный градус", "вернуть текущее состояние платформы". Чем чаще происходит опрос датчиков тем точнее будет определяться расстояние и угол поворота. Также скорость реакции повышается на события. У меня помимо отслеживания пути и угла, происходит проверка на столкновение и на наличие земли под ногами. 0

SWK
	24.02.2011, 12:28	14
	Сообщение от o9d Прерывание UART срабатывает только тогда когда данные есть. В случае с таймером, это прерывание будет постоянно вызываться и постоянно будет происходить ненужная проверка. Так таймер 1мс у меня крутится постоянно. На нем реализована куча програмных таймеров, для формирования всех временных интервалов программы. Когда - то я им еще и часы с календарем попутно делал, (сейчас проще отдельные поставить). И такая скорость опроса некоторых событий, в том числе и USORT при скоростях до 9600, вполне достаточна. Робот же за 1 мс продвинется максимум на 0,2-0,3 мм, куда уж точнее... Между тиками таймера у контроллера есть время, достаточное для выполнения около 4-5 тысяч команд (при 16 или 20МГц), главный цикл, например, ходового контроллера, успевает провернуться 4 раза. Кроме того, у меня не один контроллер, а куча, и каждый реализует свой, функционально завершенный, круг задач, обмениваясь минимумом информации более высокого уровня с другими. В армах аналогичная ситуация, но там ведь никто не городит uart на таймерах. У меня же не арм... Кроме того, я не фанат одной идеи, где что удобнее, то и использую. И USORT у меня не на таймере, а аппаратный, по таймеру я проверяю только наличие принятого байта. И кручу программные задержки. Чем выше скорость приема/передачи тем меньше расходуется времени на эту процедуру. А вот тут как раз наоборот. Время обработки прерывания от USORT и считывания байта постоянно, независимо от скорости. Значит, чем чаще приходят быйты, тем больше затрачивается времени на их обработку. Другое дело, что при разумном выборе скорости затраты времени на USORT достаточно малы и при моем способе. Некритично, одну сотую процента или несколько сотых процента времени контроллера оно займет. Также следует помнить, что по мимо текущего существует и еще другой контроллер который ждет отклика или еще чего нибудь. Задержка в одном контролере приводит к задержке во всей системе. При правильном распределении функций между контроллерами этого не должно быть. Получит, например, ходовой контроллер команду изменить скорость, или начать движение, или остановиться, на несколько миллисекунд раньше или позже - роли не играет. А жизненно важные ситуации он совместно с контроллером бамперов обрабатывает сам, с максимальным приоритетом. Или контроллер башни получит команду на включение подсветки или поворот башни на миллисекунду позже... Какие в этом проблемы? Все относительно, и без задержек в многозадачной системе не обойтись. Другое дело, насколько они критичны. Не обязательно доводить все до абсолюта, есть реальные, не такие уж и высокие, требования. Чем чаще происходит опрос датчиков тем точнее будет определяться расстояние и угол поворота. Опять же, до определенного предела. Как я уже писал, за миллисекунду мой робот сдвинется максимум на 0,2мм. За это время одометры опрашиваются в главном цикле 4 раза. Изменение же состояния датчиков одометров происходит намного реже. Если я их буду опрашивать раз в микросекунду или по прерыванию от них - ничего точнее не станет. Есть понятие "Разумная достаточность", сильно упрощающее решение многих задач. Нет смысла добиваться точности выше той, что, например, обеспечивается примененным одометром (числом его секторов на оборот колеса), и люфтами механизма (если датчик одометра не на самом колесе). Цитата: Также скорость реакции повышается на события. У меня помимо отслеживания пути и угла, происходит проверка на столкновение и на наличие земли под ногами. У меня проверкой пола, столкновений, и ближайших (до 20см) помех движению, вообще занимается выделенный контроллер бамперов. И ходовой контроллер самостоятельно принимает решение о прекращении движения в критических случаях, независимо от команд центрального, лишь докладывая ему о причине невозможности выполнения команды. В общем, все зависит в большей степени от распределения функций и задач между контроллерами, а не от скорости обмена между ними. Следует стремиться к их независимости и завершенности в пределах выполняемой задачи, взаимодействуя только на достаточно высоком уровне. Сказал центральный ходовому "вперед 50см, влево 10см", или "Ехать 60см по азимуту -10 градусов", со скоростью 80%, - остальное ходовой должен делать сам, причем независимо от того, колесами он вертит, гусеницами ворочает, или ногами топает. Ходовому решать, какой коэффициент ШИМ какому движку сделать, какую полярность подать на двигатель, и сколько срабатываний с какого одометра отсчитать. Центрального же это не касается. Он дал команду, и должен получить лишь информацию, что она выполнена, или причину невыполнения и текущий статус.

@svs39 0 / 0 / 0 Регистрация: 13.04.2010 Сообщений: 368
	24.02.2011, 13:55	15
	Сообщение от o9d UART и SPI самые простые. На UART ставишь мультиплексор/демультиплексор и вешай сколько хочешь модулей. При этом код обмена будет очень простой. а rs485 почему не вспомните- я им польэуюсь- физический уровень очень даже оптимален- скорость, простота, помехоустойчивость 0

SWK
	24.02.2011, 15:22	16
	Сообщение от svs39 а rs485 почему не вспомните- я им польэуюсь- физический уровень очень даже оптимален- скорость, простота, помехоустойчивость Для малых расстояний (в данном случае между модулями робота) RS485 не имеет особых преимуществ перед обычным RS232, даже с ТТЛ уровнями. Но требует установки микросхем сопряжения и управления ими. Богу - богово. RS485 имеет смысл только на длинных линиях (для высоких скоростей). Для межмодульного обмена, особенно на небольших (9600 - 19200 и менее) скоростях, при соблюдении некоторых элементарных правил, вполне достаточно RS232 с логическими уровнями. Даже при однопроводных интерфейсах, как у меня. А если нужна скорость (также при малых расстояниях) - есть SPI, I2C.

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	24.02.2011, 19:37	17
	У меня же не арм... Кроме того, я не фанат одной идеи, где что удобнее, то и использую. И USORT у меня не на таймере, а аппаратный, по таймеру я проверяю только наличие принятого байта. И кручу программные задержки. Такой подход раздувает код обработчика таймера. Также будет постоянно производится ненужная проверка. По большому счета в этой проверки нет никакого смысла. Удобства не вижу, идет только усложнение. А вот тут как раз наоборот. Время обработки прерывания от USORT и считывания байта постоянно, независимо от скорости. Значит, чем чаще приходят быйты, тем больше затрачивается времени на их обработку. Другое дело, что при разумном выборе скорости затраты времени на USORT достаточно малы и при моем способе. Некритично, одну сотую процента или несколько сотых процента времени контроллера оно займет. Для того чтобы обработать сообщение его нужно принять полностью/отправить полностью. Чем выше скорость отправки/приема тем меньше на это будет расходоваться времени. Между скоростью и количеством отправляемых байтов нет никакой взаимосвязи. При любой скорости чем чаще будут приходить байты, тем больше будет расходоваться времени на обработку. При правильном распределении функций между контроллерами этого не должно быть. Получит, например, ходовой контроллер команду изменить скорость, или начать движение, или остановиться, на несколько миллисекунд раньше или позже - роли не играет. А жизненно важные ситуации он совместно с контроллером бамперов обрабатывает сам, с максимальным приоритетом. Или контроллер башни получит команду на включение подсветки или поворот башни на миллисекунду позже... Какие в этом проблемы? Все относительно, и без задержек в многозадачной системе не обойтись. Другое дело, насколько они критичны. Не обязательно доводить все до абсолюта, есть реальные, не такие уж и высокие, требования. При общении с механикой 1 мс ничего толком не решает. Но при обмене инфой по эфиру 1 мс имеет большое значение. Это сильно снижает пропускную способность канала. Если такие задержки накопятся, то робот станет не мгновенно реагировать на приходящие команды. Опять же, до определенного предела. Как я уже писал, за миллисекунду мой робот сдвинется максимум на 0,2мм. За это время одометры опрашиваются в главном цикле 4 раза. Изменение же состояния датчиков одометров происходит намного реже. Если я их буду опрашивать раз в микросекунду или по прерыванию от них - ничего точнее не станет. Есть понятие "Разумная достаточность", сильно упрощающее решение многих задач. Нет смысла добиваться точности выше той, что, например, обеспечивается примененным одометром (числом его секторов на оборот колеса), и люфтами механизма (если датчик одометра не на самом колесе). Есть датчики на которых прохлопать событие очень легко. Также это важно при работе с трансиверами. Это может привести к потере нескольких кб/с. В rs485 вообще не вижу смысла. С такимже успехом можно использовать эзернет. 0

SWK
	24.02.2011, 20:41	18
	Сообщение от o9d Удобства не вижу, идет только усложнение. Хозяин - барин. Хочет - моется, хочет - парится. Кому что... Для того чтобы обработать сообщение его нужно принять полностью/отправить полностью. Чем выше скорость отправки/приема тем меньше на это будет расходоваться времени. Это только в том случае, если прием и обработка сообщения выполняются монопольно, полностью занимая контроллер. Я же всегда использую многозадачность, и в моем случае это совершенно не влияет. В процессе приема пакета параллельно выполняются и другие задачи. Само же обнаружение и пересылка очередного байта с приемника в буфер сообщения - всего лишь несколько команд. И неважно время приема пакета в целом, суммарное потраченное программой время на него почти не зависит от скорости канала. При общении с механикой 1 мс ничего толком не решает. Но при обмене инфой по эфиру 1 мс имеет большое значение. Это сильно снижает пропускную способность канала. Если такие задержки накопятся, то робот станет не мгновенно реагировать на приходящие команды. У меня скорость радиоканала 1200 бод. Длина пакета команды 8 байт. Перед пакетом после включения несущей передатчика даю паузу 100мс для стабилизации АРУ приемника. Также даю небольшую задержку перед выключением несущей после конца пакета. Итого полное врмя передачи команды получается порядка 180 мс. +-1мс никакой роли не играет. Куда мне спешить? А команды передаются достаточно высокого уровня, и не критичны по времени. В реальном времени работают модули самого робота, и достаточно автономно. Зачем мне высокая пропускная способность, для передачи 8 байт раз в несколько секунд, а то и минут? Для видео у меня отдельный радиоканал в телекамере. При желании я могу подмешивать часть информации и в видеосигнал, если будет такая необходимость. Как в отдельные строки, так и по каналу звука. Есть датчики на которых прохлопать событие очень легко. Такие датчики у меня обрабатываются не через канал, а непосредственно контроллером. Иногда выделенным (как например 12 датчиков бампера). Также это важно при работе с трансиверами. Это может привести к потере нескольких кб/с. Ну, у меня - в радиоканале 1200бод, пакет 8 байт. Не более 5 пакетов-сообщений в секунду. Куда мне cпешить - то? Будет более приличный трансивер - так у него будет большой встроенный буфер. Нет проблем...

@o9d 0 / 0 / 0 Регистрация: 10.08.2010 Сообщений: 1,264
	24.02.2011, 21:10	19
	Это только в том случае, если прием и обработка сообщения выполняются монопольно, полностью занимая контроллер. Я же всегда использую многозадачность, и в моем случае это совершенно не влияет. В процессе приема пакета параллельно выполняются и другие задачи. Само же обнаружение и пересылка очередного байта с приемника в буфер сообщения - всего лишь несколько команд. И неважно время приема пакета в целом, суммарное потраченное программой время на него почти не зависит от скорости канала. А каким это образом прерывания мешают работе других задач? Суммарное потраченное программой время при меньшей скорости увеличивается. Перед тем как отправить очередной байт, нужно дождаться завершения отправки. В вашем коде прерывания UART не используется. А значит контроллер простаивает. Также будут и простаивать и другие задачи. В других контролерах произойдет такая же проблема. В сумме выйдет приличная задержка. У меня скорость радиоканала 1200 бод. Длина пакета команды 8 байт. Перед пакетом после включения несущей передатчика даю паузу 100мс для стабилизации АРУ приемника. Также даю небольшую задержку перед выключением несущей после конца пакета. Итого полное врмя передачи команды получается порядка 180 мс. +-1мс никакой роли не играет. Куда мне спешить? А команды передаются достаточно высокого уровня, и не критичны по времени. В реальном времени работают модули самого робота, и достаточно автономно. Зачем мне высокая пропускная способность, для передачи 8 байт раз в несколько секунд, а то и минут? Для видео у меня отдельный радиоканал в телекамере. При желании я могу подмешивать часть информации и в видеосигнал, если будет такая необходимость. Как в отдельные строки, так и по каналу звука. Подобное имеет смысл при небольших объемах информации.У меня совершенно противоположная ситуация. По радиоканалу передается еще и видеопоток. Трансиверы кода принимают пакет переходят в режим простоя. Даже если сообщение будет короткое. Как обстоят дела с UART удлинителями не знаю. 0

SWK
	24.02.2011, 21:40	20
	Сообщение от o9d А каким это образом прерывания мешают работе других задач? Я этого не говорил. Суммарное потраченное программой время при меньшей скорости увеличивается. Перед тем как отправить очередной байт, нужно дождаться завершения отправки. В вашем коде прерывания UART не используется. А значит контроллер простаивает. Также будут и простаивать и другие задачи. В других контролерах произойдет такая же проблема. В сумме выйдет приличная задержка. А чего ради у меня контроллер простаивает? Главный цикл крутится постоянно, просматривая состояния задач по флажкам, и выполняя нужные действия. Ни одна задача монопольно не выполняется, все по кусочкам. Глянул флаг наличия байта на приеме, есть - скинул его в буфер сообщения, инкрементировал счетчик байт, побежал дальше. В другом месте принятый байт проверяется по некоторым критериям, и выставляются флаги начала или конца команды. Если команда принята полностью, декодер команды ее проанализирует, сделает нужные действия, выставит флажки для других задач. Все непрерывно крутится и выполняется. Процессор никогда не простаивает и ничего не ждет. Эленентарщина... Уже четверть века программы своих контроллеров по такому принципу строю. Все успевают. Сейчас главный цикл ходового крутится с периодом около 250 мкс, обрабатывая все свои задачи. И бамперы, и энкодеры, и движки, и контроль батареи, и одометры, и многое другое. Подобное имеет смысл при небольших объемах информации.У меня совершенно противоположная ситуация. По радиоканалу передается еще и видеопоток. Ну, я не валю все яйца в одну корзину... Радиоканал (315МГц) у меня для команд и телеметрии. Видео, - причем несжатое, телевизионное, - на ~1125 МГц, само по себе. Друг другу не мешают, разнос частот почти четырехкратный. Видео идет непрерывно (если включено контроллером башни), передатчик командного канала работает кратковременно. В основном идет контроль приема. Межконтроллерный обмен у меня с радиоканалом не связан. Сейчас радиоканал - в ходовом контроллере, потом уйдет в центральный, когда тот будет готов. В центральном будет Мега 128 с 2 USORT, один - на радиоканал, второй возможно буду использовать для межконтроллерного обмена. Или SPI. Пока не определился, закладываю и то и то. Ходовой с бамперами сейчас общается по SPI. Башню пока отлаживаю в автономе, через ее USORT, и СОМ порт компьютера. Наверное с ходовым башню пока связывать не буду, заведу их сразу в центральный.