Реально достижимая скорость по SPI, Программно-аппаратные трюки для достижения максимальной скорости перед Опции

[=GM=]

Тема была навеяна $ilent, но она была закрыта прежде, чем я успел в ней поучаствовать :-).

Интересует, прежде всего, потенциально достижимая скорость как в аппаратном исполнении, так и в программном.

Какие требования в "железном" исполнении? Необходимо передать по SPI nByte байт из буфера txBuffer (ОЗУ МК) и одновременно принять массив байт такой же длины в rxBuffer (ОЗУ МК). Моя программа выполняется за 8МЦ, т.е. ровно один такт на 1 бит. Интересно, можно ли добиться большего? Что скажут эксперты?

Программа $ilent работает в полудуплексе, следовательно можно снизить требования к программной реализации SPI, а именно, необходимо программно формировать только биты данных и синхронизацию на передачу ИЛИ принимать биты данных по положительным фронтам импульсов синхронизации на прием. Моя программа передает один байт за 36МЦ, т.е. за 4,5 такта на 1 бит. Как добиться большего?

Народ, не воспринимайте топик слишком сурово, это мой первый на этом сайте...

[rezident]

=GM=, есть несколько нюансов в описываемой вами схеме.

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

В чем смысл гонять данные с максимальной скоростью? А обрабатывать их до/во время/после обмена не нужно? Что приоритетней, задача выполняемая МК или обмен данными? А оба МК будут успевать подавать данные на конвейер синхронного интерфейса? Или достоверность данных вас особо не волнует?
Отсюда наверное и будет решение по прерыванию или в цикле организовывать обмен по SPI. Я бы не стал столь рискованно (на пределе возможного) организовывать обмен даже двух МК. Вот если МК и DataFlash с аппаратным конвейером SPI, то это пожалуйста. предложенный вами кусок кода вполне можно имплантировать в программу.

[=GM=]

=GM=, есть несколько нюансов в описываемой вами схеме.

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

В чем смысл гонять данные с максимальной скоростью?

Конечно, нюансы есть везде. Чёрт, как известно, сидит в деталях(:-).
А в чем смысл их гонять с минимальной скоростью(:-)? Выше я показал на примере, что при максимальной скорости есть некая экономия производительности МК.

А обрабатывать их до/во время/после обмена не нужно? Что приоритетней, задача выполняемая МК или обмен данными? А оба МК будут успевать подавать данные на конвейер синхронного интерфейса? Или достоверность данных вас особо не волнует?

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

А оба МК будут успевать подавать данные на конвейер синхронного интерфейса?

Ну вы же видите, что программа успевает и принять байт и передать его. А следующая передача может случиться через секунду. Ну вот скажем, вы делаете систему тестирования, вы принимаете байты из LPT ПК и хотите передать в JTAG, для проверки некой микросхемы или платы, используя пограничное сканирование. Что вы предпочтете, медленно заталкивать биты в последовательные регистры нескольких микросхем или быстро? Ответ очевиден, быстро (насколько позволяет система) затолкнуть скажем 600 бит, подождать процесса установления, затем протестировать...

Отсюда наверное и будет решение по прерыванию или в цикле организовывать обмен по SPI. Я бы не стал столь рискованно (на пределе возможного) организовывать обмен даже двух МК. Вот если МК и DataFlash с аппаратным конвейером SPI, то это пожалуйста. предложенный вами кусок кода вполне можно имплантировать в программу.

Спасибо. Пользуйтесь, мне не жалко. Ну я тоже не сторонник работать на пределе. Жизнь иногда заставляет. Проект был - асик с доморощенным интерфейсом 5 Мбит/с с точностью до 10 нс, передается команда, затем переключение на прием, принимается 32 бита данных, что делать? А я еще клювом прощелкал, мог бы поработать с людьми, изменить интерфейс, асик был заказной, под нас делали..Пришлось извиваться. Сейчас из 150 мкс обмен занимает 35 мкс! Да я ДПФ делаю за 70 мкс!

Код

spiLoop:       ld      txByte,X+;подготавливаем байт на передачу
               in      rxByte,SPDR;читаем принятый байт (первый байт-фиктивный)
               out     SPDR,txByte;запускаем байт на передачу
               st      Y+,rxByte;сохраняем принятый байт в приемном буфере
               <nop x 6 раз или другая задача на 6МЦ>
               subi    r16,1
               sbci    r17,0
               brcc   spiLoop;повторяем цикл

Так потянет? 6 тактов в запасе.

Нормально, Григорий(:-). Хотя у вас 10 МЦ, а в исходной проге было 8 МЦ.

А в Оксфорде учитесь?

Не, работаю. Занесло вот в ЮКей. Не каждый московский голубь долетит до середины Ламанша(:-).

Сообщение отредактировал =GM= - Jul 14 2006, 14:49