USART - интересно мнение специалистов! Опции

[James D.]

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

[MicronSys]

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

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

[iosifk]

...
Стоит задача связать линией приема-передачи две м32 и одну м16. ...
Если можно, подскажите, где можно найти примеры программ приема-передачи по USART на асме.

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

[MicronSys]

...
Стоит задача связать линией приема-передачи две м32 и одну м16. ...
Если можно, подскажите, где можно найти примеры программ приема-передачи по USART на асме.

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

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

[m16]

Намучавшись с TWI, я обратил свой взор на USART. .............
....... TWI с этой задачей почему-то не справился.

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

При передаче с мастера м32 на слэйв м32 я поубирал команды STOP у обоих МК - работает, как ни в чем не бывало!
А с м16 полный ступор. И со STOP'ом и без оного...

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

[James D.]

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

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

[rat]

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

[MicronSys]

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

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

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

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

[James D.]

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

[Rash]

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

Прикрепленные файлы

 UART_test.zip ( 30.91 килобайт ) Кол-во скачиваний: 76

 

[James D.]

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

[prottoss]

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

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

[KRS]

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

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

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

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

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

[prottoss]

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

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

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

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



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

[JeDay]

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

[James D.]

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

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

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

[prottoss]

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

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

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

[James D.]

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

[James D.]

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

[prottoss]

Раз уж затронули эту тему, то есть вопрос по 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. Ведущий МК получает команду , второй ведомый МК опять ждет...

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

[James D.]

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

[KRS]

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

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

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

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



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

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

[prottoss]

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

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

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

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

[KRS]

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

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

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

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

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

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

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

[Rash]

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

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

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

[KRS]

А чего нельзя использовать 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

[iosifk]

Стоит задача связать линией приема-передачи две м32 и одну м16. TWI с этой задачей почему-то не справился.
Если можно, подскажите, где можно найти примеры программ приема-передачи по USART на асме.

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

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

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

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

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

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

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

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


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

[prottoss]

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

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

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

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

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

[Rash]

Вообще есть Multi-processor Communication Mode
используется 9 бит для адресации и контроллер будет частично аппартно фильтровать данные
Но тут вопрос в подключении, просто так три UARTA на одну линию не подсоеденить нужны еще микросхемы типа драйвера 485

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

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

Вообще есть Multi-processor Communication Mode
используется 9 бит для адресации и контроллер будет частично аппартно фильтровать данные
Но тут вопрос в подключении, просто так три UARTA на одну линию не подсоеденить нужны еще микросхемы типа драйвера 485

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

Прикрепленные файлы

 M_2S.zip ( 2.47 килобайт ) Кол-во скачиваний: 40

 

[KRS]

Вообще есть Multi-processor Communication Mode
используется 9 бит для адресации и контроллер будет частично аппартно фильтровать данные
Но тут вопрос в подключении, просто так три UARTA на одну линию не подсоеденить нужны еще микросхемы типа драйвера 485

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

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

Вообще есть Multi-processor Communication Mode
используется 9 бит для адресации и контроллер будет частично аппартно фильтровать данные
Но тут вопрос в подключении, просто так три UARTA на одну линию не подсоеденить нужны еще микросхемы типа драйвера 485

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

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

[Rash]

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

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

[KRS]

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

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

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

[IEC]

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

[Miron]

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

[James D.]

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

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

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

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

Сообщение отредактировал James D. - Nov 24 2005, 12:21

[James D.]

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

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

[prottoss]

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

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

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

[James D.]

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

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

[Rash]

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

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

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

[prottoss]

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

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

[James D.]

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

[vm1]

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

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

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

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

[Rash]

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

[m16]

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

в конце линии

[Rash]

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

в конце линии

Код

Расположение такое:

  |---------------------------Mega
  |                            (x)|------------------------------|
  |                               |                              |
1-ый резистор              2-ой резистор                    3-ий резистор

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

[m16]

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

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

[Митрофан]

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

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

[IEC]

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

[Trollix]

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

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

[James D.]

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

[prottoss]

Мне, для моей задачи нужно 8 раздельных каналов ШИМ + часы реального времени + вывод на LCD.

8 ШИМ не проще ли реализовать на ПЛИС? А для всего остального с лихвой хватит и одного МК AVR... тем более, что на ПЛИС можно реализовать более удобный (для своих нужд) ШИМ

[Trollix]

Полностью поддерживаю.
Все гораздо проще получится, если добавите к какой-нибудь средненькой меге одну мелкую CPLD-шку от Altera (типа 3000-й серии) или Xilinx (что-то типа xc95xx), которая займется тем, что неуклюже выходит у контроллеров - битовыми потоками/управлением с жесткими требованиями по времени/диаграмме.
Если Вы еще не сталкивались с этой областью - очень рекомендую начать-попробовать: пальчики оближешь, потом с ушами не оторвешь Там на самом деле все просто.

[James D.]

А-а, правильно... Но это, когда под рукой все необходимые микрухи есть + документация (на русском).
А, если всего этого нет? Если за какой-то паршивой мегой надо в областной центр ехать, и то только в воскресенье, когда там рынок.
Если рядом нет никого, кто бы помог в трудной ситуации?
Если вся документация в инете, и для того, чтобы во всем этом разобраться надо миллионером быть. Траффик-то не резиновый.
Вобщем, одиночке во всем этом разобраться ой как нелегко.

Сообщение отредактировал James D. - Dec 2 2005, 11:39

[Trollix]

По поводу младших Altera/Xilinx есть книжки (www.findbook.ru) на русском - как правило, переводы даташитов. В Инете тоже все это есть, отыскивается легко. Были и нормальные книжки (как минимум, одна) - мне помогла начать книжка Антонова "Altera HDL".
Спрашивать по этой теме лучше в соседней ветке.

[prottoss]

А-а, правильно... Но это, когда под рукой все необходимые микрухи есть + документация (на русском).
А, если всего этого нет? Если за какой-то паршивой мегой надо в областной центр ехать, и то только в воскресенье, когда там рынок.
Если рядом нет никого, кто бы помог в трудной ситуации?
Если вся документация в инете, и для того, чтобы во всем этом разобраться надо миллионером быть. Траффик-то не резиновый.
Вобщем, одиночке во всем этом разобраться ой как нелегко.

У меня в городе тоже не все есть, что москвичам можно купить через пять минут. Но зачем ехать в областной центр? Можно все заказать по Интеренту в тех же московских магазинах по почте, если быстрее надо - то по экспресс-почте.До моей Сибири за четыре-пять дней доходит да и доставка прям домой. Залез на eFind.ru или еще куда, набрал нужный компонент и выбирай, у кого дешевле. Хоть опотом хоть в розницу, если не какой нибудь экзотичекий девайс. ПЛИС полным полно. Доки в сети навалом. Надо только поисковиком пользоваться умеючи.

По поводу пользования сети - не пробовали через GPRS? Т.е. через мобильный телефон. Дешево и сердито. Если отключить картинки и прочую лабуду, а пользоваться только текстовой информацией то 10$ в месяц достаточно. Я и сейчас, когда проблемы с выделенкой или еще какие то катаклизмы, пользую своего "мобильного друга"

[kolobok0]

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

Чтоб связать более двух последовательных портов по шинной топологии - нуна на логике сделать следующую байду...
1) каждый передатчик соединяеться со всеми приёмниками, кроме своего. Надеюсь схем урисовать не требуеться ?
2) выводите режим работы ком портом МК с 9 битом для детекции адреса...В доках - как грязи примеров и описания.

далее дело техники, вкуса и опыта...

с уважением
(круглый)

[James D.]

По поводу пользования сети - не пробовали через GPRS?

prottoss, не могли бы Вы поподробнее рассказать: как через GPRS можно Инетом пользоваться? Я в этом полный чайник. Как мобильник к компу подсоединить? Какой мобильник подешевле, можно для этого применить?
Вобщем, пожалуйста, опишите весь процесс.
Спасибо.

[prottoss]

По поводу пользования сети - не пробовали через GPRS?

prottoss, не могли бы Вы поподробнее рассказать: как через GPRS можно Инетом пользоваться? Я в этом полный чайник. Как мобильник к компу подсоединить? Какой мобильник подешевле, можно для этого применить?
Вобщем, пожалуйста, опишите весь процесс.
Спасибо.

1.Раз Вы пишите в этот форум, значит доступ к сети у Вас есть. Поэтому узнать, что такое GPRS я думаю Вы сможете и на сайтах GSM-операторов, которые такую услугу предоставляют, у них же и узнаете тарифы. А о Интернете через GPRS в сети навалом информации.

2.Я не торгую мобильными телефонами и не провожу маркетинговые исследования, по этому я не знаю, какой мобильник подешевле, а какой получше в плане пользования GPRS. Я пользуюсь тем, который мне понравился в магазине - NOKIA 5140. Связываю я телефон через ИК-порт, при этом телефон определяется как модем 115200бод. Скорость конечно намного меньше, но по крайней мере, можно проверить почту и пообщаться в форумах.

3. У этого форума немного другая тематика, поэтому давайте не будем про пользование мобильной связи.

[James D.]

Спасибо за информацию.
Теперь имею направление в котором надо искать.

[defunct]

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

И что же 3 меги у вас будут с этими камерами делать?
Если управлять поворотными шаговиками и выводить на LCD состояние камер - тогда достаточно одной меги. На что-либо большее трех мег не хватит. Так что imho овчинка выделки не стоит.

[defunct]

По поводу пользования сети - не пробовали через GPRS?

prottoss, не могли бы Вы поподробнее рассказать: как через GPRS можно Инетом пользоваться? Я в этом полный чайник. Как мобильник к компу подсоединить? Какой мобильник подешевле, можно для этого применить?
Вобщем, пожалуйста, опишите весь процесс.
Спасибо.

Со стороны МК.
GPRS обеспечит вам IP линк, следовательно вам надо реализовать или купить стек TCP/IP либо UDP/IP (UDP проще) для AVR. чтобы воспользоваться этим стеком потребуется воспользоваться одним из двух путей:
1. прикрутить к AVR - Ethernet PHY/MAC, например CS8900;
2. реализовать PPP/SLIP на базе уарта.
В общем работы тут много. Могу только сказать что AVR'a более чем хватает для обслуживания TCP/IP в обоих из приведенных путей.

Со стороны компа.
По поводу ваших вопросов - практически любой моб телефон обладает втроенным модемом, соответственно практически любой моб телефон может обеспечить связь по GPRS. Для этого достаточно любым способом подключить телефон к компьютеру - через COM, USB или IRDA порт. Далее установить драйвер модема (в большинстве случаев хватает стандартного драйвера WinXP) и создать соединение по номеру *99***1#. Подробности подключения лучше ищите на сайте мобильного оператора. Цены на мобильники "подешевле" тактичней спрашивать на барахолке, а не на этом форуме, здесь люди AVR обсуждают.