ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Понедельник
20 мая
1391412
klen (10.01.2024 01:58, просмотров: 2280)
эво оно как! при портировании-прикручивании freertos к ch32v307 понадобилось реализовать функцию-орпределитель в каком режиме в данный момент работает ядро .. 

к примеру для ARM Cortex-M это делается весьма просто - чтением регистра процессора ipsr c помощью исрукции mrs

с riscv по аналогии думал сейчас возму регистр и прочитаю - смотрю специальные регистры которые есть в QingKeV4


и вот нигде кроме dcsr нет флагов режима. dcsr предназначен в целом для отладочных средств и не предназначен для использования в коде программы... при этом еще и прочитать его нельзя из режима пользователя - привилегированный регистр. стал я читать и спрашивать интернет с запросом "ЧЕЗАНАХ?ЕПТ!"

ниже вольный перевод раззсуждений на эту тему от типо знающих:


RISC-V намеренно не позволяет коду легко определить, в каком режиме он работает, потому что это дыра в виртуализации. В качестве общего принципа код должен быть разработан так чтоб не зависел от того в каком режиме он будет работать. Код приложения должен предполагать, что он находится в режиме U. Операционная система должна предполагать, что она находится в режиме S (на самом деле она может быть виртуализирована и работать в режиме U, а функционал, который в режиме U не может быть выполнен, перехватываются и эмулируются гипервизором в исключениях).

Можно было бы создать вызов операционной системы или вызов SBI, который извлекал бы предыдущий режим из MPP или SPP в mstatus и возвращал бы его в качестве результата. Но делать этого не рекомендуется.


сижу курю бамбук и думаю как выкрутится ...

батхерт свзан с тем что в FreeRTOS многие вызовы синхронизации имеют две версии - одна для режима потока, а друга для использования в коде обработчика прерывания. не получается абстракцию создать ... на cortex-m такой проблемы не возникло.