Н ужен быстрый вывод байта на SPI. Вопрос к знающим какой быстрее апаратный или програмный? И еще вопрос как реализовать по апаратному spi 9 бит....возможно ли это?

аппаратные решения вроде всегда быстрее программных

Посмотри даташит на контроллер (раздел SPI) и сам поймеш. К тому же с аппаратным проще работать.

Я недавно (в КоудВижн) писал софт-версию квадратной шины на Таньке2313. (У нее такая такая реализация аппарартной... слов нет, одни матерки!) Так вот, максимальные частоты на которые мне удадось подняться при кварце 7.37 МГц -- не более 100-150 кбит/сек. На Асме получилось бы наверно быстрее, но не намного. По моим прикидкам раза в 2-3.

Реализация SPI скорее всего даст такую же картину.

не забудьте проверить времянку на устройстве. Бывает, что процессорный SPI обгонятет, а потом на ясно откуда глюки...

Однозначно аппаратный быстрее.

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

Сообщение отредактировал gormih - Feb 19 2007, 13:33

Для той же 2313 аппаратная реализация SPI MASTER даст Fclk/2, если не оптимизировать по объему кода. Т.е. даже быстрее, чем полноценная реализация SPI на старших кристаллах (16 против 18 тактов на передачу одного байта), но это собственно передача, и в процессе передечи ничего другого делать нельзя. Самые шустрые SPI MASTER - у последних кристаллов (mega48...168, и другие новые), если работать через USART (у них теперь есть и SPI-режим).

А что до I2C - то, скажем, вывод на графический индикатор с 400-kHz чисто программно (дерганьем ножек) на относительно низких (<=8 MHz) тактовых частотах получается даже быстрее, чем с "честным" аппаратным вариантом (а не USI, как в tiny2313). Т.е., в смысле, не быстрее 400 kHz (потому как нельзя по спецификации), но быстрее, чем позволил бы аппаратный. Причем существенно быстрее (почти вдвое для 7.37, если не врет мой склероз). Так что как бы USI для этой частоты не оказался бы даже быстрее TWI...

Сообщение отредактировал rx3apf - Feb 19 2007, 13:43

+1
Отлично сказано! Просто подытожу -- хозяйство будет быстрее работать по двум причинам:

1). Распараллеливание процессов. Т.е. аппаратная часть тупо делает свое дело (отправляет/принимает), а ты в это "время" крутишь свою бизнесс-логику, и только по прерыванию окончания процесса передачи ты отвлекаешься на короткое время для выгрузки/загрузки очередного байта данных.

2). Программная эмуляция RS-триггеров и регистров сдвига работат куда медленнее.

Есть еще один аспект -- экономия программной памяти.

Вот многие так и думают, а потом удивляются - а чего это у меня так все тормозит ? Если нужно получить максимально возможную скорость обмена по SPI (например, при работе с SD/MMC или графическим модулем), тут не подходит ни работа по прерыванию SPI, ни даже простой опрос готовности SPI. Жесткая подгонка тактов дает куда больший эффект. Т.е. взяли старый байт, плюнули новый, делаем-свое-дело-не-менее-16-тактов, взяли, плюнули и так далее до конца блока (проверку счетчиков - "внутри", в этих 16 тактах). Само собой, речь идет о блочной передаче, на командах (несколько байтов) много не съэкономишь...

Ха! Я как раз начинал писать код для USI, потом посмотрел на этот код -- какая-блин хрень вылазит, на эти танцы с бубнами и регистрами управления USI -- и решил, что будет лучше, если я реализую все это программно. Тем более, что меня не особо напрягало время работы программы. Это был обычный программатор для 24LC256.

ИМХО, АТМЕЛ накосячил у Таньки в этом месте... Как минимум, мне не понравилось, как они приспособили квадраную шину.

А еще вопросик .СК\2 Это пределитель на 255 циклов+умножить на 2.
...и как мне реализовать апаратно 9 бит?

clk/2 для SPI это SPI2X=1 и SPR1=SPR0=0

9 битов аппаратно - никак. Или делать все программно, или 8 выгонять аппаратно, и еще один - программно. Можно ли это сделать, и как именно - не задумывался за полнейшей ненадобностью.


"Полноценный" TWI у AVR тоже скорострельностью не отличается. Что USI, что TWI - выше clk/16 не прыгнешь (просто для USI код более развесистый - но спасибо хоть за это, не I2C, так хоть какой-то SPI, а то у 90s2313 и того не было). Нужно быстрее - прямой путь к "дрыгоножству"...

Ну раз SPI никак нельзя использовать для передачи 9 бит, попробуйте использовать USART в СИНХРОННОМ режиме для передачи 9 бит, он допускает работу до Fclk/2. Сам так не пробовал, но не вижу причин, которые могут помешать.

Вот только синхронный режим USART у AVR неполноценный. Обычно под "синхронным" понимается использование байтов синхронизации и указанное число битов данных, без старт- и стоп- битов, которые как раз свойственны асинхронной передаче. И вся "синхронность" - только в наличии дополнительного сигнала синхронизации и большей скорости. Как следствие - первый бит всегда будет нулевым, последний - "единичным". И использовать это для 9-битной передачи по SPI при всем желании невозможно физически...

Это что ж выходит, нельзя передать инфу без искажений от ведущего МК к ведомому в синхронном режиме? Что-то меня гложут сомнения(:-). Зачем тогда такой режим нужен?

Что такое "байтов синхронизации"? Как-то сложно всё(:-).