roboforum.ru

1. мне например с уартом намного приятней работать.
2. в уарте все могут быть мастерами и соответсвенно все модули могут общаться с кем захотят.

в I2C это называеца мульти-мастер. Просто нужно не поленица и почитать.

neiro
Мне тоже I2C не понравился сложностью реализации.
Но господа продумали всё и сделали I2C для соединения ведущего с кучкой ведомых.
Много аппаратно реализовано и программная часть расписана и готова.
Скорость, то же не плохая у I2C.

Если же брать UART, то придётся самим реализовывать фишки, которые в I2C вам на блюдечки поднесли.
Вам самим придётся отсылать адреса и следить за шиной.

485 протокол и есть ваш UART переделанный и его придётся программно реализовывать.

Короче закончу свою мысль...
Разница между UART и I2C в аппаратной реализации работы шины ведущий<->ведомые!

Добавлено спустя 2 минуты 35 секунд:
EdGull
Не смогут ваши модули общаться как им захочется без программной надстройки протокола.

Да, возможно начинающему I2C кажеца сложным и ненужным. Просто я к тому - вы запаритесь реализовывать программную часть и скорее всего будут баги. А в I2C главное делать по даташиту и все. А еще лучше скачать исходники и все будет готово.

да мне так без разницы будь то спи или и2с или уарт.

Тут ща происходит путаница понятий. Есть понятие протокол, а есть понятие интерфейс.
Так вот какой протокол не примени к интерфейсу он интерфейсом и останется

Мне просто видится менее громозко в прерывании по приёму байта просто принятые байты складывать в буферок.

Код: Выделить всё

  uart_rx_buf[uart_rx_cnt] = UDR;
    uart_rx_cnt++;

    if (uart_rx_cnt == uart_buf_lenght)

    {
        пакет принят
    }

А в прерывании по передаче байта просто класть байтики из буфера в UDR.

   if (uart_tx_cnt < uart_buf_lenght)
    {
        uart_tx_cnt++;               
        UDR = uart_tx_buf[uart_tx_cnt];   
    }
    else
    {
        пакет передан
    }

В чём тут можно запариться? 4 строки кода ))...

не надо не Аков не Наков..и прочей ерунды..

Используй тэг code <Сергей>

Извини, но ты в корне не видишь суть проблемы. Больше не буду никого уговаривать, вы не хотите думать.

RoboTok писал(а):EdGull
Не смогут ваши модули общаться как им захочется без программной надстройки протокола.

обоснуй.
а то мужики-то и не знают... (с)
мужики это мои модули
щаз вот тут прямо общаются и не знают что не могут этого делать...

neiro
Данный пример реализовывает связь между ведущим(1 штука) и ведомый(1 штука) и работает отлично, пока не появляется ещё ведомый.

EdGull
Вы упустили смысл предложения, а он в "как им захочется" и "программной надстройки".
Да и полудуплекс не айс ИМХО.

ага... а i2c типа фулдуплекс...

Короче, если I2C используют, значит он нужен

Добавлено спустя 51 секунду:
Не зря же сервы именно I2C делают, а не UART переделанный...

ага... доводы убийственные...
от сюда следует, что все быстренько переходим на 51 камни, основная масса народа в мире на них программит если ты не знал...

neiro писал(а):Мне просто видится менее громозко в прерывании по приёму байта просто принятые байты складывать в буферок.

В чём тут можно запариться? 4 строки кода ))...

не надо не Аков не Наков..и прочей ерунды..

Правильно тебе заметили - в этом коде ничего не сказано про то, как объединены Tx выходы слейвов. Если тупо в кучу - надо Tx Enable щелкать у слейвов, чтобы передатчик в каждый момент был один, и все равно в случае программных ошибок рискуем попалить порты (поясняю - это произойдет тогда, когда один слейв выдаст на выход 0, а второй - 1). Для любителей 485 напомню, что у его драйвера есть еще ножка DIR, под которую надо занять еще одну ногу контроллера и ее надо довести по плате до 485 драйвера. И которой тоже надо управлять чтоб конфликтов не было. Вот это все и названо тут преимуществами I2C перед уартом - там много чего аппаратно сделано.

Справедливости ради замечу, что слейвовые Tx можно объединить через диоды Шоттки, подтянуть к + питания - и проблема выгорания портов уйдет. А вот проблема протокола с предотвращением коллизий - останется.

RoboTok, бесполезно

Мужик - это Сергей, а ослик ИА кто ?

для boez - да, ты прав. все ноги TX в одну кучу. смотри бит TransmitEnable в даташит у авр. Чет не очень се представляю как можно одной ножкой проца спалить другую))). Эт те же не русская микросхема советских времен.ну еще можно посмотреть на схематику пина чтоб это понять.

для RoboTok - ну прально. ток в конце передачи слэйва надо бит TransmitEnable сбросить в ноль. + одна строка кода