Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Понедельник
18 августа

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

ARM, RISC-V контроллеры

1513833 Топик полностью

SciFi (24.04.2025 08:13, просмотров: 82) ответил Nikolay_Po на Ребята, кто знает, есть ли в GCC для RISC-V возможность задать свой пре-пролог для прерывания? Такое было возможно делать доработанном GCC от Microchip для их контроллеров. Указывалось в виде параметра спецификатора. И параметре - ассемблерная инструкция-другая. Остальной, штатный, пролог компилятор вставлял после моего пре-пролога.

Вот пример, как надо: __attribute__((naked)) void my_handler_hpe(){ asm("call my_handler; mret"); }

ส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้

Ответить

- По идее, не сработает. Если my_handler определить как простую функцию, то в конце у неё сработает обычный return и нарушит выполнение кода неподходящим возвратом. Может получиться так: Nikolay_Po(223 знак., 24.04.2025 09:09)
  - Ничего не понял. Что не сработает? "asm("пролог; call my_func; эпилог") - что тут может не сработать? - SciFi(24.04.2025 09:11)
    - Ну, так сработает. Если в эпилоге не забыть mret. Но, во-первых, я не хочу лишний call/ret, во-вторых, я не хочу вручную писать часть пролога, которая необходима для сохранения контекста перед выполнением кода прерывания. - Nikolay_Po(24.04.2025 09:23)
      - Я не настаиваю. Сомневаюсь, что найдёте вариант лучше, я уже немного изучал этот вопрос. А лишний call/ret - это такая мелочь. Жизнь слишком коротка, чтобы зацикливаться на такой ерунде. - SciFi(24.04.2025 09:25)
        
        Как вам мой свежий взгляд на проблему? Ни строчки на ассемблере! И заработало в железе. Nikolay_Po(3023 знак., 24.04.2025 10:48)
        
        Так у тебя же портится регистр A5 в USART1_IRQHandler !!! А работает все нормально из-за включенного HPE ???!!! Ну - я иначе никак не могу это объяснить. il-2(169 знак., 24.04.2025 13:14)
        
        Нет, HPE не включён. Просто повезло. Но что А5 портится - верно подмечено. В общем, не рабочее, если опять таки, вручну в стек не сохранять/извлекать. - Nikolay_Po(24.04.2025 13:33)
        
        Если работает, почему бы и нет? Просто "ни строчки на ассемблере" звучит как странноватый фетиш. Но в каждой избушке свои погремушки. У меня они тоже есть, но я стараюсь о них не рассказывать :-) - SciFi(24.04.2025 10:48)
        
        Оно перестаёт быть странным, когда этот код нужно передать дальше в разработку другим людям. А с ассемблером они пугаются. Ассемблер более аппаратно-зависим. А мой код пойдёт практически на любых МК, поддерживаемых GCC. - Nikolay_Po(24.04.2025 10:51)
        
        "Любой МК" в данном случае - это фикция, эта штука привязана к конкретному RISC-V. Погоня за "переносимостью" тоже может быть чрезмерной. - SciFi(24.04.2025 10:53)
        
        Покажите, где здесь непереносимость? Nikolay_Po(314 знак., 24.04.2025 10:58)
        
        На скольких разных МК вы запускали этот код? - SciFi(24.04.2025 10:59)
        
        А на скольких он у вас не пошёл? Достаточно того, что этот код поддерживается GCC. Навскидку не нашёл исчерпывающего перечня архитектур с поддержкой naked. Но вот сообщение 2011г: Nikolay_Po(786 знак., 24.04.2025 11:10)
        
        Я не настаиваю. Мой тезис - разница между "теоретически" и "практически". Вроде бы об одном и том же, но есть нюанс. - SciFi(24.04.2025 11:17)
        
        Пока все наши утверждения взаимно голословны, кроме того, что у меня ~~заработало~~ в CH32V203. - Nikolay_Po(25.04.2025 16:28)