Данные у меня передаются на одной плате - нужно передавать данные между МК.
Если по 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 обычный выход