Протокол для интерфейса Spi (да и I2c)

[alex6002]

Кто мешает повесить туда СОМ порт на прием и принимать нормальной терминалкой?

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

[AndrFV]

А вообще, меня раздражают люди, которые не читая доку на I2C пихают его в разработки, которыми мне приходится пользоваться. По стандарту автора, Philips, длинна интерфейса не может быть больше 40 см. А вот разработчикам из Speclab это видимо не ведомо :\

Вообще-то просто не надо задирать скорость интерфейса. Тогда и все протоколы будут работать на расстояния более 40 см...

[akegor]

Модбас слишком тяжел - много памяти отъедает. Для мелких чипов неподъемен. Да и нужен он не всегда. Применяем его только для связи со сторонними вещами.

[p4all]

С праздниками всех !!!
Собственно, вопрос в заголовке...
Или на воду дую ?

Я в свое время то же решал этот вопрос.
Так же, как большинство в дискусии пришел к выводу: RS-485, или UART (TTL уровни, если линия короткая). Хотя здесь все равно желательно согласование (120 Ом для плоского кабеля) и/или оптронная развязка.
Посмотрел я на Profibus, Modbus - громоздко все это. Взял за основу Modbus (QRC) и упростил телеграмму до 4-х байт. Сеть - full duplex. Первый байт мастера - адрес, 1 в 9-м бите. Остальные байты - 0 в 9-м бите. И так, 1 - адрес, 2 - код функции, 3 - байт данных, 4 - контрольная сумма LRC (гораздо проще, чем CRC, для короткой телеграммы хватает). Ответ и обработка ошибок - как в Modbus, но то же 4 байта.
Работает, как часики: 57600 бод на 40м по кабелю SFTP-4-AWG23, РС - мастер и 7 слайвов.
У меня то же не было лишнего таймера для отчета времени между посылками, потому для идентификации начала использовал 9-ый бит. Правда, микроконтроллеры MCS-51, а не PIC.

[AndrFV]

Так же, как большинство в дискусии пришел к выводу: RS-485, или UART (TTL уровни, если линия короткая). Хотя здесь все равно желательно согласование (120 Ом для плоского кабеля) и/или оптронная развязка.

485/482 - неплохие интерфейсы. Кстати, UART в них переделывается всего одной микросхемкой с несколькими конденсаторами. В ней же реализована и оптронная развязка.

[DropSoft]

Модбас слишком тяжел - много памяти отъедает. Для мелких чипов неподъемен. Да и нужен он не всегда. Применяем его только для связи со сторонними вещами.

Смотря что нужно.
На Attiny13 делал датчики протечки и датчики тока, общающиеся по урезанному модбас-рту через RS-485. Поддержка только функций 3, 4 и 6. И в одной посылке (для функций 3 и 4) от 1 до максимум 5 двухбайтных регистров. Причем и уарт программный, и работа от встроенного RC, т.е. частота подстраивается по принимаемой посылке. Вполне надежно работают.

[akegor]

Смотря что нужно.
На Attiny13 делал...

Сам не вникал, товарищ этими вопросами занимается. Он сторонник стандартной тяжеловесности, а я его периодически возвращаю на землю. Модбас, конечно, удобен, когда не сильно кастрирован, но тяжел (повторяюсь).
А вообще, я сторонник простых решений, когда это возможно. Чем проще, тем меньше мест для граблей.

[omercury]

А вообще, я сторонник простых решений, когда это возможно. Чем проще, тем меньше мест для граблей.

Передавать прямой и инверсный байты - и вся недолга. Никакого подсчёта CRC, контроль целостности данных на лету. Если все трое подключены по кольцу, то адрес необязателен, каждый съест свои байтики и подменит их ответом, а вот таймаут или сигнал сброса пакета мутить придётся - SPI-тырфейс синхронный.
Можно то же кольцо через USART организовать.

[shurik_ss]

Понимаю, что не совсем вежливо в чужой теме переводить разговор на свои заморочки, но вопрос уж весьма схож:

Проектируется сеть несложных датчиков (пока 6 штук, возможно будет до 10) на базе Тини2313 с управлялкой на Меге16 (контроллеры уже есть). Разводка сети звездой, уже есть готовая (2 витых пары в кабеле). Длина лучей звезды - от 5 до 20 метров. Скорость обмена достаточна 19 кбод. Обмен двунаправленный. Система для своих нужд, с безопасностью жизнедеятельности не связана, т.е. сертификация и другие формальности не требуются. Здание офисное, т.е. уровень помех незначительный.
Предварительно решили использовать шину I2C с очень низкой тактовой частотой (19200 Гц), простейшим подсчетом контрольной суммы пакета данных (XOR) и повтором передачи при несовпадении суммы (пакет 16 байт). Но прозвучавшая здесь мысль о том, что любая импульсная наводка на линии SCL вызовет сдвиг на один бит, заставила крепко задуматься о возможности реализации данной концепции (сами об этом как-то не подумали). Действительно, несмотря на малую скорость передачи данных, аппаратный модуль USI медленней работать не станет, и будет легко ловить микросекундные помехи. А с учетом большой длительности пакета данных (около 8 мс), появилось опасение, что битых пакетов может оказаться больше, чем целых. Что посоветуете в данной ситуации?

[ForcePoint]

Предварительно решили использовать шину I2C

Ну какой "в красную армию" I2C (пусть даже на 5, а не на 20 метров), если у него высокий уровеь подтяжкой формируется? Конечно он Вам словит не только иголку, но и погоду на мысе Горн.
На мой взгляд - если не в одной комнате всё расположено, то только дифференциальная "физика" (например 485).