[haker_fox 61]

1 hour ago, jcxz said:

Таким образом сразу гробятся все нижележащие (по приоритету) задачи.  

Да, это плата.

1 hour ago, jcxz said:

Если "так приходится делать", то скорее всего нужно открывать учебник и читать: что такое "event-driven программирование" и как его правильно готовить.

Как быть, если периферия (SPI в STM32F091) выставляет флаг BUSY в регистре STATUS от которого нет прерывания? Т.е. события не может возникнуть.

[EdgeAligned 85]

25 минут назад, _3m сказал:

Результат не будет достигнут

Ну я же и объяснил, и показал, как это делается. Задача подготавливает и запускает работу модуля, который будет вызывать высокоприоритетное прерывание. Приоритет этой задачи можно даже не повышать, чтобы обеспечить многозадачность. В  прерывании выполняется короткий код (прием байтов по интерфейсу?). Затем после завершения приема всех байтов, это прерывание выставляет флаг готовности. Ну а задача потом, когда перейдет в активное состояние, сразу подхватывает этот флаг и продолжается далее, отправляя нотификацию или очередь в другую задачу-обработчик и после этого приостанавливается до следующего раза. Задача обработчик будет разблокирована по её очереди в соответствии с её приоритетом. Всё ж просто и понятно же.

Или же используйте приём по DMA, он примет все байты без участия ЦПУ и по завершению вызовет прерывание, имеющее обычный приоритет RTOS, которое в свою очередь отправит уведомление в задачу-обработчик данных и разблокирует еёйную. Тоже все аккуратно и просто.

Изменено 27 сентября, 2023 пользователем EdgeAligned

[jcxz 242]

2 часа назад, haker_fox сказал:

Как быть, если периферия (SPI в STM32F091) выставляет флаг BUSY в регистре STATUS от которого нет прерывания? Т.е. события не может возникнуть.

Запустить от него интервал по таймеру и проверить в прерывании завершения этого интервала. Самый простой способ.

[haker_fox 61]

14 minutes ago, jcxz said:

Запустить от него интервал по таймеру и проверить в прерывании завершения этого интервала.

Т.е. запускаем таймер, который периодически в прерывании начинает проверять флаг. Запускаем транзакцию на шине. Когда флаг будет выставлен, код обработчика прерывания просигнализирует задаче о готовности любым доступным и уместным средством межпроцессного взаимодействия, предоставляемым данной ОСРВ. Я правильно Вас понял?

[jcxz 242]

3 минуты назад, haker_fox сказал:

Т.е. запускаем таймер, который периодически в прерывании начинает проверять флаг. Запускаем транзакцию на шине. Когда флаг будет выставлен, код обработчика прерывания просигнализирует задаче о готовности любым доступным и уместным средством межпроцессного взаимодействия, предоставляемым данной ОСРВ. Я правильно Вас понял?

Почти. Только не "периодически", а "однократно". Зачем периодически? Достаточно выяснить примерное время снятия BUSY и выставлять таймер на чуть бОльшее время.

В ISR достаточно предусмотреть только assert. Для разработчика.

[EdgeAligned 85]

Кривой способ. Да и assert тут каким боком то?

[haker_fox 61]

9 hours ago, jcxz said:

В ISR достаточно предусмотреть только assert. Для разработчика.

Ну что ж, скажу так: очень оригинальное и необычное решение! Мне такое в голову даже не приходило. Возьму это себе на вооружение заметку!

[tonyk_av 45]

10 hours ago, haker_fox said:

Т.е. запускаем таймер, который периодически в прерывании начинает проверять флаг.

Можно для этого использовать vApplicationTickHook().

 

[haker_fox 61]

8 minutes ago, tonyk_av said:

Можно для этого использовать vApplicationTickHook().

В принципе, да. При этом разрешение опроса флага таймером составит, как правило 1 мс. Понимаю, что настройка частоты SysTick, или иного, используемого для целей вызова планировщика, может быть адаптирована под конкретные требования. В случае же упомянутого выше флага BUSY из периферии SPI, ЕМНИПИ, счёт шёл на сотни мкс.

[EdgeAligned 85]

Ну и ничего страшного! В противоположность обычному методу без RTOS, работа задач в RTOS может содержать полинг чего-либо, особенно когда речь о коротких интервалах менее интервала переключения задач. Это упрощает построение программы, убирает лишний мусор, такой как запуск таймера и работу с ним. Потому я и говорю - кривой тот метод с таймером, ну так себе он.

И еще раз повторюсь - написание под RTOS - это своего рода искусство компромиссных решений.

[haker_fox 61]

5 minutes ago, EdgeAligned said:

Потому я и говорю - кривой тот метод с таймером, ну так себе он.

Да мы уже все поняли, что Вы хотите сказать) А мне метод - нравится! Хотя бы тем, что он необычный и пикантный!

[jcxz 242]

6 часов назад, haker_fox сказал:

Ну что ж, скажу так: очень оригинальное и необычное решение! Мне такое в голову даже не приходило.

Ёрничаете?  

PS: Кстати - необязательно для этого использовать таймер (и тратить целый таймер(!) на это). Часто я (для экономии таймеров и упрощения кода (чтобы всё в одном ISR было)), такое делаю отправкой/приёмом слова через тот же SPI. Но - отправкой с неактивным CS. Получается просто как небольшая задержка. Особенно - если ещё и установить для неё другую размерность слова (меньшее число бит).

[tonyk_av 45]

5 hours ago, haker_fox said:

А мне метод - нравится!

Я бы сильно задумался, почему мне вдруг понадобилось опрашивать флаг периферии, который не формирует прерывание. Возможно, алгоритм работы с периферией не удачен, коли приходится так извращаться.

[jcxz 242]

5 часов назад, EdgeAligned сказал:

Потому я и говорю - кривой тот метод с таймером, ну так себе он.

И что же там "кривого"?

Кривой здесь - МК, SPI которого имеет такие кривости "особенности". И вынуждает лепить дополнительные меры для коррекции.

9 минут назад, tonyk_av сказал:

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

.....или МК выбран не удачно.  

PS: Какой не выбирай алгоритм работы с флешкой, один фиг нужен минимальный интервал времени, в течение которого CS должен оставаться высоким. Между двумя соседними транзакциями по SPI. И если SPI-контроллер данного МК не умеет автоматом формировать этот интервал, или не умеет генерить прерывания по его окончанию - тут уже правка алгоритма никак не поможет. Только замена МК или выдержка интервала сторонними способами.  

Очевидно, создатели данного МК создавали его под super-loop-ный способ работы с флешкой. И никогда не слышали про РТОС на МК.  

[haker_fox 61]

10 minutes ago, jcxz said:

Ёрничаете?  

Так читается моё сообщение? Сорян, ничего даже подобного не было. Я написал то, что хотел выразить. Жаль, что иногда искренний восторг воспринимается как лёгкий сарказм😜 Это минус невербального общения💗

12 minutes ago, jcxz said:

Но - отправкой с неактивным CS. Получается просто как небольшая задержка.

Хм! Интересный подход! Из нестандартного применения SPI я недавно только использовал его для формирования кода сигма-дельта ЦАП по документации от TI. Когда данные с MISO (SPI тактировался как подчинённый от таймера для исключения джиттера фреймов) шли на ФНЧ, а сам двоичный код рассчтиывался в обработчике прерывания.