owl 0 2 февраля, 2015 Опубликовано 2 февраля, 2015 · Жалоба Всем доброго дня. Скачал самую свежую версию куба. В описаниях было много сказано о ее совместимости с FREERTOS. Интерсовал механизм приема-передачи данных по УАРТу в HAL драйвере. Возможности выставления флагов(событий) для RTOS. Как вариант буферы приема данных и т.п. и т.д. То,что увидел, очень сильно озадачило. Приемник HAL драйвера UART фактически неработоспсобен для общего применения???? Остальные драйверы пока не "копал", но если там сохранен такой же подход как и в УАРТе, то зачем все это надо было STm? Подрыгать ногами в демо проекте? Чем был плох CMSIS? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
seniorandre 0 2 февраля, 2015 Опубликовано 2 февраля, 2015 (изменено) · Жалоба В описаниях было много сказано о ее совместимости с FREERTOS. Интерсовал механизм приема-передачи данных по УАРТу в HAL драйвере. Возможности выставления флагов(событий) для RTOS. Как вариант буферы приема данных и т.п. и т.д. То,что увидел, очень сильно озадачило. Приемник HAL драйвера UART фактически неработоспсобен для общего применения???? Остальные драйверы пока не "копал", но если там сохранен такой же подход как и в УАРТе, то зачем все это надо было STm? Подрыгать ногами в демо проекте? Месяц назад занимался тем же самым, единственное что нашел, что у USART есть два callback, которые как в DMA IRQ вызываются на половину заполненности буфера или всего буфера. Так и не понял как отлавливать символ окончания команды, которую я отправляю по USART, т.к. теперь вроде прерывание занято обработчиком этих callback. Так и плюнул и вернулся к CMSIS. Может действительно у кого нибудь есть пример нормальный как правильно работать с последовательным портом с использованием FREERTOS, а то бред какой-то получается. В цикле опрашивать порт как в демо, не наш метод, да и получить событие когда пол буфера заполнено, нафига? Изменено 2 февраля, 2015 пользователем seniorandre Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
owl 0 2 февраля, 2015 Опубликовано 2 февраля, 2015 · Жалоба Месяц назад занимался тем же самым, единственное что нашел, что у 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 0 2 февраля, 2015 Опубликовано 2 февраля, 2015 · Жалоба Есть 2 простых варианта. Это настраивать буфер на прием 1 байта. Настраивать буфер с "запасом" и делать поллинг принимаемых данных. - По приему некоторого числа, делать инициализацию заново. Что одно, что второе - костыли. Все это вызывает удивление. Например вот это: #if (USE_RTOS == 1) Ну это чудо я тоже видел( (USE_RTOS == 1) ), а про буфер =1 я даже заикаться не стал, т.к. зачем этот драйвер и буфер вообще нужен. Когда я тестил, у меня вообще Rtos не запустился, т.к. в конфиге не привязали SysTick. Порадовало только одно, можно использовать весь синтаксис от FreeRtos и не заморачиваться на новом синтаксисе, т.к. возможности FreeRtos они там уменьшили, это видно если сравнить определения. классов и функций. Ну и доки можно сказать нет на новые определения, поэтому я вопрос закрыл пока. Либо надо придумывать как правильно работать с USART, а то получается что идеология идет от mbed где с DMA можно работать только через задний проход. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 3 февраля, 2015 Опубликовано 3 февраля, 2015 · Жалоба Всем доброго дня. Скачал самую свежую версию куба. В описаниях было много сказано о ее совместимости с FREERTOS. Интерсовал механизм приема-передачи данных по УАРТу в HAL драйвере. Возможности выставления флагов(событий) для RTOS. Как вариант буферы приема данных и т.п. и т.д. То,что увидел, очень сильно озадачило. Приемник HAL драйвера UART фактически неработоспсобен для общего применения???? Остальные драйверы пока не "копал", но если там сохранен такой же подход как и в УАРТе, то зачем все это надо было STm? Подрыгать ногами в демо проекте? Чем был плох CMSIS? А причём здесь CMSIS? CMSIS как был так и остался. И в кубе он есть. Что-то вы не досмотрели или недопоняли. Я писал проект тогда, когда куба не было. Был stlib. Там был действительно мрак, поэтому пришлось написать всё самому. Недавно смотрел драйвер USART куба и даже удивился. Очень даже неплохо написано. Смотрел я его правда поверхностно, но мне понравился подход. Часть функционала я писал аналогично. С другой стороны, связь с FreeRTOS, пусть и заявленная должна осуществляться на более высоком уровне, насколько я понимаю. Например у меня написан драйвер USART, поверх него драйвер модбас. И вот драйвер модбас уже управляет событиями FreeRTOS. Можно, конечно, семафорить и на приём каждого байта, хозяин-барин. Думаю, что в самом в кубе вы найдёте примеры применения FreeRTOS совместно с USART. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
seniorandre 0 3 февраля, 2015 Опубликовано 3 февраля, 2015 · Жалоба Недавно смотрел драйвер USART куба и даже удивился. Очень даже неплохо написано. Смотрел я его правда поверхностно, но мне понравился подход. Часть функционала я писал аналогично. Вы может детально не разбирались, да и ни кто не спорит что написано хорошо, но воспользоваться этим очень проблематично. Если бы входящие данные были бинарными или стандартной длиной, то все кашироно. А если на вход идут текстовые команды разной длины, то события на обработку символа или конца команды нет, приходится ставить длину буфера = 1 и уже самому обрабатывать, но это костыль. Зачем тогда драйвер нужен. А прерывание при этом занято уже самим драйвером. А уже с Freertos связать это дело десятое. Кстати на Rtos примеров можно сказать нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
owl 0 3 февраля, 2015 Опубликовано 3 февраля, 2015 · Жалоба А причём здесь CMSIS? CMSIS как был так и остался. И в кубе он есть. Что-то вы не досмотрели или недопоняли. Я писал проект тогда, когда куба не было. Был stlib. Там был действительно мрак, поэтому пришлось написать всё самому. Недавно смотрел драйвер USART куба и даже удивился. Очень даже неплохо написано. Смотрел я его правда поверхностно, но мне понравился подход. Часть функционала я писал аналогично. С другой стороны, связь с FreeRTOS, пусть и заявленная должна осуществляться на более высоком уровне, насколько я понимаю. Например у меня написан драйвер USART, поверх него драйвер модбас. И вот драйвер модбас уже управляет событиями FreeRTOS. Можно, конечно, семафорить и на приём каждого байта, хозяин-барин. Думаю, что в самом в кубе вы найдёте примеры применения FreeRTOS совместно с USART. Может быть, я действительно что-то не понимаю, но в общем случае при приеме данных с UART, нам не известна длинна входящей посылки. Поэтому только 2 выхода: поллинг, событие(семафор) приема байта. Подход к драйверу может быть и ничего. Но тогда уже стоит брать пример с драйвера RTE_DRIVER UART от KEIL для STM32F1X. Там все гораздо интереснее, хотя все равно - есть ошибки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 3 февраля, 2015 Опубликовано 3 февраля, 2015 · Жалоба Ну я ещё раз посмотрел. А как написать универсальный драйвер? :rolleyes: Сложно в общем то. Возьмём Modbus. По сути вы должны сначал выставить размер 1 и получить адрес устройства, Потом 2 и получить адрес регистра и так далее пока не получите длину ... Короче верхний драйвер вполне можно приспособить для использования этого. Другой вопрос зачем это надо. Лучше вас никто вашей задачи не знает. И если вас это не устраивает, то вы можете написать своё прерывание, где обрабатываете пакет и по приёму пакета выставляете семафор. )) Я написал приём по прерыванию, а передачу по DMA. Удобнее всего было бы если бы проц имел FIFO, по примеру NXP. Но что поделаешь ... )) Всегда чего-нибудь не хватает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
owl 0 3 февраля, 2015 Опубликовано 3 февраля, 2015 (изменено) · Жалоба На счет того, что всегда не хватает - вы абсолютно правы. С модбасом, к сожалению, не работал. Появилась пара мыслей об универсальном драйвере под RTOS. Доведу до ума покажу. Изменено 3 февраля, 2015 пользователем IgorKossak избыточное цитирование Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
