libopencm3, Неплохая либа для кортексов... Опции

[demiurg_spb]

https://github.com/libopencm3/libopencm3

ИМХО хорошая альтернатива стандартной библиотеке от ST и не только.

[Golikov A.]

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

это плохой ответ, не о чем...

А вот на время передачи блока из 512 байт в SD-карту - уже усыпляю,

Имеется ввиду, запускаем ДМА, а задачу в sleep, то есть ОС будет к ней возвращаться с каким то своим достаточно большим интервалом, так?

Подытожим, у нас есть варианты:
1. усыпление процесса и возврат к нему с долгими интервалами для проверки дождались или нет (ожидание чего-то очень долгого)
2. это прерывание на окончание ожидания и в нем какой-то симафор, что позволяет ожидающую задачу усыпить до появления симафора. (если надо подождать среднюю длительность)
3. это долбим проверку интервала прямо в задаче циклом. В некоторых ОС будут переключать задачи по временным интервалам, если ожидание затянется, а в некоторых все задачи будут ждать эту. (ожидаем чего-то очень короткого)

правильные варианты?

Мне как-то внутренне кажется устраивать заопарк прерываний в ОС не верно.
Ну то есть отправку UART сделать буфер, и прерывание символ ушел - пихать следующий символ, и так поступить со всеми интерфейсами. Боюсь что так система станет слабо предсказуемой и постоянно что-то ковыряющейся в прерываниях... Ведь их то между собой поделить будет нельзя, посылки по UART забьют передачи по другим интерфейсам, например...

Не понятно как это решить в универсальной библиотеке

[AlexandrY]

Мне как-то внутренне кажется устраивать заопарк прерываний в ОС не верно.

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

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

Работа с быстрой периферией по прежнему пишется в стиле автоматов состояний.
Задержки делаются аппаратными таймерами. Переключение состояний автоматов производится в процедурах обслуживания прерываний по цепочке от разных источников включая DMA.
Сами прерывания это прерывания уровня ядра.
Прерывание RTOS вызывается только когда уже готов блок данных для обработки. И вот там-то взводится объект синхронизации о готовности данных.

[jcxz]

Работа с быстрой периферией по прежнему пишется в стиле автоматов состояний.
Задержки делаются аппаратными таймерами. Переключение состояний автоматов производится в процедурах обслуживания прерываний по цепочке от разных источников включая DMA.

Иногда (при необходимости быстрой работы со сложной периферией) получаются очень сложные автоматы состояний со множеством состояний (десятками) и сложными переходами между ними.
Код становится трудночитаем, ведь программирование в стиле автоматов состояний гораздо хуже читается чем линейный код.
В таких случаях я иногда применяю подход "а-ля ISR-псевдозадача":
создаю отдельный контекст (стек), при завершении очередной транзакции с периферией (получении прерывания от неё, от DMA или от таймера), внутри ISR переключаюсь на этот контекст, выполняю
участок кода до след. запроса к периферии (после которого следует обратное переключение контекста на исходный стек ISR с выходом из ISR). И по завершении этого запроса - опять вход в
ISR-псевдозадачу.
Получается простой хорошо читаемый линейный код вместо леса автомата состояний.
Надо только не забывать про уровни приоритетов ISR, участвующих в этом (на NVIC). Можно просто сделать все одного уровня.

Прерывание RTOS вызывается только когда уже готов блок данных для обработки. И вот там-то взводится объект синхронизации о готовности данных.

О готовности данных, или освобождении какого-то ресурса (занятого буфера или флага в API доступа к драйверу, работающему на уровне прерываний) и т.п..

[AlexandrY]

Иногда (при необходимости быстрой работы со сложной периферией) получаются очень сложные автоматы состояний со множеством состояний (десятками) и сложными переходами между ними.
Код становится трудночитаем, ведь программирование в стиле автоматов состояний гораздо хуже читается чем линейный код.
В таких случаях я иногда применяю подход "а-ля ISR-псевдозадача":
создаю отдельный контекст (стек), при завершении очередной транзакции с периферией (получении прерывания от неё, от DMA или от таймера), внутри ISR переключаюсь на этот контекст, выполняю
участок кода до след. запроса к периферии (после которого следует обратное переключение контекста на исходный стек ISR с выходом из ISR). И по завершении этого запроса - опять вход в
ISR-псевдозадачу.
Получается простой хорошо читаемый линейный код вместо леса автомата состояний.
Надо только не забывать про уровни приоритетов ISR, участвующих в этом (на NVIC). Можно просто сделать все одного уровня.


О готовности данных, или освобождении какого-то ресурса (занятого буфера или флага в API доступа к драйверу, работающему на уровне прерываний) и т.п..

В принципе не возражаю, только вот это - "хорошо читаемый" напрягает. Субъективизм же.
Во первых в скоростной периферии важнее хорошая отлаживаемость
Во вторых хорошо читаемый только короткий код.
Расположите все ISR связанные с одним автоматом в одном месте и получите короткий код, понятно откоментируйте и отформатируйте и получите отличную читаемость.

[jcxz]

В принципе не возражаю, только вот это - "хорошо читаемый" напрягает. Субъективизм же.
Во первых в скоростной периферии важнее хорошая отлаживаемость
Во вторых хорошо читаемый только короткий код.
Расположите все ISR связанные с одним автоматом в одном месте и получите короткий код, понятно откоментируйте и отформатируйте и получите отличную читаемость.

Вот такая работа с SPI (вполне хорошо читаемая и короткая при построении драйвера на уровне OS-задачи или как я описывал - псевдозадачей (выглядит так же как с OS)):

Код

FlashRead();
n = N_PAGES;
do FlashWrite();
while (--n);

при описывании state-машиной превращается в дикий лес, из нескольких десятков шагов с вермишельной логикой ветвлений:
(учтите что здесь ещё надо расписать шаги внутри FlashRead()/FlashWrite(), с реализацией стека вызовов (стека state-переменных))

Код

while (1) {
  switch (state) {
    case STATE_0:
      StartActionRead(...);
      state = STATE_1;
      break;
    case STATE_1:
      n = N_PAGES;
    case STATE_2:
      StartActionWrite(...);
      state = STATE_3;
      break;
    case STATE_3:
      state = STATE_ERROR;
      if (!result) continue;
      state = STATE_2;
      if (--n) continue;
     ...
    case STATE_ERROR:
     ...
  ...
  }
break;
}

Особенно если учесть, что надо реализовать цикл(циклы), что внутри FlashWrite(), FlashRead() может быть несколько транзакций по SPI-шине с несколькими входами в ISR, могут быть циклы с проверкой условий и т.п.). Вообще если нужно сделать простейшую функцию (набор часто повторяемых действий) на базе state-машины.
Если взять любой код драйвера, работающий на базе задачи ОС с использованием её объектов синхронизации (для уведомления о завершениях транзакций от ISR), и попытаться его развернуть в
state-машину, то сразу видно какой получается малочитаемый код.

State-машиной ещё вполне нормально реализуются простые линейные последовательности шагов алгоритма, без ветвлений и вызовов функций. Не более того.

[scifi]

при описывании state-машиной превращается в дикий лес

Для этого существует protothreads. Никакого дикого леса.