[Eddy_Em 1]

Полноценно - да, не получится. Все равно нет-нет, да будут глюки. Вот и опять мы вернулись к вопросу: а на кой черт в нашем 21 веке нужен этот убогий модбас?

[juvf 10]

В 09.06.2022 в 19:55, Eddy_Em сказал:

И как же у меня в этом случае сейчас метео  работает?

какая ОС? какая скорость? application | core? ПО на прикладном уровне или на уровне ядра?

Сделайте скорость 100 бит/с - можно 3,5 символа отмерять песочными часами while-ом прямо в программе. сделайте скорость 921600 - и до свидания. На прикладном уровне в режиме мастера, ПК ещё сможет работать, но в режиме слейва - нет. Даже linux с плугом реалтайма - лажает. (не то что два пакета разделить не может, даже отправить 1 пакет не может. отправляешь через /dev/tty пакет в 100 байт одной командой write(), на выходе ПК 100 байт.... но иногда внутри пакета между байтами разрыв в 1-2 символа)

В 10.06.2022 в 00:11, Arlleex сказал:

Забудьте о "честных" таймаутах на контроллерах UART-порта на ПК.

Если написать свой драйвер на уровне ядра, т.е. задействовать аппаратный уарт, аппаратные таймера, dma, да ещё и аппаратный расчет crc, получить какойнить /dev/modbus - то на ПК нормально будет работать. Естественно речь идет за классический уарт. usb-vcp - не знаю. Можно контролировать "честно" не только 3.5, но и интервал в 1.5.

В 10.06.2022 в 00:11, Arlleex сказал:

Именно поэтому к фирмовому оборудованию FT-нашлепками не подлезть

подлезть, только на низких скоростях. 

[Arlleex 131]

1 час назад, juvf сказал:

Если написать свой драйвер на уровне ядра, т.е. задействовать аппаратный уарт, аппаратные таймера, dma, да ещё и аппаратный расчет crc, получить какойнить /dev/modbus - то на ПК нормально будет работать...

Аппаратный UART это 16550 который? Ага, смешно. И никакие аппаратные таймеры там вам не помогут, одни пляски вокруг костра получатся.

[juvf 10]

В 10.06.2022 в 10:30, Arlleex сказал:

Аппаратный UART это 16550 который?

Например в процессоре imx6q аппаратных UART несколько штук - выбирай любой на выбор. Также в качестве таймера можно задействовать General Purpose Timer (тот же TIM, что и в stm32).

[Arlleex 131]

18 минут назад, juvf сказал:

Например в процессоре imx6q...

А у Вас дома персоналка на imx6q? Не верю. Но ладно - малинки и подобные им тоже, вроде, за ПК считаются. Я же имею ввиду обычный рабочий комп на x86, на котором я, например, работаю и дома копаюсь. Под Win10. Да и с embedded-Linux сравнивать работу под более тяжелыми линухами (Debian, Ubuntu и т.д.), ИМХО, не корректно. Хотя тут я ни разу не специалист, могу ошибаться. Но Debian на imx6q я никогда не видел

[juvf 10]

В 10.06.2022 в 11:07, Arlleex сказал:

Под Win10. Да и с embedded-Linux сравнивать .... не корректно.

да, тут согласен. просто обычно в промышленном оборудовании в качестве мастера выступает мелкий комп. я мысленно "ПК" привык считать эмбедеды.  А для настольного х86 - скорее всего мимо.

[_3m 4]

В 10.06.2022 в 08:55, juvf сказал:

Например в процессоре imx6q аппаратных UART несколько штук - выбирай любой на выбор. Также в качестве таймера можно задействовать General Purpose Timer (тот же TIM, что и в stm32).

Все UART в imx6 - 16550 и во многих других так же. Лень открывать User manual но не факт что реализовано прерывание по окончанию передачи, его soc-строители любят выкидывать как "ненужное". Без этого прерывания сделать rs485 - боль.

Для RTU от линух нужна гарантия что обработка прерывания не задержится. Эта ос такое не гарантирует от сова вообще, с RT патчем чуть лучше но не 100% Все почему то забывают что в реальных сценариях параллельно обмену RS485 работают и другие блоки и они тоже хотят прерываний.

Убогость RTU в том что он для правильной работы требует строгого соблюдения таймингов а стандартные UART вместе со стандартными ОС (Win/Lin) к строгому соблюдению таймингов совсем не пригодны.

ASCII в этом отношении предпочтительнее.

[juvf 10]

В 10.06.2022 в 11:30, _3m сказал:

Лень открывать User manual но не факт что реализовано прерывание по окончанию передачи

по рукой UM. есть прерывание. но в общем и целом согласен. чем взрослее ЦП и чем дальше он от слова "микроконтроллер", тем меньше шансов на уарт/таймер/преывания. Но если в проце это всё есть, то вполне возможно.

[Eddy_Em 1]

On 6/10/2022 at 7:16 AM, juvf said:

какая ОС? какая скорость? application | core? ПО на прикладном уровне или на уровне ядра?

Линукс, естественно! Какая же еще может быть ОС?

Скорость - 19200. Понятно, что была бы побольше - ничего б не вышло. Да и то, я уже писал: нет-нет, а возникают битые пакеты, когда берется кусок запроса и кусок ответа. Думаю, был бы в том компе (обычный "писюк" 12-летней давности) нормальный 485, таких проблем бы не возникло. Да или даже если просто напаять преобразователь с 485 в 232 и к аппаратному подключить.

Раньше почему-то у нас "модно было" десктопные компьютеры для таких вещей использовать. Сейчас мы пользуемся компактными китайскими (20-30тыр за приличный компик): десктопная гробина нужна лишь если требуется туда запихнуть с десяток жестких дисков или понавтыкать чего-то в PCI/PCIe.

ПО крутится на прикладном уровне - еще мне для такой чуши не хватало модуль ядра писать! Кстати, я что-то и не встречал для линукса модбасовского модуля ядра - видимо, и не нужно никому...

On 6/10/2022 at 7:16 AM, juvf said:

Даже linux с плугом реалтайма - лажает.

Особенно с USB, т.к. большинство преобразователей буферизуют. Но в случае необходимости мне несложно будет на той же STM32F072 или F103 сделать…

[mantech 34]

В 10.06.2022 в 07:16, juvf сказал:

сделайте скорость 921600 - и до свидания.

Е-мое, лишь бы докопаться получается, а что не 10 мегабит, а 100?  Ну вот серьезно, зачем такая скорость для модбаса? Я уж молчу, что там регламентируется 9600-19200, ну и край 115200, вы интернет по нему раздаете?))))))))))

В 10.06.2022 в 09:57, Eddy_Em сказал:

Линукс, естественно! Какая же еще может быть ОС?

Ну ясен пень - линуксоцентризм прогрессирует...

В 10.06.2022 в 09:57, Eddy_Em сказал:

линукса модбасовского модуля ядра - видимо, и не нужно никому...

Ну очевидно, чего там на уровне ядра-то делать, CRC считать))))))))))))

В 10.06.2022 в 09:57, Eddy_Em сказал:

Особенно с USB, т.к. большинство преобразователей буферизуют.

Не знаю, сколь не делал байториентированных протоколов со скоростями до 115200 нормально все работает, просто пакеты километровой длины посылать не надо...

[juvf 10]

В 10.06.2022 в 12:15, mantech сказал:

Е-мое, лишь бы докопаться получается, а что не 10 мегабит, а 100?  Ну вот серьезно, зачем такая скорость для модбаса? Я уж молчу, что там регламентируется 9600-19200, ну и край 115200, вы интернет по нему раздаете?))))))))))

в 2-х системах была такая скорость. Не я архитектор этих систем, но участник. В одной системе мне пришлось слейва делать( сделал на ПЛИС аппаратный модуль), в другой системе в linux-embedded делал мастера. Почему такая высокая? Там требовалось опрашивать много параметров и оперативно принимать решение. Поэтому скорость задрали. Даже пришлось менять микрухи-драйвера 485, т.к. не все микросхемы такие скорости держат. 

Цитата

Data rate options
ADM3483/ADM3488: 250 kbps
ADM3485/ADM3490/ADM3491: 10 Mbps

 

[jcxz 184]

В 10.06.2022 в 09:30, _3m сказал:

Все UART в imx6 - 16550 и во многих других так же. Лень открывать User manual но не факт что реализовано прерывание по окончанию передачи, его soc-строители любят выкидывать как "ненужное". Без этого прерывания сделать rs485 - боль.

В чём проблема?

Прерывание "опустошение буфера передатчика" наверняка же имеется? Скорость - известна. В вышеозначенном прерывании запускаем таймер на длительность передачи символа, и - дело в шляпе.

 

PS: Ни в коем случае не агитирую за modbus.  

[Edit2007 3]

В 10.06.2022 в 10:46, jcxz сказал:

Все UART в imx6 - 16550 и во многих других так же. Лень открывать User manual но не факт что реализовано прерывание по окончанию передачи, его soc-строители любят выкидывать как "ненужное". Без этого прерывания сделать rs485 - боль.

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

[jcxz 184]

В 10.06.2022 в 10:55, Edit2007 сказал:

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

Что-ж Вы обманываете?? я такого не говорил, что вы нацитировали...

[mantech 34]

В 10.06.2022 в 10:26, juvf сказал:

Почему такая высокая? Там требовалось опрашивать много параметров и оперативно принимать решение. Поэтому скорость задрали.

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