Перейти к содержанию
    

Сориентируйте по протоколам/транспортам для связи 2 микроконтроллеров

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

JSON то зачем? :wacko: Чтоб максимально усложнить себе жизнь?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

JSON то зачем? :wacko: Чтоб максимально усложнить себе жизнь?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Попахивает arduino. :biggrin:

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня вопрос по CAN. Не уверен, насколько вообще критична автоматическая ретрансмиссия битых фреймов, но в принципе было бы интересно заюзать эту штуку вместо UART. Возможно, не столько по большой нужде сколько из любопытства.

 

1. Насколько стабильными должны быть частоты самих микроконтроллеров? Можно например их оба запустить на внутренних RC-генераторах?

 

2. Правильно ли я понимаю, что если точек только две и токовая петля не нужна, то можно заюзать все тот же дешевый ADUM1201 от UART?

 

Надо ли при этом городить схему с диодами и резистором, или можно просто can_tx/can_rx крест на крест соединить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Возможно, не столько по большой нужде сколько из любопытства.

Для "любопытства", имхо, лучше купить пару отладочных плат и на них в полной мере утолить свое любопытство :)

 

1. Насколько стабильными должны быть частоты самих микроконтроллеров? Можно например их оба запустить на внутренних RC-генераторах?

Тут все упирается в стабильность этого самого RC-генератора на всем диапазоне рабочих температур и требуемой скорости CAN-шины.

Подробности как всегда см. в гуглях.

 

2. Правильно ли я понимаю, что если точек только две и токовая петля не нужна, то можно заюзать все тот же дешевый ADUM1201 от UART?

Наверно можно, если удастся правильно понять вашу мысль :)

 

Надо ли при этом городить схему с диодами и резистором, или можно просто can_tx/can_rx крест на крест соединить?

Не вижу никакого смысла соединять два MK голым CAN без соотв. трансиверов и защит - это как из пушки по воробьям. Для подобной цели вполне хватит и обычных USART.

Хотя ничто не мешает извратиться и по такой "методе" соединить даже два ETH :)

 

Дабы далее не "гадать на кофейных гущах", опишите сразу топологию этой "шины": как и что это выглядит и как это все должно запитываться, какие расстояния и т.п.?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Здесь не консультационное бюро.

Качество ответов зависит от качества вопроса.

Так что сначала сами потрудитесь.

Ссылка на то что вы нашли вам в минус в профессиональной ветке.

Вашей теме в такой постановке место в ветке про ардуино или о чем-то подобном, о возможности туда ее перенести я и намекнул.

 

CAN контроллеры не могут соединятся по линиям tx и rx напрямую, нужна как минимум логика И на каждый rx от двух tx.

От RC генераторов CAN контроллеры врядли будут работать, поскольку там каждый бит делится еще на 13 точных квантов минимум, хотя и есть ресинхронизация по 3-м квантам.

Но опять же, это не консультация и все сказанное может быть неточным. :laughing:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Здесь не консультационное бюро.

Качество ответов зависит от качества вопроса.

Так что сначала сами потрудитесь.

Ссылка на то что вы нашли вам в минус в профессиональной ветке.

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

и не сообразить что к протоколу в рамках данной темы это не относится?

Если это не относится к обсуждаемой теме, то почему бы не подумать немного и не сообразить что тогда нет и смысла постить это сюда?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

modbus - кошмар для программиста.

Поясните в чем заключается кошмар? Старый и очень простой и понятный протокол передачи данных.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Поясните в чем заключается кошмар? Старый и очень простой и понятный протокол передачи данных.

 

То же самое, так и не понял кошмарности. Там 1 таймаут и то, +-лапоть. :biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Поясните в чем заключается кошмар? Старый и очень простой и понятный протокол передачи данных.

struct config
{
    typedef uint8_t version;
    static version const VERSION = 3;
    version Version;

    struct localhost
    {
        uint8_t     MAC_address[6];     // big endian
        uint8_t     Built_in_MAC  :1;
        uint8_t     DHCP_enabled :1;
        ip_addr_t   IP_address;         // big endian
        ip_addr_t   Netmask;            // big endian
        ip_addr_t   Gateway;            // big endian
        ip_addr_t   DNS[2];             // big endian
        char        Hostname[64];
    }   Localhost;

    struct telnet
    {
        in_port_t   Port;
        char        Password[21];   // 20 symbols + trailing '\0'
    }   Telnet;

    struct ademco685
    {
        uint32_t    Baudrate;
        uint8_t     Receiver_ID;            // Receiver ID
        uint8_t     System_enabled;         // bitset
        uint8_t     Keep_alive_timeout;
        uint16_t    Copy_filter_timeout;    // seconds
    }   ADEMCO685;

Все данные (кроме оговоренных в комментариях) в маленьких индейцах. Напишите чтение/запись через modbus. Только честно - чтобы можно было менять как один параметр через Preset Single Register, так и произвольную группу через Preset Multiple Registers. И чтобы в процессе записи группы или через Preset Single Register не допускалась запись половины 32-битного числа. Любопытно глянуть на простоту реализации. А это только малая часть настроек моего устройства.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

То же самое, так и не понял кошмарности. Там 1 таймаут и то, +-лапоть. :biggrin:

 

В таймауте как раз и кошмарность.

Вроде и ничего сложного, но почему-то возникают проблемы на "поделках"

 

 

Напишите чтение/запись через modbus. Только честно - чтобы можно было менять как один параметр через Preset Single Register, так и произвольную группу через Preset Multiple Registers. И чтобы в процессе записи группы или через Preset Single Register не допускалась запись половины 32-битного числа. Любопытно глянуть на простоту реализации. А это только малая часть настроек моего устройства.

А что сразу функции 4/6/16? MODBUS ими не ограничивается!

Кто мешает использовать 20/21 (Read File Record/Write File Record)?

Или даже (при действительно необходимости) свои функции, стандарт ведь это допускает.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Или даже (при действительно необходимости) свои функции, стандарт ведь это допускает.
И что потом делать с этими функциями, если готовые программы о них не знают? Так почему не использовать свой протокол целиком, если нет жесткого требования использовать именно modbus?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И что потом делать с этими функциями, если готовые программы о них не знают? Так почему не использовать свой протокол целиком, если нет жесткого требования использовать именно modbus?

Из modbus-а имеет смысл использовать только его механизм деления на кадры. Я говорил уже.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...