Коммуникация между двумя ATmega640, Выбор конфигурации. Опции

[Dikoy]

Есть плата с двумя мега640 (схема резервирования).
Думаю как лучше организовать межчиповую связь.
Девайс в металле, схему коннекта между чипами прилагаю.

http://s017.radikal.ru/i414/1207/53/5d906e6272a7.gif (25 кБ)

Между чипами идёт SPI, I2C и две дополнительные дороги, которые можно использовать для контроля.
На и2ц висит ещё барометр, который должен читаться первым чипом.
Лапы MOSI/MISO имеют вывод на джамперы и я могу соединить их как хочу. На схеме показано соединение по умолчанию.

Итак. Надо гонять данные между камнями, причём траффик от второго к первому ощутимо больше, чем наоборот. Раз так в 1000. Фактически, первый запрашивает у второго отчёт, второй отчитывается. Так и живут.

Изначально я думал сделать жёстко. От первого ко второму по I2C (за одно и барометр читать). От второго к первому по SPI. Никаких коллизий, всё чётко.

Сейчас лезут мысли про мультимастерный SPI и прочие изыски.

Что скажет купечество? Принимаю идеи, критику и просто добрые слова

Сообщение отредактировал Dikoy - Jul 18 2012, 21:14

[_Артём_]

Изначально я думал сделать жёстко. От первого ко второму по I2C (за одно и барометр читать). От второго к первому по SPI. Никаких коллизий, всё чётко.

Нормальный вариант.

Сейчас лезут мысли про мультимастерный SPI и прочие изыски.

Зачем такой огород городить? Ещё и мультимастерный.

[Dikoy]

У I2C громоздкое прерывание. Даже не смотря на то, что передавать надо будет посылки 4-6 байт и на низкой скорости (не более 100 кБит), всё равно обработка прерываний займёт время.
Это вот смущает...

Тут с верхней полки подсказывают, что проще всего сделать по SPI жёстко мастер-слейв, а когда слейву (второму чипу) есть что сказать, он просто ставит лапку.

[_Артём_]

У I2C громоздкое прерывание. Даже не смотря на то, что передавать надо будет посылки 4-6 байт и на низкой скорости (не более 100 кБит), всё равно обработка прерываний займёт время.
Это вот смущает...

Мало с i2с работал - не помню может ли slave время тянуть. Если может и поток небольшой - то не важно сколько оно там обрабатывается: __enable_interrupt на входе в прерывание i2c не улучшит ситуацию?

Тут с верхней полки подсказывают, что проще всего сделать по SPI жёстко мастер-слейв, а когда слейву (второму чипу) есть что сказать, он просто ставит лапку.

Поставит, а когда ему можно передачу начинать в master-режиме? Как к этому первый чип подготовится?

[Dikoy]

Вложенное прерывание?
Ну не знаю... Не люблю я их на восьмибитниках....

А зачем ему в мастер режим?
Второй чип получил от первого команду. Первый мастер, второй - слейв.
Эту команду осмыслил и готов ответить. он поднимает лапку.
Первый чип видит, что стоит лапка и начинает читать из второго данные. Первый байт длина, а дальше в прерывании тупо счётчик. А то и вовсе кольцевой буфер.
Кстати, да. Тупо писать в буфер без всякого парсинга. Когда второй чип опустит лапку, значит всё сказал, можно разгребать буфер.
Прерывание тогда вообще из 2 строчек будет...

[_Артём_]

Вложенное прерывание?
Ну не знаю... Не люблю я их на восьмибитниках....

А что так?
AVR поддерживает их без проблем.
Всего то нужно запретить повторное срабатывание от того же источника и разрешить прерывания. Всё.
Если конечно по скорости позволительно.

Не люблю я их на восьмибитниках....

на 16/32-битниках разве по другому?
Разрядность тут не важна: лишь бы скорости и памяти под стек хватило.

А зачем ему в мастер режим?

Кстати - да.
Пусть в slave работает - если спрашивают, то отвечает тем что есть.

[Dikoy]

Всего то нужно запретить повторное срабатывание от того же источника и разрешить прерывания. Всё.
Если конечно по скорости позволительно.
на 16/32-битниках разве по другому?

SPI довольно быстр, можно не успеть выковырнуть байт до следующего интеррапта.
В 32 битниках обычно соплей побольше И можно DMA всякие настроить и делать большую часть буферизации аппаратно.

[ILYAUL]

На схеме показано соединение по умолчанию

Странное какое-то умолчание. Обычно DS чётко трактует схему подключения двух процессоров по SPI. И джамперы , как бы уже встороены внутри MCU тоже согласно DS.
И обмен данными вроде бы одновременный. Мастер может передавать и получать. И скорость SPI должна быть в 4 раза меньше тактовой как минимум. И местами поменять мастера со слейвом вроде бы трудностей нет. У кого инфы больше тот и мастер. И входной буфер на два байта.

не помню может ли slave время тянуть

Может.

[_Артём_]

SPI довольно быстр, можно не успеть выковырнуть байт до следующего интеррапта.

Какую скорость думаете использовать?
Для slave f_spi_max=f_osc/4 - ~ 32 такта на байт. Если ипользовать nested interrupt, то наверное можно успеть, а может и нет - как-то маловато тактов.

И можно DMA всякие настроить и делать большую часть буферизации аппаратно.

DMA не помешал бы.

[Dikoy]

Странное какое-то умолчание.

Такая плата.

Какую скорость думаете использовать?
Для slave f_spi_max=f_osc/4 - ~ 32 такта на байт. Если ипользовать nested interrupt, то наверное можно успеть, а может и нет - как-то маловато тактов.

Я решил остановиться на тупом поллинге. То есть полностью отказаться от прерываний, а читать байты из слейва (второго чипа) по мере наличия времени и желания. Тогда можно поставить f_osc/4 легко.
А если использовать прерывания, надо снижать скорость. Получается тож на тож, плюс риск подгадить реально важным прерываниям, которые волею судеб имеют более низкий приоритет, чем у SPI.

[ILYAUL]

У Вас , как уже писали выше ~ 32 такта.

Код

INT_SPI:
in SaveSREG,SREG
in или  sts  temp,SPDR
sts Buffer_spi,temp
out SREG,SaveSREG
reti

Итого от 10-до 12 тактов в зависимости от 3 строчки. Остается ещё 20 тактов до след. прерывания.

[_Артём_]

У Вас , как уже писали выше ~ 32 такта.

Код

INT_SPI:
in SaveSREG,SREG
in или  sts  temp,SPDR
sts Buffer_spi,temp
out SREG,SaveSREG
reti

Итого от 10-до 12 тактов в зависимости от 3 строчки. Остается ещё 20 тактов до след. прерывания.

Не так уж много там и остаётся: на вход выход в прерывание 3+3.

Код

sts Buffer_spi,temp

Как-то слишком просто - так годится если один байт принять надо.
Если больше, то набо ещё инкоемент указателя.

Код

*Buffer_spi++=SPDR;

А это уже дольше.
Плюс ещё задержка на вход в не SPI-прерывание и выполнение sei.

Поэтому думаю, что при f_spi=f_osc/4 вписаться трудно будет.
Если делить на 8-16 - то должно хватать.

[ILYAUL]

Я уже посчитал выход , кстати он 4 такта.
Вместо

Код

sts Buffer_spi,temp

Код

st X+,temp

для много байт , тогда уже (-1 такт)
Также можно выбросить 1 и предпоследнюю строку т.к. SREG в прерывании не изменяется . 32 такта для asm - это очень много и в любом раскладе байт будет принят. SEI обычно решено в самом начале программы и без особой на то нужды (например запись чтение 16 байтных регистров) его не дергают.
Учитывая , что мастер может в любой момент остановить обмен ( появилось более важное прерывание) то задача вполне решаема на такой скорости и с прерываниями.

[_Артём_]

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

Да, минимум 4.

Вместо

Код

sts Buffer_spi,temp

Код

st X+,temp

для много байт , тогда уже (-1 такт)

Это если на асме, а на Си

Код

st X+,temp

не пройдёт, то есть ещё и загрузку/выгрузку X надо делать и чтение-сохранение Buffer_spi.

Также можно выбросить 1 и предпоследнюю строку т.к. SREG в прерывании не изменяется .

SREG можно не сохранять, но мастер не должен читать больше чем можно и буфер тольно прямой, без зацикливания.

SEI обычно решено в самом начале программы и без особой на то нужды (например запись чтение 16 байтных регистров) его не дергают.

Вложенные прерывания ещё один случай такой нужды.

[Dikoy]

Это если на асме, а на Си st X+,temp не пройдёт, то есть ещё и загрузку/выгрузку X надо делать и чтение-сохранение Buffer_spi.

На си получается 65 тактов.
С указателем 47.

IAR не любит асм вставки, а полностью писать проект на асме я не могу по целому набору причин.

Вложенные прерывания ещё один случай такой нужды.

Вложеные прерывания есть вероятный источник рассинхронизации, что совсем не есть хорошо.
Пусть луше оно лишних 20 тактов отмолотит, но зато гарантия отсутствия рассинхронизации.