аппаратный i2c и на аврах был "ну очень слёзен". У меня 99% - программные

Интервал интервалу рознь. Иногда требуется задержка в несколько тактов шины (не менее) для работы ядра или периферии.
У тех же Cortex-ов, иногда не просто nop-ы нужно вставлять, а грамотно пользоваться барьерами))
Таймеров мало, а суть проблемы программных задержек не ясна. Объясните в чем зло?


Ок. Берем SPI на почти-процовой частоте. Каждый байтик уходит за 16 тактов. По мне так куда смешнее смотреть на конструкции вида:


Без грамотного проектирования с передачей-приемом по DMA больших блоков с обработкой прерываний по приему SPI и окончания передачи DMA не вижу
никакого преимущества аппаратного SPI перед софтовым. Причем, софтовый имеет неоценимые плюшки в виде незанимания аппаратного SPI и полной свободе в выборе пинов. Сам я использую аппаратные SPI - просто привык использовать их совместно с DMA. Написал драйвер работы с SD-картой
через SPI с callback-функциями - уровень разработки скажу не для слабонервных. Можете привести пример над которым мы бы все могли "поржать"?
А еще хотелось бы посмотреть на 9-битный SPI, нужный, например, для подключения дисплеев nokia... не у всякого МК есть такой.

На AVR он как раз весьма хорош (наверное, потому что был взят в виде готовой корки).

в каком семействе? на мелких моделях - плюнул и забыл.

Например, на ATmega48 и т.п. На tiny модуль другой.

Мозги лучше иногда включить... После деления частоты кварца для экономии потребления камень начинает работать на 2457600/16=153600 Гц( если изначально ХТАL=2,457мГц) или 3579545/8=447443Гц (если ХТАL=3,579 мГц). После этого нужно сформировать одну из синусоид верхних частот: 1209Гц, 1336Гц,1477Гц или 1633Гц и сверху наложить с фазовой задержкой одну из синусоид нижних частот: 697Гц, 770Гц,852Гц,941Гц, чтобы получить сигнал DTMF. На эти операции уходит ровно 153600/1209=127, 153600/1336=115, 153600/1477=104, 153600/1633=94 машинных цикла при частоте 153600 Гц (в знаменателе генерируемая частота) или 447443/1209=370, 447443/1336=335, 447443/1477=303, 447443/1633=274 при частоте 447443Гц. Так формируется сигнал DTMF c помощью ЦАПа R/2R. При XTAL=2,457мГц DTMF-сигнал, содержащий частоту 1209 Гц, строится по 20 точкам, 1336Гц-18 точкам, 1447Гц-16 точкам, 1633Гц-14 точкам за период. И какие могут быть таймера при таком решении задачи, если команда возрата из прерываниея (таймерного в частности) reti съедает 4 машинных цикла + 2 цикла на сохранение и восстановление слова-состояния. Замечу, когда кнопка тастатуры нажата - сигнал формируется непрерывно! Все это ради экономии потребления тока. Частоты этих кварцов делятся на верхние частоты почти без остатка - нацело, поэтому погрешности при формировании сигналов DTMF таким способом - нет или 1 Гц.
P.S. Лучше эту тему убрать или перенести.

Сообщение отредактировал ESN - Sep 30 2015, 11:50

Насколько я вижу, Вы здесь придумали некий НЕДО аппаратный SPI и лихо его "побеждаете" софтовым. Давате все-же определимся, что типичный аппаратный SPI по нынешним временам, имеет, как мнимум FIFO если не DMА, и не все вместе, и настраивамую разрядность. До кучи еще поддержка не только SPI режима. По скоорости они тоже превосходят ногомахалки на многомегагерцовых контролерах.

Интересно, закроют производство или нет?
У меня под 2 тыс. плат на AVR-ах по всей стране работают и их надо сопровождать по гарантии еще 3 года а недавно еще дозаказали полтысячи.
А переделывать... пусть меня пристрелят. Не хочу.

Сообщение отредактировал Ga_ry - Sep 30 2015, 13:15

Не нужно тут байки рассказывать, что ногодрыг за 16 тактов сработает! От силы же 2МГц!!!

На это раз я солидарен с zltigo.

Я вот так думаю -- если стоит задача передавать по "квадратной" шине или SPI отдельные байты, то наверно -- да, изящнее будет выглядеть программная реализация, а не использование аппаратной части МК. Чем, собственно, и занимаются разработчики. (Я тоже не избежал участи испытать на своих проектах всю прелесть TWI. Ужас, какой-то!)

А вот если нужно передавать не байты, а пакеты, то аппаратные возможности камня однозначно рулят. И особенно рулят те камни, у которых имеется DMI -- подготовил в памяти пакет, снабдил его CRC, сообщил DMA параметры (адрес, количество) и дал команду "Старт!" И всё -- ушел делать фоновую работу или лёг спать. Когда процесс передачи закончится, прерывание "позвонит".

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




Если бы я был на Вашем, тёзка, месте, то я бы выбрал STM32. Поигравшись с этими бестиями, Вам уже будут не интересны другие камни. Думаю, мои слова подтвердят многие разработчики, кто работал с STM32. У XMega ниша слишком узкая и перспективы туманны. Хотя, сам по себе, камень хороший. Ключевое слово -- "был".

Можно конкретнее, а то я не вижу что именно увидели вы?


По долгу службы я очень интенсивно использую SPI для больших объемов данные (управление LED-панелями).
В такой задаче передача только аппаратным SPI + DMA.
В задачах передачи единиц байт плюсов от применения DMA и прерываний не вижу.
В популярной меге8 с ОЗУ байт 512 (на стек, переменные и т.п.) просто нет таких объемов данных.
Ровно как и нет FIFO, DMA, переменной длины слова...
Т.е. получается "АВРщина головного мозга" по определению?
Как быть с тинькой 13?

По делу: давно и плотно сижу на STM32. Серийных проектов на AVR давно уже нет, а те что были переехали на Cortex-M0.
Причем, AVR мне очень нравились и продолжают нравиться (хотя и не слежу за новостями).

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

Это как? Даже если микроконтроллер умеет в запись непосредственного значения в регистр ввода-вывода за 1 такт (в чём я лично сомневаюсь), то эти данные надо предварительно подготовить. Кроме того, бывает такое, что по SPI надо принимать, а не только пересылать.

Ок. Впадаем в крайности - нужно подготовить и передать 1 байт по SPI.
Есть мнение, что аппаратный и софтовый варианты реализации не сильно будут отличаться по времени, размеру кода.
Точнее сильно, но это не меняет ситуацию принципиально - толком ни поспать, ни что-то полезное сделать.
С программной точки зрения: что там ожидание, что тут.


С этим согласен. Когда SCK приходит из вне - лучше аппаратно реализовать.
Но чаще всего МК сам генерит SCK, а прием или передача особой роли не играет.

Насчет "правильных SPI": не у всякого мелкого МК есть аппаратный-то...

Вообще-то АППАРАТНАЯ передача по SPI выглядит иначе - кладется информация в регистр-FIFO-DMA и уходится заниматься ДРУГИМИ делами без всякого "ожидание".

На нет и спроса нет.