[aleksandr-zh 4]

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

[adnega 10]

Руки бы поотрывал и засунул их в задницу тем, кто временные интервалы не таймерами задает, а "нопами". АВРщина головного мозга!

Интервал интервалу рознь. Иногда требуется задержка в несколько тактов шины (не менее) для работы ядра или периферии.

У тех же Cortex-ов, иногда не просто nop-ы нужно вставлять, а грамотно пользоваться барьерами))

Таймеров мало, а суть проблемы программных задержек не ясна. Объясните в чем зло?

 

Вы еще ногодрыг вручную устройте на какие-нибудь I2C, 1-wire и т.п. Особенно ржачно смотреть, как аврщики городят всякие велосипеды вроде I2C (а то и SPI) на камнях, имеющих это аппаратно!!!

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

BYTE sd_send_byte(const BYTE data)
{
    BYTE spib;
    while((SD_SPI->SR & (1 << SPI_SR_TXE)) == 0);
    SPI3->DR8 = data;
    while((SD_SPI->SR & (1 << SPI_SR_RXNE)) == 0);
    spib = SD_SPI->DR8;
    return spib;
}

 

Без грамотного проектирования с передачей-приемом по DMA больших блоков с обработкой прерываний по приему SPI и окончания передачи DMA не вижу

никакого преимущества аппаратного SPI перед софтовым. Причем, софтовый имеет неоценимые плюшки в виде незанимания аппаратного SPI и полной свободе в выборе пинов. Сам я использую аппаратные SPI - просто привык использовать их совместно с DMA. Написал драйвер работы с SD-картой

через SPI с callback-функциями - уровень разработки скажу не для слабонервных. Можете привести пример над которым мы бы все могли "поржать"?

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

[aaarrr 63]

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

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

[aleksandr-zh 4]

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

[aaarrr 63]

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

[ESN 0]

Руки бы поотрывал ...

Мозги лучше иногда включить... После деления частоты кварца для экономии потребления камень начинает работать на 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. Лучше эту тему убрать или перенести.

Изменено 30 сентября, 2015 пользователем ESN

[zltigo 0]

Без грамотного проектирования с передачей-приемом по DMA больших блоков с обработкой прерываний по приему SPI и окончания передачи DMA не вижу

никакого преимущества аппаратного SPI перед софтовым. Причем, софтовый имеет неоценимые плюшки в виде незанимания аппаратного SPI и полной свободе в выборе пинов. Сам я использую аппаратные SPI - просто привык использовать их совместно с DMA. Написал драйвер работы с SD-картой

через SPI с callback-функциями - уровень разработки скажу не для слабонервных. Можете привести пример над которым мы бы все могли "поржать"?

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

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

 

 

[s_gary 0]

Интересно, закроют производство или нет?

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

А переделывать... пусть меня пристрелят. Не хочу.

Изменено 30 сентября, 2015 пользователем Ga_ry

[Eddy_Em 1]

Вопрос именно в строгости времянки, а не лишних строках (например, нужно выводить в тот же внешний ЦАП данные с периодом 16 тактов). Тогда лучше уж написать кусочек на асм, чем добавлять в код asm("nop").

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

[zhevak 0]

Давате все-же определимся, что типичный аппаратный SPI по нынешним временам, имеет, как мнимум FIFO если не DMА, и не все вместе, и настраивамую разрядность.

 

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

 

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

 

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

 

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

 

 

вот сижу и думаю: так осваивать теперь Xmega али нет?...

вроде на следующей неделе платки для обучения работе с stms32 получу ... только на них и сосредоточиться?

 

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

[adnega 10]

Насколько я вижу, Вы здесь придумали некий НЕДО аппаратный SPI и лихо его "побеждаете" :) софтовым.

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

 

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

По долгу службы я очень интенсивно использую SPI для больших объемов данные (управление LED-панелями).

В такой задаче передача только аппаратным SPI + DMA.

В задачах передачи единиц байт плюсов от применения DMA и прерываний не вижу.

В популярной меге8 с ОЗУ байт 512 (на стек, переменные и т.п.) просто нет таких объемов данных.

Ровно как и нет FIFO, DMA, переменной длины слова...

Т.е. получается "АВРщина головного мозга" по определению?

Как быть с тинькой 13?

 

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

Причем, AVR мне очень нравились и продолжают нравиться (хотя и не слежу за новостями).

 

[zltigo 0]

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

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

 

 

[one_eight_seven 3]

Каждый байтик уходит за 16 тактов.

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

[adnega 10]

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

Ок. Впадаем в крайности - нужно подготовить и передать 1 байт по SPI.

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

Точнее сильно, но это не меняет ситуацию принципиально - толком ни поспать, ни что-то полезное сделать.

С программной точки зрения: что там ожидание, что тут.

 

Кроме того, бывает такое, что по SPI надо принимать, а не только пересылать.

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

Но чаще всего МК сам генерит SCK, а прием или передача особой роли не играет.

 

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

[zltigo 0]

Точнее сильно, но это не меняет ситуацию принципиально - толком ни поспать, ни что-то полезное сделать.

С программной точки зрения: что там ожидание, что тут.

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

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

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