Когда мне 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 в режиме слейва - если вообще это нужно конечно.