Намучавшись с TWI, я обратил свой взор на USART. Изучаю даташит.
Было бы интересно узнать по этому поводу мнение работавших с обоими интерфейсами.
Если провести сравнительный анализ, какая из этих систем более удобна и надежна в работе?
Стоит задача связать линией приема-передачи две м32 и одну м16. TWI с этой задачей почему-то не справился.
Если можно, подскажите, где можно найти примеры программ приема-передачи по USART на асме.
Спасибо.

http://gaw.ru/html.cgi/txt/app/micros/avr/index.htm
Здесь смотри

Если линия связи небольшая ( 1 - 3 м ) можно сделать RS232 ( MAX232)
Ну а если больше то RS485 ( MAX485)

Есть интерфейс LIN, базирующийся на передаче по UART.
У меня есть полные драйвера для 78К и V850. Но там все подробно расписано.
Трансиверы LIN тоже сейчас доступны. А сама сеть "сигнальный+земля" - очень простая.
Удачи.

Тоже хорошо но тогда уже надо программно LIN делать
Зачем ставить еще микрухи те паче ATMEL сделал программную реализацию LIN

????????? не удосужившись разобраться с протоколом обмена и писать программу методом научного тыка . С таким подходом коллега у Вас ни один интерфейс с задачами справляться не будет.Есть проект (не мой) в котором на TWI три проца сидят с распределенными приоритетами и прекрасно общаются. имхо Вам IgorKossak правильно указал.Удачи

To m16.
Ну да, видел я разные фразы на форумах, типа: "Есть проект (не мой) в котором на TWI три проца ... прекрасно общаются", "Слыхал, что TWI очень хорошо использовать для обмена между МК, причем без дополн. микрух", "Говорят, что TWI - прекрасный интерфейс, но сам не пробовал" и т.д. и т.п.
IgorKossak правильно говорил, не спорю, просто, отчаявшись, я уже перебирал разные варианты, и этот в том числе. Как эксперимент.
Но толком мне никто ничего не сказал, код рабочий, как пример не привел. Нет, я, конечно же, ничего не требовал (ни в коем случае!), просто просил мне помочь, но... Вот и получается: "????????? не удосужившись разобраться с протоколом обмена..." Я даташит по TWI чуть ли не наизусть выучил, пробовал исправить прогу и так, и эдак, все согласно инструкции. Не вышло. Может быть упустил какой-то нюанс... Не знаю.

Вернемся к USART.
Три МК стоят на одной плате, расстояние - несколько см. Можно ли их соединить напрямую, без дополнительных микросхем? Соединение: RxD идет на TxD и наоборот. Нужны ли подтяг. резисторы и настройка соответствующих линий портов В/В?

Связывал два 51(атмеловских) без дополнительных микросхем и подтягивающих резисторов. На расстоянии около 1м на 9600 все нормально работало. Но тут 3 контроллера - И2Ц может?

Да можно соеденить
А делал VideoSwitch было два блока
1- клава на 64 клавиши
2- блок сам Switch

растояние было 2 м провод 4-х жилы телефонный

порты настроивать не надо просто инициализ. USART и вперед !!!!

Резисторы и т.д. и т.п. не надо!!!

А, может быть, поделитесь примером кода на асме для приемника и передатчика?

кода то баловался, может поможет. Проект AVR Studio 3.21. Вобщем в даташитах на мнги есть примеры использования UART, и аплекейшенов на их сайте куча, а примеров вооще до фига по инету темболее на асме.

Спасибо за помощь.

Если все стоит на одной плате, почему не использовать SPI? Скорость на много выше, чем USART, да и настроек меньше...

если кварцы одинаковые можно и UART разогнать не обязательно же использовать стандартные баудрейты! UART удобнее тем чтоон дуплексный (если точка точка)

Вот точка точка можно без микросхем соеденить! А вот 3 устройства на один провод не повесить.

Нужно или 2 UART или можно одно соеденение UART второе SPI

Здесь как раз речь идет о трех устройствах.



К тому же на SPI все равно быстрее. При 16 Мгц тактовой частоты 8Мбит/с на SPI против 2Мбит/с у USART

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

Данные у меня передаются на одной плате - нужно передавать данные между МК.
Если по USART 3 МК не соединить, это плохо однако!
Два у меня общаются по TWI, но как только пытаюсь передать на третий, идет сбой.



Минуточку! Если я все 3 проца соединю по SPI, то как я их прошивать-то буду? Одна прога будет шиться во все три проца сразу! Или я чего-то не понял? Объясните.

Я не пойму, Вы создаете устройство для того чтобы постоянно шить процы :-). Вообще SPI в большенстве случаев служит для более благородных целей. А программирование через этот интерфейс - это уже вспомогательная фишка. С таким же успехом ATMEL могла бы поставит блок последовательного программирования на USART. А решить проблему можно (если у Вас устройство собрано на макетной плате с помощью джамперов и нескольких резисторов).

Вот Вам с ходу: на все пины SPI всех трех МК вешаете резисторы 470 ОМ последовательно с соответствующей линией SPI. К точке соединения трех резисторов соответствующей линии SPI прицепляете соответсвующую же линию программатора SPI. В разрыв RESET каждого МК ставите джампер. Сам RESET каждого МК подтягиваете к питанию через резистор 4,7 - 10 ком. Все. Какой МК будете программировать, тот джампер на ресете и замыкайте.

Ага, ну я так и думал вообще-то. Ну ладно, спасибо за совет.

Раз уж затронули эту тему, то есть вопрос по SPI.
Допустим, я соединил 3 МК (MISO, MOSI, SCK) параллельно. На шине мастер один - мега 32, и два подчиненных - м32 и м16.
Работать должно так:
1. мастер м32 передает данные на слэйв м32.
2. мастер м32 передает данные на слэйв м32.
3. мастер м32 передает данные на слэйв м16.
4. мастер м32 принимает данные от слэйв м16.
Далее п. 2, 3 и 4 повторяются по кольцу.
В описании SPI не нашел процедуры адресации контроллера, на который идет передача.
Можно ли это как-то осуществить?

Аппаратной адресации в SPI нет, за исключением вывода SS, который может использоваться как вход выбора ведомого контроллера. Но для этого надо задейстовать лишние выводы контроллеров, которых всегда не хватает. Лучше всего реализовать протокол обмена программно. Кстати если бы Вы использовали USART? Вам тоже бы понадобилась програмная реализация протокола обмена.

Простейший пример реализации протокола:

1.ведомые МК ждут активности на шине SPI

2.ведущий МК выдает байт номера устройства на шине и, затем, байт команды.

3.оба ведомых МК принимают сначала номер устройства, после чего тот ведомый МК, номер которого совпал с ему присвоенным, принимает команду и начинает ее обрабатывать. Второй МК и ведущий ждут активности на шине.

4.ведомый МК после обработки команды посылает номер устройства "ВЕДУЩИЙ" и ответную команду.

5. Ведущий МК получает команду , второй ведомый МК опять ждет...

Вобще любой протокол можно придумать самому.

Ясно. Получается, для соединения нескольких МК реально лучше всего использовать именно TWI. А у меня с ним проблемы... Ну ёлки-палки!

8 Мбит получится только у мастера! У слэйва минимальный прескалер 4.
И еще слэйв должен успевать подготавливать данные.

Где Вы вычитали, что у слэйва минимальный прескалер 4? Не знал об этом, если это так на самом деле.

Re:И еще слэйв должен успевать подготавливать данные

А что USART или TWI сам данные готовит? :-)

Во всех даташитах написано, где описывается бит SPI2X

Если использовать UART, то передача байта не зависит от приема. в SPI и TWI же надо успеть запихать байт вовремя.

Хотя в TWI некоторые контроллеры придерживают SCL пока не подготовлен байт, но реализация мастера часто это игнорирует и пявляются ошибки. последний раз в Power PC с этим столкнулись

А чего нельзя использовать USART на три устройства я не понял. Организуй протокол например такой
1 способ:
@AA DATA 0D.
@ - системный символ
AA - адрес устройства
DATA - данные
0D - 0x0D - символ в конца даных (в ASCII - '\r')
единственное ограничение всё байты должны быть ASCII символами.
Так работают промышленные модули ввода/вывода типа ICOS, ADAM и т.д, только по RS485.

2 способ:
Команды: 01 OpCode Число байт Параметры
Даные: 02 Число байт Данные
Ответ: 04 Ответ Число байт OpCode(посланной ком.) Параметры
где OpCode может быть адресом + код команды (так работают BlueTooth модули)

это самое простое, а протокол дело вкуса.

Вообще есть Multi-processor Communication Mode
используется 9 бит для адресации и контроллер будет частично аппартно фильтровать данные

Но тут вопрос в подключении, просто так три UARTA на одну линию не подсоеденить нужны еще микросхемы типа драйвера 485

Извините меня, но эта переписка напоминает известную историю:
"все хорошо, только Жучка померла...
Мяса объелась...
Конюшня сгорела...
полковое знамя..."

Давайте с самого начала определим то, что Вы хотите.
Вы хотите сеть! 3 абонента. Это уже понятно.

Топология сети бывает
1. Точка - точка. Для этого у одного из абонентов должно быть два!!! порта.
2. кольцо - здесь все понятно. Требует повышенного ресурса на трансляцию "чужих пакетов"
3. шина - требует физич согласования с портами или спец управления.

Физически как расположено - тут Вы сказали. Уже хорошо.

Далее.
1. данные идут потоком. что получили то, например запомнили или переслали. здесь все просто.
2. данные идут кадрами. Например команды. Сразу вопрос: как формируется признак начала кадра. В системе MCS51 для этого использовали бит четности в посылке по UARTу. В LIN - паузу специальной длительности. В I2C можно использовать один из адресов. У SPI есть только аппаратный выбор слэйва. Признак начала кадра надо формировать отдельно. Либо битом порта, либо кодированиеем данных, а это понижение скорости передачи и доп затраты процессорного времени.
Укладываются ли ваши данные в эти кадры? Сколько данных в кадре? Защита от ошибок? Как начало кадра отличается от данных. Если слэйв пропустил начало кадра, то что должно произойти? Как проверяется то, что команда получена? Перезапросы? Сообщения о правильном/неправильном приеме.

Далее.
Сеть с одним мастером или со множеством мастеров? Есть ли передача эстафеты? Арбитраж? Коллиззии?

В чем типичная ошибка?
НИКОГДА не пытайтесь спроектировать систему "начиная от гайки". Это только кажется что в начале все очень просто. Заканчивается ВСЕГДА полохо или ОЧЕНЬ ПЛОХО.
Настоящий путь - проектирование от ЗАДАЧИ. Всегда тяжелое начало, но потом кончается работающим проектом.

Попробуйте "нарисовать поле дураков" (раньше это называлось ТехЗадание).
Вот примерно так. Составьте себе задание. Распишите ВСЕ диаграммы обмена сообщениями. Определите бюджет времени. Проверьте, что ядро операционной системы может обслужить столько прерываний. Отсюда получите пребуемую скорость обмена. Определите как будут формироваться кадры, соответственно выберите протокол обмена, порт обмена. Линии связи. И только потом ассемблер.
К этому момент Вы уже будете знать круг задач, которые Вам надо запрограммировать.
Посмотрите то, как строятся сетевые интерфейсы. Не физический уровень, а обмен сообщениями. Там уже расписано как и куда передавать. Как обрабатывать ошибки и т.д....
А все, что тут предлагается сможет только подтолкнуть Вас к ответу. Поскольку задача НЕ ОПРЕДЕЛЕНА ПОЛНОСТЬЮ, то и опветы самые разнообразные...


Вот пока все.
Удачи!

Да я не спорю по этому поводу, хоть по 1-wire соединяй, дело вкуса, времени и, самое главное, требований к машинному времени.

Но все же мое мнение, что SPI лучше по временным характеристикам и простоте использования, нежели другие вышеперечисленные интерфейсы. Даже при 4Мбит/с SPI выигрывает по скорости и, в некоторых случаях, по объему кода. У USART кроме служебной информации в кадре передаются еще старт-бит и стоп-бит минимально. Вообще RS-*** разрабатывался для передачи на большие расстояния. А вот TWI и SPI как раз для общения по одной плате между чипами

Вот та нельзя?

RxD -----\ RxD1 ----|
Master \ | Slave1
|--TxD \-------- TxD1 |
| \ |
| \ RxD2 --|
| \ | Slave2
| \--- TxD2 |
|---------------------------------|



Вот та нельзя?
P.S. см. файл

Неа так нельзя дело в том что это у TWI open drain выход а у UART обычный выход

ну значит надо поставить пару транзюков (лишнее место на плате конечно), если хочется иметь UART, а не TWI.

Еще не совсем понятно как общаются контроллеры

например если нужно два логических соеденения например 1 контроллер общается со 2 (точка точка) и с 3 (точка точка) то тут можно использовать USART для одного соеденения и SPI для второго

елси все три обящются между собой то самое просто использовать TWI, можно даже и мастера шины менять в TWI это предусмотрено.

Вопрос по существу: На данной шине какая приоритетность обмена?
Т.Е. сколько мастеров (инициаторов обмена)? Если один, тогда можно и UART. Там есть режим многопроцессорного обмена и ведущий может обращаться к ведомым путем указания его прядкового номера. У меня в проэкте есть один ведущий и 10 ведумых - все работает великолепно. При большем количестве мастеров возникнет усложнение алгоритма обмена. По поводу TWI (уж очень он смахивает на I2C) сам не разбирался, но там должна быть по протоколу предусмотрена процедура обмена с разными устройствами, находящимися на одной шине. Скорее всего упустили какой-нибудь ньюанс.

Задача на USART вполне решаемая если у вас один мастер в линии соединял так до 8 МК с реализацией мультипроцессорного режима причем стояли вперемешку 51 камни и AVR

Попробовал работать со SPI. Ввел простую прогу передачи (без прерываний) из даташита в один МК, два других стер.
Так вот, этот мастер-передатчик говорит, что передача прошла. Теперь вопрос - куда? Если кроме него на шине никого нет.
В TWI по-другому: если передачи нет - стоит и ждет, вплоть до зависания.
В чем тут дело?

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

P.S. Ради интереса пробую разные интерфейсы связи, т.к. опыта работы с ними нет. Пока что TWI показал лучшие результаты по сравнению с другими. Но у меня получается надежно передавать данные только между двумя МК (в одну сторону: м32->м32), как только пытаюсь передать на третий (м32->м16) - передача не идет...

P.P.S. Ёлки-палки, у всех связь нескольких МК работает, а у меня нет! Хоть и делаю все по правилам. Я бы с удовольствием использовал TWI, но что-то не идет. А где ошибка не найду.

Моя тема, посвященная мучениям с TWI: http://forum.electronix.ru/index.php?showtopic=9473

Если кто-то может реально помочь, очень прошу - напишите. Если надо, предоставлю свои программы.

SPI отличается от TWI. В нем нет ни каких аппаратных примочек, определяющих, прошла передача или нет. Если мастер выплюнул на шину MOSI (Master Output - Slave Input) байт данных, все слэйвы на шине MOSI приняли в регистр данных SPI байт от мастера, при этом, одновременно, при передаче мастера, все слэйвы выплюнут по шине MISO (Master Input - Slave Output) байт из своего регистра данных SPI, если у них на выводе SS присутствует лог. 0. Это если задействовать SS, что требует от мастера выделения двух портов IO для двух слэйвов. Можно эти линии (SS) и не использовать. Я говорил Вам выше о подключении через резисторы 470 Ом, так вот они как раз и пригодятся. О возможном алгоритме протокола по SPI я говорил Вам выше.

Вообще лучше досконально изучить интерфейс самому, прежде чем его использовать. Кстати, прислушайтесь к тому что сказал Вам IgorKossak...

Остается только программно реализовать определение успешного прохода передачи.
Это касается и USART - он тоже никак не определяет, принял слэйв данные или нет.
Можно сделать так (USART):
1. Мастер выдает байт на шину, и сразу же переключается на прием.
2. Слэйв принял байт (сохранил), переключается на передачу, отсылает принятый байт мастеру, переключается на прием и ждет следующий байт.
3. Мастер, приняв байт от слэйв, берет следующий байт, отправляет, переключается на прием и т.д.
Или так: 3. Мастер, приняв байт от слэйв, сравнивает принятый байт с отправленным, если совпадают - отправляет следующий, иначе выдает сигнал ошибки, и опять выдает тот же байт.

Правильно будет так сделать или нет?

USART дуплексный зачём его переключать на приём и передачу, посмотри мои предыдущие посты (они на второй странице), вроде там есть нормальный протокол как сделать (я не настаиваю так совет)

При двух слэйвах реализовать дуплексность USART на этих слэйвах проблематично, хотя можно. Кому то из них придется отключаться от линии TxD, таким образом приняв первый байт (адрес слэйва), он (слэйв) должен будет определить его это адрес или нет. Если не его, он отключает линию TxD, если его, делает что то осмысленное, и передает ОК по TxD

Так я же о чем говорю: мастер-передатчик передает данные не глядя - принял их приемник или нет. А приемник ждет данных, и пока они не поступят, ему некуда деваться. Поэтому, для того, чтобы передатчик передавал данные более осмысленно, его нужно постоянно переводить в режим приема, т.е. гонять байты данных от мастера к слэйву и обратно.
Вопрос адресации решил простейшим способом - от мастера идут две линии к слэйв1 и 2. На который надо передавать данные, та линия сбрасывается в "0". Не так изящно, конечно, как хотелось бы, но пока пусть будет так.

Можно поставить в TXD транзисторы, как справедливо упоминали выше,
а можно просто диоды шотки.
Так как обычно обмен идет в порядке запрос-ответ,
то достаточно полудуплексного режима,
поэтому TXD и RXD всех процессоров
можно объеденить общим проводом подключенным через резистор к питанию.
Только необходимо на отвечающей стороне обеспечить задержку не менее 0.5бита,
обычно это не проблема, такую задержку дает программа подготавливающая ответ.

UART применять удобнее чем SPI так как он имеет буферизацию и возможность
выделения заголовка с помощью 9 бита.
Бывают варианты UARTов с синхронизацией 1:8 и даже 1:1 если от внешнего источника.
Так что скорости UARTов могут быть достаточно высокими
и если программа еще чем то занимается кроме обмена
SPI может не дать выигрыша в скорости.
Что толку от скоростей SPI если полученные данные
программа не успеет забрать из за отсутствия буферизации.

Вопрос к TWI спецам, на плате резисторы подтяжки (4.7кОм) где лучьше ставить, ближе к Mege, в конце линии или всё равно? У меня три устройства (цифровые потенциометры), можно сказать расиданы на плате в разных местах, по TWI связаны, а между ними AT mega.

в конце линии

(x) - где сейчас стоят резюки.
И где оптимальней?

на коце более длинной линии от меги

Для связи нескольких процев с uart интерфейсом попробуй объединить их в кольцо посредством малых схем сопряжения уровня.Такой способ позволяет также совмещать процы разных производителей и использовать большое количество.Правда после 15 сеть начинает давать ошибки,поэтому надо будет снижать скорость передачи и кварцы подбирать.Реально сейчас работает у меня на работе сеть из двух atmel'ов мега 8535 и s2313 и шести промышленных контроллеров РеМиКонт130,работающих по ИРПС.Скорость 9600,но этого достаточно.

кстати,использую Алгоритм Билдер 4.7 для создания прог и Унипроф для записи/чтения процев.Закидываю через LPT.Надо ли кому?

Поо поводу зависания TWI: вероятно нет подтверждения приема байта (по I2c после каждого байта в последнем такте приемник должен установить подтверждение). Кроме этого по протоколу должен производиться орбитраж по скорости двух устройств. Т.Е. оба общаться будут на скорости медленного.
По поводу USART: связать можно сколько линия потянет, и адресовать так-же. И от линии отключаться в физическом плане не надо. Фишка в девятом бите. Слейвы все настраиваются на прием байта с девятым битом в 1. Если адрес переданный в этом байте не соответствуюет устройству, он ждет следующего. Если адрес его - ожидает приема байт со сброшенным девятым битом. Это реализовано на аппаратном уровне. Дальше байты для данного устройства передаются со сброшенным девятым битом. После окончания передачи желательно от устройства получить подтверждение приема. И все сначала. Нет там ничего сложного!!

ИМХО, наилучшее решение в этом случае - все три МК объединить в один-единственный, взяв кристалл помощнее. Сразу уйдут в небытие большинство коммуникационных гемороев между задачами, отладка упростится на порядок, срок разработки также сильно сократится

Мне, для моей задачи нужно 8 раздельных каналов ШИМ + часы реального времени + вывод на LCD. Стоит задача сделать систему наблюдения для 8-ми охранных телекамер. Задача пока в стадии осмысления, стройный алгоритм не готов, просто решил сначала разобраться, как я смогу реализовать это все на трех МК - нужна будет передача данных (синхронизация).
Если бы можно было это все сделать на одном МК, разве б я заморачивался с этими интерфейсами связи? Да ни в коем разе!
Можно было бы использовать ATmega1281/2561 ну, или ATmega640/1280/2560, но их вроде бы еще нет в продаже...