FFFF

это то понятно, что не равны. 32 очереди по 32 элемента в каждой это я привел в качестве примера. Если взять 1 элемент очереди равным 8 байтам и расположить в памяти все это как статические массивы, то весь этот список из очередей займет 8 килобайт. Это очень много, и это при том что не создашь более 32х задач одного приоритета. А по сути большая часть этой отведенной памяти не будет использоваться все время. И вот таких структур 2, по 8 килобайт, под готовые к выполнению задачи, и задачи блокированные. Итого 16 кб.

предположим задачи имеют приоритет, значение которого в диапазоне от 0 до 32х. Готовые к выполнению задачи раскиданы по 32м очередям, очередь не одна . Как эффективно представить 32 очереди в озу, чтобы не страдала производительность, и при этом была экономия памяти, и небыло ограничения на количество запускаемых задач

я пишу на ассемблере.:это значит что все делается руками, ни какой компилятор за меня ничего не сделает. Что хотелось узнать, какую стратегию при выделении памяти используют операционные системы с ограниченными ресурсами. Например RSX если не ошибаюсь была и с вытеснящей многозадачностью и многопользовательская и при этом минимум озу. Второй вопрос, я не до конца ясно представляю что из себя представляет память при динамическом выделении, насколько понимаю это называют кучей. Поясню, если читать книги, статьи, то собственно понятно пока не начнешь реализовывать. Между идеями и отрывочными представлениями которые в этих книгах представляют и тем как на самом деле все это реализовано пропасть.

Добрый день. В книгах по устройству операционных систем больше освещаются теоретические вопросы, много различных абстракций скрывающих реализацию на нижнем уровне, даже если все понятно в теории, то приступая к написанию кода встает много вопросов как это правильно и эффективно реализовать давно уже во мне тлело желание написать небольшую операционную систему, использую ассемблер, выбор пал на микроконтроллер с ядром cortex m4 под ядро операционной системы я выделил участок ОЗУ объемом в 64 Кбайта. Предположим ОС будет многозадачной, вытесняющая многозадачность. задачам назначаются приоритеты из диапазона 0-32. Сначала была мысль создать 32 статических массива под задачи в состоянии готовности, и 32 массива под блокированные задачи. 1 массив состоит из 32 8байтных элементов, итого 256 байт на 1 очередь с определенным приоритетом, 256 х 32 очереди = 8 Кбайт на 1 структуру, а структур две, активных и блокированных задач. Итого 16 Кбайт. а под ядро отведено всего 64 Кбайта. Плюс ко всему а что если возникнет задач одного приоритета более чем 32, их не поместить в 32 элементный массив. а если каких то задач одного приоритета мало, например низкоприоритетных то выходит что память под них зарезервирована, но по сути не используется. Возникает вопрос как были организованы операционные системы 70-80х годов с ограниченными ресурсами Динамически выделяли память? или как это устроено например во FreeRTOS, у нее если не изменяет память 256 приоритетов если динамически выделять память мне не совсем понятно как выглядит все это в ОЗУ, например, выделили память под строку, записали в память, через время выделили память под некую переменную, или структуру, потом под некий массив, а если он динамический? а потом вновь под чтото выделили память, и возникла необходимость что то еще положить в динамический массив, куда это все пишется, рядом с последней записью в памяти? то есть это выглядит как некая сплошная каша из указателей и данных принадлежащих разным задачам? как я понимаю чтобы отслеживать все это и вести учет необходимо строить еще кучу структур, а чтобы использовать дополнительное процессорное время как же выделялась память внутри операционных систем 70-80х годов с ограниченными ресурсами, какие там были алгоритмы вопросы видимо идиотские для большинства, но хотелось бы разобраться. заранее спасибо

для чего в серии STM32F4 оперативная память разделена на неравные банки SRAM1, SRAM2, SRAM3, 112К, 16К, 64К что дает это разделение, для чего какой банк рекомендуется использовать?

собственно я сам до этого дошел, думаю это лежит на поверхности я Си не знаю, 516 строка для меня темный лес

если передавать номер функции в регистре перед вызовом SVC то можно и больше чем 256 еще и быстрее будет. надо лишь в регистр ввести значение необходимой функции. 2 команды если число больше 255, не придется доставать значение из SVC в обработчике

А меня жаба душит транжирить SVC на такое... Вообще не хочу, чтобы FreeRTOS использовала SVC. а Вы как бы распорядились SVC?

спасибо. и как это сделано в любой rtos? системная функция вызывается прямо в обработчике исключения и возвращается в него? я с Си плохо знаком, пробираться в дебрях rtos для меня мучение

В cortex M есть команда вызова системных функций, SVC при исполнении этой команды процессор переходит в обработчик исключения супервизора. что должно происходить в обработчике исключения супервизора, вызов системной функции прямо в обработчике? как то странно это. логичнее на мой взгляд было бы выйти из обработчика передав управление вызываемой функции в привилегированном режиме. незнаю как только реализовать это попроще как правильно должно это все работать по задумкам разработчиков?

помогите понять что имели ввиду в Reference manual RM0090 от ST. в референсе для STM32F42xxx and STM32F43xxx написано: It is recommended to enter Over-drive mode when the application is not running critical tasks and when the system clock source is either HSI or HSE. To optimize the configuration time, enable the Over-drive mode during the PLL lock phase. а немного ниже It is recommended to exit from Over-drive mode when the application is not running critical tasks and when the system clock source is either HSI or HSE.There are two sequences that allow exiting from over-drive mode режим Over-drive это разгон МК до 180 МГц переводил гуглом, вот что он выдает Рекомендуется использовать режим Over-drive, если приложение не работает критически Рекомендуется выйти из режима Over-drive, если приложение не работает критически задач так в каком случае используется режим, в критических задачах или в некритических? или имелось ввиду что вход и выход из режима следует осуществлять в периоды когда не выполняются критические задачи?

Добрый день подскажите между какими выводами необходимо разместить конденсаторы по 0.1мкф у SDRAM, картинка ниже логично предположить что конденсаторы ставятся между выводами 1-54, 14-41 и 27-28, это VDD-VSS А как быть с VDDQ-VSSQ ? Как ставить конденсатор, между выводами 3-6 или 3-52 ?

меня интересуют дисплеи без внутренней GRAM, насколько я понимаю интерфейс MIPI-DPI и LTDC разработаны именно для работы с такими дисплеями, в даташитах на такие дисплеи указывают чаще интерфейс как Digital или 24RGB. в общем, опять же насколько я понимаю это дисплеи для потокового вывода изображения. вот мне и хочется узнать необходимо ли постоянно выводить изображение на такой дисплей с определенной частотой, даже если это статическая картинка, или можно выводить изображение по мере необходимости, как в дисплеях с GRAM

добрый день. пытаюсь вникнуть как работает контроллер LTDC в микроконтроллерах STM, возникает куча вопросов. первый вопрос касается даже не столько LTDC сколько самих дисплеев с интерфейсом MIPI-DPI, непонятно вот что, обязательно ли необходимо постоянно обновлять выводимое изображение (например с частотой в 60 Гц) если это статическая картинка? или можно вывести изображение и обновлять его только когда это необходимо? или дисплеи так устроены что необходимо постоянно выводить изображение с определенной частотой? спасибо