Serjaru 0 Posted December 15, 2017 (edited) · Report post Есть программка для выявления проблемы. Простое usart эхо, принимает байты - срабатывает прерывание и отправляет hello назад. Сам код может быть странный, но суть не в этом. Выдернули из большого. Суть в том, что прерывание "виснет" когда начинаю бомбить быстро байтами. Как будто захлебывается. Помогает только снятие питания или резет. и срабатывает строка "if(HAL_UART_Receive_IT(&huart1, &rcv, 1)!=HAL_OK)" Как быть? В чем проблема? Сразу для ответов "гугли", "читай RM" и прочих ... проходим мимо! Я хочу получить ответ, о тех, кто действительно умный и знает, как решить проблему, кто уже сталкивался с этим. .... UART_HandleTypeDef huart1; .... char rcv; volatile int rcvd; .... .... int main(void) { ... MX_USART1_UART_Init(); ... while (1) { if(rcvd) { HAL_GPIO_WritePin(Led_GPIO_Port, Led_Pin, GPIO_PIN_SET); rcvd = 0; HAL_UART_Transmit(&huart1, "Hello!\r\n", 8, 0xFFFF); HAL_GPIO_WritePin(Led_GPIO_Port, Led_Pin, GPIO_PIN_RESET); } } } .... .... .... void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if(huart == &huart1) { if(rcv == '\n') rcvd = 1; if(HAL_UART_Receive_IT(&huart1, &rcv, 1)!=HAL_OK) { HAL_GPIO_TogglePin(GPIOE, GPIO_PIN_0); } } } ... ... ... Edited December 15, 2017 by Sergey Abaev Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ViKo 0 Posted December 15, 2017 · Report post Как быть? Может, что-то не хватает? Не хватает воли плюнуть на HAL, изучить Reference Manual и написать простую программу самостоятельно, не выдергивая из "большого". Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Serjaru 0 Posted December 15, 2017 · Report post Не хватает воли плюнуть на HAL, изучить Reference Manual и написать простую программу самостоятельно, не выдергивая из "большого". Ну такие ответы от умников я тоже ожидал. Проходите мимо! Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
x893 0 Posted December 15, 2017 · Report post Нет понимания работы. Надо смотреть, что происходит при вызовах HAL_... Переставьте выше HAL_GPIO_TogglePin(GPIOE, GPIO_PIN_0); на прием каждого байта и убедитесь, что PE0 дергается при приеме каждого байта. Ну а дальше нужно логически промоделировать работу процессора и прерываний. HAL содержит больше бессмысленных операций, поэтому это один путь. SPL содержит меньше ненужного кода, но нужно больше мозга для использования. CMSIS минимальное кол-во кода, но мозга ещё больше надо + умение читать RM Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
adnega 0 Posted December 15, 2017 · Report post Суть в том, что прерывание "виснет" когда начинаю бомбить быстро байтами. Как будто захлебывается. Помогает только снятие питания или резет. Поможет обработка переполнения приемника. Если произойдет переполнение приемника, а соответствующих флаг вы не сбросите, то будете постоянно находится в прерывании приемника. Подробности в RM. Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
x893 0 Posted December 15, 2017 · Report post Можно добавить HAL_UART_ErrorCallback и там отслеживать ошибки мастерства программирования. Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sadat 0 Posted December 15, 2017 · Report post Ну и кто за вас будет сбрасывать всякие ошибки приёма? Полностью уверен в том, что устанавливается бит ошибки приёмника (а их там несколько) - вот всё и "тухнет". Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
x893 0 Posted December 15, 2017 · Report post HAL их сбрасывает за меня (и за остальных тоже). Полностью можно быть уверенным после просмотра кода. Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
pvman 0 Posted December 15, 2017 (edited) · Report post когда "виснет", смотреть состояние флагов usart. в обработке прерывания проще убрать обработку через HAL, это будет значительно читабельнее и в сотни раз короче и быстрее. в даташите на пальцах всё расписано, сделать несколько обязательных строчек и всё. Edited December 15, 2017 by pvman Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
x893 0 Posted December 15, 2017 · Report post Так написал же Sergey Abaev, что он не читает RM. Пусть код индусский изучает. Видимо и примеры ему тоже смотреть лень. Сразу в бой с HAL_... - как Чапаев на белом коне. Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vlad_new 0 Posted December 17, 2017 · Report post Можно попробовать в прерывании, перед выходом, поставить что то типа сброса всех флагов и ошибок напрямую в регистрах уарта. Скорее всего, как уже было замечено, какой то флаг вам не дает выйти из прерывания ( вернее вы туда тут же влетаете ). Ну или анализируйте, на сколько корректно HAL всё это делает за вас :) Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
leocat 0 Posted December 17, 2017 (edited) · Report post Это с какой же частотой UART "бомбить" нужно, чтобы "заклинило". Не знаю, не знаю... У меня 1 мбит/сек на прерываниях ничего не теряет. Ну и правильно написали: HAL - в топку. Это индусское изделие еще тот гемор. Ну и если прерывание уже в обработке (для UART например), то повторно его не вызовете. Флаг сбрасывать нужно, ручками. Мало того, если по выходу из прерывания его (флаг) не сбросить ( USART_ClearITPendingBit( USART1, USART_IT_RXNE ); ), то повторно и не сработает. ( пример из SPL ) Edited December 17, 2017 by leocat Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
juvf 0 Posted December 18, 2017 · Report post Суть в том, что прерывание "виснет" когда начинаю бомбить быстро байтами. Как будто захлебывается. Помогает только снятие питания или резет.Вставал на подобную граблю. Не знаю, может вам это поможет.... St сделали багу закладку, чтоб не всё так сладко было, и оформили её как фичу, имхо. Суть в том, что прерывание RXNEIE срабатывает не только когда RXNE==1, но и ИЛИ когда ORE==1. У меня было так, что один раз когда нибудь встанет флаг ORE, и я зависал навечно в прерывании RXNEIE. Вы в одном обработчике должны проверять оба флага и делать соответствующее ветвление, ну и соответственно сбрасывать флаг ORE. Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
rakpavel 0 Posted December 18, 2017 · Report post да, флаг USART_FLAG_ORE -указывает на ошибку переполнения, как раз похоже на случай ТС. Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Serjaru 0 Posted December 18, 2017 · Report post Народ!!!! спасибо всем, кто подсказал. Проблему понял и решил. Наверно это одна из тупейших тем, но сорри. На то он и форум. Еще раз спасибо за помощь и советы! Тема закрыта. Так написал же Sergey Abaev, что он не читает RM. Пусть код индусский изучает. Видимо и примеры ему тоже смотреть лень. Сразу в бой с HAL_... - как Чапаев на белом коне. Это вы зря! Примеров перелопатил много! Просто не понятно, почему так просто можно "подвесить" МК. Я уже разобрался конечно. Поможет обработка переполнения приемника. Если произойдет переполнение приемника, а соответствующих флаг вы не сбросите, то будете постоянно находится в прерывании приемника. Подробности в RM. СПАСИБО!!! Посмотрю RM Можно добавить HAL_UART_ErrorCallback и там отслеживать ошибки мастерства программирования. Вот это не знал!!!! Что-то не подумал над этим, а действительно! Спасибо!! Ну и кто за вас будет сбрасывать всякие ошибки приёма? Полностью уверен в том, что устанавливается бит ошибки приёмника (а их там несколько) - вот всё и "тухнет". Виноват - я болван :rolleyes: Не хватает воли плюнуть на HAL, изучить Reference Manual и написать простую программу самостоятельно, не выдергивая из "большого". Частично конечно согласен, но форум и знающие люди быстрее направят, а иначе зачем форум. Это конечно не говорит, что я вылез из пещеры и сразу в бой. Но и книги + форум = лучше HAL их сбрасывает за меня (и за остальных тоже). Полностью можно быть уверенным после просмотра кода. Да я делал проект через куб, и добавил только, что выше. Просто удивляет, почему так просто можно "подвесить" МК. Но уже все понял! Спасибо! когда "виснет", смотреть состояние флагов usart. в обработке прерывания проще убрать обработку через HAL, это будет значительно читабельнее и в сотни раз короче и быстрее. в даташите на пальцах всё расписано, сделать несколько обязательных строчек и всё. Век живи, век учись! Спасибо, учтем! Можно попробовать в прерывании, перед выходом, поставить что то типа сброса всех флагов и ошибок напрямую в регистрах уарта. Скорее всего, как уже было замечено, какой то флаг вам не дает выйти из прерывания ( вернее вы туда тут же влетаете ). Ну или анализируйте, на сколько корректно HAL всё это делает за вас :) СПАСИБО!!!!! Это с какой же частотой UART "бомбить" нужно, чтобы "заклинило". Не знаю, не знаю... У меня 1 мбит/сек на прерываниях ничего не теряет. Ну и правильно написали: HAL - в топку. Это индусское изделие еще тот гемор. Ну и если прерывание уже в обработке (для UART например), то повторно его не вызовете. Флаг сбрасывать нужно, ручками. Мало того, если по выходу из прерывания его (флаг) не сбросить ( USART_ClearITPendingBit( USART1, USART_IT_RXNE ); ), то повторно и не сработает. ( пример из SPL ) 115200, где-то получалось около 720 байт в сек. Наверно это немного. Но как я понял, принимает он без проблем, всё успевает. А вот назад, в сторону компа - затыкается. И видимо я не ждал окончания отправки. И как-то все висло! Вставал на подобную граблю. Не знаю, может вам это поможет.... St сделали багу закладку, чтоб не всё так сладко было, и оформили её как фичу, имхо. Суть в том, что прерывание RXNEIE срабатывает не только когда RXNE==1, но и ИЛИ когда ORE==1. У меня было так, что один раз когда нибудь встанет флаг ORE, и я зависал навечно в прерывании RXNEIE. Вы в одном обработчике должны проверять оба флага и делать соответствующее ветвление, ну и соответственно сбрасывать флаг ORE. Спасибо, проверю!!! да, флаг USART_FLAG_ORE -указывает на ошибку переполнения, как раз похоже на случай ТС. Спасибо! Спасибо! Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...