SPI по двум ногам в одну сторону между двумя 328, можно ли железно? Опции

[iiv]

Всем привет,

есть два контроллера atmega328p, соединенные двумя ногами через оптокоплер. Оптокоплер направлен только в одну сторону, пусть с первого на второй контроллер. Мне надо непрерывно передавать с первого на второй пакет фиксированной длины в 16 байт. Чем чаще, тем лучше, не реже 0.5мс.

Процессоры работают на одинаковой, но не синхронизированной частоте.

Приемник занят другой работой.

Попробовал посылать так:

по первой ноге по прерыванию приходит команда начала, дальше с частотой 4мГц сыплю на вторую ногу свой пакет.

Так как есть CRC, есть небольшая избыточность, то все работало. Единственно, при начале прерывания приемник должен был 32мкс только принимать данные. Раньше я мог это себе позволить, а сейчас уже нет.

Хочется чего-то аппаратного. Понятно - SPI. Но у него 3 ноги, а у меня только две закоммутировано. Реально ли как-то организоввать протокол передачи на двух ногах или это для таких процессоров не реально? Очень не хочется ставить 3-4 опторазвязанные ноги...

Спасибо

ИИВ

[Палыч]

Хочется чего-то аппаратного.

Может быть, применить USART ?

[iiv]

Может быть, применить USART ?

забыл сказать, USARTы обоих процессоров, к сожалению, заняты...

[Палыч]

забыл сказать, USARTы обоих процессоров, к сожалению, заняты...

Ну, выбор то - не велик: кроме USART, в наличии TWI и SPI...

Но у него 3 ноги, а у меня только две закоммутировано...

При необходимости, можно и двумя обойтись: MOSI и SCK.

[редактор]

При необходимости, можно и двумя обойтись: MOSI и SCK.

Совершенно верно, если передача идет в одну сторону, двух ног достаточно. Одна - тактовая (SCK), вторая - данные (MOSI).

[SmarTrunk]

А (вопрос начинающего) как же без CS (SS)? Ведь этот сигнал начинает и заканчивает передачу? Передатчику-то все равно, а вот приемнику же надо указать начало и конец передачи? Разве для аппаратного SPI это не обязательно?

[ILYAUL]

Он может такое делать ,чего-то там указывать. Посмотрите другую тему в интерфейсах в этом форуме. Но в обычно это сигнал выбора устройства с которым контроллер хочет пообщаться и если в системе только одно устройство с SPI , то CS сажают на землю

[Палыч]

А (вопрос начинающего) как же без CS (SS)?

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

[maksimp]

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

АЦП AD7799 сбрасывает свой интерфейс SPI если получает 32 единицы по MOSI, это можно применять вместо передёргивания nCS. Можно ли такое же сделать в слейве на AVR без больших извращений?

[Plain]

SPI. Но у него 3 ноги, а у меня только две

Передавать ведомому SS и данные. SCK завести с подходящего таймера.

[ILYAUL]

.... плохой согласованности работы master и slave...

Там с согласованностью и так может возникнуть проблема, если slave не успеет обработать принятый байт за 0.5ms. Не говоря уже о втором.И что-то мне подсказывает , что для ее решения потребуются все 4 ноги SPI
Или уж в самом крайнем случае три. Хотя топикстартера мы похоже уже потеряли.

[_Артём_]

Там с согласованностью и так может возникнуть проблема, если slave не успеет обработать принятый байт за 0.5ms.

ms? или us?
Если ms, то сложно не успеть на 16МГц.
Если us, то можно и не успеть, но в прицыпе можно справиться: за 32 команды можно как-нибудь прочитать данные - прерывание ведь совсем короткое:

Код

unsigned char *ptr;
#pragma vector=SPI_STC_vect
__interrupt void SpiRxCIsr()
{
*ptr++=SPDR;
}

Не говоря уже о втором.И что-то мне подсказывает , что для ее решения потребуются все 4 ноги SPI Или уж в самом крайнем случае три.

Чем добавочные ноги улучшат ситуацию?

[ILYAUL]

ms? или us?

У него мс. Про тактовую Atmega молчок. Прерывание , как таковое , это ещё не вся обработка . Что там с ним делают дальше и сколь долго нет инфы. Зато есть инфа

...сыплю... пакет.

Слово пакет подразумевает не один байт. Так , что slave надо ещё в эти 0.5мс (стиль автора) принять пакет неизвестной длины. Аппаратный SPI может "за раз" принять два байта.

Чем добавочные ноги улучшат ситуацию?

SS - активирует работу аппаратного SPI. (Задача то сделать аппаратный) Ну в крайнем случае можно и отказаться и поискать другой путь. CLK- без комментов
MOSI MISO - это ( по моему мнению , лень ведь было написать ИМХО ) единственное , что может синхронизировать работу мастера и slave т.к slave может одновременно ,с так некстати попыткой мастера отослать ему данные, вернуть ему код неготов . И мастер уйдёт на второй круг. Тем самым дать slave timeout. А slave даже и не узнает , что там "долбится" мастер , пока не разрешит своё прерывание SPI и не изменит код в буфере обмена на готов. Т.е не отвлёчется на этого .... мастера.

[_Артём_]

Про тактовую Atmega молчок.

дальше с частотой 4мГц сыплю на вторую ногу свой пакет.

Максимальная частота clock-а в slave режиме не более 1/4 частоты ядра, Поэтому 16 МГц, но это предположение.

SS - активирует работу аппаратного SPI.

Да, тут я не прав: как минимум SS у slave нужно посадить на землю.

[ReAl]

Слово пакет подразумевает не один байт. Так , что slave надо ещё в эти 0.5мс (стиль автора) принять пакет неизвестной длины.

Там рядом со словом "пакет" есть слова "фиксированной длины 16 байт".

iiv, я правильно понял, что прибито гвоздями только число линий в интерфейсе, а с платой можно и поиграться?
Тогда можно поставить одновибратор с перезапуском (в простейшем случае состоящий из диода+резистора+конденсатора), который пачку импульсов SCK растянет в длинный SS.
Если правильно выбрать CPOL/CPHA, всё будет хорошо. Для устранения проблемы байтовой сихронизации достаточно будет гарантировать паузу между байтами больше времени выдержки одновибратора. Можно — между пакетами, внутри пакта все байты пойдут одной пачкой, если успевать кормить SPI на передаче, синхронизм врядли успеет куда-то деться, а успеет — на то CRC.