-
Постов
367 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные AVI-crak
-
-
4 hours ago, Aldec said:
В армах более 200 прерываний и периферии если они все будут разрешены то контролер повиснет изза тормозов .
У вас не получится использовать все имеющиеся прерывания чисто физически. Потому как не получится задействовать всю имеющуюся периферию - ног мк не хватит.
Более того - периферия условно делится на быструю и медленную. Можно одним единственным быстрым прерыванием намертво повесить мк, тогда как другие просто не способны срабатывать быстро.
-
8 hours ago, haker_fox said:
Но тогда выходит абсурд: если одна задача отдала управление за 5% от временного слота
Вооот, а иногда даже не 5% - а ниже требуемого времени на переключение, и тогда оно зависает в непонятном состоянии. Просто для пользователей фриортос, добровольное переключение - это настолько редкая команда, что её почти никто не использует.
Для моей ос, добровольное переключение os_pass() - наверное самая важная команда. От неё зависит общее быстродействие всей системы. И применяется она буквально во всех местах, где требуется ожидание внешней реакции. При этом системный таймер на 1мс может оказаться в тысячи раз медленнее шрейдера задач (когда нечего делать). Но и проверять состояние спящих тысячу раз за 1мс - тоже глупо (в системной задаче).
Потому таймеров две штуки, и вот они действительно никак не связаны между собой.
-
1 minute ago, haker_fox said:
А как оно может сбиться?
Сколько времени назначить новой задаче при добровольном переключении? Остаток неиспользованного времени, или пересчитать новое время - с перезапуском таймера?
-
4 minutes ago, Forger said:
Это не так, задача может принудительно в любой момент
И что, системное время при этом не сбивается? А то у меня был такой промежуточный вариант на одном таймере (сейчас два). Для коррекции системного времени приходилось делать массу телодвижений, да ещё и на асме(в котором я потом вообще запутался) . Но ошибка всё равно накапливалась с очень слабым прогнозом (в + или -), отчего счётчик системного времени превращался в показометр попугаев. То-есть приходилось запускать второй счётчик реального времени, чтобы хоть как-то выйти из положения.
Сейчас два физических счётчика: время работы задач, и системное время. Работают независимо и синхронно, без ошибок и лишнего кода.
-
14 minutes ago, haker_fox said:
Насколько я понимаю, можно взять любую ОС, создать N задач с равными приоритетами. И они будут переключаться по очереди.
Любую не получится, точнее работать будет - но в N раз медленнее. Тут весь прикол - с какой стороны происходит управление. Любая ос с приоритетами и вытеснением - даёт задаче фиксированное время работы. Это время фиксировано, буквально. Даже если задаче нечего делать, и она готова отдать своё время - всё равно придётся ждать стандартные 1мс + остальные задачи + работу планировщика. На новом витке эта задача уже будет с иным приоритетом, и может даже не запустится. Но первоначальная задержка всё-таки сохраниться. А там ещё и гонка появится - то ещё удовольствие.
Гораздо проще когда задача сама решает свою судьбу, вот прямо здесь и сейчас. Тем-более что это решение получается гораздо более быстрым чем через работу планировщика.
-
Есть два основных подхода решения почти всех задач: по важности (когда уже жопа горит), и к моменту актуальности готового решения.
Вот когда нужно прямо сейчас: начинается запрещение прерываний, кастование приоритетами, и даже разгон частоты мк. Девайсы с таким подходом обычно тормозят в самых неожиданных местах, непредсказуемо. Наличие и тип ос не влияет на конечный результат. В любом случае получится дёрганный уродец, без шанса понравится пользователю.
Второй вариант когда все активные задачи выполняются с равным приоритетом запуска но разным временем работы. Нормированная по времени задержка получается почти автоматически (если не делать глупостей). А тройной буфер спасает любую безвыходную ситуацию. Я говорю про активные задачи, которым есть чего делать - все остальные либо отправляются в сон, либо замораживаются, либо отдают своё время чтобы не отсвечивать. Всё это есть в вытесняющей ос, но не столь гибко как у меня.
-
3 hours ago, Aldec said:
Переключение задач таймером это не вариант
Просто есть несколько типов ос: с приоритетами в задачах, и с переключением по таймеру, и смешанное управление. Они разные, и время реакции у них разное, и способ применения, и даже области использования разные.
Если вам пока ещё не надо, это не означает что инструмент плохой. Просто у вас нет задачи для этого инструмента.
-
On 10/1/2020 at 8:23 PM, Картошка said:
Надеюсь что-то выковырять получится.
Спрашивай, если чего непонятно. У меня где-то валяются старые версии, без математики. Просто М3 сейчас не применяю, а для М0 ось уже избыточна.
-
3 hours ago, jcxz said:
Это всего лишь - признак низкой квалификации написателя. Не умеющего грамотно распределить память.
И что такое "статические задачи"?
Наоборот, успешный проект со статической ос - признак неимоверной упоротости создателя. Это как собирать кораблик в бутылке.
Статическая ос - это как моментальный дамп памяти обычной ос после инициализации и запуска всех необходимых работе задач. Вот только без самих функций управления задачами. В системе остаётся только переключатель. Так-как в такой памяти слишком много нулей - этот дамп ещё и сжимается для экономии места в флеше. Запуск подобной ос заключается в заполнении памяти данными из дампа, и переключением на первую задачу. А дальше оно само, полностью автономно от пользователя. Потому-что каких-либо средств отладки просто не предусмотрено.
-
1 hour ago, Картошка said:
Что-то еще меньше по коду и функционалу. // Нужно именно простейший функционал по выполнению задачи с вытеснением по лимиту времени и все, больший функционал - излишки.
Реализация двух функций было бы достаточно.
Да вот фига. Работа с памятью, работа со стеком, работа с разными по типу потоками, удаление задач как бонус к простому переключению контекста. А сверху её логирование + динамическое распределение времени. Без всего этого работа превращается в страдание.
Существуют ОС со статическими задачами. Где почти все операции выполняет перепроцессор во время сборки кода. Но с таким инструментарием можно создать только самый простой проект. Потому как памяти мало, а задач может быть много - они чисто физически не поместятся в память.
Ковыряй если есть желание https://github.com/AVI-crak/Rtos_cortex
-
11 hours ago, haker_fox said:
А вы уверены, что через 20 лет можно будет купить этот чудо-микроконтроллер?
Уже сейчас есть публичная цена (это очень важно!!), и с небольшим количеством нервных клеток - его всё-же можно приобрести. Но цена у него... Как будто он границу десять раз пересекал.
-
5 hours ago, ivan dimir said:
Где-то я вас видел.
Да не может такого быть. У меня всего две кошки - белая и чёрная. У белой 4 ноги, а у чёрной - две задних и две передних. И у них нет доступа к интернету.
6 hours ago, haker_fox said:На дворе уже 20-й год) Си сдаёт позиции.
Мне например руст нравится, простой и компактный код. А вот, с регистрами проще работать на Си.
-
11 hours ago, ivan dimir said:
И в Кубе и на cmsis похожие функции .
Важен порядок применения этих функций, а так-же версия модуля i2c - для выбранного чипа st. Назовите название вашего чипа st полностью, например stm32h750vbt6 (на корпусе написано). Название внешней ером полностью, от этого зависит набор команд.
Ну а в целом - i2c должен быть оформлен отдельным Си файлом, отдельно от алгоритма чтения ером, который в свою очередь тоже отдельный файл. Так будет меньше путаницы и больше мобильности.
-
On 8/29/2020 at 4:46 AM, Fox_Sanchez said:
Есть проект с на STM32F429 с FreeRTOS. Там несколько не сильно загруженных задач.
Проверь в настройках FreeRTOS режим энергосбережения. Когда ядро уходит в сон с работающей периферией - иногда подобная фигня случается.
-
17 hours ago, a123-flex said:
Я вот не готов 60к штук купить, актуально.
Это напрямую к производителю. И не 60к за раз, а контракт на 60к в течении года или даже больше. То-есть посылки вам будут от 200 штук в неделю, оплата вперёд за чипы что находятся в производстве (там очень длинный конвейер). И штрафы за просрочку платежей - тоже в стоимости чипов на конвейере + упущенная прибыль от потенциального платёжеспособного клиента.
Про запас они ничего не делают.
-
On 6/19/2020 at 1:10 AM, 1234Alex said:
Как-бы уже и идеи закончились.
Если сами паяли - то первым делом нужно проверить контакты. У меня только с третьего раза получилось, после того как всё бессвинцовое удалил. Исправная USB3300 заметно кушает ток, с небольшим нагревом.
-
Тут странность более высокого масштаба - экономия энергии мк на фоне сварочного аппарата.
-
11 hours ago, Baser said:
Сербы применили STM32F746ZG - отлично!
Что-то мне подсказывает - что ПП получилась красивой и простой, без обилия переходных, всего на двух слоях, и с огромной площадью.
-
2 hours ago, mantech said:
ногодрыг - это программный цикл по которому откуда-нибудь данные перекидываются в порт и программно формируется защелкивание и т.д.
Нет, это болезнь мозга под названием - адруино_мышление. От этой болезни можно вылечиться, если использовать голову по назначению.
Xenia -
Любая техническая документация печатается в строгой последовательности - всё что раньше важнее того что ниже. Собственно читать её нужно именно в такой последовательности, и на практике применять, и в алгоритмах использовать.
Если первым идёт описание команды ресета и сна - то это первое что должно использоваться в обмене с дисплеем.
-
mantech - В моём понимании ногодрыгом считается всё что не является аппаратным параллельным RGB интерфейсом, или последовательным DSI. В том плане что появляются дополнительные обращения к внешним регистрам девайсов - для управления места, типа операции и данных для изменения. Даже на stm32f107, данные буфера подготовленные для заполнения области экрана - прекрасно переносятся с помощью dma и одного таймера. Кстати без таймера получается лажа - dma работает быстрее возможностей интерфейса экрана.
Не ногодрыг - когда слои графики целиком и полностью находятся в линейной области памяти: с полным аппаратным доступом со стороны процессора, dma, dma2d, и ltdc интерфейса. Линейной области памяти - это значит что не требуется дополнительных программных операций по чтению из внешних накопителей данных, всё имеет свой прямой адрес без взаимного перекрытия.
-
15 hours ago, Baser said:
Да и сербский "ногодрыг" привел к тому, что скорость перерисовки экрана только 1-2 раза в секунду.
Да что там за код такой, что так туго работает?
Ногодрыг на stm32f107 - 60 кадров 320*240 : с песнями и танцами.
Ногодрыг для stm32f746 - 60 кадров 480*320 : с песнями, танцами, цыганами и конями.
Если в коде есть лишние слои абстракции, а сам код не имеет чёткого разделения на уровни - то получится аналог швейцарского ножа, у которого есть 100500 лезвий. Такой нож в условиях реального боя просто кидают во врага, он как кирпич лучше работает.
-
2 hours ago, Xenia said:
А возможен ли
Для режима терминал - буфер вообще не нужен, используется аппаратный механизм самого дисплея - скролл на необходимое количество строк.
А для вывода текста в произвольное место - нужно знать что там было раньше, иначе будут хвосты оставаться. Для этого "произвольное" место закрепляется в структуре описания экрана, с чётким описанием границ этого "произвольного" места. Для того чтобы в момент печати знать какой кусок экрана нужно очистить.
И да, без структуры описания экрана - получится алгоритм рисования экрана. В принципе сгодится, если таких экранов один или два. Но если вариантов больше - то флеша может и не хватить. Гораздо проще один раз написать алгоритм, который будет обрабатывать структуру.
-
1 hour ago, Xenia said:
Соответственно этому, я и от графических библиотек ожидаю примитивов, которые бы именно на дисплее могли что-то рисовать, а не в памяти SDRAM.
Рисовать в буфере, да ещё и в нескольких слоях - намного приятнее чем перерисовывать все слои программно на самом дисплее. Тем-более что чтение с дисплея за всегда тормозное.
Можно не использовать слои и задний фон, но тогда области прорисовки будут иметь фиксированную площадь - для гарантированного уничтожения старого изображения. И всё это будет крутиться через структуру описания выбранного экрана - которую придётся проходить полностью, даже для рисования одной буквы. Это решение для супер-экономии, что-то типа боковой нижней полки в конце вагона поезда. Ехать будем, но без удовольствия.
-
1 hour ago, digital said:
сотня блоков по 4Мбайта это почти полгига оперативки
Ну так и самого флеша может больше терабайта быть, разговор-то про дорогие модели.
Один блок для дешмана, десять для фирменного ширпотреба, сотня для топа. А для гиков изолированная память в виде многослойного кеша - очень быстрая флешь малого объёма с высоким ресурсом перезаписи. Пока на флешь карте есть мк - скорость явно зависит от цены девайса.
Тестирование SDRAM. Мистическая проблема.
в ARM
Опубликовано · Пожаловаться
Ну не знаю, A0 это всегда SDRAM_A0. Сама память отдаёт по младшему адресу все 16 бит разом. DQM0, DQM1 - это как-раз для управления отдельными байтами. Периферийный блок sdram в ST - самостоятельно рулит адресацию, если его верно настроить.
А то что на схеме приклеено - просто не должно работать, внешний чип памяти инициализируется адресными линиями.