-
Постов
367 -
Зарегистрирован
-
Посещение
Весь контент AVI-crak
-
Ну не знаю, A0 это всегда SDRAM_A0. Сама память отдаёт по младшему адресу все 16 бит разом. DQM0, DQM1 - это как-раз для управления отдельными байтами. Периферийный блок sdram в ST - самостоятельно рулит адресацию, если его верно настроить. А то что на схеме приклеено - просто не должно работать, внешний чип памяти инициализируется адресными линиями.
-
У вас не получится использовать все имеющиеся прерывания чисто физически. Потому как не получится задействовать всю имеющуюся периферию - ног мк не хватит. Более того - периферия условно делится на быструю и медленную. Можно одним единственным быстрым прерыванием намертво повесить мк, тогда как другие просто не способны срабатывать быстро.
-
Вооот, а иногда даже не 5% - а ниже требуемого времени на переключение, и тогда оно зависает в непонятном состоянии. Просто для пользователей фриортос, добровольное переключение - это настолько редкая команда, что её почти никто не использует. Для моей ос, добровольное переключение os_pass() - наверное самая важная команда. От неё зависит общее быстродействие всей системы. И применяется она буквально во всех местах, где требуется ожидание внешней реакции. При этом системный таймер на 1мс может оказаться в тысячи раз медленнее шрейдера задач (когда нечего делать). Но и проверять состояние спящих тысячу раз за 1мс - тоже глупо (в системной задаче). Потому таймеров две штуки, и вот они действительно никак не связаны между собой.
-
Сколько времени назначить новой задаче при добровольном переключении? Остаток неиспользованного времени, или пересчитать новое время - с перезапуском таймера?
-
И что, системное время при этом не сбивается? А то у меня был такой промежуточный вариант на одном таймере (сейчас два). Для коррекции системного времени приходилось делать массу телодвижений, да ещё и на асме(в котором я потом вообще запутался) . Но ошибка всё равно накапливалась с очень слабым прогнозом (в + или -), отчего счётчик системного времени превращался в показометр попугаев. То-есть приходилось запускать второй счётчик реального времени, чтобы хоть как-то выйти из положения. Сейчас два физических счётчика: время работы задач, и системное время. Работают независимо и синхронно, без ошибок и лишнего кода.
-
Любую не получится, точнее работать будет - но в N раз медленнее. Тут весь прикол - с какой стороны происходит управление. Любая ос с приоритетами и вытеснением - даёт задаче фиксированное время работы. Это время фиксировано, буквально. Даже если задаче нечего делать, и она готова отдать своё время - всё равно придётся ждать стандартные 1мс + остальные задачи + работу планировщика. На новом витке эта задача уже будет с иным приоритетом, и может даже не запустится. Но первоначальная задержка всё-таки сохраниться. А там ещё и гонка появится - то ещё удовольствие. Гораздо проще когда задача сама решает свою судьбу, вот прямо здесь и сейчас. Тем-более что это решение получается гораздо более быстрым чем через работу планировщика.
-
Есть два основных подхода решения почти всех задач: по важности (когда уже жопа горит), и к моменту актуальности готового решения. Вот когда нужно прямо сейчас: начинается запрещение прерываний, кастование приоритетами, и даже разгон частоты мк. Девайсы с таким подходом обычно тормозят в самых неожиданных местах, непредсказуемо. Наличие и тип ос не влияет на конечный результат. В любом случае получится дёрганный уродец, без шанса понравится пользователю. Второй вариант когда все активные задачи выполняются с равным приоритетом запуска но разным временем работы. Нормированная по времени задержка получается почти автоматически (если не делать глупостей). А тройной буфер спасает любую безвыходную ситуацию. Я говорю про активные задачи, которым есть чего делать - все остальные либо отправляются в сон, либо замораживаются, либо отдают своё время чтобы не отсвечивать. Всё это есть в вытесняющей ос, но не столь гибко как у меня.
-
Просто есть несколько типов ос: с приоритетами в задачах, и с переключением по таймеру, и смешанное управление. Они разные, и время реакции у них разное, и способ применения, и даже области использования разные. Если вам пока ещё не надо, это не означает что инструмент плохой. Просто у вас нет задачи для этого инструмента.
-
Спрашивай, если чего непонятно. У меня где-то валяются старые версии, без математики. Просто М3 сейчас не применяю, а для М0 ось уже избыточна.
-
Наоборот, успешный проект со статической ос - признак неимоверной упоротости создателя. Это как собирать кораблик в бутылке. Статическая ос - это как моментальный дамп памяти обычной ос после инициализации и запуска всех необходимых работе задач. Вот только без самих функций управления задачами. В системе остаётся только переключатель. Так-как в такой памяти слишком много нулей - этот дамп ещё и сжимается для экономии места в флеше. Запуск подобной ос заключается в заполнении памяти данными из дампа, и переключением на первую задачу. А дальше оно само, полностью автономно от пользователя. Потому-что каких-либо средств отладки просто не предусмотрено.
-
Да вот фига. Работа с памятью, работа со стеком, работа с разными по типу потоками, удаление задач как бонус к простому переключению контекста. А сверху её логирование + динамическое распределение времени. Без всего этого работа превращается в страдание. Существуют ОС со статическими задачами. Где почти все операции выполняет перепроцессор во время сборки кода. Но с таким инструментарием можно создать только самый простой проект. Потому как памяти мало, а задач может быть много - они чисто физически не поместятся в память. Ковыряй если есть желание https://github.com/AVI-crak/Rtos_cortex
-
Уже сейчас есть публичная цена (это очень важно!!), и с небольшим количеством нервных клеток - его всё-же можно приобрести. Но цена у него... Как будто он границу десять раз пересекал.
-
Да не может такого быть. У меня всего две кошки - белая и чёрная. У белой 4 ноги, а у чёрной - две задних и две передних. И у них нет доступа к интернету. Мне например руст нравится, простой и компактный код. А вот, с регистрами проще работать на Си.
-
Важен порядок применения этих функций, а так-же версия модуля i2c - для выбранного чипа st. Назовите название вашего чипа st полностью, например stm32h750vbt6 (на корпусе написано). Название внешней ером полностью, от этого зависит набор команд. Ну а в целом - i2c должен быть оформлен отдельным Си файлом, отдельно от алгоритма чтения ером, который в свою очередь тоже отдельный файл. Так будет меньше путаницы и больше мобильности.
-
STM32 FreeRTOS UART бьются данные
AVI-crak ответил Fox_Sanchez тема в STM
Проверь в настройках FreeRTOS режим энергосбережения. Когда ядро уходит в сон с работающей периферией - иногда подобная фигня случается. -
Это напрямую к производителю. И не 60к за раз, а контракт на 60к в течении года или даже больше. То-есть посылки вам будут от 200 штук в неделю, оплата вперёд за чипы что находятся в производстве (там очень длинный конвейер). И штрафы за просрочку платежей - тоже в стоимости чипов на конвейере + упущенная прибыль от потенциального платёжеспособного клиента. Про запас они ничего не делают.
-
Если сами паяли - то первым делом нужно проверить контакты. У меня только с третьего раза получилось, после того как всё бессвинцовое удалил. Исправная USB3300 заметно кушает ток, с небольшим нагревом.
-
Тут странность более высокого масштаба - экономия энергии мк на фоне сварочного аппарата.
- 11 ответов
-
- usart
- handler mode
-
(и ещё 1 )
C тегом:
-
Что-то мне подсказывает - что ПП получилась красивой и простой, без обилия переходных, всего на двух слоях, и с огромной площадью.
-
Нет, это болезнь мозга под названием - адруино_мышление. От этой болезни можно вылечиться, если использовать голову по назначению. Xenia - Любая техническая документация печатается в строгой последовательности - всё что раньше важнее того что ниже. Собственно читать её нужно именно в такой последовательности, и на практике применять, и в алгоритмах использовать. Если первым идёт описание команды ресета и сна - то это первое что должно использоваться в обмене с дисплеем.
-
mantech - В моём понимании ногодрыгом считается всё что не является аппаратным параллельным RGB интерфейсом, или последовательным DSI. В том плане что появляются дополнительные обращения к внешним регистрам девайсов - для управления места, типа операции и данных для изменения. Даже на stm32f107, данные буфера подготовленные для заполнения области экрана - прекрасно переносятся с помощью dma и одного таймера. Кстати без таймера получается лажа - dma работает быстрее возможностей интерфейса экрана. Не ногодрыг - когда слои графики целиком и полностью находятся в линейной области памяти: с полным аппаратным доступом со стороны процессора, dma, dma2d, и ltdc интерфейса. Линейной области памяти - это значит что не требуется дополнительных программных операций по чтению из внешних накопителей данных, всё имеет свой прямой адрес без взаимного перекрытия.
-
Да что там за код такой, что так туго работает? Ногодрыг на stm32f107 - 60 кадров 320*240 : с песнями и танцами. Ногодрыг для stm32f746 - 60 кадров 480*320 : с песнями, танцами, цыганами и конями. Если в коде есть лишние слои абстракции, а сам код не имеет чёткого разделения на уровни - то получится аналог швейцарского ножа, у которого есть 100500 лезвий. Такой нож в условиях реального боя просто кидают во врага, он как кирпич лучше работает.
-
Для режима терминал - буфер вообще не нужен, используется аппаратный механизм самого дисплея - скролл на необходимое количество строк. А для вывода текста в произвольное место - нужно знать что там было раньше, иначе будут хвосты оставаться. Для этого "произвольное" место закрепляется в структуре описания экрана, с чётким описанием границ этого "произвольного" места. Для того чтобы в момент печати знать какой кусок экрана нужно очистить. И да, без структуры описания экрана - получится алгоритм рисования экрана. В принципе сгодится, если таких экранов один или два. Но если вариантов больше - то флеша может и не хватить. Гораздо проще один раз написать алгоритм, который будет обрабатывать структуру.
-
Рисовать в буфере, да ещё и в нескольких слоях - намного приятнее чем перерисовывать все слои программно на самом дисплее. Тем-более что чтение с дисплея за всегда тормозное. Можно не использовать слои и задний фон, но тогда области прорисовки будут иметь фиксированную площадь - для гарантированного уничтожения старого изображения. И всё это будет крутиться через структуру описания выбранного экрана - которую придётся проходить полностью, даже для рисования одной буквы. Это решение для супер-экономии, что-то типа боковой нижней полки в конце вагона поезда. Ехать будем, но без удовольствия.
-
Ну так и самого флеша может больше терабайта быть, разговор-то про дорогие модели. Один блок для дешмана, десять для фирменного ширпотреба, сотня для топа. А для гиков изолированная память в виде многослойного кеша - очень быстрая флешь малого объёма с высоким ресурсом перезаписи. Пока на флешь карте есть мк - скорость явно зависит от цены девайса.