Я не понимаю как vTaskDelayUntil может гарантировать завершения передачи данных? Поясните.

Либо я не понимаю того, что написано на сайте FreeRTOS, либо вы что-то путаете. Либо я не понимаю как вы применяете эту функцию.

https://www.freertos.org/vtaskdelayuntil.html

Кто нибудь подскажет, можно ли как нибудь вывести полученный результат от stm вывести на экран компа

Текст и вычисления?
На комп поставить монитор serial порта (например, putty), а на stm изучить usart. Я бы больше рассказал, но в деталях не шарю

Спасибо!

Я имел ввиду как на ардуино типа serial.begin

Serial - это ардуиновская библиотека для работы с UARTом

смысл Until вот тут хорошо отображён...

vTaskDelay=время выполнения задачи+время задержки. vTaskDelayUntil = сразу считает с момента вызова задержку.  если грубо, то используя один или другой тип задержки мы делаем приоритет либо выполняемому коду, либо тому с чем работаем. я обычно предпологаю сколько времени по i2c будет передаваться информация, и делаю запас в 2 тика. и на столько вызываю vTaskDelayUntil.

"vTaskDelay=время выполнения задачи+время задержки. vTaskDelayUntil = сразу считает с момента вызова задержку"

Это я прекрасно понимаю ))). Просто в том посте вы написали так, что это выглядело будто бы vTaskDelayUntil как-то гарантирует выполнение всего кода в задаче, то есть как будто  vTaskDelayUntil не даёт планировщику переключится на другую задачу. Это и ввело в заблуждение.

Я понял, вы просто делаете время выполнения задачи жёстко фиксированным, но при этом так чтоб задача успела всё поделать.

сомнительная логика в использовании vTaskDelayUntil , но это ваше право. я про другое хотел, разве функции отправки в блокирующем режиме не возвращают выполнение программе только после полной передачи? т.е. когда выполнилось HAL_SPI_Transmit можно смело лепить защелку, данные уже точно ушли

вот тут у меня большой пробел... как в принципе работает HAL_SPI_Transmit, да как в общем и I2C трансмитт... вообще как я понимаю, на стороне "железной реализации протокола (любого)" должен быть буфер, куда мы и отправляем с помощью например HAL_SPI_Transmit... соответственно мы отправили, а дожидаться передачи не обязательнно. но это же не так? есть ли какой-либо буфер на стороне интерфейса.

когда вы вызываете HAL_SPI_Transmit , то пока не передадутся все байты - управление вам не вернется. а вот когда вызываете HAL_SPI_Transmit_IT или DMA - то вы просто даете указалеть на данные  и их кол-во и идете заниматься своими делами. буфер у ппередатчика и у приемника есть, но он маленький, на один байт (или uint16_t точно не помню)

воооот.. понял. и хорошо и плохо по факту..
извиняюсь, только начал сознательно работать с интерфейсами.

Получается, что если мы например очень длинный пакет данных принимаем через SPI то во FreeRTOS, есть шанс того что посередине приёма мы будем прерваны обработчиком задач, и данные таки не будут приняты? с передачей примерно тоже самое может получиться.....

с любым протоколом так же получается.( хотя в 1мс. я думаю даже несколько кадров Ethernet можно получить.

без Freertos не задумывался об этом.. но там и например обработка двух-трёх клиентов Ethernet задача не из приятных.

Кстати у мен уже второй программатор ст линк почему то отказывает после какого то срока небольшого. Пользую по юсб с ноута. Сгореть врядли мог. Просто подключаю и комп пишет тип устройство не работает правильно. Дрова поставить на него не могу. Может сталкивался кто и есть способ оживить? Очень долго ждать доставки

Во-первых надо защитить доступ к периферии из разных потоков, семафоры, мьютексы, и т.д.
Во-вторых, если хотите, чтобы данные принялись или отправились с помощью блокирующей функции, то надо делать это в критической секции

Вообще в идеале не юзать блокирующие функции, либо организовать одну задачу по работе  с spi(например) и отдавать или принимать  данные этой/с этой задачи с помощью очередей