Синхронный режим USART Pic16F628A

[waddds]

Два Pic16F628A нужно состыковать как ведущий и ведомый (вообще ведущий будет один, а ведомых больше, но сейчас это неважно). С USART на практике еще не сталкивался. Вообще это будет вторая собственного производства программа. Изучил даташит в оригинале, в русском переводе, микрочиповский документ с уточнениями(исправлениями?) DS80151N. Почти все понял. Кроме некоторых моментов.
Как, все таки правильно конфигурировать ноги RB1 и RB2. Для синхронного режима в оригинале RB1 - вход, RB2 - выход. Для всех вариантов приема и передачи. Но если синхрогенератор будет работать только на ведущем? И нужно ли менять вход-выход на ноге данных при приеме и передаче? Ну никак не доходит до меня. Не могу прийти к единому мнению.
И еще. Синхроимпульсы с ведущего идут только когда TXEN = 1? Для переключения на прием от ведомого TXEN сбрасывать? BRG останется включен? Или для приема только CREN устанавливать на время ожидания посылки от ведомого? А TXEN не трогать?.
Буду рад любым разъяснениям. Особенно о настройке ног.

[Аlex]

Синхронный УАРТ, мягко говоря - извращение. Не понятно, зачем его вообще создали. УАРТ хорош именно асинхронностью.
Если нужна синхронная пердача - возьмите SPI. 1 мастер, куча слейвов. Никакого шаманства с ногами и всяческих коллизий на шине. Да и как интерфейс SPI проще намного.

PS: Чем асинхронная связь не угодила ? Кстати, несколько слейвов, которые будут отвечать мастеру - гемор с согласованием ног.

[waddds]

Мне бы с аппаратным последовательным приемопередатчиком разобраться, не говоря уже о программном SPI. Быстро не осилю, ибо чайником себя ощущаю, пока что. Синхронный режим... Тактирование от одного генератора мне подходит, в асинхронном для этого нужно ногу еще одну задействовать. А ноги нужны. А коллизии какие? Передавать в каждый момент будет только один из слейвов по запросу от мастера. Я уже и ппрограмму на си начал писать, а в виде пометок и плана действий она уже почти готова, вот только с TRISB 2-1 и с работой BRG осталось разобраться.

Добавлено after 9 minutes 53 seconds:
Я изначально хотел асинхронный использовать, адресный 9й бит там как раз кстати. А потом сравнил оба режима и в данной ситуации синхронный больше приглянулся. Может и неправ я, но хочется добить работу в этом направлении. А потом и с асинхронным попробую. И выберу оптимальный вариант. И практика не помешает. И извращений еще много, скорее всего будет, пока опыта наберусь..

[Аlex]

не говоря уже о программном SPI

Речь об аппаратном SPI, а не о программном. Хотя и программный делается элементарно, обычным ногодрыгом.

в асинхронном для этого нужно ногу еще одну задействовать.

Как раз таки и не нужно, в чём и прелесть. Синхронизация идёт по первому стартовому биту. Достаточно настроить одинаковые скорости и будет всё работать.

А коллизии какие? Передавать в каждый момент будет только один из слейвов по запросу от мастера.

Как только Вы соедините все TX'ы слейвов, получится накладочка. Передача происходит активным нулевым уровнем, а на остальных будет высокий уровень. Можно, конечно, развязать всякими диодами или транзисторами, сделав OD, но это всё - доп. детали.

адресный 9й бит там как раз кстати.

Не нужно этого всего. Протокол Вы можете изобрести собственный, в котором 1 байт отведёте под адресацию.

[waddds]

Так в 628 вроде бы нет аппаратного SPI илия чего то не понимаю?
Вместо продвижения вперед еще больше запутался... Програмно изобретать могу не осилить.
А насчет накладки... Получается, что один из слейвов передает, а остальные на этой же линии сидят на приеме и могут эту передачу принимать? В этом накладка?
То есть все таки асинхронный режим придется использовать?
Но вопрос с конфигурацией ног на вход-выход остается открытым... Или по логике прием -вход, передача - выход?

[Аlex]

Так в 628 вроде бы нет аппаратного SPI илия чего то не понимаю?

Да, прошу прощения, ввёл в заблуждение.
Не привык, что в МК нет этого интерфейса. 628-ые юзал достаточно давно

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

Нет. Получается, что при передаче одним из узлов, будет КЗ на линии TX. На остальных то там висит 5V. А передающий просаживает до 0. Их нельзя просто тупо параллелить.

То есть все таки асинхронный режим придется использовать?

Попробуйте начать именно с него.
А ноги сконфигурируются один раз и просто - TX на выход, RX на вход. И всё.

[waddds]

Ладно, буду пробовать асинхронный режим.
А насчет езды попробую поспорить. Там же не напрямую 5В. Через резисторы , насколько я знаю? Ну а ноль да, через сток транзистора на минус?

[Аlex]

Через какие резисторы ? На выходном каскаде PIC'а 2 транзистора - один к плюсу прижимает (лог. 1), второй к минусу (лог.0). Оба закрыты - Z-состояние.

[waddds]

Ну в запишите так вроде нарисовано порты, я считал, что это не полная схема.. А как же тогда программные резисторы включаются на 5В на порт В?

[Аlex]

А причём тут подтягивающие сопротивления ? У УАРТа выхода не OD. Подтяжка не нужна.

[waddds]

То есть передача идет не через стандартный выход порта?

[Аlex]

Что значит "стандартный" ? Передача идёт с ноги TX.
Вы меня пугаете своими вопросами

[КРАМ]

waddds писал(а):

То есть передача идет не через стандартный выход порта?

Стандартный.
Стандартный выход - пуш/пул. То есть у него работают оба транзистора. Если СПЕЦИАЛЬНО настроить порт как открытый сток и СПЕЦИАЛЬНО включить подтяжку, то работать будет только НИЖНИЙ N-канальный транзистор порта, а верхний будет всегда закрыт. Но при работе УАРТа порт работает в пушпульном режиме.
ЗЫ. Вы изобретаете деревянный велосипед с квадратными колесами. Мультимастерный протокол нужен в очень редких случаях.
Опишите свою задачу.

[dosikus]

Не скажу за "Мультимастерный протокол", но у меня UART работает в Single-wire Half-duplex communications на один пин в OD на 1wire .
Правда это не пЫк...

[КРАМ]

waddds писал(а):

Два Pic16F628A нужно состыковать как ведущий и ведомый (вообще ведущий будет один, а ведомых больше, но сейчас это неважно).

А так 1Wire и способ его реализации на UART не обсуждался.

[waddds]

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

[Аlex]

Может немного не в тему, но если нужно толко опрашивать входа, без их обработки перед передачей, то стоит посмотреть в сторону специально предназначенных для этого микросхем.
А так - UART, с развязанными TX'ами. Простой вариант - диоды. Делается всё элементарно. Всё у Вас получится

[КРАМ]

Ну, превосходно.
В пределах ОДНОЙ платы можете соединить Tx мастера со всеми Rx слейвов. А все Tx слейвов с Rx мастера. Все слейвы держат свои пины Tx В ТРЕТЬЕМ СОСТОЯНИИ. В протоколе обмена должен содержаться адрес слейва в пакете от мастера к слейвам. Если задействовать 9 битный режим обмена, то старший 9 бит можно сделать ПРИЗНАКОМ адресного байта. В этом адресном байте мастер выставляет адрес слейва, для которого будет выдан последуюший за адресным байтом пакет. Все слейвы парсят ВЕСЬ входящий поток от мастера, но ответит только тот слейв, чей адрес предшествовал пакету. Отвечающий слейв переводит пин своего Tx в активное состояние и передает ответ. Затем снова переводит пин в третье состояние. Так и происходит обмен. Мастер по кругу опрашивает слейвы и они по кругу ему отвечают Никаких коллизий на шине.
Если речь идет о связи с удаленными МК, то напрямую с МК работать нельзя. Нужны приемопередатчики. Либо RS232, либо RS422/485.

[Аlex]

Хорошая, кстати, идея рулить третьим состоянием. Только бы ТС не запутался
И ещё. На всякий случай повесить потдтяжечку к плюсу. Чтобы не было лишних нулевых уровней, когда все слейвы будут в режиме ожидания (иметь Z-состояние).

[КРАМ]

Аlex писал(а):

На всякий случай повесить потдтяжечку к плюсу.

Не на всякий случай, а ОБЯЗАТЕЛЬНО. Иначе будет дикий геморрой на приеме у мастера. Висящая шина без подтяжки будет генерировать всякую пустопорожнюю шнягу в направлении мастера, что вызовет серьезные проблемы с данными, особенно в зазоре между запросом мастера и ответом слейва.
А в дифшине RS485 это должна быть растяжка дифпары в пассивный уровень шины.