[mantech 42]

В 08.06.2022 в 07:37, VladislavS сказал:

в ПЛИС сейчас такое же кубоводство. Открываете Vivado, накидываете туда кубиками микропроцессор, периферию к нему, синтезируете схему.

В условиях санкций разве это еще актуально? Думал, плисоводы уже начали импортокитайзамещение)))

[AleksBak 0]

В 08.06.2022 в 08:37, VladislavS сказал:

Смотрим, а висит то этот порт на AXI-шине, которая простая и удобная, но медленная.

А можете, что-то пояснить по этой шине? В смысле какие отличия между собой у этих всех шин? Непросто так же обозвали так. Или хотя бы подсказать соотв. документ по ним. Знаю, что она (эта шина) вроде 64-битная (?) и ... все. Дальше "знания" заканчиваются.

Понимаю, что немного (а может и нет вообще-то) "не по теме", но тут выше пошли какие-то непонятные посты-монологи с херней-болтновней вне темы и так что вот что я спросил (техническое) именно и есть по теме 100.000%. Спасибо.

[VladislavS 39]

В 08.06.2022 в 08:27, AleksBak сказал:

А можете, что-то пояснить по этой шине?

Мля, ну шикарная же документация у производителя.  pg155-axi-lite-ipif

[AleksBak 0]

В 08.06.2022 в 10:00, VladislavS сказал:

шикарная же документация у производителя

Спасибо. Я вообще-то думал про шину в ядре ARM. А она оказывается какая-то популярная эта шина (ARM® AMBA® AXI control interface). Надо самому еще тоже поискать/почитать, что це такое.

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

..не найдешь.

[jcxz 217]

В 08.06.2022 в 07:37, VladislavS сказал:

Вроде всё зашибись, но начинаете дрыгать ногой, а оно ТОРМОЗИТ. На ПЛИС торомозит. Спрашиваешь у коллег-плисоводов, что за на? В ответ - так GPIO в плис медленный. Как так? Ну вот так. И живут с этим. Начинаем разбираться, а чего же оно тормозит то? Оказывается, порт не имеет регистров, хранящих своё состояние. Вместо этого функции библиотеки XIL  для работы c портом хранят его состояние в ОЗУ. Чтобы дёрнуть ногой надо прочитать из ОЗУ состояние порта, изменить его, сохранить обратно на будущее и записать новое состояние в порт. Еще и обернуть это всё средствами обеспечения атомарности. Упасть не встать.

Да, вот так всегда.   Кубоводы громко кричат как всё легко и просто - "нажми на кнопку и уже получил результат". Но когда дело доходит до практики, когда есть с чем сравнить - сделанное набором из кубиков и сделанное вдумчивым изучением доков, так они сразу куда-то пропадают. Максимум что можно услышать: "проц жирный, зачем такты/байты экономить"?

PS: И главное правило при пользовании кубами - никогда не смотреть в листинг!  Иначе может поплохеть.  Если сравнить полученное с некубовским кодом. 

[Arlleex 160]

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

Но тогда на ум приходит анекдот:

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

Но себя я отношу к третьей категории джедаев

[Eddy_Em 1]

On 6/7/2022 at 8:59 PM, mantech said:

И в чем же он дрянь?

А вот сравните modbus-rtu на физике RS-485 с обычным CAN! Самые основные недостатки модбаса: 1) невозможен мультимастер, 2) нет аппаратного контроля ошибок (дебильные CRC приходится вручную считать, а уж про конфликты на шине вообще молчу), 3) огромные таймауты (минимум по 3.5 слова) между пакетами, что минимум в полтора раза замедляет линию для коротких пакетов. Ну и в общих чертах: 4) модбас - просто уродливый протокол!

[haker_fox 61]

On 6/8/2022 at 5:46 PM, Eddy_Em said:

А вот сравните modbus-rtu на физике RS-485 с обычным CAN! Самые основные недостатки модбаса: 1) невозможен мультимастер, 2) нет аппаратного контроля ошибок (дебильные CRC приходится вручную считать, а уж про конфликты на шине вообще молчу), 3) огромные таймауты (минимум по 3.5 слова) между пакетами, что минимум в полтора раза замедляет линию для коротких пакетов. Ну и в общих чертах: 4) модбас - просто уродливый протокол!

Все первые четыре пункта лёгким усилием превращаются в достоинства:

1. Мультимастер не всегда нужен в промавтоматике. Для неё и делали Modbus.

2. Этот протокол работал на i8080 и подобных, если не слабее по вычислительной мощности. И ничего не тормозило. Неужели мощности современных микроконтроллеров не хватает, чтобы посчитать CRC-16?

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

4. Гадкий утёнок - он же прекрасный лебедь! Попахивает расизмом. Сейчас не время для этого. По-крайней мере не пока.

[dimka76 53]

On 6/8/2022 at 12:46 PM, Eddy_Em said:

огромные таймауты (минимум по 3.5 слова) между пакетами, что минимум в полтора раза замедляет линию для коротких пакетов. 

CAN - не возможность передать за раз больше 8-ми байт. Отсюда то же самое замедление в полтора раза со стандартным ID и больше, чем в полтора с расширенным ID.

СAN это физический уровень. MODBUS это транспортный уровень.

Запустите MODBUS на CAN, а не на RS485 )))

CAN ориентирован не на получателя, а на данные.

MODBUS ориентирован на получателя.

 

Так зачем же сравнивать теплое с мягким ?

[juvf 17]

1) это не недостаток, а свойство. modbus модбас применяется там, где 1 мастер и куча слейвов. Например в АСКУЭ, устройство сбора данных опрашивает в жилом доме электросчетчики. Счетчикам нефиг лезть в шину. Их задача считать эл. Сиди молча. Тебя спросят - отвечай. Мастер раз в сутки опросил и сохранил данные.

2) тут прям пестрит куча вопросов: "а это что?", "а у кого есть?", "а причем тут стандарт модбас?".... я на плисе в верилоге написал свой модуль кубик. Этот кубик принимал пакет и складывал в двухпортовое озу данные, на лету считал (аппаратно) CRC, аппартно вычислял паузу в 3.5 символа, аппаратно вычислял паузы в 1.5 между байтами. Потом, после паузы в 3.5 символа если crc == 0 и не было пауз в 1.5 символа и адрес получателя совпал, то кубик выставлял прерывание процессору. Процессор уже голые данные парсил.

Так что всё в ваших руках. можно на маленькой плис сделать аппаратный контроллер модбас и прикрутить его к стм32. Можно разработать свой аппаратный контроллер (свой чип) и засунуть его в soic-8. Ни кто не запрещает. да более того, можно написать прогу модбаса и запихнуть его в 5/8/10 ногий МК. Будет вам внешний "аппаратный" контроллер RS-485.

 

3) ну про таймауты вам уже ответили... добавлю.... как это МИНИМУМ в 1.5 раза? допустим мастер отправляет запрос в 6 символов, а слейв отвечает 250 символов. Накладные расходы 7 символов. (250 + 6 + 7)/(250 + 6) = 1,02734375. 2%. где тут 1,5 раза?

4)монрмальный протокол. Его нужно использовать по назначению. Кто-то пытается устроить сеть с мультимастерами и начинаю - фу, это г. А он для этого не предназначен.

 

У CAN свои преимущества и своя специфика, у Modbus свои преимущества и специфика. Например у модбас пакет до 256 байт, в то время, как у кан до 8.

 

[mantech 42]

В 08.06.2022 в 12:46, Eddy_Em сказал:

4) модбас - просто уродливый протокол!

1-3 - просто за уши притянуто, как всегда, ну а 4 - ну какое чудо до сих пор везде генту втыкает, есть куда лучшие дистрибутивы!!!

Изменено 8 июня, 2022 пользователем mantech

[dimka76 53]

On 6/8/2022 at 12:46 PM, Eddy_Em said:

4) модбас - просто уродливый протокол!

Уродливый ACK в CAN )))

Датчик отправил в сеть температуру.

Подтвердили получение все узлы в сети, даже те, которым эта температура не нужна.

А тот, кому нужна эта температура - не подтвердил.

А отправитель и не знает об этом )))

[Eddy_Em 1]

On 6/8/2022 at 1:26 PM, dimka76 said:

Запустите MODBUS на CAN, а не на RS485 )))

Мне проще запустить CAN на CAN ☺

У нас уже давно 2 телескопа (БТА и Ц-1000) работают на sew'овских приводах, там обычный CAN, и посылки в 8 байт даже излишними бывают (зачастую хватает 4-6 байт). У меня термомониторинг зеркала БТА на CAN работает (самопальный протокол), тоже никаких проблем. Вообще не вижу, кому вменяемому может прийти в голову в 2022 году пользоваться древним модбасом, который и был придуман таким кривым именно из-за проблем связи! А уж гонять модбас по TCP - вообще маразм! Ну если у тебя уже есть TCP, почему бы не поднять поверх него IP? А еще проще - вместо TCP поднять UDP и работать на этом уровне (особенно проще для микроконтроллеров).

On 6/8/2022 at 1:43 PM, dimka76 said:

А отправитель и не знает об этом )))

Очень даже знает: если ему нужно подтверждение, пусть мастер высылает в ответ подтверждение! Я именно так и делал протокол, где нужно было контролировать получение. Можно еще и таймслоты добавлять!

[Eddy_Em 1]

On 6/8/2022 at 1:32 PM, mantech said:

есть куда лучшие дистрибутивы!!!

Лучше генты нет. Есть чуть хуже: Calculate или Slackware. Вот и закончились дистры GNU/Linux!

А если вы systemd/Linux с линуксом путаете, у вас что-то не так с логикой.

[aaarrr 69]

On 6/8/2022 at 1:43 PM, dimka76 said:

А отправитель и не знает об этом )))

Ему и не надо - что датчик с этой информацией делать будет?

Зато в модбасе красота: отправили запрос датчику -> ждем (сколько, кстати?) -> ой, тайм-аут (датчик помер? надо бы еще одним запросом кинуть для надежности!) -> запрос -> опять тайм-аут (ладно, теперь докладываем). А остальные устройства подождут, чего им сделается.