[Алексей Васильевич 0]

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

Ну вот, как я и подозревал - у Вас неправильная архитектура ПО.

Во-первых: нужно завершать RX-DMA-транзакцию не только по размеру, но и по таймауту.

Вот по таймауту и вычисляется ошибка, об этом и писал и проблема как раз в самой ошибке.

 

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

Во-вторых: мухи - отдельно, котлеты - отдельно прикладные кадры данных - отдельно, блоки байтов принимаемые из UART - отдельно

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

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

Это не "невозможно", это Вы не смогли. Всё это возможно. Но лучше использовать РТОС, а не суперцикл.

писал как раз о  РТОС с 3-мя потоками , что именно не смог? если пустой проект пустой цикл обмена с одним устройством работает с такой же скорость как текущий проект c 60 устройствами на DMA, на осциллограмме пакеты идут плотно , у меня проблема со скоростью доставки полезной информации , а не скоростью обмена пустых сообщений.

 

 

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

А у ТС сейчас RS-485 на 57600 кбод работает вроде как. И ему ещё мало. С CAN будет меньше.

на 50 метров и 60 ячеек достаточно, дальше все у RS-485 плохо если питание берется из линии. Тема создана с целью создать аналогичное устройство с одним/двумя мастерами и одной линией до 1000 ячеек, сейчас мастеров 8 со своими отдельными капризными линиями на RS485.

[Алексей Васильевич 0]

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

Значит ищите баги в своём коде.

 

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

Чтобы убрать влияние времени обработки пакета, я бы сделал немного по-другому:

1. Мастер отправляет всем кадры, которые нужно (до 1000-ти кадров). Ни один слэйв не отправляет ответ, а если хочет ответить, то просто формирует ответ в своём внутреннем буфере передачи (нозовём это кадром статуса).

2. После отправки последнего кадра, мастер отправляет спец. кадр запроса кадра статуса с нужного узла. Запрашиваемый узел сразу стартует передачу заранее подготовленного кадра статуса из буфера. "Сразу" - это означает: после приёма последнего стоп-бита последнего байта кадра запроса от мастера, слэйв запускает таймер задержки переключения ПРИЁМ-ПЕРЕДАЧА. За время этой задержки мастер и слэйв переключают свои драйверы линии, первый - из передачи в приём, второй - из приёма в передачу. После завершения задержки - слэйв передаёт кадр статуса.

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

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

[jcxz 184]

3 часа назад, Алексей Васильевич сказал:

Вот по таймауту и вычисляется ошибка, об этом и писал и проблема как раз в самой ошибке.

Какая ошибка? Вы о чём? По таймауту должна завершаться DMA-транзакция! Именно так и строят стандартно работу DMA-UART. И проблема у Вас в том, что Вы этого не понимаете.

Цитата

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

Речь о том что DMA - это только способ передачи память-регистры_UART (как я выше писал) и способ уменьшения загрузки CPU (за счёт уменьшения числа прерываний). Про какие-то ваши прикладные кадры данных он не должен знать. Прикладные кадры данных вытаскиваются из уже полученного потока байт в памяти (записанного туда через DMA) программой драйвера.

3 часа назад, Алексей Васильевич сказал:

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

Какие "ячейки"? Вы о чём??? Вы мой пост прочитали? Я не писал ни про какие "ячейки". Любой обмен на шине в моём варианте выглядит как: TX_мастера1, TX_мастера2, TX_мастера3, ... или: TX_мастера1, TX_слэйва1, TX_мастера2, TX_слэйва2, ... Всё просто. Не надо никаких "ячеек" и прочего, Вы хотя бы такой простой обмен реализуйте, чтобы он стабильно работал без каких-то "наслоений" чего-то на что-то.

Время (таймером) нужно отсчитывать только на задержку переключения драйвера шины ПРИЁМ-ПЕРЕДАЧА и на ожидание завершения выполнения команды слэйвом. Ни часов ни каких-то дополнительных "синхронизаций" здесь не нужно - таймер перезапускается каждый раз от момента события на шине. Т.е. - получил слэйв конец кадра, посмотрел по содержимому кадра - должен ли он на него отвечать, и если да - запускает таймер переключения ПРИЁМ-ПЕРЕДАЧА и начинает это переключение, после которого стартует передачу. Мастер также закончил передачу, посмотрел на содержимое кадра которое он передавал, и если на него требуется ответ слэйва - начинает переключение ПЕРЕДАЧА-ПРИЁМ (с запуском таймаута ожидания ответа от слэйва).

Любой обмен на шине начинается с передачи кадра мастером, после которого идёт ответ слэйва, или не идёт если на кадр не требуется ответа. Все посылки мастера разделены на два типа: 1) не требующие ответа (передача команд и данных к слэйвам); 2) требующие ответа (запросы данных или результатов выполнения команд от слэйвов). После посылки команды слэйву, мастер должен после завершения (отправки последнего байта) запускать таймер выполнения команды для данного конкретного слэйва и запрашивать результат обработки команды у этого слэйва только после истечения времени максимальной длительности выполнения команды слэйвом.

Ни в 2 ни в какое другое число раз ничего умножать не нужно. Нужно отсчитывать только 3 интервала:

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

2) Длительность обработки команды слэйвом. Можно использовать либо просто максимальную длительность выполнения любой команды, либо устанавливать время в зависимости от кода команды. Это время отсчитывается только мастером, отдельно для каждого слэйва. До истечения этого времени мастер не должен запрашивать результат выполнения предыдущей команды у слэйва. Но в течение этого времени он может либо работать с другими слэйвами, либо слать этому же слэйву другие команды не требующие ответа.

3) Таймаут ожидания ответа от слэйва на запрос мастера. Отсчитывается мастером от момента завершения переключения ПЕРЕДАЧА-ПРИЁМ.

 

Можно конечно реализовать ещё групповые запросы слэйвов мастером одним кадром, с цепочкой ответов от слэйвов после. Сэкономив таким образом на временах переключения между передачами и приёмами, но Вы сначала хотя-бы добейтесь чтобы простой вариант, описанный выше, стабильно работал. Без ошибок и "наслоений". И только после этого стоит делать групповые запросы как опцию. Если простой вариант даже толком не работает - рано браться за групповые запросы.

 

7 часов назад, syoma сказал:

Это верно. Но для дальнейших действий может лучше почитаем CAN спецификацию?

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

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

[Eddy_Em 1]

4 hours ago, jcxz said:

Любой обмен на шине начинается с передачи кадра мастером

CAN-интерфейс как бы не SPI и не RS-485, официально "мастера" никакого нет: все устройства на шине равноправны.

4 hours ago, jcxz said:

Нужно отсчитывать только 3 интервала

И интервалов столько не нужно, а то получится уродство вроде модбаса поверх CAN (или, да простят мои маты, canopen). Отправили команду что-то сделать, не получили ответа через максимально приемлемое время (скажем, 10 секунд) — повторяем отправку. Вот если нужна строгая синхронизация и в каждый пакет еще вштамповывается синхроимпульс...

[syoma 1]

10 hours ago, jcxz said:

Но в любом случае воспринимать ACK как сигнал того, что удалённый получатель принял кадр и начал его обработку - нельзя. Удалённый узел в этот момент мог перезагружаться и не видел этот кадр.

Но в автомобилях именно так и работает и никто не жаловался. Один узел просто сообщает обороты двигателя, а другие их используют. Переключатель света просто выставляет на шину сообщение "Включить габариты" и остальные узлы молча выполняют эту команду без подтверждения. CANopen тоже так работает с механизмом PDO.

А если узел вдруг начал перезагружаться, то его задача при перезагрузке - это сообщить всем "Привет! Я здесь!" и спросить Remote Frame "А не скинет ли мне кто-нибудь последнее состояние вот этих и этих данных?" У другие узлы с удовольствием ему помогут получить самые новые данные. Это очень легко реализуемая фича.

Режим "Запрос/ответ" все-таки надо забыть. Софт, как и концепцию обмена, при переходе с RS485 на CAN стоит перелопатить, иначе будут те же грабли и преимуществ от новой шины вы просто не получите.

По ситуации с репитерами абсолютно не вижу проблем, но напишу позже. Сейчас нет времени.

[Алексей Васильевич 0]

6 часов назад, jcxz сказал:

Какая ошибка? Вы о чём? По таймауту должна завершаться DMA-транзакция! Именно так и строят стандартно работу DMA-UART. И проблема у Вас в том, что Вы этого не понимаете.

У вас есть реальный опыт работы в сетях RS458/CAN или вы просто завязываете свои личные выводы ?

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

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

6 часов назад, jcxz сказал:

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

2) Длительность обработки команды слэйвом. Можно использовать либо просто максимальную длительность выполнения любой команды, либо устанавливать время в зависимости от кода команды. Это время отсчитывается только мастером, отдельно для каждого слэйва. До истечения этого времени мастер не должен запрашивать результат выполнения предыдущей команды у слэйва. Но в течение этого времени он может либо работать с другими слэйвами, либо слать этому же слэйву другие команды не требующие ответа.

3) Таймаут ожидания ответа от слэйва на запрос мастера. Отсчитывается мастером от момента завершения переключения ПЕРЕДАЧА-ПРИЁМ.

Все это прошлые примитивные этапы, сейчас оптимизировано 99% команд уже есть в памяти и в хал на них просто передаются ссылки и длина. 

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

22 минуты назад, syoma сказал:

По ситуации с репитерами абсолютно не вижу проблем, но напишу позже. Сейчас нет времени.

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

[Михась 2]

EtherCAT очевидно мало. Тут обязательно надо добавить технологию блокчейна.

[shads 0]

Привет усем!

Думаю для ТС подойдет вариант CAN с использованием репитеров, без использования аппаратного ACK и с использованием программного подтверждения от адресуемых модулей. 

В случае широковещательной посылки подтверждения ACK достаточно.

Изменено 15 января, 2020 пользователем shads

[AlexandrY 2]

26 minutes ago, shads said:

Привет усем!

Думаю для ТС подойдет вариант CAN с использованием репитеров, без использования аппаратного ACK и с использованием программного подтверждения от адресуемых модулей. 

В случае широковещательной посылки подтверждения ACK достаточно.

Да не репитер ему нужен, а каплер. Репитеры хорошо работали бы на RS485 или Ethernet-е. 
На CAN-е нужны самостоятельные контроллеры сегментов, полностью самостоятельно обслуживающие свой сегмент на 100 узлов со своей внутренней адресацией и менеджментом.   
 

[jcxz 184]

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

CAN-интерфейс как бы не SPI и не RS-485, официально "мастера" никакого нет: все устройства на шине равноправны.

Читайте внимательнее то, на что отвечаете. Речь там шла об RS-485.

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

Но в автомобилях именно так и работает и никто не жаловался.

Опять...   Где Вы видели автомобиль размером 2км в поперечнике? Да ещё с 1000-ю CAN-узлами? Причём тут автомобиль, если у ТС-а система совсем не похожа на автомобиль? И проблемы там будут другие, коих в автомобиле в принципе быть не может.

Цитата

А если узел вдруг начал перезагружаться, то его задача при перезагрузке - это сообщить всем "Привет! Я здесь!" и не спросить Remote Frame "А не скинет ли мне кто-нибудь последнее состояние вот этих и этих данных?" У другие узлы с удовольствием ему помогут получить самые новые данные. Это очень легко реализуемая фича.

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

А для распределённой системы ТС-а, то что часть узлов может не работать, часть - перегружаться - это должно быть обычной ситуацией (так как каждый узел - географически самостоятелен). И это не должно ложить всю систему. Иначе суммарная надёжность её будет == 0.

Цитата

По ситуации с репитерами абсолютно не вижу проблем, но напишу позже. Сейчас нет времени.

Ну напишите. Расскажите как сигнал будет успевать распространяться через все репитеры за время кратно меньше одного бита. Причём - в обе стороны. И при этом сохраняться польза от ACK-ов такой же как, в авто. И как отказ одного узла не будет ложить всю систему.  

[jcxz 184]

1 час назад, Алексей Васильевич сказал:

У вас есть реальный опыт работы в сетях RS458/CAN или вы просто завязываете свои личные выводы ?

Много лет работал с RS-485. Десятки/сотни тысяч моих устройств с ним сейчас работают у заказчиков. Поэтому и говорю, что все ваши проблемы - следствие кривизны ПО. Да и не я один это вам писал уже.

Да и с CAN тоже есть и законченные проекты, и в текущем проекте есть два CAN-интерфейса.

1 час назад, Алексей Васильевич сказал:

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

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

26 минут назад, AlexandrY сказал:

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

Скорей всего так. Если уж выбирать CAN. Но боюсь у ТСа возникнут ещё бОльшие проблемы при опросе. Так как там будет ещё более сложная организация сети чем сейчас.

[HardEgor 63]

2 часа назад, Алексей Васильевич сказал:

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

Можно не смотреть, если вы имеете ввиду ST HAL из CubeMX, то он поможет начинающим, которые не успевают охватить всё сразу, зато с HAL можно быстро реализовать простенькую программу и она даже будет работать. Чуть только требования выросли - функции HAL переписываются на оптимальные.

[jcxz 184]

Куб и "достаточно грамотные специалисты" - вещи в принципе не совместимые. Или то, или другое. Но не вместе. имха.  

[syoma 1]

2 hours ago, jcxz said:

Ну напишите. Расскажите как сигнал будет успевать распространяться через все репитеры за время кратно меньше одного бита. Причём - в обе стороны. И при этом сохраняться польза от ACK-ов такой же как, в авто. И как отказ одного узла не будет ложить всю систему.

И напишу. Я и не предлагал отказаться от репитеров, или тех же каплеров, как их называют. Да, сеть надо делить на сегменты по 50-60 узлов. Между сегментами ставятся репитеры, задачей которых будет принимать сообщения с одной сети, буферизировать и слать в другой.

Quote

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

Почему вы вдруг решили, что для ТС-а эта ситуация должна быть обычной? Менеджмент должен быть, но случаться она должна отнюдь не каждую секунду, иначе не только с CANом а вообще с любым интерфейсом будут проблемы.

А по менеджменту -  надо отваливание узлов решать, да и все. Механизм очень простой, я уже описал в прошлом сообщении.

 

Автору - Алексей Васильевич, вы можете написать, что требуется от сети, а не то, что вы сейчас делаете на RS485? Т.е. отделить требования от реализации? Я на 99% уверен, что с CANом ваш уже реализованный вариант мастер-слейв вообще не нужен(и вы можете выбросить этот код вообще), но по-моему некоторые тут это не совсем понимают.

Т.е. вопросы:

- Вы просто периодически шлете 7-8 байтовые команды от одних узлов другим? Как часто это должно происходить (а не сделано у вас в коде)? Асинхронно - по событию, или периодически?

- Или у вас один узел должен собирать информацию со всех остальных 999 узлов? Опять же это требуется(а не реализовано у вас в коде) периодически или лучше как только, так и сразу?

- Есть ли у вас моменты, когда один узел должен послать одну и ту же команду нескольким или многим узлам одновременно? (точнее требуется ли это в вашем применении)

- Или у вас есть большие блоки данных для обмена?

- Или все вышесказанное или часть вместе?

- Вопрос по теме jcxz - узлы могут включаться и выключаться из сети неожиданно в любые моменту(например их кто-то вручную переставляет)? Или это нештатная ситуация для вашего применения?

Короче требования к сетевому обмену надо.

 

[Алексей Васильевич 0]

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

Автору - Алексей Васильевич, вы можете написать, что требуется от сети, а не то, что вы сейчас делаете на RS485? Т.е. отделить требования от реализации? Я на 99% уверен, что с CANом ваш уже реализованный вариант мастер-слейв вообще не нужен(и вы можете выбросить этот код вообще), но по-моему некоторые тут это не совсем понимают.

Т.е. вопросы:

- Вы просто периодически шлете 7-8 байтовые команды от одних узлов другим? Как часто это должно происходить (а не сделано у вас в коде)? Асинхронно - по событию, или периодически?

- Или у вас один узел должен собирать информацию со всех остальных 999 узлов? Опять же это требуется(а не реализовано у вас в коде) периодически или лучше как только, так и сразу?

- Есть ли у вас моменты, когда один узел должен послать одну и ту же команду нескольким или многим узлам одновременно? (точнее требуется ли это в вашем применении)

- Или у вас есть большие блоки данных для обмена?

- Или все вышесказанное или часть вместе?

- Вопрос по теме jcxz - узлы могут включаться и выключаться из сети неожиданно в любые моменту(например их кто-то вручную переставляет)? Или это нештатная ситуация для вашего применения?

Короче требования к сетевому обмену надо.

Требования:

Два равноценных "Центральных блока" на STM32F407 с общей сетью устройств на STM32F42 до 1000 устройств. Центральные блоки с друг другом через сеть Не общаются.

Обмен должен как можно меньше отнимать ресурсов так, как контролер занят файловой системой SPI_FLASH, графическим дисплеем , клавиатурой, принтером этикеток , сканером ШК , по USB соединен с 1C или периодически в него втыкают USB флэшки. 

Соединение устройств производится общим плоским НЕ экранированным кабелем 0.5мм2 x4 жилы без разрыва в районе устройств.

Через 50-100 устройств происходит разрыв провода для установки "репитера", одна из сторон записывается отбельным блоком питания 24-36v

Устройство представляет из себя пиксельный индикатор с кнопками

"Центральный блок" с низким приоритетом доставляет блоки 8-64байта с уникальным ID конкретным устройствам 1-40 пакетов в минуту.

Устройства с низким приоритетом периодически отсылают последний принятый ID и еще один параметр, обоим "Центральном блокам" доставку проверять не нужно.

При нажатии кнопки на устройстве (не более 10 нажатий в секунду) оно отправляет с высоким приоритетом команду на другое устройство с подтверждением доставки.

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

 

 

 

Изменено 15 января, 2020 пользователем Алексей Васильевич