согласен, ошибка . На самом деле ограничения немного другие:

RS232 / RS485 ADU = 253 bytes + Server address (1 byte) + CRC (2 bytes) = 256 bytes.
TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.

http://www.modbus.org/docs/Modbus_Applicat...tocol_V1_1b.pdf на странице 5

По сравнению с самой идеей - это так, пыль для моряка. Вообщем, это не вопрос.


Я надеюсь, обойдемся одним. В крайнем случае перейдем на лпц2103, не много проиграем


И изобретать свой протокол для передачи пакетов кэн через эзернет? Нет чтото у меня желания.

Напишите, посмотрим.

Один полубайт за 8 тактов

На XMega, разве что.

Это не я. Это IAR психанул. Делался этот код из листинга сишного варианта процедуры, вот и осталось.


В понедельник. Сейчас ниасилю с мобильника.

В ZH всегда старший байт адреса таблицы переходов. Эта таблица состоит из 256 rjmp и начинается с адреса кратного 256. ZL, R19, R18, R17 - CRC аккумулятор. R16 - принятый байт CRC которого надо подсчитать.

Объём всего этого 9*256 слов = 2304 слова. Так что таблицу из 256 rjmp придётся посредине размещать. Чтоб rjmp доставал.
А текст всего этого я ессно не вручную писал, а програмку составил. Она .asm и формировала.
У меня там даже 12 тактов на байт получалось. Т.к. я следующий байт сразу-же после вычисления CRC читал. Без rjmp назад. 256 копий кода получилось. Зато 1мегабайт в секунду успевал принять и CRC32 на лету посчитать при 20 мГц тактовой!
К сожалению у АВР команды eori с непосредственными данными нет. Если бы была - на 3 такта быстрее и на 3*256 слова короче получилось бы. Хотя м.б. можно eor на subi/sbci заменить. Но для этого теорию CRC посмотреть нужно.

А насчёт CAN - я имел в виду, что через эзернет только данные передаваться будут. А CAN протоколом пусть АВР занимается. Хотя тут вот какой вопрос - можно-ли сделать так, чтобы иногда передача через эзернет по инициативе нашего устройства начиналась? Или обязательно его опрашивать всё время надо?

Это точно.



По efind'у - не очень хорошо. Но, учитывая, что я сейчас работаю с ATmega324 - при желании можно.

А для меня, было бы интересно COM порт виртуальный реализовать. Тогда, в одну сторону MODBUS не проблема. Нельзя же всё на Rst7 валить. Ну а туннель, не всем нужен.

Пока не вникал, работает ли Ваше ЦРЦ в целом, но
сразу встречное предложение:



Бухгалтерия: продули 5 тактов и два регистра, выиграли 256 байт.
Ессно, без претензий на абсолютную правоту.

Можно и так конечно, но 5 тактов это 35% снижения скорости. А 256-3=253 слова (а не байт) экономии это только 12.5%. И ещё при таком способе экстремально быстро CRC посчитать не получится (это я не про 5 тактов). Я после каждого расчёта CRC rjmp не делал, а с приёмом синхронизировался, следующий байт данных читал, в буфер сохранял, ксорил и ijmp там-же делал (на это от 7 тактов уходило - если данные ждать не приходилось). И на расчёт CRC32 12 тактов уходило. Итого 19 тактов, что меньше 20. Т.е. как я уже писал - удавалось в поток данных 1 мБайт в секунду вклиниваться и в реальном режиме его контролировать.

А я CRC32 в том примере считал вводя данные в старший байт CRC аккумулятора. Мне это как-то ближе. Хотя исторически все почему то в младший байт вводят. Ну и производящие многочлены в этих случаях побитно переставлены - EDB88320 и 04C11DB7.

У меня тоже предложение, как FLASH сэкономить. В табличном вычислителе ничего не вычислять. А только регистры загружать. Тогда мы в 3 такта проиграем, а в коде 3*256=768 слов выиграем. А в регистрах проиграем т.к. ещё 3 регистра по сравнению с первоначальным вариантом задействовать придётся. Но итог всё равно лучше чем у вас получится - т.к. в тактах проигрыш 3 такта а регистрах всё как и вас (у вас тоже 3 регистра добавилось R0, R1 и регистр =08).

Итог:
1. По сравнению с моим первоначальным вариантом - проигрыш 3 такта =21% быстродействия, 3 регистра, выигрыш на 33% FLASH меньше -1536 вместо 2304 слов в таблицах (+ то, что rjmp везде доставать будет).
2. По сравнению с вашим вариантом - проигрыша ни в чем нет, выигрыш по быстродействию 2 такта =12%, выигрыш по FLASH 20% 1536 вместо 2048 слов в таблицах (+ то, что размещать можно не в начале/конце FLASH).
Если кому интересно - могу и с "классическим" вариантом сравнить (где команды lpm используются).

А у меня - такие чайниковские вопросы по теме:
1. Какое преимущество даст подсчет CRC32 на лету.
2. Какое преимущество увеличение ОЗУ (что такое "дропает").
3. Не будет ли проблем с мак-адресом. В смысле не придётся ли за него кому-нибудь платить.

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



to drop - бросить. Среди людей, работающих с ЛВС означает отбрасывание пакета по какой либо причине - не наш, не содержит ожидаемых данных, не смогли обработать из-за отсутствия ресурсов и т.д.



По науке - надо заплатить. Но, я думаю, что если пользоваться Atmel'овским ID - конфликтов Вы не встретите

Логично.

А чего там сравнивать - классика медленнее.

Что-то было про "заменить eor на subi" - не получится.

А если нибблами считать? Там извратиться никак нельзя?

ИМХО, если на лету не считать, то проц будет колом вставать часто. А у нас же еще RS-485 есть. Ему тоже жить хочется.

Уровень УАРТ - через прерывания и буфер приема/передачи. Это понятно.
Забирает памяти 256 байт, выровненных + 1 регистр-указатель навсегда отобрали.

Когда мне FLASH для таблицы из 256*32х битных слов не хватало я CRC нибблами считал т.к. всего 16*32х битных слов надо. Быстрее чем побитно получалось, но и только.

Ну рассчёт CRC работе RS485 мешать не будет. Прерывания-то во время рассчёта ничо не мешает разрешить. А вот наоборот, во время работы с RS485 (и передача и приём) с эзернетом работать не получится (ни принимать ни передавать). Т.к. прерывания от USART это минимум 12..13 тактов если в нём даже никакие ошибки не проверять. Хотя конечно можно извратится до невозможности и во время приёма/передачи по эзернет с USART по готовностям работать. Придётся приём/передачу 1 байта по USART по нескольким приёмам/передачам по эзернет раскидать. Даже и с двумя USART одновременно таким образом работать получится. Занимался я такими извращениями, но размер потребной FLASH при этом увеличивается многократно. И время кодирования/отладки соответственно т.к. кол-во вариантов приёма/передачи и переходов между ними большое получается + переходы от передачи по USART к ожиданию ответа и приёму самого ответа. Это примерно как для ПЛИС вручную программу писать.

Чтобы и во время работы с эзернет USART работать продолжал - ему 256 байт ОЗУ на передачу и 256 байт на приём надо. И это на каждый USART. Так что без внешнего ОЗУ видимо не обойдёшся. А ещё видимо придётся 16ти разрядные таймеры считающие с частотой процессора под это дело задействовать.

Я имею ввиду, что у нас обмен с RTL8201 идет нибблами.



Дык это в общем случае. А здесь RS485, т.е. полудуплекс.
Поэтому именно 256 байт.

По поводу прерывания приема символа из RS485 берем шаблон из ГЦЦ ISR(xxx,ISR_NOBLOCK){} и все.

Т.е. вы предлагаете принимать в тотже буфер из которого только что передали запрос? Но в этом случае если в ответе например CRC не совпадёт, мы повторить запрос не сможем т.к. этим неверным ответом буфер затрём.

А тут я не понял. Как на асме-то приём выглядеть будет. И передача тоже. Её ведь тоже по прерыванию придётся делать. Или вы предполагаете так поступить: пока с RS485 работать не закончили - с эзернетом не работаем. Ну и наоборот. Но что-то мне такой способ не нравится. И так-уж RS485/модбас сильно тормозной. Ну и то, что в этом случае мы токо мастером сможем быть. А слейвом никак.

Дык там не надо повторять. Просто молчание ягнят. Ошибка обнаруживается по таймауту.
С другой стороны, их надо регистрировать в диагностических целях, чтобы наш конвертор не превращал систему в общество слепо-глухонемых. Это возможно только в случае реализации набора счетчиков и некоторого сервиса уровня аппликухи. Подробно на modbus.org. Курим мануалы



Экий Вы непонятливый...

Передача аналогично.
В первом приближении обработку ошибок не включаем. Пока не прижмет
Обработка пакета и его формирование в самом низком приоритете.
Паузы в 3.5 символов, таймауты и т.д. по единому системному таймеру на базе Т1.
В такой постановке вопроса чем более тормозной модбас, тем спокойнее душа программера

Вот так делать нельзя, флаг UDRE снимается после чтения UDR, поэтому, разрешение прерывания в самом начале приведет к попе.

Но это не вопрос, там все в принципе решается. Щас занялся этим, как раз несколько огрехов поймал (неправильно стрипается VLAN-тег, перенес его отбрасывание прямо в прием пакета; где-то между ревизиями случайно грохнул отбрасывание пакета длинной меньше 64 байт и т.д.)

Вы мне вот что скажите, сколько времени ожидать пакет от slave'а после передачи ему запроса?

MODBUS over serial line specification and implementation guide V1.02 p.19

Практически >= 1 секунды.
Если посмотреть на те же преобразователи частоты - от 100мс до 10 секунд.


Спасибо за уточнение. Я понял, что Вы про RXC в первую очередь.


Это уже плохо. Медленно.
Может, альтернативы есть?
Насчет UDRE - еще хуже. Думать надо

З.Ы. Придумал как правильно передавать
У нас AuxReg уже украден.

Тогда первым действием отправляем в UDR
Потом sei
потом ужЕ адресуем след. байт и он хранится в AuxReg до прерывания.
Все ОК, тем более, что первый байт совершенно не сложно отправить в основном процессе

Да, безусловно. Описался.




А не дофига ли? Это же если пару-тройку девайсов отпали, то на круг будет добавка по пол-минуты...



Да там единственная альтернатива - опрос не по прерываниям, причем в отдельном цикле и внутри приема/передачи пакета из/в эзернет. Иначе - никак, ведь пакет длинной 254 байта из эзернета (а на самом деле 254+8(преамбула макс.)+4(возможный тег VLAN)) = 212мкс да плюс еще выход из прерывания - больше 2х байт на скорости 115200 - значит может пропускать байты.

Короче, код там хитрый получается, но получается. Думаю, до конца недели по вечерам асилю.

Кстати, вопрос про тестовые терминальные програмки еще открыт.

Ну, я ступил - написал только про медленные устройства.
Вообще, устройства с таймаутами одного порядка группируются в один сегмент. Множественные запросы ведь не допускаются...
Я в PLC пока не копенгаген, мож кто напишет.

+1
Но код там не просто хитрый, а очень хитрый получается. Т.к. из 2*8 тактов между приёмом нибблов по моим прикидкам удастся высвободить только 5 тактов подряд на приём/передачу по USART. А в этих 5 тактах 3..4 такта на опрос готовности потратить придётся (это самый распостранённый случай). А уж само чтение/передачу по USART при приёме следующего байта из эзернет делать - другой вариант приёма из эзернет. И таких вариантов по моим прикидкам штук 20 или даже больше набирается. С приёмом/передачей 1 байта из USART в 5 тактов ведь не уложишся, а ещё переходить от передачи к приёму по USART при приёме из эзернет придётся - драйвер RS485 на приём переключать. При передаче в эзернет - чуть проще конечно. Там кол-во свободных тактов подряд побольше получается. Из-за этого число вариантов передачи в эзернет поменьше будет. Как и число переходов от варианта к варианту.

Если вы до конца недели всё это асилите - снимаю шляпу.

И ещё - в приеме/передаче USART прерывание разрешать нельзя. Т.к. если это прерывание прерывание от эзернет прервёт, а в нём мы с USART работать будем, то страшная каша получается. Придётся в прерывании от USART соответственно готовности от эзернет смотреть.

Или я может чего не понимаю? Может во время работы с эзернет мы на RS485 забьём (и наоборот). Тогда таких проблем конечно не будет - в таком случае всё элементарно.

Мне кажется в проетке ATmega164 оптимальнее чем ATmega168 использовать т.к. там 2 USART. И ног больше - ОЗУ подключить легче.
А ещё хотел ссылочку попросить. Где про эзернетовские пакеты+преамбулы+теги наиболее понятно и жел-но по русски написано.

Я пользуюсь вот этим http://book.itep.ru/1/intro1.htm

Особенно добавляет пессимизма то , что UART находится черт знает где по адресам.

Кстати, про передачу - надо обеспечивать, чтобы пауза между посылками было меньше 3.5 символа.

При приеме езера и RS485 одновременно поллинг UART можно сделать 2-3 раза. Етого хватит.
В общем, решаемо.

В АСУТП есть:
- коммутационный процессор -КП (это мост между различными интерфейсами и изером)
- выносные контроллеры (связаны с КП по RS485 - в разных вариантах) - типовой цикл опроса до 1с и меньше
- невыносные контроллеры (связаны с КП по интерфесу MPI - типа SPI) - типовой цикл опроса 5-20 мс.
Все локальное управление выполняется местными контроллерами.
На верхнем уровне данные архивируются, визуализируются, сигнализируются и т.д. Управления задвижками, реле, двигателями, управления циклограммами - это не функция верхнего уровня. Если есть управление - то на уровне более глобальном. Например, параллельно работают 4 насоса, потребление снизилось ночью, с верхнего уровня может прийти команда локальному контроллеру - 2 насоса отключить.
PS. Мне видится в качестве КП - LPC2106.

Ну это не проблема - 1 такт добавляется.

Не 3.5, а 0.5 символа. А некоторые требуют вообще 1 бит. Иначе запрос игнорируют.

Решаемо, но надо помнить, что любой байт из эзернета может последним в пакете оказаться. В этом случае и кол-во вариантов завершения приёма из эзернета соответственно возрастает.
Поэтому я про ATmega164 думаю. Если FLASH не хватит - можно 324 поставить. По ножкам совпадает. И ОЗУ без фиксатора адреса подключается - ног хватает. И USART 2 шт. И стоит стоко-же если не дешевле почему-то.

А мне кажется, что наилучшим тестером для этого устройства будет ещё одно такое-же устройство. Таким образом мы и приём и передачу одновременно оттестим. Хотя посложней конечно сделать будет. А может я и ерунду конечно написал т.к. в эзернете профан.

А у меня такой вопрос - сколько тактов у нас есть с момента появления прерывания от эзернета до того, как мы первый нибблл данных прочесть ОБЯЗАНЫ? Если это 8 тактов - не вложимся. Т.к. из-за асинхронности 1 такт добавляется, потом 4 такта команды которую прерываем (макс), 4 такта переход на саму таблицу прерываний и в самой-же таблице чтение с данных с порта 1 такт. Итого 10 тактов получается.
Или у нас 15 тактов есть? Или больше из-за преамбул и т.п.?

А тут у меня такой вопрос - если нам на запрос по модбас (мы мастер) не ответили или ответ с ошибкой CRC пришёл - надо-ли запрос повторять? И если надо, то скоко раз?

Не, не годится. Во первых - я сейчас делаю гейт Modbus TCP <-> Modbus serial, значит для RS485 устройство будет мастером. Во вторых - надо именно с чужим проверять, а то можно потом обнаружить, что со своим пашет, а с чужим - нет.



Ну вот у RTL8201BL задержка от появления сигналов до выставления CRS 600нс макс, и до RXDV 3200нс (хотя это уже не суть важно). А до последнего ниббла преамбулы (его надо точно прочитать, чтобы быть уверенным в начале пакета) 7.5*800=6000нс. Значит, от установки CRS у нас есть время в 120 тактов до чтения байта, но еще надо сохранить все регистры и засинхронизироваться с RXCLK - это еще накладных расходов на 50 тактов примерно.

Да я-то имел в виду - специальную тестовую програмку для генерации всяких хитрых пакетов туда прописать. Таких пакетов, которые другим путём получить проблематично. Например с повреждённым CRC и т.п.

Ну при таком раскладе я полон оптимизма. Т.к. в других частях программы никаких особых извращений не надо делать будет. Если что-то не относящееся к собственно эзернет нужно сделать - подключусь. Да хоть ту-же генерацию глючных пакетов под управлением от RS485 в режиме слейва - если вообще это нужно конечно.

ЧИТАЕМ ВНИМАТЕЛЬНО. (Это относится и ко мне )
Modbus_over_serial_line_V1_02.pdf, p13


Итого мы оба неправы.
< 1.5 символа

Зависит от требований.
Modbus обеспечивает только правильность принятой информации, а достоверность прихода не гарантирована. Это уже вопрос второй, надпротокола.
Например, IP обеспесчивает правильность принятой информации, а уже TCP - гарантирует приход (а для примера, UDP - не гарантирует).

Не гарантирует, т.к. нет подсчета контрольной суммы данных, только заголовка. Хотя если через Ethernet - то гарантия есть.

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

IP - интернет прококол. Содержит IP адреса получателя, отправителя, инфо и КС. На принимающей стороне пакеты с неверной КС просто отбрасываются.
TCP - протокол передачи. Делает разбиение (и сбор принятых) данных по небольшим пакетам (они могут идти по разным маршрутам) и организует диалог для контроля принятых пакетов.

Контрольная сумма там только заголовка

Тут ничего не поделаешь. Тише едешь ... Закон жизни.
Тем не менее, связка TCP/IP в данный момент основная.

Для автора темы.
Варианты конвертора Ethernet-RS485 выпускает www.moxa.com
Цены у наших продавцов от 20 до 30 евро.
Варианты http://www.moxa.com/product/Serial_to_Ethernet_Products.htm.
Мы ипользовали NPort 6110. Сейчас объект под пуско-наладкой.
Документацию и утилиты конфигурации и тестирования можно у них найти на сайте через поиск.
Это вариант организации мастера на уровне OPC-драйвера или мастер отделен по сети TCP/IP.

Насчет 20-30 евро ничего не попутали? может быть 120-130?

Нам NPort5150 обошёлся с доставкой в 4000р.
Не может быть, чтобы такая разница в ценах.

20-30 это скорее похоже на RS-232 <-> RS-485

Попробуйте efind.ru и посмотрите текущие цены. Вообще-то они уже сняты с производства, наши тоже покупали под объект штук 50-70 по хорошим ценам, но все течет и изменяется.
PS. А вообще-то они нам не очень понравились. По изеру все пингуется без проблем (хотя длины типа 800 м-1200м, до 3000 м, правда по волокну), а модбасом танцы с бубном (хоть и 10-20м).

Мне наоборот оччень понравилось. Даже сам чё-то подобное хочу сделать (по мотивам данной темы)
А с модбасом понятно почему проблемы.
Не любит он тайм-ауты. А в езернете тайм-ауты не нормируются и могут достигать нескольких миллисекунд (а то и больше).
Правда, в NPort по-моему, есть настройки пакетов, то есть фикс. длина, отправлять каждый байт, автомат и т.д.
То есть смысл в том, что пакет модбаса (RTU) надо отправлять одним пакетом езернета, без разрывов.
Либо использовать аски, там таймауты до 1 с.

У нас такой случай был с модулями RealLab от конторы НИЛ АП (RLDA).
Из-за таких случайных задержек на NPort 2 модуля друг за другом ушли в какое-то 4-е измерение и перестали отвечать на внешние раздражители.
Потом оказалось, что они вошли в какой-то недокументированный режим калибровки и самостоятельно вернуться уже не смогли.

На объекте типа "Таможенный склад" стоит порядка 10 КРУ. На каждом КРУ стоят Sepam от 4 до 6 штук и еще Deif овские счетчики. На верху сервер данных с оркестром и АРМ InTouch.
Штуки 4 КРУ уже запустили. А с другими пляски продолжаются.
Подумалось. Может, мы говорим об одном и том же объекте в Питере ?


Как раз вчера, я консультировал ребят и рассказывал им как настроить таймауты NPort. Завтра уже будут результаты. Может придется ехать с осциллом смотреть сигналы.
Очень опасное место, там кранами на большой скорости перетаскивают грузы. Надо смотреть в оба. Задавят легко.

Хоть убейте, ну $165 минимум (специальный сентябрьский лохотрон от Вектора ) нашел за этот NPort. Что-то Вы попутали, да и вообще, любой АСУшный чих (любой модуль, я имею в виду) стоит от 100 евро.

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

Не помню сайт, откуда скачивал



Еще бы посоветовал, для отладки со стороны сети CommView. Положил на местный ftp в upload

Может, я что-то попутал. Я закупками не занимаюсь, а в голове как-то отложилось ...
PS. Впрочем, для Вас такие цены очень даже хорошо.
А утилиты и документацию NPorta скачайте, будете знать, что надо делать.

О да, без этого - как без рук. Давно пользуюсь с удовольствием.

К сожалению, это все не совсем то, что я просил. Я просил рабочий эмулятор модбас-устройства с последовательным портом. И терминал для MODBUS-TCP, который умеет создавать и посылать именно пакеты модбас. Я, конечно, могу скрипты понаписывать, но не хотелось бы ошибиться.

В NModbus был эмулятор слейва

Лучше взять реальное устсройство, например Deif или счетчик СЭТ-4ТМ или что-то (от родоначальника Modicon). Для Sepam 1000+ серии 40 Merlin Gerin пакеты расписаны с CRC.
На все есть хорошие pdf.
Не ошибетесь.

А можно мордой лица ткнуть? Ссылку в смысле...

www.nmodbus.com

Нажмите для просмотра прикрепленного файла

Под Win невозможно слейв сделать (или какой-то страшный драйвер придётся писать). Дело в непредсказуемых задержках. А тут задержки в доли милисекунды нужны. Даже переключать приём-передачу в RS485 и то проблема. Я эту проблему в Win обходил использованием драйвера CAN (вместо драйвера RS485). Драйвер CAN только 0 передаёт, а 1 за счёт резисторов устанавливается. Уровни-то у CAN и RS485 не сильно отличаются - на короткой линии всё работает. Т.е. передатчик 1 выставил и приём - это одно и тоже. Т.е переключать приём и передачу вообще не нужно. Конечно самопереданные байты приходится принимать, а потом отбрасывать. Но вобщем мастера реализовать можно, а вот со слейвом проблема. Быстро ответить не получится - время не гарантируется. Кстати с переключением между передачей и приёмом RS485 у контроллера тоже проблемка есть. После передачи последнего байта запроса мастером надо СРАЗУ-ЖЕ на приём переключаться. Иначе, если слейв СРАЗУ-ЖЕ отвечать начнёт, в сети RS485 2 устройства одновременно передавать будут. Причём одно 1 (стоп-бит и паузу после него), а другое 0 (стартовый бит). Я эту проблему управлением приёмом-передачей с помощью таймера решаю. Когда последний байт в передачу пишу - таймер в соответствии со скоростью/форматом запускаю. И он (таймер) своим выходом автоматом с передачи на приём RS485 драйвер переключает.
Кстати рекомендую Rst7 платку с учётом этого разводить.

Зачем-то существуют обозначенные паузы, являющиеся маркерами фрейма RTU

Может ModbusPoll_4.3.1 подойдёт?

И устройства существуют, творцы коих про существование этого не знают.
Вообще с паузами в модбасе полный бардак. Я встречался как с такими устройствами, которые при скорости 115200 в режиме слейва через 16 милисекунд отвечает. И с такими которые через 50 микросекунд отвечает. Но заявлять "это устройство нестандартное - поэтому мы с ним работать не будем" глупо. Ты работать не будешь - купят у того кто будет.
А вобще про модбас я в этой теме уже своё мнение высказывал: убогий протокол. Поэтому в своих разработках на CAN перехожу.