Jump to content

    

AVI-crak

Участник
  • Content Count

    265
  • Joined

  • Last visited

Community Reputation

0 Обычный

About AVI-crak

  • Rank
    Местный

Recent Profile Visitors

2090 profile views
  1. У вас не получится использовать все имеющиеся прерывания чисто физически. Потому как не получится задействовать всю имеющуюся периферию - ног мк не хватит. Более того - периферия условно делится на быструю и медленную. Можно одним единственным быстрым прерыванием намертво повесить мк, тогда как другие просто не способны срабатывать быстро.
  2. Вооот, а иногда даже не 5% - а ниже требуемого времени на переключение, и тогда оно зависает в непонятном состоянии. Просто для пользователей фриортос, добровольное переключение - это настолько редкая команда, что её почти никто не использует. Для моей ос, добровольное переключение os_pass() - наверное самая важная команда. От неё зависит общее быстродействие всей системы. И применяется она буквально во всех местах, где требуется ожидание внешней реакции. При этом системный таймер на 1мс может оказаться в тысячи раз медленнее шрейдера задач (когда нечего делать). Но и проверять состояние спящих тысячу раз за 1мс - тоже глупо (в системной задаче). Потому таймеров две штуки, и вот они действительно никак не связаны между собой.
  3. Сколько времени назначить новой задаче при добровольном переключении? Остаток неиспользованного времени, или пересчитать новое время - с перезапуском таймера?
  4. И что, системное время при этом не сбивается? А то у меня был такой промежуточный вариант на одном таймере (сейчас два). Для коррекции системного времени приходилось делать массу телодвижений, да ещё и на асме(в котором я потом вообще запутался) . Но ошибка всё равно накапливалась с очень слабым прогнозом (в + или -), отчего счётчик системного времени превращался в показометр попугаев. То-есть приходилось запускать второй счётчик реального времени, чтобы хоть как-то выйти из положения. Сейчас два физических счётчика: время работы задач, и системное время. Работают независимо и синхронно, без ошибок и лишнего кода.
  5. Любую не получится, точнее работать будет - но в N раз медленнее. Тут весь прикол - с какой стороны происходит управление. Любая ос с приоритетами и вытеснением - даёт задаче фиксированное время работы. Это время фиксировано, буквально. Даже если задаче нечего делать, и она готова отдать своё время - всё равно придётся ждать стандартные 1мс + остальные задачи + работу планировщика. На новом витке эта задача уже будет с иным приоритетом, и может даже не запустится. Но первоначальная задержка всё-таки сохраниться. А там ещё и гонка появится - то ещё удовольствие. Гораздо проще когда задача сама решает свою судьбу, вот прямо здесь и сейчас. Тем-более что это решение получается гораздо более быстрым чем через работу планировщика.
  6. Есть два основных подхода решения почти всех задач: по важности (когда уже жопа горит), и к моменту актуальности готового решения. Вот когда нужно прямо сейчас: начинается запрещение прерываний, кастование приоритетами, и даже разгон частоты мк. Девайсы с таким подходом обычно тормозят в самых неожиданных местах, непредсказуемо. Наличие и тип ос не влияет на конечный результат. В любом случае получится дёрганный уродец, без шанса понравится пользователю. Второй вариант когда все активные задачи выполняются с равным приоритетом запуска но разным временем работы. Нормированная по времени задержка получается почти автоматически (если не делать глупостей). А тройной буфер спасает любую безвыходную ситуацию. Я говорю про активные задачи, которым есть чего делать - все остальные либо отправляются в сон, либо замораживаются, либо отдают своё время чтобы не отсвечивать. Всё это есть в вытесняющей ос, но не столь гибко как у меня.
  7. Просто есть несколько типов ос: с приоритетами в задачах, и с переключением по таймеру, и смешанное управление. Они разные, и время реакции у них разное, и способ применения, и даже области использования разные. Если вам пока ещё не надо, это не означает что инструмент плохой. Просто у вас нет задачи для этого инструмента.
  8. Спрашивай, если чего непонятно. У меня где-то валяются старые версии, без математики. Просто М3 сейчас не применяю, а для М0 ось уже избыточна.
  9. Наоборот, успешный проект со статической ос - признак неимоверной упоротости создателя. Это как собирать кораблик в бутылке. Статическая ос - это как моментальный дамп памяти обычной ос после инициализации и запуска всех необходимых работе задач. Вот только без самих функций управления задачами. В системе остаётся только переключатель. Так-как в такой памяти слишком много нулей - этот дамп ещё и сжимается для экономии места в флеше. Запуск подобной ос заключается в заполнении памяти данными из дампа, и переключением на первую задачу. А дальше оно само, полностью автономно от пользователя. Потому-что каких-либо средств отладки просто не предусмотрено.
  10. Да вот фига. Работа с памятью, работа со стеком, работа с разными по типу потоками, удаление задач как бонус к простому переключению контекста. А сверху её логирование + динамическое распределение времени. Без всего этого работа превращается в страдание. Существуют ОС со статическими задачами. Где почти все операции выполняет перепроцессор во время сборки кода. Но с таким инструментарием можно создать только самый простой проект. Потому как памяти мало, а задач может быть много - они чисто физически не поместятся в память. Ковыряй если есть желание https://github.com/AVI-crak/Rtos_cortex
  11. Уже сейчас есть публичная цена (это очень важно!!), и с небольшим количеством нервных клеток - его всё-же можно приобрести. Но цена у него... Как будто он границу десять раз пересекал.
  12. stm32 eeprom

    Да не может такого быть. У меня всего две кошки - белая и чёрная. У белой 4 ноги, а у чёрной - две задних и две передних. И у них нет доступа к интернету. Мне например руст нравится, простой и компактный код. А вот, с регистрами проще работать на Си.
  13. stm32 eeprom

    Важен порядок применения этих функций, а так-же версия модуля i2c - для выбранного чипа st. Назовите название вашего чипа st полностью, например stm32h750vbt6 (на корпусе написано). Название внешней ером полностью, от этого зависит набор команд. Ну а в целом - i2c должен быть оформлен отдельным Си файлом, отдельно от алгоритма чтения ером, который в свою очередь тоже отдельный файл. Так будет меньше путаницы и больше мобильности.
  14. Проверь в настройках FreeRTOS режим энергосбережения. Когда ядро уходит в сон с работающей периферией - иногда подобная фигня случается.
  15. Это напрямую к производителю. И не 60к за раз, а контракт на 60к в течении года или даже больше. То-есть посылки вам будут от 200 штук в неделю, оплата вперёд за чипы что находятся в производстве (там очень длинный конвейер). И штрафы за просрочку платежей - тоже в стоимости чипов на конвейере + упущенная прибыль от потенциального платёжеспособного клиента. Про запас они ничего не делают.