КРАМ писал(а):исполнение практически мгновенное.
само исполнение вроде и у меня мгновенное, но вот какие-то промежуточные действия явно тормозят... например, в окошке слева, что появляется в режиме отладки, выводится "дерево отладки" (так и не понял, нахрен оно нужно, ведь в окне кода и так видно, в каком модуле на какой функции остановка), так вот, оно обновляется крайне долго - пустое место заполняется содержимым не мгновенно, а за те самые 10 секунд и более... ноут у меня не самый быстрый и молодой, но все равно подозрительно выглядит это...
VladislavS писал(а):А что, в личке про это не пишут?
судя по всему, воспитанные люди, когда им сказать нечего, не пишут.
COKPOWEHEU писал(а):Просто реализация от ST (как и у Ардуины) оказалась неудачной.
про ST-шников не скажу, а в чем неудачность ардуины-то? миллионы поклонников вряд ли согласятся с вами...
имхо, если бы разработчики HAL провели какой-то "опрос мнений", возможно, вышло бы все намного лучше... мне представляется, что надо уйти от концепции низкоуровневой аппаратуры на таких "больших и мощных" МК, как ARM, и сформировать нечто типа системы драйверов, как в ОС (но попроще, со скидкой на отсутствие ОС). например, предоставить на выбор 3 варианта: минимальный размер, оптимум и максимальная скорость - это на этапе конфигурирования проекта. сами драйверы должны иметь наиболее абстрактный интерфейс, например, как уже было предложено, ПОРТ - собирается из пинов, и настраивается целиком одинаково, т.е. или ввод, или вывод и т.п. Система прерываний делается отдельной сущностью, как бы самостоятельной, а не пришитой к конкретной периферии, и в неё можно либо добавить обработчик (в момент добавления нужная периферия нужным образом настраивается), либо отсоединить обработчик (с аналогичными настройками). то есть пользователю интересно прерывание по изменению уровня пина - он пишет что-то типа add_interrupt_handler(PinToggleInterrupt, MyPort, MyPin, MyHandler, HandlerPriority), и всё, может быть уверен, что обработчик будет вызван при изменении уровня пина на указанном порту. и такая функция для всех МК одинакова, даже если нет системы приоритетов, то все равно параметр остается (просто игнорится компилятором). Аналогично для всего прочего. Ведь принципиально необходимости во всяких отдельных GPIO_Init-ах или TIM_Init-ах нужды нет - все настройки автоматически известны в зависимости от того, как пользователь собрался использовать драйвер, и выделять это в отдельную функцию, которую он должен руками вызывать, нет необходимости - вы ведь не работаете с драйвером мышки на компе напрямую, он как бы и без вас есть и настроен, вы хотите получать координаты курсора и получаете их, а откуда они возникают - вам не нужно. так и в МК с "правильным" (по моему мнению) HAL-ом быть должно: хотите сигнал оцифровывать, пишите Add_Adc_Samples_Handler(BufferedSamplesMode, BUF_SZ, SampleSpeed, MyPort, MyPin, MyHandler) - и получаете вызов MyHandler с указателем на буфер, в котором данные - и было там DMA или не было, вам особо и думать не надо (для максимальной производительности, вероятно, будет DMA и статически выделенный буфер, возможно даже два чередующихся, а для минимального размера, возможно, и не будет)
и подобный HAL покроет 90% всех потребностей, а остальные 10% будут радовать
Eddy_Em 
Eddy_Em, вон, в истерику впадает при попытке заюзать float без отдельного вычислительного модуля в ядре, а я должен страдать от коллбека?! я тоже раньше думал (еще с AVR), что вызывать функции из обработчика - не хорошо: куча регистров в стеке сохраняется, дескать, медленно это и плохо. а потом смотрю - миллионы ардуинщиков, а так же тысячи пользователей ОСРВ, вот совсем не парятся по этому поводу! 16 регистров в стеке, 32 такта на вход и 32 такта на выход - это что, убийственно даже для AVR с его жалкими 20 МГц тактовой (максимум)?! и знаете, как-то сразу стало легче жить... для моей практики AVR это было третьим "отпустило": первые два - это printf и float