adnega

Подразумевается, что ADCH перед сдвигом копируется во временную переменную с расширением типа. Вопрос только какого? Видимо, типа как и "u"?

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

Все просто: DMA натравливаете на буфер памяти и на SPI->DR. Но выбираете канал, который управляется событием по таймеру, а не канал для SPI_TX. Настраиваете таймер с нужной частотой, разрешаете ему генерировать DMA-запросы. Если CPU у Вас работает на 168МГц, то ничего страшного. Если частота ниже, то будут неприятности связанные с тем, что между DMA-запросом и DMA-транзакцией проходит от 12 тактов. Позже попробую, покажу в чем может быть затык. Какая частота CPU (168МГц), шины для SPI (168/2)? Номер SPI (SPI2)? Какая частота у SPI_SCK (5.25МГц = 168/32)? Какая задержка tNXT (250нс)? Какая длина посылки? Какой таймер свободен?

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

Дык, ответ в сообщении 16.

)) Сравнили. В МК чем-то нужно жертвовать. Из всех зол, это меньшее. Но ТС вряд ли подойдет, т.к. семейство другое... PS. На большом отрезке любопытно наблюдать динамику в ST. Как переделали AFIO в новых процах (большое за это спасибо), в новых SPI поддерживаются посылки от 4 до 16 бит (и паузы вставлять можно), появились 32-битные таймеры и т.п. Но на мой взгляд плохо, что переделали RTC (навороченный календарь вместо счетчика секунд), плохо что вынесли GPIO из bit-band региона((

Дык, NSS-ом в STM обычно софтово машут.

Попробовал. Получилось)) Правда, на STM32F303 (с новым SPI). void init_SPI2(void) { SPI2->CR1 = (1 << SPI_CR1_SSM) | (1 << SPI_CR1_SSI) | (0 << SPI_CR1_SPE) | (2 << SPI_CR1_BR) | (1 << SPI_CR1_MSTR); SPI2->CR2 = (1 << SPI_CR2_SSOE) | (7 << SPI_CR2_DS) | (0 << SPI_CR2_FRF) | (1 << SPI_CR2_NSSP) // ВСТАВИТЬ ПАУЗЫ | (0 << SPI_CR2_TXDMAEN); SPI2->CR1 = (1 << SPI_CR1_SSM) | (1 << SPI_CR1_SSI) | (1 << SPI_CR1_SPE) | (2 << SPI_CR1_BR) | (1 << SPI_CR1_MSTR); } Передача: SPI2->CR2 = (1 << SPI_CR2_SSOE) | (7 << SPI_CR2_DS) | (0 << SPI_CR2_FRF) | (1 << SPI_CR2_NSSP) | (0 << SPI_CR2_TXDMAEN); DMA1_Channel5->CCR = (DMA_PL_HIGH << DMA_CCR_PL) | (DMA_SIZE_BYTE << DMA_CCR_MSIZE) | (DMA_SIZE_BYTE << DMA_CCR_PSIZE) | (1 << DMA_CCR_DIR) | (1 << DMA_CCR_MINC) | (0 << DMA_CCR_EN); DMA1_Channel5->CPAR = (DWORD)&SPI2->DR8; DMA1_Channel5->CMAR = (DWORD)&val; DMA1_Channel5->CNDTR = 8; DMA1->IFCR = (0x0F << 16); DMA1_Channel5->CCR = (DMA_PL_HIGH << DMA_CCR_PL) | (DMA_SIZE_BYTE << DMA_CCR_MSIZE) | (DMA_SIZE_BYTE << DMA_CCR_PSIZE) | (1 << DMA_CCR_DIR) | (1 << DMA_CCR_MINC) | (1 << DMA_CCR_EN); SPI2->CR2 = (1 << SPI_CR2_SSOE) | (7 << SPI_CR2_DS) | (0 << SPI_CR2_FRF) | (1 << SPI_CR2_NSSP) | (1 << SPI_CR2_TXDMAEN); Частота SPI 72Мгц/8/2 = 4.5МГц. Пауза между битами 540нс.

Делал сенсорные кнопки на TSC в STM32F3xx. Думаю, это одно и то же. С UserManual без каких-либо библиотек запускается с пол оборота, но осциллограф желателен.

У STM я таких возможностей не видел. Добавлю: сейчас посмотрел на STM32F3xx (у них SPI другой) На картинке таки вставляет один пробел в SCK, но не знаю будет ли работать с DMA. Могу как-нить попробовать, или F3 для Вас не вариант.

С помощью таймера, SPI, DMA и какой-то матери конечно можно сделать. Но тут вопрос в другом: интерфейс SPI настолько "дубовый", что делать какие-либо задержки между байтами, это на мой взгляд нарушение основной его идеологии. Пока не видел ни одного устройства (и которые Вы привели в пример тоже к ним относятся), которым бы требовалась задержка ежду байтами. Чисто формально можно называть такие интерфейсы не SPI, а например C-Bus, но в SPI никаких задержек не требуется. Если один интерфейс для управляемый светодиодных лент, где пауза соответствует защелкиванию данных, но между байтами поток непрерывный. Так как будем интерфейс называть? Повторяю, задержка не нужна - посмотрите внимательно, что такое tNXT по диаграмме (а не по переводу с английского). Добавлю: тут недавно обсуждали DMA + SPI на STM. Картина не такая уж и радужная. Гарантировать интервал в 200нс с помощью DMA, таймеров и прочего, по-моему, не получится. Относитесь к DMA как сущности, которая может быстро и без участия CPU передать БОЛЬШОЙ кусок данных. Как только речь заходит о единичных транзакциях начинаются проблемы. Время между DMA-запросом и DMA-транзакцией далеко не ноль, "но это еще пол беды, вся беда в том, что" это время не постоянно.

Если внимательно посмотреть картинку, то tNXT расстояние между двумя соседними ФРОНТАМИ тактового сигнала. При этом на максимальной частоте tNXT = tCK, т.е. никакой дополнительной задержки вставлять не нужно.

Для светодиодов обычно говорят "максимальный продолжительный ток 20мА" или "импульсный максимальный ток при 1/10 заполнения 60мА". Цифры привел лишь для примера. Даже если вы повысите ток в несколько раз (но ограничить его все-таки нужно), ну после 10 000 ИК-команд телевизору упадет дальность передачи в два раза - просто замените диод.

lirc Вы обучали с ИК-пульта телевизора? Возможно есть смысл увеличить ток светодиода, как рекомендовали выше (R2=33 Ом).

С учетом всех исправленных замечаний и за исключением замечаний к USART1 - все в порядке. Проверьте действительно ли обработчик EXTI0_IRQHandler так называется (в стартапе). А лучше название скопировать из стартапа. Может стоит добавить объявление типа такого void EXTI0_IRQHandler(void) __attribute__((interrupt("IRQ"))); void EXTI0_IRQHandler(void) { ... Ваш код ... }

С этого и надо было начинать)) Светодиод у Вас модулируется? Хотя я кажется понял: у Вас есть чужая прошивка в контроллере, а Вы просто ходите подключить приемник и передатчик к контроллеру?

Это какие, например?

Так не пойдет... Кто дал Вам право читать USART1->DR, не проверив соответствующий флаг в USART1->SR? Почему не обрабатываете флаг переполнения? С таким обработчиком нельзя разрешать прерывания на передачу. Если запретить прерывания от USART1, то прерывание от PA0 работает?

"Вам шашечки или ехать?". Схема наипростейшая - ставьте в базу 1кОм и все будет работать. Если нужно академическое решение задачи, то в конце концов получится не статическое решение, мол "подали напряжение на R1, потек ток через диод", а динамическое - с учетом управляющей транзистором частоты. Какая у Вас частота модуляции? На какой частоте работает приемник?

Из DS на транзистор. При токе Iб=0.5 мА Uбэ=0.7В, при токе Iб=5мА, Uбэ=0.9В. Т.е. на R1 с одной стороны 3.3В, а с другой 0.9В. Затем закон Ома.

В формуле с R2 я бы еще вычел Uкэ=0.3В, соответственно R2=85 Ом. R1 можно поставить 1кОм. Ток Iб будет (3.3 - 0.9) / 1000 = 2.4 мА (т.к. Uбэ = 0.9В)- ничего страшного, если максимальный выходной ток 16мА. Свечение светодиода Вы модулируете? Какой частотой? Если она сильно отличается от частоты приемника, то больших расстояний не будет. ...поправил с учетом DS на транзистор.

Появился! Заметно полостевший RM0090 версии 5 с SDRAM, DMA2D и прочими вкусностями. Вовремя, а то STM32F429VGT6 второй день "пылятся" на столе))

Скорее всего не проходят верификацию после прошивки. PS. Ни разу не видел протортого контроллера.

Если нечего передавать, то прерывание на передачу должно быть запрещено. Это Вы знаете? А лучше покажите обработчик USART1.

Только когда MAC-и одинаковые, если нет ошибок в софте.