[adnega 11]

11 минут назад, jcxz сказал:

У вас дом наверное не 2 км в поперечнике? Да и устройств я думаю на порядки меньше чем нужно ТС? Тогда ваш случай не имеет никакого отношения к случаю ТС. Те проблемы, которые у него могут  возникнуть, у Вас не должны проявляться в принципе.

У меня шина порядка 20~40 метров всего на скорости 50 кбит/с. Но даже при этом без согласования не работает. Могу снять осциллограммы с терминатором и без если нужно.

Медленный спад удлиняет доминантное состояние по версии приемника, и это приводит к ошибкам на шине.

Терминатор не только борется с отражениями, но и ускоряет этот переход.

Вот любите вы, jcxz, додумывать и притягивать то, чего нет: я не утверждал, что моя задача == задаче ТС.

Я утверждаю, что для CAN важно:

- правильная топология с терминаторами;

- правильное положение точки семплирования;

- правильное распределение идентификаторов.

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

С RS485 было дело лет 7 назад на оном объекте в системе УД - куча проводов, куча узлов, медленный опрос - пришлось придумывать схемы с приоритетами опроса узлов,

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

считаю, можно и нужно применять CAN.

2 минуты назад, _pv сказал:

сотня устройств на шине нагрузку сравнимую с терминатором сделает.

Может да, а может и нет... Мы инженеры и должны разрабатывать по-науке, а не в режиме "и так сойдет". Цена вопроса меньше рубля. Мы рубль экономим?

Я думаю сотня, устройств скорее добавит емкости шине, чем проводимости. Ну и отражения никто не отменял.

Кста, у некоторых CAN-phy есть вход управления крутизной. Иногда повышенная крутизна отрицательно сказывается на распространяемом сигнале.

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

Еслиб это было так, то CAN не работал бы на 1 Mbit.

Это картинка линии, в которой есть хотя бы один терминатор. Попробуйте отключить все терминаторы и увидите при попытке передачи

резкий переход в доминантное состояние, затем падение по экспоненте, при этом передатчик зафиксирует ошибку перехода в рецессивное состояние,

включится ретрансмиссия, и так до BUSOFF.

[AlexandrY 3]

6 minutes ago, adnega said:

Это картинка линии, в которой есть хотя бы один терминатор. Попробуйте отключить все терминаторы и увидите при попытке передачи

Ну так и RS485 без терминаторов не работает. Даже на дистанции 1 м. 

[adnega 11]

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

Ну так и RS485 без терминаторов не работает. Даже на дистанции 1 м. 

Берем линию 1 метр.

Берем два узла RS485, и, постепенно повышая скорость передачи, получаем два значения скорости, выше которой происхоит >1% ошибок передачи

соответственно для терминированной и нетерминированной линии. Получаем аналогичные два числа для CAN узлов.

Я утверждаю, что разница между двумя значениями для случая RS485 будет ощутимо меньше чем для случая CAN. Кто не согласен?

[jcxz 243]

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

Берем два узла RS485, и, постепенно повышая скорость передачи, получаем два значения скорости, выше которой происхоит >1% ошибок передачи

...

Я утверждаю, что разница между двумя значениями для случая RS485 будет ощутимо меньше чем для случая CAN. Кто не согласен?

Ещё бы объяснили что такое есть "два значения скорости, выше которой происхоит >1% ошибок передачи"? Что за скорость имеющая "два значения"? 

[adnega 11]

7 минут назад, jcxz сказал:

Ещё бы объяснили что такое есть "два значения скорости, выше которой происхоит >1% ошибок передачи"? Что за скорость имеющая "два значения"? 

"два значения скорости ... соответственно для терминированной и нетерминированной линии".

1. В терминированную линию 1 метр трансиверами RS485 передаем 100 каких-то пакетов на малой скорости.

2. На другом конце принимаем эти пакеты и сравниваем с тем, что передавали.

3. Если есть более одного битого пакета, то запоминаем скорость передачи. Тестирование закончено.

4. Если битых пакетов нет или всего один, то увеличиваем скорость на 10% и продолжаем с п.1.

Повторяем эксперименты с нетерминированной линией - в результате запоминаем второе значение скорости.

Сравниваем два запомненных значения.

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

9 часов назад, AlexandrY сказал:

Хотя интересно зачем DMА использовать для CAN где есть всего два майлбокса. 

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

 

[jcxz 243]

31 минуту назад, Алексей Васильевич сказал:

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

DMA или не DMA - вообще никак не должно влиять на "пакеты не той длины". DMA или запись процессором в регистры - это всего лишь способ передачи данных из программы (памяти) в регистры передатчика UART.

Использование DMA на больших скоростях предпочтительнее для уменьшения загрузки процессора. Только и всего. На STM32 с их урезанным UART, DMA даёт ещё больший эффект уменьшения загрузки процессора, чем на других МК, с более прямым UART.

Если загрузка процессора не важна, или низкая, то DMA будет как собаке 5-я нога.

Вам надо сначала найти баги в имеющемся ПО, которые приводят к "пакетам не той длины". Иначе - с большой долей вероятности то же самое будет и на CAN.

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

30 минут назад, jcxz сказал:

DMA или не DMA - вообще никак не должно влиять на "пакеты не той длины".

Перед тем как отправить пакет в DMA создаю команду на прием пакета ЗАДАННОЙ длинны, калбек отправки переключает драйвер на прием. Если пакет ответа будет короче , калбек приема не отработает , опрос на время остановится, а сама ошибка будет обработана в отбельном потоке, таких ошибок может быть десятки в секунду падает скорость обмена. 

41 минуту назад, jcxz сказал:

спользование DMA на больших скоростях предпочтительнее для уменьшения загрузки процессора.

У меня пакеты маленькие и их сотни в секунду , без DMA организовать плотную отправку у меня не получилось физически (возможно кому-то это удалось).

 - В одном потоке главного цикла невозможно параллельно подключить LAN, а работа основной программы останавливает опрос,

- В нескольких потоках с равным приоритетом скорость обмена падает в 3 раза    

- В нескольких потоках с приоритетом обмена , не работает USB и LAN , обновление экрана и клавиатура отвечает с задержкой в несколько секунд.

 

[AlexandrY 3]

9 hours ago, adnega said:

Повторяем эксперименты с нетерминированной линией - в результате запоминаем второе значение скорости.

Не, спасибо.
С нетерминированной линией делайте опыты один. А мы уже опытные. 

Вот макетик мне сварганили недавно. В нем платы с реле связаны по физике RS485, а остальные по CAN.

Для RS485 использованы драйвера ISL32173EIBZ.  
Так вот их приходилось менять уже 10! раз.
У драйверов деградировали входы и они начинали подсаживать одну из линий A или B или обе.
Как версия - звон на нетерминированной линии RS485, всплески на фронтах и в последствии полупробой. 
Поскольку такие полупробои случались во время тестирования плат без терминаторов.  
Ну люди подходили подключали платы по одной чтобы проверить и забывали ставить терминаторы. 

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

[syoma 1]

А чем определялся именно выбор CAN для этой сети, вместо другого интерфейса?

Чисто физически 1000 CAN трансиверов на одну сеть не повесить, поэтому нужны репитеры, которые бы разделяли сети на сегменты. Тогда можно и скорость повысить и это как-то скомпенсирует задержку на репитерах.

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

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

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

А чем определялся именно выбор CAN для этой сети, вместо другого интерфейса?

RS485 в моем случае имеет проблемы и ограничения, за 5 лет использования и модернизации принял решение перейти на CAN как следующий этап развития системы.

Основные требования: быстрый ответ устройств, не ограниченный скоростью их опроса мастером. Построение простой масштабируемой сети по заданию заказчика без изменения конструкции. 

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

Чисто физически 1000 CAN трансиверов на одну сеть не повесить, поэтому нужны репитеры, которые бы разделяли сети на сегменты.

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

Основной трафик это фоновые задачи для "слейвов" от "мастера" на низком приоритете, слейвы отвечают редкими короткими командами в приоритете, часть этих команд являются командами для других "слэйвов". 

[HardEgor 88]

30 минут назад, Алексей Васильевич сказал:

RS485 в моем случае имеет проблемы и ограничения, за 5 лет использования и модернизации принял решение перейти на CAN как следующий этап развития системы.

Основные требования: быстрый ответ устройств, не ограниченный скоростью их опроса мастером. Построение простой масштабируемой сети по заданию заказчика без изменения конструкции.

RS485 точно так же выполняет основные требования как и CAN, всё зависит от "радиуса кривизны рук" разработчика  мастера и слэйвов. Если постараться, можно и CAN сделать тормозным....

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

11 минут назад, HardEgor сказал:

RS485 точно так же выполняет основные требования как и CAN, всё зависит от "радиуса кривизны рук" разработчика  мастера и слэйвов. Если постараться, можно и CAN сделать тормозным....

Прошу описать алгоритм получения одним мастером сообщения от любой из 1000 ячеек за 0.3 сек ?

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

[HardEgor 88]

55 минут назад, Алексей Васильевич сказал:

Прошу описать алгоритм получения одним мастером сообщения от любой из 1000 ячеек за 0.3 сек ?

Элементарно - посылаешь запрос и получаешь ответ :)

Зависит от скорости интерфейса, задержки слэйва(пока он переварит запрос и подготовит ответ), размера запроса, размера ответа.

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

 

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

[syoma 1]

3 hours ago, Алексей Васильевич said:

Основные требования: быстрый ответ устройств, не ограниченный скоростью их опроса мастером.

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

Тогда задержка будет в идеале 0.0с и зависеть только от загрузки сети.

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