[_Pasha 0]

Хм... думаю, что речь всё же шла об туннелировании Modbus

 

А вот и нет! Изначально,

 

Протокол OPC является посредником, он интерпретирует данные TCP/IP портов в пакетах и разносит их по полям ее.

********************************

PS. Надеюсь, что не запутал Вас.

 

Запутал-таки :)

 

Очевидно, обе реализации, как тоннель, так и виртуальный RTU, имеют востребованность.

 

По поводу TCP есть одна засада:

Modbus_Messaging_Implementation_Guide_V1_0b.pdf

Normally, on MODBUS serial line a client must send one request at a time. This means that the client must wait for the answer to the first request before sending a second request.

On TCP/MODBUS, several requests can be sent without waiting for a confirmation to the same server. The MODBUS/TCP to MODBUS serial line gateway is in charge of ensuring compatibility between these two behaviors.

 

Хочется услышать мнение RST7, как бороться с накоплением пакетов.

[galjoen 0]

А что вы всё в Модбас упёрлись? На мой взгляд это совершенно убогий протокол. Существует только из-за тяжёлого наследия. И тут ещё проблемка: пока мы весь пакет от ведомого не получим - работать с изернет не сможем. А 256 байт на скорости 115200 это более 20 милисекунд. Можно конечно извратится и чтение с USART в том-же цикле, что и чтение из изернет сделать, но это уж совсем большой изврат. Так и придётся для модбас 2й процессор ставить.

На мой взгляд переходник в CAN более перспективен. У CAN-то всё буферизировано. Да и у АВР с CAN - ОЗУ и FLASH поболее, хотя и дороже конечно.

приема - гдето под 4Мбита/с. Т.е. дропать пакеты он сможет именно с такой скоростью :) (и даже быстрее, потому что сначала я проверяю, мой ли пакет, а только потом считаю CRC32, этот расчет выполняется медленнее приема пакета, тут ничего не попишешь)

Могу написать, как CRC32 за 14 тактов на байт считать (за счёт увеличения размера потребной FLASH конечно). А вообще-то с какой скоростью из изернета к нам байты валятся? Может удастся CRC32 на лету считать? Если глупость написал - не пинайте. В изернете я полный ноль. Кстати может подскажете, что про изернет почитать. Это я насчёт переходника изернет2CAN.

 

А ещё я у вас Rst7 заметил странный код на асме:

dec R16

tst R16

Это зачем так сделано? Если задержка нужна - нагляднее nop поставить. Хотя я может там чего не понимаю конечно.

Rst7 - если не трудно изложите идею чтения данных из изернета пожалуйста, так чтобы чайники вроде меня поняли.

[defunct 0]

Хочется услышать мнение RST7, как бороться с накоплением пакетов.

Очевидно, в пределах линейки m48-168 - никак.

Надо больше памяти. M162 и внешнюю память или ARM.

Но тогда вся прелесть устройства (дешевизна) отпадает.

 

Думаю более логичным будет организация тунеля UDP<->modbus serial, а TCP GW реализовать на PC (если вопрос с поддержкой спецификации over TCP действительно актуален) и буфферизацию соответcтвенно делать там же.

e.g.

 

 

1. PC Modbus over TCP

|

2. <intermediate format over UDP >

|

3. Modbus over UDP

|

4. modbus serial

 

Первые два пункта реализовать на PC.

3-й и 4-й - возложить на девайс.

 

Сервер преобразовывающий Modbus over TCP в некий промежуточный формат over UDP с которым и будет работать девайс будет достаточно простой аппликушкой, с автопоиском UDP клиентов, опять же через broadcast.

 

А что вы всё в Модбас упёрлись? На мой взгляд это совершенно убогий протокол.

С чем работаем в то и уперлись.

Абсолютно нормальный протокол. Бывают гораздо хуже.

[_Pasha 0]

А что вы всё в Модбас упёрлись?

Слухи о кончине модбаса сильно преувеличены.

Насчет TCP

Microchip TCP/IP stack

 

P.S. Кто-нить знает, как с доставабельностью Atmega164/324 ?

[Rst7 5]

Хочется услышать мнение RST7, как бороться с накоплением пакетов.

Тут я думаю играми с размером приемного окна мы вопрос решим. Принимается один пакет, размер окна выставляется 0, пакет отправляется в усарт, принимается ответ, отправляется в сокет и размер окна устанавливается опять в исходный. Вся буферизация будет в стеке большого брата.

 

Для упрощения задачи, нет ли у кого программок на комп, одна для имитации какого-нибудь модбас-устройства с последовательным портом, другая - терминал для модбас с сериал-лайн и модбас-тцп, очень мне не хочется такой софт еще писать для тестов.

[7403 0]

Откуда взято ограничение длины?

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

 

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

[Rst7 5]

И тут ещё проблемка: пока мы весь пакет от ведомого не получим - работать с изернет не сможем. А 256 байт на скорости 115200 это более 20 милисекунд. Можно конечно извратится и чтение с USART в том-же цикле, что и чтение из изернет сделать, но это уж совсем большой изврат.

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

 

Так и придётся для модбас 2й процессор ставить.

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

 

На мой взгляд переходник в CAN более перспективен. У CAN-то всё буферизировано. Да и у АВР с CAN - ОЗУ и FLASH поболее, хотя и дороже конечно.

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

Могу написать, как CRC32 за 14 тактов на байт считать (за счёт увеличения размера потребной FLASH конечно).

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

А вообще-то с какой скоростью из изернета к нам байты валятся?

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

Может удастся CRC32 на лету считать?

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

А ещё я у вас Rst7 заметил странный код на асме:

dec R16

tst R16

Это зачем так сделано? Если задержка нужна - нагляднее nop поставить. Хотя я может там чего не понимаю конечно.

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

 

Rst7 - если не трудно изложите идею чтения данных из изернета пожалуйста, так чтобы чайники вроде меня поняли.

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

[galjoen 0]

Могу написать, как CRC32 за 14 тактов на байт считать (за счёт увеличения размера потребной FLASH конечно).

 

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

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

 eor ZL,R16; получили в ZL объединяющую величину [1 такт]
ijmp; переход на таблицу переходов, а оттуда rjmp на наш случай [2+2 такта]

mAF:; сюда попадаем из таблицы переходов по rjmp. Объединяющая величина =AF. Таких кусков кода 256 штук.
ldi ZL,XX1; 1е число табличного вычисления CRC [1такт]
eor ZL,R19; получили новый старший байт обновлённого CRC аккумулятора [1 такт]
ldi R19,XX2; 2е число [1 такт]
eor R19,R18; следующий байт CRC ак-ра [1 такт]
ldi R18,XX3; 3е число [1 такт]
eor R18,R17; следующий байт CRC ак-ра [1 такт]
ldi R17,XX4; это младший байт - его ни с чем ксорить не надо [1 такт]
; итого получили обновлённый CRC32 ак-р, потратив на это 12 тактов. Ещё 2 такта понадобятся чтоб rjmp вернутся назад.

Объём всего этого 9*256 слов = 2304 слова. Так что таблицу из 256 rjmp придётся посредине размещать. Чтоб rjmp доставал.

А текст всего этого я ессно не вручную писал, а програмку составил. Она .asm и формировала.

У меня там даже 12 тактов на байт получалось. Т.к. я следующий байт сразу-же после вычисления CRC читал. Без rjmp назад. 256 копий кода получилось. Зато 1мегабайт в секунду успевал принять и CRC32 на лету посчитать при 20 мГц тактовой!

К сожалению у АВР команды eori с непосредственными данными нет. Если бы была - на 3 такта быстрее и на 3*256 слова короче получилось бы. Хотя м.б. можно eor на subi/sbci заменить. Но для этого теорию CRC посмотреть нужно.

 

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

[AlexG_changed 0]

Слухи о кончине модбаса сильно преувеличены.

 

Это точно.

 

P.S. Кто-нить знает, как с доставабельностью Atmega164/324 ?

 

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

[SapegoAL 0]

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

[_Pasha 0]

В ZH всегда старший байт адреса таблицы переходов. Эта таблица состоит из 256 rjmp и начинается с адреса кратного 256.

Пока не вникал, работает ли Ваше ЦРЦ в целом, но

сразу встречное предложение:

 

; пусть CRC32_stuff - адрес начала табличного вычислителя, сразу за таблицей прерываний

; ЦРЦ аккумулятор младший байт в регистре CRC_Lo

.def  Reg_m8 = r20; ввели регистр, в котором постоянно болтается 0x08

    ldi Reg_m8,0x08 

; как добраться до вычислителя 
   eor      CRC_Lo, r16       ; 1
   mul      CRC_Lo, Reg_m8; 2
   movw   zL, r0                 ; 1
   adiw     zL, CRC32_stuff  ; 2
   ijmp                              ; 2

 

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

Ессно, без претензий на абсолютную правоту.

[galjoen 0]

Пока не вникал, работает ли Ваше ЦРЦ в целом, но

сразу встречное предложение:

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

 

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

[galjoen 0]

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

Ессно, без претензий на абсолютную правоту.

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

; пишу со вводом в младший байт CRC акк-ра
; R4, R3, R2, ZL - CRC акк-р. R17, R18, R19 - вспомогательные регистры. R16 - принятый байт CRC которого надо подсчитать.
; тут инициализируемся
rjmp Begin; идём в начало цикла

backCRC:
eor ZL,R2; получили новый младший байт обновлённого CRC аккумулятора [1 такт]
mov R2,R17; необходимая пересылка на кот-й теряется 1 такт [1 такт]
eor R2,R3; следующий байт CRC ак-ра [1 такт]
mov R3,R18; необходимая пересылка на кот-й теряется 1 такт [1 такт]
eor R3,R4; следующий байт CRC ак-ра [1 такт]
mov R4,R19; необходимая пересылка на кот-й теряется 1 такт [1 такт]
; итого получили обновлённый CRC32 ак-р, потратив на это 17 тактов.
Begin:; Здесь точка первоначального входа в цикл чтения данных и расчёта их CRC

; Тут получаем данные, для которых собственно и считается CRC32

eor ZL,R16; получили в ZL объединяющую величину [1 такт]
ijmp; переход на таблицу переходов, а оттуда rjmp на наш случай [2+2 такта]

mAF:; сюда попадаем из таблицы переходов по rjmp. Объединяющая величина =AF. Таких кусков кода 256 штук.
ldi ZL,XX1; 1е число табличного вычисления CRC  - младший байт[1такт]
ldi R17,XX2; 2е число [1 такт]
ldi R18,XX3; 3е число [1 такт]
ldi R19,XX4; 4е число [1 такт]
rjmp backCRC; регистры загружены - возвращаемся собственно на вычисление [2 такта]

Итог:

1. По сравнению с моим первоначальным вариантом - проигрыш 3 такта =21% быстродействия, 3 регистра, выигрыш на 33% FLASH меньше -1536 вместо 2304 слов в таблицах (+ то, что rjmp везде доставать будет).

2. По сравнению с вашим вариантом - проигрыша ни в чем нет, выигрыш по быстродействию 2 такта =12%, выигрыш по FLASH 20% 1536 вместо 2048 слов в таблицах (+ то, что размещать можно не в начале/конце FLASH).

Если кому интересно - могу и с "классическим" вариантом сравнить (где команды lpm используются).

 

А у меня - такие чайниковские вопросы по теме:

1. Какое преимущество даст подсчет CRC32 на лету.

2. Какое преимущество увеличение ОЗУ (что такое "дропает").

3. Не будет ли проблем с мак-адресом. В смысле не придётся ли за него кому-нибудь платить.

[Rst7 5]

1. Какое преимущество даст подсчет CRC32 на лету.

 

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

 

2. Какое преимущество увеличение ОЗУ (что такое "дропает").

 

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

 

3. Не будет ли проблем с мак-адресом. В смысле не придётся ли за него кому-нибудь платить.

 

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

[_Pasha 0]

... только регистры загружать.

Логично.

Если кому интересно - могу и с "классическим" вариантом сравнить (где команды lpm используются).

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

 

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

 

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

 

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

 

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

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