Какие именно ограничения вас интересуют? Электрические или логические?
roboforum.ru
Технический форум по робототехнике.
Соединение контроллеров: коммутатор
Когда я это всё разрабатывал, то не знал принципов работы I2C. Потом почитал на неё доки и удивился, как оно похоже получилось
Какие именно ограничения вас интересуют? Электрические или логические?
Какие именно ограничения вас интересуют? Электрические или логические?
Зачем все это так делать?
1. Процессору на прием и анализ адреса требуется настолько мало времени, что обсуждать это не имеет смысла. а программный побитный прием под вопросом.
2. При данном построении используется на 1 вывод процессора больше, я не говорю о лишней микросхеме.
3. Если нужна очень высокая помехозащищенность или магистраль больше 10м применяйте RS485 (всего 2 провода).
4. Применяйте встроенный УАПП для связи, будет намного меньше проблем.
1. Процессору на прием и анализ адреса требуется настолько мало времени, что обсуждать это не имеет смысла. а программный побитный прием под вопросом.
2. При данном построении используется на 1 вывод процессора больше, я не говорю о лишней микросхеме.
3. Если нужна очень высокая помехозащищенность или магистраль больше 10м применяйте RS485 (всего 2 провода).
4. Применяйте встроенный УАПП для связи, будет намного меньше проблем.
1. На приём и анализ адреса - да, много времени не надо. А вот на приём и анализ всего пакета времени уйдёт довольно много. А принять и проанализировать его придётся, т.к. иначе мы не узнаем, где он закочнился и начался новый.
Предлогаемая же схема позволяет легко аппаратно отделить пакеты друг от друга.
2. Если вы хотели сказать в пользу I2C, то я ничего не имею против, когда в контроллере есть её полная аппаратная поддержка. Т.е. такая, когда имеется отдельный буфер на весь пакет (а не на 1 байт), система сравнения ареса пакета. Вобщем так, что пока не примет свой пакет, вообще МК не дёргает. А когда если вы попробуете программно реализовать I2C, то это займёт на порядок больше ресурсов МК, чем в предлогаемом варианте.
Эта схема будет работать на любом МК, вне зависимости от отсутствия там поддрежки тах или иных протоколов, что позволяет легко связывать между собой МК разных типов, семейств и фирм.
3. RS-485 - это электрический стандарт связи, а не логический протокол. К данной конструкции без особых проблем можно прикрутить и RS-485, и ещё чё нибудь, хоть оптику.
4. Хорошо, когда этот самый УАПП в МК есть, да ещё и с FIFO-буферами. А когад нет, то предлогаю данную схему.
Предлогаемая же схема позволяет легко аппаратно отделить пакеты друг от друга.
2. Если вы хотели сказать в пользу I2C, то я ничего не имею против, когда в контроллере есть её полная аппаратная поддержка. Т.е. такая, когда имеется отдельный буфер на весь пакет (а не на 1 байт), система сравнения ареса пакета. Вобщем так, что пока не примет свой пакет, вообще МК не дёргает. А когда если вы попробуете программно реализовать I2C, то это займёт на порядок больше ресурсов МК, чем в предлогаемом варианте.
Эта схема будет работать на любом МК, вне зависимости от отсутствия там поддрежки тах или иных протоколов, что позволяет легко связывать между собой МК разных типов, семейств и фирм.
3. RS-485 - это электрический стандарт связи, а не логический протокол. К данной конструкции без особых проблем можно прикрутить и RS-485, и ещё чё нибудь, хоть оптику.
4. Хорошо, когда этот самый УАПП в МК есть, да ещё и с FIFO-буферами. А когад нет, то предлогаю данную схему.