Перейти к содержанию
    

Arlleex

Свой
  • Постов

    5 738
  • Зарегистрирован

  • Посещение

  • Победитель дней

    13

Arlleex стал победителем дня 20 марта

Arlleex имел наиболее популярный контент!

Репутация

129 Очень хороший

2 Подписчика

Информация о Arlleex

  • Звание
    Гуру
    Гуру

Контакты

  • ICQ
    Array

Посетители профиля

17 481 просмотр профиля
  1. Думаю, стоит подумать над перемещением размера прошивки с конца куда-нибудь в начало, в известные и неизменные адреса. Завтра прошивка стала занимать больше места и теперь заново искать адрес под размер образа - так себе.
  2. А в чем сложность? Не с позиции дартаньянизма спрашиваю - просто какое-то количество времени назад активно работал с цинком, как раз FreeRTOS-бареметал. SDK дает работающий BSP, не надо курить-настраивать DDR и кэш-регионы (самое сложное для стартапа) - все само "из коробки". При необходимости правится легко. И кстати: раз на цинке меряли задержку: а как меряли? Я лично не проверял (ибо не было нужды), но задержка между активизацией FIQ до смены режима CPU с User на FIQ - мгновенная. uCLinux.
  3. Сосед сверху. Надоел, падла.
  4. Если так удачно случилось, что периферия и доступы не пересекаются (физически или система построена так, чтобы гарантировать отсутствие таких пересечений во времени) - то это, несомненно, благотворительно повлияет на детерминизм, но не сведет предсказуемость задержек к 100%. И тут тогда уже придется не абстрагироваться, а называть конкретный тип CPU и штудировать его возможности. Реально критичные ко времени процессы выполняются на аппаратном уровне - ПЛИСами или возможностями периферии. CPU тут лишь как связующее звено для управления такой периферией. Исходят из расчета на достаточную производительность CPU с запасом, чтобы, например, успеть подготовить данные для отправки на эту самую "быструю" периферию. Попытка ориентироваться на такты CPU была хорошей практикой в простых МК типа PIC/AVR - вспомним программаторы USB 1.0 на AVR-ках, там времянка ногодрыжного формирования всех USB-сигналов как раз сделана на ассемблере с учетом определенной частоты CPU и CPI инструкций. Этот способ никак не годится для "толстых" микроконтроллеров и тем более Application CPU, хоть даже Real-Time Cortex-R. В последнем ядре, безусловно, есть свои механизмы, но они не гарантируют никаких +/- 1..2..5 тактов. Выполниться то выполнится. Если в CPU не поддерживаются прерываемые LDM/STM, то кирдык капут. Если такая операция начала шинную транзакцию, то возникшее прерывание будет ждать ее завершения. В Cortex-M вопрос прерываемости/перезапуска этих инструкций implementation-defined. Стоит ли игра свеч? Для ARM (настоящих, а не Cortex-M, т.к. этот профиль настоящим ARM не является), в которых из CPU торчит только FIQ/IRQ, нет таких разделений - я заглянул в порт FreeRTOS под Cortex-A9 - запрет прерываний, реализуемый критической секцией, реализуется выключением и FIQ, и IRQ. В ядре ОСРВ? Нет, конечно. С чего ей там быть?🙂 Да и как она должна тогда выглядеть, чтобы всем подходила и всегда работала исправно? ОСРВ лишь гарантирует, что реакция на некое воздействие произойдет за какое-то гарантированное время. Это время с запасом должно покрывать время всяких переключений контекстов, шинных блокировок CPU и других "непрошенных" задержек. Критичные к задержке (тем более в области десятков - под сотню тактов CPU) выполнения механизмы должны быть сделаны железно, а не программно. Конечно, если систему спроектировать так (и она сама по себе может позволить так спроектироваться), что внешние события разнесены во времени, никогда не накладываются, то, может, и можно получить какие-то вменяемые результаты. Но потом переход на другой МК и все... по новой?
  5. Это не рушит внутренности ОСРВ как таковой. Она как и обычно будет думать, что только она и запущена на проце и никаких прерываний вовсе нет. А они есть, и смещают идеальную временную диаграмму обработки событий и реакцкию на них.
  6. Попробуйте нагрузить систему большим количеством параллельно работающих шинных мастеров: DMA, Ethernet/USB DMA, алгоритмами, активно пользующимися групповой загрузкой/сохранением LDM/STM на реализациях CPU (я про Cortex-M) без возможности рестарта их после прерываний и т.д. Никаких 1, 2 и даже 10 тактов там не будет🙂 А потом, например, кэш-контроллеру указание обновить линию или вовсе регион памяти дали. Тыщу способов подвесить процессор на неопределенное количество тактов. А если еще чтоб универсально - про ARM7 с одноранговыми прерываниями и костылями в виде программной эмуляции вложений - тоже не забыть.
  7. Речь о какой RTOS? А вот FreeRTOS вводит критические секции на свои сервисные и функции ядра, пока ходит по спискам списков и т.д. и переключение контекста вообще не показатель "быстроты" ОСРВ при оценке задержек. На каком-нибудь ARM7 с обычными прерываниями FIQ/IRQ вход в критическую секцию запрещает все прерывания, а не только групповые, как у Cortex-M. Так что размазывать наносекунды по таким CPU, да еще и с системой кэшей, работающими DMA с борьбой за системную шину и т.д. дело, обреченное на провал, ИМХО🙂
  8. Если прям там реалтайм реалтаймович, то самым надежным способом будет поставить ПЛИС или SoC CPU + FPGA, на ней крутить этот самый реалтайм, а управлять CPU. Выцеплять даже микросекунды на обычных CPU/MCU - дело бесперспективное.
  9. FreeRTOS, как и наверное все ОС не предназначены для того, чтобы из нее "выходить". Потому что выходить некуда - контекст полностью разрушается. На деле Вам нужно пересмотреть механизм передачи управления прошивке, т.к. я не вижу ни одной причины отдавать управление из-под запущенной RTOS. Напишите простейшую прослойку-начальный-запускатель, который в зависимости от некого флажка в ОЗУ будет передавать управление той или иной области памяти - разумеется, с предварительной "оценкой" возможности запуска кода оттуда по неким признакам - по контрольной сумме и т.д. Из своей задачи ставите в этот флажок номер запускаемой программы и сбрасываете CPU.
  10. Вот специально же разрабатывали ядро так, чтобы нельзя было лезть туда куда не просят🙂 По теме: после старта ОС переводит CPU в непривелигированный режим, поэтому просто так менять значение MSP нельзя. Как и некоторых (многих) системных регистров CPU. Можно, конечно, сколхозить, но вам это решение не понравится)) А вообще можно, конечно, в исходнике порта FreeRTOS одну чиселку поправить, но это опять же - не хорошо.
  11. Речь про программный, а если еще "глобальнее" - абстрактный регулятор с отсутствующими природными ограничениями.
  12. Это называется адаптивный регулятор🙂 На самом деле любой регулятор, в котором есть хотя бы строчки ограничения выходного сигнала, уже, по факту, "не классический" ПИД, а с прибамбасами.
  13. Не надо - в любых аппноутах именитых фирм все тоже с ног на голову перепутано. Негласно считается, что тот, кому надо - разберется.
  14. Да ладно вам. Весь мир уже настолько мешает в одну кашу все эти скорости, что попытка добраться до реальной битовой скорости порой проходит через лютые дебри. И попытка опираться на какую либо "систематизацию" при встрече с характеристиками "бод" или "бит/с" с разными приставками просто не имеет смысла. P.S. Даже всем известный Fast Ethernet 100 уже противоречит "скорости изменения сигнала в канале связи, не привязанную к протоколу"🙂
×
×
  • Создать...