[galjoen 0]

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

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

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

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

Уровень УАРТ - через прерывания и буфер приема/передачи. Это понятно.

Забирает памяти 256 байт, выровненных + 1 регистр-указатель навсегда отобрали.

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

[_Pasha 0]

Быстрее чем побитно получалось, но и только.

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

 

Чтобы и во время работы с эзернет USART работать продолжал - ему 256 байт ОЗУ на передачу и 256 байт на приём надо.

 

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

Поэтому именно 256 байт.

 

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

[galjoen 0]

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

Поэтому именно 256 байт.

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

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

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

[_Pasha 0]

мы повторить запрос не сможем т.к. этим неверным ответом буфер затрём.

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

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

 

А тут я не понял. Как на асме-то приём выглядеть будет.

 

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

 rxc_isr: 
             sei
             push  r0
             in      r0,Sreg
             push  r0
             push  xL
             push  xH
             push  zL
             ldi     xH,high(Modbus_Buffer)
             lds    xL, ModBus_BufPos; не надо нам регистр портить для хранения указателя. Это от лукавого
             lds    zL,UDR0
             st      X+,zL
             sts    ModBus_BufPos,xL
             pop   zL
             pop   xH
             pop   xL
             pop   r0
             out    Sreg,r0
             pop   r0
             reti

Передача аналогично.

В первом приближении обработку ошибок не включаем. Пока не прижмет :)

Обработка пакета и его формирование в самом низком приоритете.

Паузы в 3.5 символов, таймауты и т.д. по единому системному таймеру на базе Т1.

В такой постановке вопроса чем более тормозной модбас, тем спокойнее душа программера :)

[Rst7 5]

rxc_isr:              sei

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

 

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

 

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

[_Pasha 0]

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

The master is configured by the user to wait for a predetermined timeout interval ( Response time-out) before aborting the transaction.

This interval is set to be long enough for any slave to respond normally ( unicast request). If the slave detects a transmission error, the

message will not be acted upon. The slave will not construct a response to the master. Thus the timeout will expire and allow the

master’s program to handle the error. Note that a message addressed to a nonexistent slave device will also cause a timeout.

Практически >= 1 секунды.

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

 

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

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

.def Auxreg=r15; все-таки украли регистр
rxc_isr: 
             lds     AuxReg,Udr0
             push  AuxReg; избавились от дабл-буфера
             sei
             pop   AuxReg
; дальше по тексту
             push  r0
...................................

 

Это уже плохо. Медленно. :crying:

Может, альтернативы есть?

Насчет UDRE - еще хуже. Думать надо

 

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

У нас AuxReg уже украден.

 

Тогда первым действием отправляем в UDR

Потом sei

потом ужЕ адресуем след. байт и он хранится в AuxReg до прерывания.

Все ОК, тем более, что первый байт совершенно не сложно отправить в основном процессе

[Rst7 5]

Я понял, что Вы про RXC в первую очередь.

 

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

 

 

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

 

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

 

Это уже плохо. Медленно. Может, альтернативы есть?

 

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

 

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

 

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

[_Pasha 0]

А не дофига ли?

Ну, я ступил - написал только про медленные устройства.

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

Я в PLC пока не копенгаген, мож кто напишет.

[galjoen 0]

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

 

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

+1

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

 

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

 

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

 

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

 

Мне кажется в проетке ATmega164 оптимальнее чем ATmega168 использовать т.к. там 2 USART. И ног больше - ОЗУ подключить легче.

А ещё хотел ссылочку попросить. Где про эзернетовские пакеты+преамбулы+теги наиболее понятно и жел-но по русски написано.

[prottoss 0]

Где про эзернетовские пакеты+преамбулы+теги наиболее понятно и жел-но по русски написано.

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

[_Pasha 0]

С приёмом/передачей 1 байта из USART в 5 тактов ведь не уложишся

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

 

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

 

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

В общем, решаемо.

[alexander55 0]

Я в PLC пока не копенгаген, мож кто напишет.

В АСУТП есть:

- коммутационный процессор -КП (это мост между различными интерфейсами и изером)

- выносные контроллеры (связаны с КП по RS485 - в разных вариантах) - типовой цикл опроса до 1с и меньше

- невыносные контроллеры (связаны с КП по интерфесу MPI - типа SPI) - типовой цикл опроса 5-20 мс.

Все локальное управление выполняется местными контроллерами.

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

PS. Мне видится в качестве КП - LPC2106.

[galjoen 0]

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

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

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

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

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

В общем, решаемо.

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

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

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

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

 

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

Или у нас 15 тактов есть? Или больше из-за преамбул и т.п.?

В АСУТП есть:

- коммутационный процессор -КП (это мост между различными интерфейсами и изером)

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

[Rst7 5]

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

 

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

 

А у меня такой вопрос - сколько тактов у нас есть с момента появления прерывания от эзернета до того, как мы первый нибблл данных прочесть ОБЯЗАНЫ?

 

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

[galjoen 0]

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

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

Значит, от установки CRS у нас есть время в 120 тактов до чтения байта, но еще надо сохранить все регистры и засинхронизироваться с RXCLK - это еще накладных расходов на 50 тактов примерно.

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