3 ATMega8 к 1 COM-порту ПК Опции

[li4]

Подскажите пожалуйста как решить такую задачу. Есть 3 ATMega8 каждый из которых используется как 3-х канальный АЦП. Мне нужно их все подключить к одному COM-порту компьютера, причем нужно чтобы передача данных происходила без потерь. Ведь пока 1 контроллер передает данные в ПК, остальные тоже работают, а данные передавать не могут, потому что линия занята.

[otrog]

Ссылка на WAKE
http://www.spetspribor.com/support/software/wake/wake.html
к сожалению не работает , поэтому выложил сохраненную страницу со всеми файлами на ФТП
/upload/DOCs/WAKE.rar

байт-стаффинг конечно не очень хорошо, но жесткая времянка еще хуже(ИМХО).
А то что MODBUS закрытый может я и ошибся, но всякие там оговорки типа:

After 30 days, the ActiveX Controls stop communicating and return a result indicating that trial has expired

мне не нравятся.

ПС
2 prottoss На Вашем сайте исходников MODBUS нет, значит это закрытый протокол .

[prottoss]

2 prottoss На Вашем сайте исходников MODBUS нет, значит это закрытый протокол .

Мдя, после того, что я тут выложил, и Ваших слов некоторые точно подумают, что MODBUS придумал я , хм....я уже подумываю о новой версии - PROTTOSSBUS, а че? звучит ...

Зато на моем сайте есть достаточное количество информации, что бы разобраться в протоколе и начать продуктивно работать в этом направлении. Что касается исходников - я уже говорил выше - есть на http://modbus.org совершенно БЕЗВОЗМЕЗДНЫЕ готовые исходники (под PIC, но переделывается влет за неделю) и для клиента и для сервера. Все на Сях. Может быть выложу и свои - надо их причесать немного...

[SasaVitebsk]

2 prottoss На Вашем сайте исходников MODBUS нет, значит это закрытый протокол .

Мдя, после того, что я тут выложил, и Ваших слов некоторые точно подумают, что MODBUS придумал я , хм....я уже подумываю о новой версии - PROTTOSSBUS, а че? звучит ...

Зато на моем сайте есть достаточное количество информации, что бы разобраться в протоколе и начать продуктивно работать в этом направлении. Что касается исходников - я уже говорил выше - есть на http://modbus.org совершенно БЕЗВОЗМЕЗДНЫЕ готовые исходники (под PIC, но переделывается влет за неделю) и для клиента и для сервера. Все на Сях. Может быть выложу и свои - надо их причесать немного...

Это замечательно, может кому то понадобитсся именно полный MODBUS. Я, правда достаточно давно, реализовывал его на ASM51. В принципе с точки зрения микроконтроллера ничего сложного нет. Но для меня немного нафталином попахивает.

А вот с точки зрения PC, всё не так просто. Например задача - контроллировать задержку в 1.5 символа (пишу по памяти) на высоких скоростях (а RS485 поддерживает до 2Мбит) представляется сомнительной. Я столкнулся с тем что у меня PC самопроизвольно рвала пакеты. Иногда вставляя незначительные промежутки, но и скорость у меня не рекордная! А что будет на большой? Кроме того незнание момента окончания передачи для PC, а расчёт его, - тоже вызывает ощущение - не очень.

Всё идейно важное, - на мой взгляд из первого уровня (как я бы сказал) из MODBUS взял тот же WAKE. А для меня красивым протоколом на втором уровне является X-modem. Я исследовал для себя. Он даёт самую высокую скорость при ошибках в линии. Очень идея красивая. Правда я делал адаптивные размеры пакетов и анализировал статистику.

Интересно было бы повозится с LIN и с CAN. Чтобы самому составить своё собственное мнение.

А вообще интересно наблюдать, что все более-менее современные протоколы в конечном итоге приближаются к сетевым.

[defunct]

Например задача - контроллировать задержку в 1.5 символа (пишу по памяти) на высоких скоростях (а RS485 поддерживает до 2Мбит) представляется сомнительной. Я столкнулся с тем что у меня PC самопроизвольно рвала пакеты. Иногда вставляя незначительные промежутки, но и скорость у меня не рекордная! А что будет на большой? Кроме того незнание момента окончания передачи для PC, а расчёт его, - тоже вызывает ощущение - не очень.

Разве идея MODBUS это не master-slave (запрос-ответ)?
Насколько помню там тупо до ужаса.
Посылаешь пакет, ставишь тайм-аут (отфонарный) ~100ms, если в ответ что-то пришло - хорошо, считаешь CRC, 0 - отлично, проверяешь код функции, совпал - значит ответ на наш запрос, ну а дальше парсишь сообщение.
Слейву еще проще. Получил команду - отправил незамедлительно ответ.

Где там задержки в 1.5 символа-то?

фунции modbus драйвера:

Код

void mb_SendPacket(U8 *pData, U8 size)
{
  while (size--)
    uq_PutChar( *pData++ );
}


void mb_PutMessage(PModbusDesc pDesc)
{
    pDesc->CRC = mb_crc16( (U8 *)pDesc, sizeof(*pDesc) - 2 );
    mb_SendPacket( (U8 *)pDesc, sizeof(*pDesc));
}

U8 mb_GetMessage(U8 *pStorage, U8 *retsize, U8 maxsize)
{
  U32  tempclock = Kernel_GetClock() + 100; // 100 ms timeout
  U8   temp;
  *retsize = 0;
  do
  {
     if ( (uq_GetChar(&temp)) && (*retsize < maxsize))
     {
        pStorage[(*retsize)++] = temp;
     }
     Kernel_idle();
   } while (Kernel_GetClock() < tempclock);
  
   return ((*retsize) == 0) ?  FAILED : SUCCESS;
}

[singlskv]

Слейву еще проще. Получил команду - отправил незамедлительно ответ.

Не, незамедлительно нельзя!
по стандарту нужно выдержать интервал не менее 4 длительностей байта

Посылаешь пакет, ставишь тайм-аут (отфонарный) ~100ms, если в ответ что-то пришло - хорошо

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

Где там задержки в 1.5 символа-то?

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

Когда мастер PC под Win то существует проблема обрезания длинных пакетов:

Например задача - контроллировать задержку в 1.5 символа (пишу по памяти) на высоких скоростях (а RS485 поддерживает до 2Мбит) представляется сомнительной. Я столкнулся с тем что у меня PC самопроизвольно рвала пакеты. Иногда вставляя незначительные промежутки, но и скорость у меня не рекордная! А что будет на большой? Кроме того незнание момента окончания передачи для PC, а расчёт его, - тоже вызывает ощущение - не очень.

Кстати SasaVitebsk какая у Вас скорость ?
Удалось ли победить обрезание пакетов ?

[defunct]

Не, незамедлительно нельзя!
по стандарту нужно выдержать интервал не менее 4 длительностей байта

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

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

Однако это позволит запросто избавиться вот от этого:

Когда мастер PC под Win то существует проблема обрезания длинных пакетов

По стандарту нужно чтобы каждый принимаемый байт попадал в фрейм
длительностью 1,5 байта на данной скорости.

опять-таки, эта часть стандарта объясняется только кривизной мастера, и надумана только для ASCII режима. В RTU посылки-то с нормальным кодом защиты, т.о. нам не страшны любые искажения и смещения потока.

[SasaVitebsk]

Я думаю всё это обосновано следующим. Должно быть описано КАЖДОЕ состояние. И это, в принципе, правильно. Я начал передавать фрейм. Передал - заголовок. Слэйв принял. Но ждать он может ограниченное время - иначе клинч.

Давайте посчитаем какой должен быть разрыв м/у байтами. Фактически разрыв м/у байтами должен быть меньше, чем для слэйва принятие решения о завершении пакета. Так какой он должен быть? Ну возьмём фиксированный - к примеру 5мс. Нельзя. Для скорости 1200 бод (а нижняя по стандарту думаю вообще 300) байт - 8.3мс. Таким образом для данной скорости 5мс - мало. Поэтому таймаут привязан к скорости. Возьмём 10 байт. Учтём, что после завершения пакета (для слэйва) слэйв должен обработать команду и подтвердить её приём или ответить на команду. Таким образом к задержке для мастера надо прибавить ещё задержку на ответ. Таким образом чем больше задержка - тем ниже пропускная способность шины. Это понятно. Таким образом желательно ввести МИНИМАЛЬНУЮ задержку. Но она не может быть меньше одного символа. В этом случае мы просто не будем знать закончилась ли передача. Ну вот Вам и формула должна быть минимальная задержка более одного символа. Выбрано 1.5.


Как раз здесь у меня претензий нет. Претензии по самим командам. С некоторыми я ни соглашусь ни в жизнь.

Должен быть интерфейс. Слейв должен по запросу выдавать свою програмную модель что-ли. А мастер не вправе читать/писать всё подряд. Мастер и слэйв должны быть защищены друг от друга. А здесь протоколы этого не предусматривают.

[otrog]

Слейв должен по запросу выдавать свою програмную модель что-ли.

Давно присматриваюсь к "Пирамиде".
http://upload.caxapa.ru/pyramid/

Целью проектирования является разработка простого метода доступа к внутренним
параметрам приборов. Базовое условие - терминал не обязан знать или предполагать что-
либо о приборе для решения этой задачи. Единственное требование к терминалу –
реализация стандартов доступа, относящихся к системе Пирамида. Вся информация о
параметрах, методах работы с ними, элементах навигации по параметрам должна храниться
исключительно в приборе.

Изумительно выглядела бы связка WAKE(транспортный уровень) + Пирамида(логический уровень).