[tonyk_av 75]

6 hours ago, Siluan said:

Проблема в том

Проблема в том, что вы не понимаете, _как_ идёт приём посылки при использовании DMA.

6 hours ago, Siluan said:

правда есть ДМА

Вот именно. Помимо DMA, в полноценном UART, который есть не во всех МК у STM, имеется механизм RTO, предназначенный для аппаратной поддержки Модбас-подобных протоколов. Поэтому фраза об аппаратной поддержке Модбас в описании UART у STM32 как раз и означает, что определение границ посылки происходит аппаратно, без задействования CPU. По прерыванию вы получаете уже готовую посылку, и вам остаётся только сравнить адрес узла в посылке со своим адресом.

[Arlleex 328]

16 часов назад, tonyk_av сказал:

Например, на STM32 приём _всей_ посылки вызывает всего одно прерывание, а отправка - два.

Интересно, это как. У меня минимально 4 прерывания до переключения линии в Rx state.

[mantech 131]

12 часов назад, Siluan сказал:

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

И в чем проблема? Ну не совпал адрес, после этого просто игнорируйте данные, а таймаут, так после посл. символа зарядите прерывание таймера на 1мс и ждите события спокойно, чет не вижу тут вообще никаких проблем))

12 часов назад, Siluan сказал:

Читайте тему с начала.

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

5 часов назад, tonyk_av сказал:

Помимо DMA, в полноценном UART, который есть не во всех МК у STM, имеется механизм RTO, предназначенный для аппаратной поддержки Модбас-подобных протоколов

Да не грузите вы ТСа этими ДМА, мне самому-то сложновато бывает сразу в них разобраться особенно на новом проце, там задача не стоит этого заморачивания с его скоростями и т.п. Там бы нормально изучить принцип приема пакета и таймаута в прерываниях, не задействуя при этом основную программу и другие процессы... По правилам, этот модбас должен просто быть процессом полностью на прерываниях, как автомат, причем как принимать, так и передавать данные, с осн. программой он должен взаимодействовать только через регистры и флаг записи в регистр со стороны хоста, чтобы программа могла принять новые данные в работу, а когда хост что-то считывает из устройства, основная программа может вообще не знать об этом, не то, что там что-то считать и вычислять, т.н. принцип мейлбокса, ИМХО.

Edited November 11, 2024 by mantech

[jcxz 356]

12 часов назад, Siluan сказал:

Прочитал про "нормальный" МК STM32, тот же одиночный 8 бит регистр.

...

Я уж было обрадовался, думал придумали что-то навроде аппаратного CAN с собственным апааратным FIFO.

может LPC17xx (с FIFO в UART) спасёт гиганта мысли, отца русской демократии?  

[tonyk_av 75]

1 hour ago, mantech said:

этот модбас должен просто быть процессом полностью на прерываниях, как автомат, причем как принимать, так и передавать данные

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

[mantech 131]

5 часов назад, tonyk_av сказал:

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

Вы в курсе, что такое взаимодействие через мейлбокс? По простому, есть набор input и holding регистров, первые слейв только передает в хост, вторые чтение\запись, так вот у вас есть допустим 10 инпут и 5 холдингов, это регистры в памяти 16 бит, автомат модбаса сам выдаст их содержимое по запросу хоста, тут не нужна работа осн программы, нужно только иметь актуальные данные в этих регистрах, А если хост что-то записал в холдинги, то тогда автомат модбаса либо ставит флаг, что регистры изменены, либо вызывает коллбэк-функцию, тогда осн. программа уже применяет новые данные в регистрах для дальнейшей работы, и то это нужно не всегда.

Edited November 11, 2024 by mantech

[tonyk_av 75]

15 hours ago, mantech said:

Вы в курсе, что такое взаимодействие через мейлбокс?

В курсе.

15 hours ago, mantech said:

По простому

И зачем вы это мне описываете? Я это всё прекрасно знаю, более того, у меня в ПЛК реализован соответствующий механизм синхронизации доступа к данным. А то, что вы описали, слишком примитивно и не учитывает очень многих вещей, поэтому нормально работать будет с очень серьёзными оговорками. Если интересно, то обдумайте на досуге, как реализовать взаимодействие процессов, когда процесс вычислений длится долго, и за время вычислений поступила команд на запись данных, используемых в вычислениях. Начали вычисления с одними данными, а заканчиваем с другими? Очевидно, что так нельзя, и тривиальными колбэками тут не отделаться.

Edited November 12, 2024 by tonyk_av

[Arlleex 328]

49 минут назад, tonyk_av сказал:

Если интересно, то обдумайте на досуге, как реализовать взаимодействие процессов, когда процесс вычислений длится долго, и за время вычислений поступила команд на запись данных, используемых в вычислениях. Начали вычисления с одними данными, а заканчиваем с другими? Очевидно, что так нельзя, и тривиальными колбэками тут не отделаться.

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

[mantech 131]

4 часа назад, tonyk_av сказал:

Если интересно, то обдумайте на досуге

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

3 часа назад, Arlleex сказал:

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

Такое впечатление, что это пишут те, кто вообще видел все это только в теории, в чем проблема запретить прерывание, пока идет обновление 16и битного регистра, про критические секции похоже тоже не слыхали...

Edited November 12, 2024 by mantech

[tonyk_av 75]

7 hours ago, Arlleex said:

а уж, при скоростях модбаса между двумя транзакциями действительно времени мало...

Забыли про Modbus/TCP?

7 hours ago, Arlleex said:

.. А даже если и так - атомарно и целостностно читаются актуальные значения регистров в теневой буфер, оттуда берется все для расчетов.

Хм, вот в ПЛК, например, 8000 регистров, портов с Модбас несколько- и как тут поступать?

[Arlleex 328]

2 часа назад, tonyk_av сказал:

Хм, вот в ПЛК, например, 8000 регистров, портов с Модбас несколько- и как тут поступать?

Так в чем проблема? Эти 8000 регистров используются в 1 вычислении? Нет, конечно.

[tonyk_av 75]

1 hour ago, Arlleex said:

Так в чем проблема? Эти 8000 регистров используются в 1 вычислении? Нет, конечно.

А какие используются? Как определить? Этими регистрами оперирует программа пользователя. Что он там у себя написал, по какой ветви пойдёт алгоритм вычислений- не известно.

[MrYuran 34]

В 10.11.2024 в 15:57, Siluan сказал:

Тут еще один момент. Слейв в сети будет принимать все пакеты адресованые всем устройствам и ответы на них. Есть ли смысл сделать слейв на отдельном МК, а в основной МК передавать адресованные ему пакеты по какому нибудь быстрому интерфейсу?

Ну, как вариант, если уж настолько критично. А может, наоборот, перенести на "слейв" то, что требует такого жесткого реалтайма.

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

Можно ещё поиграться с приоритетами прерываний, хотя вход-выход тоже займет некоторое время, но не 22мкс