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

Arlleex

Свой
  • Постов

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

  • Посещение

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

    13

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

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

Репутация

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

2 Подписчика

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

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

Контакты

  • ICQ
    Array

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

17 489 просмотров профиля
  1. Тогда задача не решаема. Ибо Вы пытаетесь считать хэш двух разных прошивок - одной с еще неизвестным хэшем, другую - с известным и записанным.
  2. А разница? Хоть 100 байт, если места хватит. Насчет блочных хэшей - тоже не вижу проблемы, т.к. блок добивается нулями как на стороне программы подготовки бинарника, так и на стороне МК при "распаковке". Можно.
  3. Коллега имел в виду вот что Вот Вы скомпилировали свой hex-файл прошивки. В ней так или иначе предусмотрели 2 служебных поля (пока что пустых): Application Size и CRC32. 1. Дальше сторонней утилитой открываете бинарник и записываете в App Size размер файла прошивки (он же размер образа, лежащего во Flash МК потом). 2. Дальше считаете КС от начала до App Size включительно. 3. Дальше считаете КС до конца файла, исключая App CRC32. Полученную КС кладете в App CRC32 и сохраняете бинарник. Теперь при старте МК выполняет штатную процедуру загрузки. МК читает App Size, и точно так же как программа подготовки бинарника считает КС. Сверяет с записанной. Совпало - ок, нет - образ записан криво.
  4. Единым блоком считать КС не получится так. Особенно, если в качестве алгоритма взят CRC.
  5. Ну Вы же сами пишете программу - все от Вас только и зависит. Я после компиляции проекта в 2 зарезервированных места кладу размер прошивки в байтах и контрольную сумму, посчитанную, разумеется, без учета содержимого в контрольной сумме. Написал простейший сишный екзешник, запускаемый либо отдельно, либо прямо IDE-шкой после компиляции. В МК загрузчик знает адреса размера прошивки и контрольной суммы и делает все наоборот: читает размер, проходится по всей прошивке кроме контрольной суммы, контрольную сумму добавляет в конце и должен получиться 0. Ведь никто не мешает КС проверять не единым блоком, а разбитым на несколько отдельных участков памяти.
  6. И размера, и КС. Я кладу в неиспользуемые вектора, либо после таблицы векторов (в разных проектах исторически по-разному).
  7. Думаю, стоит подумать над перемещением размера прошивки с конца куда-нибудь в начало, в известные и неизменные адреса. Завтра прошивка стала занимать больше места и теперь заново искать адрес под размер образа - так себе.
  8. А в чем сложность? Не с позиции дартаньянизма спрашиваю - просто какое-то количество времени назад активно работал с цинком, как раз FreeRTOS-бареметал. SDK дает работающий BSP, не надо курить-настраивать DDR и кэш-регионы (самое сложное для стартапа) - все само "из коробки". При необходимости правится легко. И кстати: раз на цинке меряли задержку: а как меряли? Я лично не проверял (ибо не было нужды), но задержка между активизацией FIQ до смены режима CPU с User на FIQ - мгновенная. uCLinux.
  9. Сосед сверху. Надоел, падла.
  10. Если так удачно случилось, что периферия и доступы не пересекаются (физически или система построена так, чтобы гарантировать отсутствие таких пересечений во времени) - то это, несомненно, благотворительно повлияет на детерминизм, но не сведет предсказуемость задержек к 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) выполнения механизмы должны быть сделаны железно, а не программно. Конечно, если систему спроектировать так (и она сама по себе может позволить так спроектироваться), что внешние события разнесены во времени, никогда не накладываются, то, может, и можно получить какие-то вменяемые результаты. Но потом переход на другой МК и все... по новой?
  11. Это не рушит внутренности ОСРВ как таковой. Она как и обычно будет думать, что только она и запущена на проце и никаких прерываний вовсе нет. А они есть, и смещают идеальную временную диаграмму обработки событий и реакцкию на них.
  12. Попробуйте нагрузить систему большим количеством параллельно работающих шинных мастеров: DMA, Ethernet/USB DMA, алгоритмами, активно пользующимися групповой загрузкой/сохранением LDM/STM на реализациях CPU (я про Cortex-M) без возможности рестарта их после прерываний и т.д. Никаких 1, 2 и даже 10 тактов там не будет🙂 А потом, например, кэш-контроллеру указание обновить линию или вовсе регион памяти дали. Тыщу способов подвесить процессор на неопределенное количество тактов. А если еще чтоб универсально - про ARM7 с одноранговыми прерываниями и костылями в виде программной эмуляции вложений - тоже не забыть.
  13. Речь о какой RTOS? А вот FreeRTOS вводит критические секции на свои сервисные и функции ядра, пока ходит по спискам списков и т.д. и переключение контекста вообще не показатель "быстроты" ОСРВ при оценке задержек. На каком-нибудь ARM7 с обычными прерываниями FIQ/IRQ вход в критическую секцию запрещает все прерывания, а не только групповые, как у Cortex-M. Так что размазывать наносекунды по таким CPU, да еще и с системой кэшей, работающими DMA с борьбой за системную шину и т.д. дело, обреченное на провал, ИМХО🙂
  14. Если прям там реалтайм реалтаймович, то самым надежным способом будет поставить ПЛИС или SoC CPU + FPGA, на ней крутить этот самый реалтайм, а управлять CPU. Выцеплять даже микросекунды на обычных CPU/MCU - дело бесперспективное.
  15. FreeRTOS, как и наверное все ОС не предназначены для того, чтобы из нее "выходить". Потому что выходить некуда - контекст полностью разрушается. На деле Вам нужно пересмотреть механизм передачи управления прошивке, т.к. я не вижу ни одной причины отдавать управление из-под запущенной RTOS. Напишите простейшую прослойку-начальный-запускатель, который в зависимости от некого флажка в ОЗУ будет передавать управление той или иной области памяти - разумеется, с предварительной "оценкой" возможности запуска кода оттуда по неким признакам - по контрольной сумме и т.д. Из своей задачи ставите в этот флажок номер запускаемой программы и сбрасываете CPU.
×
×
  • Создать...