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

[=GM=]

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

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

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

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

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

[Yura_K]

А какие ограничения на использование регистров? Обязательно два буфера? Можно ли использовать прерывание SPI?

2) отправить его в регистр SPDR на передачу,
3) прочитать из SPDR принятый по SPI байт,

хм, а не наоборот?

Сообщение отредактировал Yura_K - Jul 13 2006, 16:13

[ksv198]

2) отправить его в регистр SPDR на передачу,
3) прочитать из SPDR принятый по SPI байт,
хм, а не наоборот?

А что вы собственно читать из SPDR собрались до записи в него? Результат предыдущего сдвига?
Принцип работы SPI - кольцевой регистр сдвига, пока мастер не инициировал передачу, слэйв ничего сам не отдаст. Поэтому все правильно - сначала пишем в SPDR, потом читаем.

[=GM=]

2) отправить его в регистр SPDR на передачу,
3) прочитать из SPDR принятый по SPI байт,
хм, а не наоборот?

А что вы собственно читать из SPDR собрались до записи в него? Результат предыдущего сдвига?
Принцип работы SPI - кольцевой регистр сдвига, пока мастер не инициировал передачу, слэйв ничего сам не отдаст. Поэтому все правильно - сначала пишем в SPDR, потом читаем.

Как я уже сказал, не имеет значения, читать до записи или после, хотя после записи читать надо немедленно иначе данные могут быть переписаны. При чтении до записи самое первое чтение будет пустым, ну сделайте буфер на 1 байт больше и все.

Поскольку эксперты не хотят делиться своими тайными приемами и трюками(:-), публикую первый вариант программы для аппаратного скоростного SPI, передача идет на предельно достижимой скорости fCLK/2, fCLK-тактовая частота процессора, один байт передается за 16 машинных циклов (МЦ). Регистровая пара Х указывает на начало передающего буфера, пара Y указывает на байт ПЕРЕД приемным буфером, txByte, rxByte - верхние регистры, скажем r16, r17.

Код

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

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

[zltigo]

Как я уже сказал, не имеет значения, читать до записи или после, хотя после записи читать надо немедленно иначе данные могут быть переписаны.

как Вам уже сказали, Вы элементарноь не понимаете элементарнейший принцип работы SPI :-(
Могу это еще раз подтвердить.

[=GM=]

Как я уже сказал, не имеет значения, читать до записи или после, хотя после записи читать надо немедленно иначе данные могут быть переписаны.

как Вам уже сказали, Вы элементарноь не понимаете элементарнейший принцип работы SPI :-(
Могу это еще раз подтвердить.

Ой, кто это(:-)? Кто же мне это сказал, и когда? Чего я там элементарного не понимаю? Всё я понимаю(:-). Но, учтите, задача стоит - достичь максимально возможной скорости передачи по SPI. Приведите внятное видение вами данной проблемы.

Подтверждать не надо, надо доказывать, цифрами, программками, ссылками на документы...А так написать, я считаю, это просто гнилой наезд.

Поскольку эксперты не хотят делиться своими тайными приемами и трюками(:-), публикую первый вариант программы для аппаратного скоростного SPI, передача идет на предельно достижимой скорости fCLK/2, fCLK-тактовая частота процессора, один байт передается за 16 машинных циклов (МЦ). Регистровая пара Х указывает на начало передающего буфера, пара Y указывает на байт ПЕРЕД приемным буфером, txByte, rxByte - верхние регистры, скажем r16, r17.

Код

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

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

В вашем примере отсутствует проверка готовности буферов приемника и передатчика. Нельзя записывать байт в буфер SPI до того как он освободится и/или не имеет смысла читать байт до того как он запишется в буфер SPI.

Я привел фрагмент программы, основной цикл, который выполняется точно за то время, как передается (и принимается) байт по SPI. Зачем я его буду проверять на готовность, если я и так знаю, что он готов к приему следующего байта! и терять при этом драгоценные такты. Я НЕ записываю байт до того, как он освободится, я записываю в тот момент, когда он только что стал пустым. Точно также и с принятым байтом.

[rezident]

Я привел фрагмент программы, основной цикл, который выполняется точно за то время, как передается (и принимается) байт по SPI. Зачем я его буду проверять на готовность, если я и так знаю, что он готов к приему следующего байта! и терять при этом драгоценные такты. Я НЕ записываю байт до того, как он освободится, я записываю в тот момент, когда он только что стал пустым. Точно также и с принятым байтом.

Тады, ой! Я не обратил на этот факт внимание. Хотя все равно это чисто теоретический кусок кода, не имеющий практического применения. В реальности нужны еще кое-какие проверки, хотя бы на окончание буфера, выделенного для приемоперадачи или на количество байт заданных для чтения/записи.

[=GM=]

Я привел фрагмент программы, основной цикл, который выполняется точно за то время, как передается (и принимается) байт по SPI. Зачем я его буду проверять на готовность, если я и так знаю, что он готов к приему следующего байта! и терять при этом драгоценные такты. Я НЕ записываю байт до того, как он освободится, я записываю в тот момент, когда он только что стал пустым. Точно также и с принятым байтом.

Тады, ой! Я не обратил на этот факт внимание. Хотя все равно это чисто теоретический кусок кода, не имеющий практического применения. В реальности нужны еще кое-какие проверки, хотя бы на окончание буфера, выделенного для приемоперадачи или на количество байт заданных для чтения/записи.

Принято.

Что касается проверок. Код приведен практически реальный. Можно было бы, конечно, поставить декремент счетчика байт (но считать можно было бы только до 256, а если мне надо передать 300?) и переход по условию, но тогда было бы 9 МЦ, а у меня 8! Кто может написать быстрее(:-)? Ну ладно, это у меня отпускные настроения разыгрались(:-).

А по делу так. Устанавливаете таймер на прерывание точно после последнего переданного байта, вот вам и будет выход из цикла, останется только подчистить верхушку стека...Зато 8 МЦ! Кому они нужны, право? Ну скажем, можно сделать хороший джейтаг для отладки, на АВР с тактовой 20 МГц скорость может достигать 10 мбит/с.