klen (15.06.2026 19:04, просмотров: 144) ответил Nikolay_Po на Мне до обнаружения этой очевидности пара недель потребовалась.
Чувствую себя как тот кадр, у которого не получается
программировать МК...-
- Есть вопросы. 1. Как при выходе из прерывания, при включённом HPE,
если это прерывание само меняет контекст и само восстанавливает по
своему разумению те же регистры, что восстанавливает и HPE,
оставить контекст RTOS для задачи, а не восстановленое HPE
состояние регистров на момент входа в прерывание? Я знаю только
один способ - установить GIHWSTKNEN и выйти, предварительно сбросив
MIE, чтобы защититься от вложенности. Nikolay_Po(579 знак., 16.06.2026 17:13)
- Сегодня делал ретроспективное ревью кода примера FreeRTOS от WCH. Ранее от меня ускользнуло, но сейчас, на текущей глубине раскопок, бросилось в глаза - у них включено HPE и они ставят GIHWSTKNEN в прерывании переключателя контекста. Единственное что, не защищают этот бит от вложенных прерываний, потому оно и глючило у меня при попытке использовать вложенность. - Nikolay_Po(17.06.2026 16:56)
- У меня такая переключалка выходит, в части блокировки прерываний приоритетом до RTOS API включительно: Nikolay_Po(1443 знак., 16.06.2026 16:46)
- Контекст сохраняется не где-то каг-то, а в прерывании ;-). А из прерывания переключения контекста он уходит не строго обратно, а уже в другую задачу. А таг всё верно ;-). - =AlexD=(16.06.2026 10:24)
- Дык, стек РТОС, это доступ через какой-нить индексный регистр,
программно, а стек вызовов-прерываний проца, это чисто механическая
штука. Прерывания, вообще, для кода, прозрачны, он их не осчучает:
откуда-то, из параллельной вселенной, ему падают флаги и данные. - mse homjak(15.06.2026 19:15)
- я разумею почти так же ( сохранение регистров проца при эксепшене
не совсем аппаратная штука - традиционно компилятор генерит пролог
и эпилог ). вопрос в том где связзь HPE и кода сохранения и подъема
контекста задачи ОС? я утверждаю что её нет. но это не точно :)
думаю что суть в правильном назначении приоритетов прерываниям - у
меня в этом было откровения после которых все заработало с HPE - klen(15.06.2026 19:43)
- Меня что беспокоит: если я выхожу из прерывания, при входе в
которое было включено HPE, то при выходе, регистры, сохраняемые
аппаратно, восстановятся на значения в момент входа. Как быть, в
таком случае, с прерыванием, которое переключало контекст задачи и
при выходе должно оставить новые значения регистров, не те, чтобы
были на момент входа? Разве HPE не будет препятствовать сохранению
новых значений регистров, если они - контекст задачи RTOS, на
которую только что Nikolay_Po(14 знак., 16.06.2026 17:16)
- Дык, этта... Контекст задачи должэн переключать планировщик. - mse homjak(16.06.2026 18:46)
- Ну так все порты FreeRTOS на RISC-V (да и на прочие схожие по
возможностям контроллера прерываний чипы/архитектуры), используют
для переключения контекста прерывание. Контекст прерывания (содержимое набора регистров, значение указателя стека) перед
возвратом из прерывания, заменяется на контекст задачи ОС (то же самое, плюс некоторые регистры, которые могут не
сохранятся при обычном прерывании). И HPE этому препятствует,
восстанавливая контекст прерывания Nikolay_Po(996 знак., 16.06.2026 21:10)
- Ну, ХЗ. Я предполагал, что стек задачи, это не стек машины. Или там
нет возможности для такого финта ушами? Ну, типа, mashine/user
mode. Там указателя стека, как такового, нет, мож как-то можно
разделять стек машины и стек задачи? По крайней мере, команда mret
на что-то намекает. Да и, в принцыпе, наработана масса трюков, типа
замены вершины стека и возврат из прерывания в процэдуру
сохранения/смены контента для переключения задач. - mse homjak(16.06.2026 22:36)
- Если задача должна быть вытеснена (а FreeRTOS - вытесняющая ОС),
это можно сделать, лишь прервав задачу прерыванием. Внутри
прерывания, вместо восстановления контекста прерывания "как было до
прерывания", восстанавливается контекст более приоритетной задачи.
И вот это нетиповое использование прерывания, с возвратом не в
прежний контекст прерывания, а в новый, и, по моему мнению, не
совместимо с аппаратным восстановлением контекста. Nikolay_Po(387 знак., 16.06.2026 22:37)
- Ну, меняем вершину стека на адрес процэдуры сохранения и переключения контента и делаем мрет. И запоминаем состояние текущей задачи, типа пушолл и заменив на следующую, пополл. В вершину стека адрес места останова восстанавливаемой задачи и рет. Тока тут проблема: смысла в теневом сохранении контента маловато.Тут стока тасований регистров и памяти, что лишние сохранения-восстановления особо погоды не сделают. - mse homjak(16.06.2026 22:48)
- Если задача должна быть вытеснена (а FreeRTOS - вытесняющая ОС),
это можно сделать, лишь прервав задачу прерыванием. Внутри
прерывания, вместо восстановления контекста прерывания "как было до
прерывания", восстанавливается контекст более приоритетной задачи.
И вот это нетиповое использование прерывания, с возвратом не в
прежний контекст прерывания, а в новый, и, по моему мнению, не
совместимо с аппаратным восстановлением контекста. Nikolay_Po(387 знак., 16.06.2026 22:37)
- Ну, ХЗ. Я предполагал, что стек задачи, это не стек машины. Или там
нет возможности для такого финта ушами? Ну, типа, mashine/user
mode. Там указателя стека, как такового, нет, мож как-то можно
разделять стек машины и стек задачи? По крайней мере, команда mret
на что-то намекает. Да и, в принцыпе, наработана масса трюков, типа
замены вершины стека и возврат из прерывания в процэдуру
сохранения/смены контента для переключения задач. - mse homjak(16.06.2026 22:36)
- Ну так все порты FreeRTOS на RISC-V (да и на прочие схожие по
возможностям контроллера прерываний чипы/архитектуры), используют
для переключения контекста прерывание. Контекст прерывания (содержимое набора регистров, значение указателя стека) перед
возвратом из прерывания, заменяется на контекст задачи ОС (то же самое, плюс некоторые регистры, которые могут не
сохранятся при обычном прерывании). И HPE этому препятствует,
восстанавливая контекст прерывания Nikolay_Po(996 знак., 16.06.2026 21:10)
- Дык, этта... Контекст задачи должэн переключать планировщик. - mse homjak(16.06.2026 18:46)
- Сохранение, да. Но эксепшын, аппаратен и сразу, в машине моде. Т.е код будет исполнен всегда, плус, у него свои регистры и всё такое. mse homjak(366 знак., 15.06.2026 19:58)
- Меня что беспокоит: если я выхожу из прерывания, при входе в
которое было включено HPE, то при выходе, регистры, сохраняемые
аппаратно, восстановятся на значения в момент входа. Как быть, в
таком случае, с прерыванием, которое переключало контекст задачи и
при выходе должно оставить новые значения регистров, не те, чтобы
были на момент входа? Разве HPE не будет препятствовать сохранению
новых значений регистров, если они - контекст задачи RTOS, на
которую только что Nikolay_Po(14 знак., 16.06.2026 17:16)
- я разумею почти так же ( сохранение регистров проца при эксепшене
не совсем аппаратная штука - традиционно компилятор генерит пролог
и эпилог ). вопрос в том где связзь HPE и кода сохранения и подъема
контекста задачи ОС? я утверждаю что её нет. но это не точно :)
думаю что суть в правильном назначении приоритетов прерываниям - у
меня в этом было откровения после которых все заработало с HPE - klen(15.06.2026 19:43)
- Есть вопросы. 1. Как при выходе из прерывания, при включённом HPE,
если это прерывание само меняет контекст и само восстанавливает по
своему разумению те же регистры, что восстанавливает и HPE,
оставить контекст RTOS для задачи, а не восстановленое HPE
состояние регистров на момент входа в прерывание? Я знаю только
один способ - установить GIHWSTKNEN и выйти, предварительно сбросив
MIE, чтобы защититься от вложенности. Nikolay_Po(579 знак., 16.06.2026 17:13)