там уровни иные раз, выходные каскады = открытый коллектор два.
второе решает проблему коллизий мультимастера, первое - помехозащищенность

Во! Терь "въехал". Спасибо!

Получается, cудя по тому, что мах13089 это 232-485, то "там" не CAN......?

Конечно не CAN, в гнилой ЖКХ-шной автоматике его не часто используют из-за высокой стоимости решения

Псевдо-CAN в данном случае являлся тупым использованием драйвера CAN физического уровня. А на программном уровне всё было от обычных последоваnельных полудуплексных протоколов, таких как RS-232 и RS-485, т.е тупо 1 мастер- 254 слейва, запрос мастера -ответ слейва. Что и подтверждалось на практике переполюсовкой линии RS-485 на входе приёмо-передатчика псевдоCAN, и Меркурий с интерфейсом CAN вдруг начинал работать в сети RS-485. В настоящем же CAN куча всяких примочек - обработка коллизий, мультимастерность, почтовые ящики разные (типа endpoint в USB). Ну вы, надеюсь, все знаете.

Ага... ))

"...кто имеет ум, тот сочтит число зверя, ибо число это человеческое, число это..." из трёх цифер... с двумя буквами в начале... ЛЮ485

Написано же, есть некий DSP, аппаратно обрабатывающий CRC и особенности протокола. Т.е. выход CAN это связка DSP+UART. Конечно, всё можно сделать и программно, но отдельно же указывается экономия ресурсов CPU, которая получается из-за задействования этого самого DSP.

Никто не мешает сделать связку DSP+UART и для модбаса. Это тоже сэкономит ресурсы CPU. Но не делают, почему-то. А для CAN делают.


PS. Всякие ОК и прочее, о чём говорит LordN, дают драйверы выходные. DSP просто знает, как этим пользоваться.