Arlleex

SCS-область ядра имеет атрибут памяти Strongly-ordered. Однако, это не исключает побочных эффектов при доступе в эту область. NVIC почти всеми своими регистрами лежит в области SCS, поэтому после записи регистра ICER нужно сделать DSB + ISB. Только тогда можно быть уверенным, что после барьеров прерывание точно не возникнет.

Architecture Reference Manual на ARMv7-M: Если после запрета прерывания доступа к Normal-памяти нет, то барьер не нужен. Даже если произойдет прерывание, оно сохранит регистры в стек и после извлечет обратно. При этом прерывание по побочным эффектам равноценно инструкциям барьеров памяти. Если есть доступ к памяти с атрибутом Normal (например, ОЗУ), то нужен барьер DSB. На память с атрибутом Device (все I/O-регистры) не распространяется буфер записи. Однако буфер записи может быть в реализации системного уровня (конкретная периферия МК), DSB и прочие не помогут. Поможет только второй доступ к памяти с таким же атрибутом (например, чтение того же регистра после его записи).

А, да. На порядок ошибся. 200 секунд копить P.S. Согласен, тогда второй способ - замер количества временных интервалов между фронтами.

Если ISR процесса A выполняется в N раз быстрее ISR процесса B, то в начале ISR процесса B можно разрешить прерывания для ISR A. Получится подобие вложенных прерываний. Чем короче будет код в ISR A (обработчик частотомера), тем меньшее влияние на времянку софт-UART он будет оказывать. Обратное влияние практически не будет заметно. Хотя, я так и не понял, как если даже при конской скорости UART в 9600 бод время передачи одного бита в 24 раза меньше максимального периода прерываний 400Гц... Может вообще пересмотреть алгоритм работы? 1. Заводим вход частоты на любое внешнее прерывание (как сейчас, в общем-то). 2. В ISR этого прерывания увеличиваем счетчик CNT внешних прерываний. 3. Заводим еще один таймер (программный, например), на период T (1...20с). 4. По истечении периода T рассчитываем исходя из CNT частоту, CNT обнуляем. 5. Заводим аппаратный таймер с частотой 9600 (ну или сколько там надо). 6. В обработчике этого таймера реализуем автомат выдачи битов UART. В зависимости от последней измеренной частоты подстраиваем T. Например, нафига копить частоту 400Гц 20с? Достаточно 1с. А для частоты 0.01Гц надо уже копить хотя бы 20с. Ну это образно, я не знаю требований к точности. ISR внешнего прерывания настолько короткий, что даже вложенных прерываний эмулировать не придется. Ну либо обратной логикой воспользоваться - в прерывании ВЧ-таймера увеличиваем CNT, а между соседними внешними прерываниями производить расчет. Тоже не вижу большой проблемы.

Гадать не придется - по SPI там только экран переводится в режим RGB и дальше работает по LTDC STM32

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

Вы изначально хотели "Hello, world" вывести. Исходя из этого я и писал ответные посты. Видел. И даже видя, что стоит за этими функциями, не вижу в них ничего сложного. Ну тогда надо было хоть сказать, что экран надо запустить без SDRAM, по SPI. Думаю, для Ваших целей там памяти примерно 0 потребуется.

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

SDRAM используется, да. Та гифка работает под вот этим кодом

Ну вон в коде фигурируют LCD_PIXEL_WIDTH, LCD_PIXEL_HEIGHT, LTDC_Pixelformat_RGB565 и другие настройки. Что, в принципе, удобно. Особенно удобно, если надо хоть от чего-то оттолкнуться, если лень RM читать. Тот пример как раз демонстрационный для LTDC, соответственно экран программно переводится в режим RGB-интерфейса. Так что можно быстро начать курить LTDC даже не сильно вдаваясь в мануал. Я лет 5 назад, когда надо было очень быстро запилить проект на таком камне, но с экраном 800x480, именно этот проект брал за основу. Сначала тупо увеличил размеры буферов в SDRAM и переназначил параметры экрана. Заработало сразу. А если с нуля - как минимум неделя улетела бы на поднятие SDRAM/LTDC/отрисовку примитивов. А потом по ходу работы проект был перепилен на 99%. Так что как отправная точка самое оно (ведь @Xenia, как я понял, пока что большего и не нужно) Кстати, тут Вы не совсем правы. Индусы (или STM-ные студенты?) все-таки сделали API для минимально необходимых компонентов Так что "ездящий текст" или прямоугольники какие-нить можно сделать Ну, типа Правда, немного намудрили они с функциями, поэтому для .gif выше я дописал пару функций в ~2 строки каждая.

Это примеры для конкретной платы. Для конкретной той, что с маленьким таким экраном. Той, что на картинке у меня, она же STM32F429I-Disco. Печать идет на текущем активном слое. Задается сначала LCD_SetLayer(), потом на этом слое происходят остальные махинации (стирание, отрисовка и т.д.). В той функции LCD_Init() все параметры LCD взяты из даташита на этот экран (размерности HSYNC/VSINV, длительности импульсов гашения и т.д.). Настраивается SDRAM там же, настраивается LTDC контроллера. В SRDAM размещаются два буфера - один для переднего, другой для заднего слоев. Для быстрого старта этого более, чем достаточно. И что значит разрешение экрана где задавать? Конечно же либо в самой функции magic number-ами, либо define-ами, как еще. За коим чертом в микроконтроллерном девайсе с мелким экраном менять разрешение? Ну если так хочется, то можно просто на лету переконфигурировать LTDC. Ток нафига... P.S. Для примеров там все достаточно прозрачно

На сайте STM-овцев есть архив с демопроектами для этой платы. В числе этих проектов есть примеры работы с экраном. Вы хотите, чтобы экран отхэллоуворлдил, но демопроектами пользоваться не хотите... Так? Или под демопрограммой Вы подразумеваете ту фиговину, что с платой "заставкой" шла? Я ее, кстати, уже через минуту затер своими наработками Но повторюсь, если хотите надписи элементарно повыводить да посмотреть как там примерно что-то делается, то есть демопроекты. Прям на сайте. Вот ради интереса скачал и отредачил какой-то пример с LCD под себя, пять минут и Если интересно, выложу архив. А ссылка на "сборную солянку" - тут. Хотя кой смысл выкладывать архив, если я поправил лишь main под себя в данном случае... #include "main.h" #include "stm32f4xx.h" #include "stm32f429i_discovery.h" #include "stm32f429i_discovery_lcd.h" int main(void) { LCD_Init(); LCD_LayerInit(); LTDC_Cmd(ENABLE); LCD_SetLayer(LCD_FOREGROUND_LAYER); LCD_SetTransparency(0); LCD_SetLayer(LCD_BACKGROUND_LAYER); LCD_SetColors(LCD_COLOR_YELLOW, LCD_COLOR_BLACK); LCD_SetFont(&Font16x24); LCD_Clear(LCD_COLOR_BLACK); LCD_DisplayStringLine(LCD_LINE_2, (uint8_t *)" Hello from"); LCD_DisplayStringLine(LCD_LINE_3, (uint8_t *)" Arlleex"); LCD_SetColors(LCD_COLOR_RED, LCD_COLOR_BLACK); LCD_DisplayStringLine(LCD_LINE_5, (uint8_t *)" to"); LCD_DisplayStringLine(LCD_LINE_6, (uint8_t *)" electronix.ru"); while (1) { } } Проект там называется LTDC_Display_2Layers в папке демок периферии.

Можно, конечно, повтыкать в RM и, возможно, на монстре из каскадных таймеров и каналов DMA реализовать то, что ТС требуется. Но стоит ли оно того... Например, механизм чтения... Берутся 2 таймера. Обзовем их TIM1 и TIM2 (к аппаратным блокам TIM1/2 STM32 тут отношения нет). 1. TIM1 настраиваем на режим сравнения с периодом больше времени передачи одной порции (байт?) данных по SPI. Счетчик повторений TIM1 настраиваем на количество байт управляющих данных для записи. 2. В TIM2 настраиваем общий период переполнения таймера, больший удвоенного времени передачи одной порции данных по SPI. Один из каналов сравнения (COMPARE 1) настраиваем на период, чуть больший времени передачи одной порции данных по SPI (как в TIM1). Канал сравнения COMPARE 2 настраиваем на время, чуть меньшее общего периода переполнения TIM2. Счетчик повторений TIM2 настраиваем на количество желаемых считываемых данных. TIM2 делаем включаемым по событию UPDATE от TIM1 каскадом (не помню, можно ли так). Между тем, событие сравнения TIM1 привязываем к одному из каналов DMA, который осуществляет пересылку данных из управляющей структуры в SPI с инкрементом адреса в памяти. Канал 2 DMA настраиваем на COMPARE 1 TIM2, который будет швырять пустые транзакции записи в SPI (настроить надо без инкремента в памяти). Канал 3 DMA настраиваем на COMPARE 2 TIM2, который будет швырять пришедшие данные из SPI DR в память (настроить надо с инкрементом адреса буфера в ОЗУ). 3. Запускаем TIM1. Каждое событие сравнения TIM1 будет формировать DMA-запрос на пересылку данных из структуры управления в SPI. Как только данных на передачу больше не будет, обнулится счетчик повторений TIM1 и сформируется его событие UPDATE, по которому запустится каскадный таймер TIM2. TIM1 при этом выключится (one pulse mode потому что). Событие COMPARE 1 толкнет (через DMA) "пустую" передачу по SPI, провоцируя ведомого заполнить постепенно входящий DR SPI-блока STM32. Когда транзакция завершится, подоспеет событие COMPARE 2, по которому входящие данные из SPI DR передадутся в ОЗУ приложения. И так M раз (M - количество данных, записанное в счетчике повторений TIM2). В конце концов, счетчик повторений TIM2 обнулится, возникнет событие UPDATE у этого таймера и он выключится, как и TIM1 однажды. По сути, надо будет заполнить только управляющую структуру, количество данных для чтения и (при предварительно настроенных таймерах, DMA и т.д.) включить TIM1. Прерывание по UPDATE TIM2 будет сигналом окончания чтения. Но теперь глянуть бы на возможности по роутингу сигналов DMA-контроллера от блоков таймеров и SPI STM32, чтобы понять, реально ли так сделать...

А в самом Keil-е контроллер правильный выбран? Если да, то, видимо, баг...

У меня дофига приложений, где 2.5V используется. И, как верно отметили, чаще всего в GbE, FPGA. А некоторые приложения требуют целый зоопарк 1.2/1.8/2.5/3.3V. Еще и раздельные линии с одинаковым потенциалом, разделенные, как правило, цепочками фильтров. Вот, например, у меня питание GbE-коммутатора Зоопарк источников питания (слева)