Здравствуйте.
Контроллер STM32L.
Возможно глупый вопрос - при возникновении прерывания по USART я ухожу по вектору прерывания проверяю флаги, смотрю что было прерывание по передаче, начинаю обрабатывать данное прерывание и тут у меня приходит байт по USART. Но я ведь в это время обрабатываю прерывание по передаче и при окончании обработки уже флаги прерываний проверять не собираюсь. Как поведет себя контроллер - по выходу из прерывания заново вызовет вектор прерывания с флагом по приему или как то иначе.
Знаю, что надо читать документацию или на крайний случай экспериментировать, но может, кто уже знает и подскажет сразу.
Заранее благодарен за любую помощь.
Полная версия этой страницы: STM32 прерывание по USART - по приему и передаче одновременно
Снова войдет в этот обработчик, если, конечно, не возникло более приоритетных прерываний.
если конечно вы не сбросите все флаги прерываний по выходу.
именно для этих целей часто регистры сброса флагов прерываний обычно не чувствительны к записям нулей или единиц
часто
INTERUPT_STATUS_CLEAR_REG = 0x01 - правильно
INTERUPT_STATUS_CLEAR_REG |= 0x01 - не правильно
именно для этих целей часто регистры сброса флагов прерываний обычно не чувствительны к записям нулей или единиц
часто
INTERUPT_STATUS_CLEAR_REG = 0x01 - правильно
INTERUPT_STATUS_CLEAR_REG |= 0x01 - не правильно
Цитата(Нортон @ May 23 2013, 17:13) 
Контроллер STM32L.
Как поведет себя контроллер - по выходу из прерывания заново вызовет вектор прерывания с флагом по приему или как то иначе.
Отлично себя поведёт благодаря tail-chaining...Как поведет себя контроллер - по выходу из прерывания заново вызовет вектор прерывания с флагом по приему или как то иначе.
Цитата(Нортон @ May 23 2013, 16:13)
... крайний случай экспериментировать
Это единствененно правильный вариант. И приступайте к нему сразу не теряя времени.
Из опыта скажу, что на высоких скоростях UART на прием в STM32 без DMA применять нельзя.
Поскольку прерывания по приему начинают пропускаться.
Да верный совет. А еще лучше начинать эксперименты с чужих бесплатных библиотек. Работая таким образом вы не создаете проблем другим программистам.. 
..
Начинать надо с документации. Почитать, понять, потом проверить.
Из опыта УАРТ проца никогда не сможет передавать символ быстрее чем 10 клоков проца, это абсолютный максимум не достижимый, и вы что скажете что вам не хватит 10 клоков на то чтобы войти в прерывание, и сохранить символ в буфер? А тактов там гораздо больше. Просто в процедуре сохранения символа не надо делать обработку сообщения...
..Начинать надо с документации. Почитать, понять, потом проверить.
Из опыта УАРТ проца никогда не сможет передавать символ быстрее чем 10 клоков проца, это абсолютный максимум не достижимый, и вы что скажете что вам не хватит 10 клоков на то чтобы войти в прерывание, и сохранить символ в буфер? А тактов там гораздо больше. Просто в процедуре сохранения символа не надо делать обработку сообщения...
Цитата(Golikov A. @ May 24 2013, 18:12)
Из опыта УАРТ проца никогда не сможет передавать символ быстрее чем 10 клоков проца, это абсолютный максимум не достижимый, и вы что скажете что вам не хватит 10 клоков на то чтобы войти в прерывание, и сохранить символ в буфер? А тактов там гораздо больше. Просто в процедуре сохранения символа не надо делать обработку сообщения...
А если есть более приоритетные прерывания? А если прерывания временно запрещены?
ну там и не 10 клоков%).... да и 100 мегагерцовых уартов я чет не видал....
Просто хотел отметить что физ ограничений нет, так что фраза без дма применять НЕЛЬЗЯ - не верна. Можно но как и для всего что работает на пределе надо сильно думать.
Вообще висеть в прерываниях не есть хороший тон ИМХО, я там только флаги расставляю че сделать надо...
Просто хотел отметить что физ ограничений нет, так что фраза без дма применять НЕЛЬЗЯ - не верна. Можно но как и для всего что работает на пределе надо сильно думать.
Вообще висеть в прерываниях не есть хороший тон ИМХО, я там только флаги расставляю че сделать надо...
Цитата(AlexandrY @ May 24 2013, 16:22)
Это единствененно правильный вариант. И приступайте к нему сразу не теряя времени.
Из опыта скажу, что на высоких скоростях UART на прием в STM32 без DMA применять нельзя.
Поскольку прерывания по приему начинают пропускаться.
Из опыта скажу, что на высоких скоростях UART на прием в STM32 без DMA применять нельзя.
Поскольку прерывания по приему начинают пропускаться.
Это описано в еррата какой-либо? У меня сложилось впечатление, что в этих процах ПДП вообще применять стоит редко и осторожно, а вместе с вашей репликой и вовсе выходит, что уапп в этих процессорах лучше не применять
Цитата(DASM @ May 24 2013, 19:26)
Это описано в еррата какой-либо? У меня сложилось впечатление, что в этих процах ПДП вообще применять стоит редко и осторожно, а вместе с вашей репликой и вовсе выходит, что уапп в этих процессорах лучше не применять
Само наличие такого явления как еррата означает, что в ней много чего еще нет.
На микроконтроллеры которые по 6-ть лет выпускются до сих порт обновляют ерраты.
И как-то не досуг писать в ST про их проблемы.
Но факт есть факт, на 900 кбит UART в STM32 пропускал прерывания на прием. При том что сама процедура прерывания была короткой и самой приоритетной. Прерывания в остальной программе запрещались не больше чем на десятки тактов.
Вот эта процедура:
Код
void USART1_IRQHandler(void)
{
unsigned short sr;
unsigned int tmp;
sr = USART1->SR;
if( sr & USART_SR_RXNE )
{
// Получили байт, сохраняем в кольцевом буфере
tmp = comc_in_buf_head[0];
comc_input_buf[0][comc_in_buf_head[0]++] = USART1->DR;
comc_in_buf_head[0] &= (COMC_IN_BUF_SZ - 1);
if( comc_in_buf_head[0]==comc_in_buf_tail[0] ) comc_in_buf_head[0] = tmp; // Если происходит переполнение то не сдвигать указатель буфера
if( receive_task[0]!=0 )
isr_evt_set (BYTE_FROM_UART_EVNT, receive_task[0]);
}
if( sr & USART_SR_ORE )
{
dummy = USART1->DR;
}
if( ( sr & USART_SR_TXE) && (USART1->CR1 & USART_CR1_TXEIE) )
{
USART1->DR = comc_output_buf[0][comc_out_buf_tail[0]++];
comc_out_buf_tail[0] &= (COMC_OUT_BUF_SZ - 1);
if( comc_out_buf_head[0] == comc_out_buf_tail[0] )
{
USART1->CR1 &= ~USART_CR1_TXEIE; // Запретим прерывания если нечего передавать
}
}
}
{
unsigned short sr;
unsigned int tmp;
sr = USART1->SR;
if( sr & USART_SR_RXNE )
{
// Получили байт, сохраняем в кольцевом буфере
tmp = comc_in_buf_head[0];
comc_input_buf[0][comc_in_buf_head[0]++] = USART1->DR;
comc_in_buf_head[0] &= (COMC_IN_BUF_SZ - 1);
if( comc_in_buf_head[0]==comc_in_buf_tail[0] ) comc_in_buf_head[0] = tmp; // Если происходит переполнение то не сдвигать указатель буфера
if( receive_task[0]!=0 )
isr_evt_set (BYTE_FROM_UART_EVNT, receive_task[0]);
}
if( sr & USART_SR_ORE )
{
dummy = USART1->DR;
}
if( ( sr & USART_SR_TXE) && (USART1->CR1 & USART_CR1_TXEIE) )
{
USART1->DR = comc_output_buf[0][comc_out_buf_tail[0]++];
comc_out_buf_tail[0] &= (COMC_OUT_BUF_SZ - 1);
if( comc_out_buf_head[0] == comc_out_buf_tail[0] )
{
USART1->CR1 &= ~USART_CR1_TXEIE; // Запретим прерывания если нечего передавать
}
}
}
Причем ждать пропуска прерываний приходилось довольно долго. Никакой системы в появлении этого бага не обнаружил.
После того как стал использовать DMA проблем не стало.
Тоже вначале было без ДМА, но никаких проблем никогда не было, правда и скорость больше 115200 не использовал.
Потом прицепил ДМА, принципиальной разницы не заметил, ибо нет загруженности проца.
Так что кому что нравится, но с ДМА кошерней
Потом прицепил ДМА, принципиальной разницы не заметил, ибо нет загруженности проца.
Так что кому что нравится, но с ДМА кошерней
Цитата(demiurg_spb @ May 25 2013, 00:45)
Так что кому что нравится, но с ДМА кошерней
ИМХО, для процессоров с недоделанным UART'ом (без FIFO), в сколько нибудь сложном и загруженном приложении без DMA никак.
чудеса... ДМА же запускается по тем же самым прерываниям, то есть если ДМА его видит то и обычная процедура должна была увидеть. В целом, наверное, в сложных системах на скоростях уарта 900 КБит (вот же вы его разогнали) правда уже за всем не уследить. Но я бы менял протокол а не дма прикручивал бы. Если все работает на грани - это вероятный источник проблем для меня, лучше поменять идеологию и получить запас. ИМХО....
Цитата(aaarrr @ May 25 2013, 01:19)
ИМХО, для процессоров с недоделанным UART'ом (без FIFO), в сколько нибудь сложном и загруженном приложении без DMA никак.
Согласен.Цитата(Golikov A. @ May 25 2013, 09:59)
чудеса...
А я скажу что чудес не бывает в нашей профессии.Всё рано или поздно вылезает наружу...
о том и речь, что если такое произошло хорошо бы было понять почему оно так получилось....
Цитата(AlexandrY @ May 24 2013, 23:07)
Причем ждать пропуска прерываний приходилось довольно долго. Никакой системы в появлении этого бага не обнаружил.
После того как стал использовать DMA проблем не стало.
После того как стал использовать DMA проблем не стало.
Похоже на проблемы с конвеером. Тады ой будет - такое возникнет рано или поздно с любой периферией.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.