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

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

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

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

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

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

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

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

Для той же 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...

+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 при всем желании невозможно физически...

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

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

_Информацию_ можно. Но структура информации будет такой же, как и в асинхронном режиме - т.е. старт-бит, данные, [паритет], стоп.




Это (байты или биты синхронизации) используется в синхронных протоколах, когда нет возможности определить начало посылки иным способом. Типично - в беспроводных системах передачи данных. Идет шум или поток данных, некоторая последовательность проверяется коррелятором, при превышении порога (или точном совпадении - зависит от назначения) запускается приемник. Еще синхронные трансиверы типично умеют сами считать CRC16, поскольку скорости большие, и вычислять CRC программно - очень накладно.

Ну так! Человек вроде и спрашивал
Вот он вытолкнет 9 бит, а на другой стороне примет, какое ему дело, что будет дополнительно передаваться старт и стоп биты? А вы говорите невозможно...

Не, в беспроводных эт понятно, там нет провода синхронизации, приходится её вырабатывать на приёмном конце, да это еще не все, передаётся несущая, чтобы подстроить местный гетеродин, потом преамбула, чтобы подстроить тактовую частоту, потом передается кодовое слово, или фазовый пуск, или по-вашему, байты синхронизации, чтобы указать начало инфобит (вот у меня один раз было изделие, так там был фазовый пуск длиной 288 бит, ей-богу не вру!).

Но при чём здесь беспроводные системы? Автору надо передать 9 бит и 9 импульсов синхронизации.
Предлагается решение 11 бит (добавляется старт и стоп) и 11 импульсов, скорость 8 мбод при тактовой 16 МГц. И все довольны, особенно автор топика. Почему нельзя использовать?

Автору надо передать 9 битов данных. А будет передано 11, причем два из них с жестко заданными значениями. Для чего, кому и куда надо передать данные - в вопросе не было. Типично, обмен по SPI таких извращений не позволяет. Хотя и значения, не кратные 8 битам, тоже экзотика. Если получатель допускает такой формат посылки - да, можно так и сделать. А если нет - облом.

Как правило, получатель именно требует такой формат ;О) ЦАПы,АЦПы... Есть вариант, некратные 8 биты совать программно, а 8-бит аппаратно. Или формировать посылку так, чтобы передавать кратно 8 битам, а остаток ненужных бит впустую вдвигался в приёмник и там погибал. Безвестно. Делал и так, и так.

Я так понял ...юарт будет дату а клок... чем выводить?

Не правильно понял, да и не в том направлении тебя отправили.
Лучше расскажи общественности зачем тебе надо 9 байт по SPI передавать, чем управлять собираешься?

Вот это , возможно, более правильный вариант, но надо смотреть как именно воспримет это целевое устройство. Т.е. делать нужно так, берете 2 байта, 11111111 10000000, здесь "1" - это, условно, данные - 9 бит, теперь передаем через SPI байт 10000000, младшим битом вперед, затем второй байт 11111111, таким образом у нас не значащие "0" выталкиваются из сдвигового регистра приемника в никуда и в нем остаются только 9 бит значимых данных, у нас они помечены как "1". А спрогнозировать как поведет себя подчиненный можно прочитав даташит на него.

Любопытно, никогда таких не видел. Пример можно ? А то все, с которыми я имел дело, имели четко кратный байту формат, и без фиксированных значений битов в обрамлении кадра. Самое изратное, что приходилось видеть - это SPI-режим у VNC-1L. Вот тут да, ужас, летящий на крыльях ночи...

AD840x, AD520x...Говорю-ж ЦАПы, АЦАпы. Тыкай в любого, особенно если многоканальное чего.

AD840x - это цифровые потенциометры (это не совсем DAC). Да, действительно, 10-битная посылка. Но вовсе не толерантная к лишним фиксированным битам, насколько я могу судить. AD5203 - тоже потенциометр. Стандартная 8-битная посылка. AD5200 - 8-битная. 5201 - шестибитная. А, ну еще 5207 - с десятибитной. А вот если "ткнуть" в типичные ADC и DAC - AD420 два байта, AD770x - 8/16/24 бита (это с которыми я работал). Так что исключения - редчайшие, и это, скорее всего, встречается только у очень древних продуктов, в те времена аппаратный SPI у микроконтроллеров был скорее исключением, чем правилом...

[quote name='GDI' date='Feb 20 2007, 11:54' post='213431']
[quote]Я так понял ...юарт будет дату а клок... чем выводить?[/quote]
Не правильно понял, да и не в том направлении тебя отправили.
Лучше расскажи общественности зачем тебе надо 9 байт по SPI передавать, чем управлять собираешься?






Цветной дисплей с спи ...9-й бит идет как бит команды....нужно дисплей как можно быстрее заполнять.

В синхронном режиме выделяется отдельная ножка под клок, в даташите описано.


Если уж быть до конца честным, то стандартный SPI работает только с байтами (т.е. 8 бит). По крайней мере так описано в последней ревизии S12SPIV3 от Freescale, которая у меня под рукой. Исходя из этого, мне крайне сомнительно, что автору надо передавать в стандартный ЦАП, память или другое спай-устройство, выпускаемое серийно, поскольку такие устройства, как правило, разрабатываются под определенный интерфейс, в частности под SPI, а не на 9-10-11..бит, это смертельно для рынка.

Уже ответили, мои догадки были неправильные.

И кому от этого легче?

Правда? Ну вот вам свежайший AD7680 c 20-битной посылкой. Или AD7690. С 18-битовой... ;О) Напишите в АДИ, что уже есть процессоры с аппаратным СПИ. А то мужики-то не знают...Удивяцца, небось.

Вот ещё один способ придумал, экзотический(:-).

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

Вгрубе алгоритм такой. Программа записывает первый байт в спай-регистр и запускает выдачу клоков по сравнению. Затем она отсчитывает 16 тактов (время передачи 8 бит на 8 мбодах), посылает второй байт, отсчитывает 2 такта и останавливает оср. Вот как-то так, по-моему, должно работать.

Примеров много. Но при этом они вполне адекватно относятся к 24-битной посылке, защелкивая только последние 20(18, сколько-нужно) бит.

Обо што и речь!

;О) Через ж..., автогеном. ;О)

Тогда, мне кажется, лучше всего эту задачу решить на матрице - отдельный вход выделить на "команда/данные" и честный SPI для связи с МК, а на второй стороне - хитрый 9-битный для дисплея.

(Размышляя... ) Или на сдвиговом регистре типа 579 - параллельно грузить с процессора, последовательно выдавать... бит команда/данные завести на последовательный вход, CS программно формировать - дернул ногой, 9 nop, дернул взад, его же на загрузку регистра, такты прямо с кварца через буфер.

А какую максимальную скорость SPI поддерживает этот дисплей? и какую дает используемый контроллер, на выбранном кварце. В общем надо использовать аппаратный SPI и передавать 9 бит данных за 2 байта, можно , конечно сделать так, как предлагает =GM=, но мне не совсем понятна его идея... клоки можно считать и асинхронным таймером, подав их на асинхронный вход, а затем каким либо образом прерывать передачу SPI, например запрещая SPI, но будет ли это лучше и надежнее и намного быстрее простой передачи 2х байт, сомневаюсь.

Ха! Зато ровно 9 бит и 8 мбит/с!

Критиковать легко! У вас есть другое решение, которое даёт то же самое? Если да, то покажите.

Да не переживайте, это не наезд какой. Просто уж очень завихрасто. ;О) Половину ресурсов МКшки на это дело уйдёть. Да и пока таймер зарядишь-разрядишь, пока то, пока сё. А так СПИ оттарабанил - один битик вручную передёрнул и вуаля. Или наоборот.
http://electronix.ru/forum/index.php?showt...7568&st=19#

Я бы поставил два дополнительных логических элемента и после передачи 8 битов от SPI передёрнул ноги данных и тактовой частоты. ИМХО, расходы невелики, а все проблемы решаются оптом.

На 579 ...это какая МС?.... я уже много думал ,лучше был у дисплея паралельный ,ещеб в 9раз шустрее был. По даташиту описания скорости не...но внутренний генератор 815кГц.На атмеге 128 икварце16мГц,частота клока около 700кГц, при програмном исполнении.

579 - 74HC579, но я внимательно прочитал - вариант, предложенный =GM= делает то же самое на внутренних ресурсах. Тип дисплея огласите, пожалуйста. Информации о его частоте недостаточно - интерфейс может работать асинхронно от генератора дисплея, надо смотреть временные параметры интерфейса.
700КГц - 22 такта на бит - это вам удалось. Полагаю, что реально уложиться в 6-8 тактов.

тип дисплея D15G14E на чипе PCF8833. Чип поддерживает паралельный ,но дисплей только spi.

при таком кварце аппаратный SPI даст вам до 8МГц.

serial clock SCLK period (SCLK) min 150 ns (стр.77 даташита) - 6.6МГц максимум. Исходите из этого.

Не вижу вообще никакой проблемы. Зачем работать по байту плюс D/C, если можно работать блоками, кратными 9 байтам (что даст восемь байтов и восемь битов управления). Подготавливать, правда, чуть-чуть сложнее, но я вообще не представляю побайтовой работы с дисплеем...

Поскольку максимальная скорость интерфейса дисплея 6.6(6) МГц, то вопрос с 8 мбодами отпадает сам собой(:-).

А вот если устроит скорость 4 мбода, то могу показать, как сделать чисто программно. На такой скорости, конечно, можно только обновлять экран 19 раз в секунду, больше ничего не успеть. Да ещё большой вопрос, откуда брать новые кадры..или картинка статическая?

Применительно к SPI - да (в том случае, когда устройство действительно некритично в ведущим "лишним" битам). Применительно к эмуляции SPI через USART в синхронном режиме - нет. Поскольку последний передаваемый бит всегда будет равен "1", а прием так и вовсе не начнется до тех пор, пока не появится бит "0". Не говоря уж о разных SPI-модах...

Для озвученного устройства USART в синхронном режиме отпадает, т.к. данные там могут передаваться сплошняком: 9 бит + 9 бит + 9 бит + 9 бит... и контроллер дисплея будет интерпретировать старт и стоп биты как текущие биты данных.

Хотя для других применений, скажем для передачи 9-битных данных с одной атмеги на другую, или для передачи на самопальный регистр сдвига, USART в синхронном режиме вполне подойдёт.

Мне было необходимо использовать два SPI. Учитывая уже написанное (что использовать в данном случае прерывание для получения максимальной скорости неэффективно) я поступил так, как предлагает уважаемый Сергей Борщ. С небольшой разницей. Я подключил сдвиговый регистр - как ячейку памяти (память внешняя у меня используется) а на сдвиг подал SCK первого SPI. Таким образом я выполняя сначала вывод в озу 1 байт и в SPI - второй, - работаю сразу с двумя SPI и таким образом экономлю время. Естественно таким образом можно сделать и больше каналов.

...забавно. А как много девайсов которые работают на тактовой выше 400 КГц? Кто-нибудь задумывался? Нужна ли скорость выше 400 КГц? ...у аппаратного есть несколько преимуществ, если в системе есть прерывания длительностью более чем период тактовой I2C то есть риск потерять бит при обмене (при программной реализации ведомого), еще не тратится время процессора на прием/передачу каждого бита (справедливо, когда тактовая CPU намного выше тактовой I2C), в общем чем больше в системе прерываний тем выгоднее аппаратный интерфейс

Всё правильно, но тут обсуждается SPI по большей части. А он иногда используется на запредельных скоростях. Например для передачи данных на аппаратное устр-во (обычный регистр сдвига). Или на дисплей графический. То есть передаётся большой объём данных.

В некоторых случаях, не то что 400кГц,а 10МГц допустимо.

А прерывания - бессмыслены. CLK/2. 8 бит - 16 тактов. Вход- выход в обработчик больше потянут.

Спасибо всем ,откликнувшимся ...я сделал выводы и буду пробовать варианты !

Сделал открытие ...атмега128-16au, на 3.5в , нормально шпилит на 24мГц...правда без конденсаторных обвязок на кварце

Открытие!

Поварируй с питанием - будет 27. А с внешней флэши (ОЗУ) поднимали до 34.