Довелось мне Modbus реализовывать в синтезируемом процессоре в плис. Думаю.... да зачем мне проц грузить модбасом? Считать там интервалы в 1,5 и в 3,5 символов. Сделал контроллер Modbus аппаратный. Т.е. приходит пакет, контроллер принимает, проц вообще не участвует в приеме. после пакета прошло времени в 3,5 символа и если между байтами внутри пакета не было пауз в 1,5 символа и если совпал crc и если адрес "мой", то контроллер выставляет прерывание процессору. процессор знает в каком месте его озу лежит готовый принятый пакет. Проц парсит пакет, обрабатывает, записывает в определённое место озу ответ и дает контроллеру "старт". Контроллер выплёвывает ответ в уарт, сам считает и отправляет crc. Контроллер сам управляет ногами DE/RE драйвера RS485. С таким контроллером работать с модбасом - ну просто красота. Доставляет.

Протокол не новый и достаточно распространённый, не менее чем CAN. Но если нету плис - то и нету контроллера. вот и возник вопрос - не придумали ли ещё готовый, законченный контроллер MODBUS в каком нить SOIC-8? Или может существует какой-нибудь АРМ в котором есть аппаратный контроллер modbus?

Протокол, в общем-то, и заточен под аппаратную реализацию.
Целиком готовых контроллеров не встречал, в некоторых (msp430) есть аппаратный кодек CRC.
В общем-то, протокол достаточно примитивный, ресурсов отнимает минимум, программные реализации давно устоялись, поэтому нет запроса на реализацию в железе, в отличие от того же CAN

А как использовать "законченный контроллер MODBUS в каком нить SOIC-8", что-то даже в голову не приходит..
Разве что как контроллер пары светодиодов

А чё? Два уарта, пять ног всего нада+питание.
уарт на хост как мона быстрее Тут проблема не в 8ног, а в том, что у этого 8-ногого зоопарка не найдешь озу нужного размера. Не, ну если забить на это, то у меня ascii в тиньке 2313 не сильно тяжелый. Правда, я потом его подпилил все-таки для своих сугубо внутренних нужд- endianness поменял, забадали перестановки.

Ну так чтобы «нажал на кнопку - чик - и все уже готово», то не знаю. А так у LPC17xx (ну и у 2xxx, видимо, UART-ты то оттуда перекочевали) есть прерывание по паузе поступления байтов в приёмное FIFO

И аппаратное управление передатчиком RS485 у UART1.

Хотя паузы на каком-нибудь свободном OUTPUT COMPARE не проблема сделать. Скажем, у AVR
OCR1A = TCNT1 + TICKS_FOR_3_5_BYTE;
в каждом прерывании UART и прерывание OCF1 даст конец пакета.

Трудно сказать, у кого такого нету. У AT91Sam7S и выше/шире(новее) - тоже есть.

Сообщение отредактировал _Pasha - Oct 4 2012, 18:32

Ну, значит, это скорее норма для всего потолще 8-битников.

O!!!! А запилить контроллер в отдельном 8-ми ногом МК - что-то не догадался. Действиетльно... там даже не 2 уарта нада.... можно уарт + и2ц или спи. Спасибо за подсказку.

дак так и делал. причем контролировал 2 интервала, ещё и 1,5 символов между байтами
OCR1B = TCNT1 + TICKS_FOR_1_5_BYTE;

Но когда много этих модбасов стекается в 1 устройство.... тут уже возникают трудности.

Вот это тот случай, который я пытался объяснить в безжалостно закрытой фекальной ветке про ОС РВ.
А если пофантазировать, есть одно оченно частное решение - когда вообще деваться некуда. Если бы не ограничение на тайм-ауты по минимальному значению, оно бы было популярно.
Пожертвовать 0.5 символа.
При приеме пакета (для RS485) использовать передачу при выключенном передатчике, засылать что нить при приеме каждого байта и получается, что на втором фиктивно переданном символе программа спотыкается о Т15, а на 4-м - Т35.
Изврат?

Сообщение отредактировал _Pasha - Oct 5 2012, 04:56

Нет. Вполне нормально для гражданского времени:-)

При приеме пакета (для RS485) использовать передачу при выключенном передатчике, - что то я фокуса не понял

Для AVR


Сообщение отредактировал _Pasha - Oct 5 2012, 07:28

понял..... мне кажется изврат. можно таблом прощёлкать свою посылку. если между 2-мя пакетами будет пауза меньше 4-х символов, то пакеты склеются. нужно тогда запрос давать не раньше чем через 5 символов после предыдущей транзакции.