stm32cube + RTOS + UART, Ничего не понимаю. Опции

[owl]

Всем доброго дня.
Скачал самую свежую версию куба.
В описаниях было много сказано о ее совместимости с FREERTOS.
Интерсовал механизм приема-передачи данных по УАРТу в HAL драйвере. Возможности выставления флагов(событий) для RTOS. Как вариант буферы приема данных и т.п. и т.д.
То,что увидел, очень сильно озадачило. Приемник HAL драйвера UART фактически неработоспсобен для общего применения????
Остальные драйверы пока не "копал", но если там сохранен такой же подход как и в УАРТе, то зачем все это надо было STm? Подрыгать ногами в демо проекте?
Чем был плох CMSIS?

[seniorandre]

В описаниях было много сказано о ее совместимости с FREERTOS.
Интерсовал механизм приема-передачи данных по УАРТу в HAL драйвере. Возможности выставления флагов(событий) для RTOS. Как вариант буферы приема данных и т.п. и т.д.
То,что увидел, очень сильно озадачило. Приемник HAL драйвера UART фактически неработоспсобен для общего применения????
Остальные драйверы пока не "копал", но если там сохранен такой же подход как и в УАРТе, то зачем все это надо было STm? Подрыгать ногами в демо проекте?

Месяц назад занимался тем же самым, единственное что нашел, что у USART есть два callback, которые как в DMA IRQ вызываются на половину заполненности буфера или всего буфера. Так и не понял как отлавливать символ окончания команды, которую я отправляю по USART, т.к. теперь вроде прерывание занято обработчиком этих callback. Так и плюнул и вернулся к CMSIS. Может действительно у кого нибудь есть пример нормальный как правильно работать с последовательным портом с использованием FREERTOS, а то бред какой-то получается. В цикле опрашивать порт как в демо, не наш метод, да и получить событие когда пол буфера заполнено, нафига?

Сообщение отредактировал seniorandre - Feb 2 2015, 14:01

[owl]

Месяц назад занимался тем же самым, единственное что нашел, что у USART есть два callback, которые как в DMA IRQ вызываются на половину заполненности буфера или всего буфера. Так и не понял как отлавливать символ окончания команды, которую я отправляю по USART, т.к. теперь вроде прерывание занято обработчиком этих callback. Так и плюнул и вернулся к CMSIS. Может действительно у кого нибудь есть пример нормальный как правильно работать с последовательным портом с использованием FREERTOS, а то бред какой-то получается. В цикле опрашивать порт как в демо, не наш метод, да и получить событие когда пол буфера заполнено, нафига?

Есть 2 простых варианта.
Это настраивать буфер на прием 1 байта.
Настраивать буфер с "запасом" и делать поллинг принимаемых данных. - По приему некоторого числа, делать инициализацию заново.
Что одно, что второе - костыли.
Все это вызывает удивление. Например вот это:
#if (USE_RTOS == 1)
/* Reserved for future use */
#error “USE_RTOS should be 0 in the current HAL release”
#else
#define __HAL_LOCK(__HANDLE__) \
do{ \
if((__HANDLE__)->Lock == HAL_LOCKED) \
{ \
return HAL_BUSY; \
} \
else \
{ \
(__HANDLE__)->Lock = HAL_LOCKED; \
} \
}while (0)

#define __HAL_UNLOCK(__HANDLE__) \
do{ \
(__HANDLE__)->Lock = HAL_UNLOCKED; \
}while (0)

[seniorandre]

Есть 2 простых варианта.
Это настраивать буфер на прием 1 байта.
Настраивать буфер с "запасом" и делать поллинг принимаемых данных. - По приему некоторого числа, делать инициализацию заново.
Что одно, что второе - костыли.
Все это вызывает удивление. Например вот это:
#if (USE_RTOS == 1)

Ну это чудо я тоже видел( (USE_RTOS == 1) ), а про буфер =1 я даже заикаться не стал, т.к. зачем этот драйвер и буфер вообще нужен.
Когда я тестил, у меня вообще Rtos не запустился, т.к. в конфиге не привязали SysTick.
Порадовало только одно, можно использовать весь синтаксис от FreeRtos и не заморачиваться на новом синтаксисе, т.к. возможности FreeRtos они там уменьшили, это видно если сравнить определения. классов и функций. Ну и доки можно сказать нет на новые определения, поэтому я вопрос закрыл пока. Либо надо придумывать как правильно работать с USART, а то получается что идеология идет от mbed где с DMA можно работать только через задний проход.

[SasaVitebsk]

Всем доброго дня.
Скачал самую свежую версию куба.
В описаниях было много сказано о ее совместимости с FREERTOS.
Интерсовал механизм приема-передачи данных по УАРТу в HAL драйвере. Возможности выставления флагов(событий) для RTOS. Как вариант буферы приема данных и т.п. и т.д.
То,что увидел, очень сильно озадачило. Приемник HAL драйвера UART фактически неработоспсобен для общего применения????
Остальные драйверы пока не "копал", но если там сохранен такой же подход как и в УАРТе, то зачем все это надо было STm? Подрыгать ногами в демо проекте?
Чем был плох CMSIS?

А причём здесь CMSIS? CMSIS как был так и остался. И в кубе он есть. Что-то вы не досмотрели или недопоняли.
Я писал проект тогда, когда куба не было. Был stlib. Там был действительно мрак, поэтому пришлось написать всё самому. Недавно смотрел драйвер USART куба и даже удивился. Очень даже неплохо написано. Смотрел я его правда поверхностно, но мне понравился подход. Часть функционала я писал аналогично.

С другой стороны, связь с FreeRTOS, пусть и заявленная должна осуществляться на более высоком уровне, насколько я понимаю. Например у меня написан драйвер USART, поверх него драйвер модбас. И вот драйвер модбас уже управляет событиями FreeRTOS. Можно, конечно, семафорить и на приём каждого байта, хозяин-барин. Думаю, что в самом в кубе вы найдёте примеры применения FreeRTOS совместно с USART.

[seniorandre]

Недавно смотрел драйвер USART куба и даже удивился. Очень даже неплохо написано. Смотрел я его правда поверхностно, но мне понравился подход. Часть функционала я писал аналогично.

Вы может детально не разбирались, да и ни кто не спорит что написано хорошо, но воспользоваться этим очень проблематично. Если бы входящие данные были бинарными или стандартной длиной, то все кашироно. А если на вход идут текстовые команды разной длины, то события на обработку символа или конца команды нет, приходится ставить длину буфера = 1 и уже самому обрабатывать, но это костыль. Зачем тогда драйвер нужен. А прерывание при этом занято уже самим драйвером.
А уже с Freertos связать это дело десятое.
Кстати на Rtos примеров можно сказать нет.

[owl]

А причём здесь CMSIS? CMSIS как был так и остался. И в кубе он есть. Что-то вы не досмотрели или недопоняли.
Я писал проект тогда, когда куба не было. Был stlib. Там был действительно мрак, поэтому пришлось написать всё самому. Недавно смотрел драйвер USART куба и даже удивился. Очень даже неплохо написано. Смотрел я его правда поверхностно, но мне понравился подход. Часть функционала я писал аналогично.

С другой стороны, связь с FreeRTOS, пусть и заявленная должна осуществляться на более высоком уровне, насколько я понимаю. Например у меня написан драйвер USART, поверх него драйвер модбас. И вот драйвер модбас уже управляет событиями FreeRTOS. Можно, конечно, семафорить и на приём каждого байта, хозяин-барин. Думаю, что в самом в кубе вы найдёте примеры применения FreeRTOS совместно с USART.

Может быть, я действительно что-то не понимаю, но в общем случае при приеме данных с UART, нам не известна длинна входящей посылки. Поэтому только 2 выхода: поллинг, событие(семафор) приема байта.
Подход к драйверу может быть и ничего. Но тогда уже стоит брать пример с драйвера RTE_DRIVER UART от KEIL для STM32F1X. Там все гораздо интереснее, хотя все равно - есть ошибки.

[SasaVitebsk]

Ну я ещё раз посмотрел.
А как написать универсальный драйвер?
Сложно в общем то.
Возьмём Modbus.
По сути вы должны сначал выставить размер 1 и получить адрес устройства, Потом 2 и получить адрес регистра и так далее пока не получите длину ...
Короче верхний драйвер вполне можно приспособить для использования этого.
Другой вопрос зачем это надо.
Лучше вас никто вашей задачи не знает. И если вас это не устраивает, то вы можете написать своё прерывание, где обрабатываете пакет и по приёму пакета выставляете семафор. ))
Я написал приём по прерыванию, а передачу по DMA.
Удобнее всего было бы если бы проц имел FIFO, по примеру NXP. Но что поделаешь ... ))
Всегда чего-нибудь не хватает.

[owl]

На счет того, что всегда не хватает - вы абсолютно правы.
С модбасом, к сожалению, не работал.
Появилась пара мыслей об универсальном драйвере под RTOS.
Доведу до ума покажу.

Сообщение отредактировал IgorKossak - Feb 3 2015, 19:58

Причина редактирования: избыточное цитирование