Я это ещё не смотрел - на такие эксперименты надо много времени. Может ничего не "падает".
Падает, чесслово! Да и времени много не надо, чтобы увидеть эффект - в течение 4-х минут гарантированно падает.
Далее мои предположения (может все и не так):
Это как-то связано с прерыванием UART. Я тут делал штуку, типа той, что
Andy Korg сделал, про часы. И все пытался это прерывание использовать. У меня не получилось стабильной работы, используя это прерывание, хотя я все делал, как и у Вас,
pvvx, в сборке. В конечном итоге плюнул на это прерывание, отключил его, завел таймер и по таймеру все считываю из UART-а. И все заработало стабильно. В моем случае это приемлемо, потому как я знаю с какой периодичностью МК шлет данные, сколько их и пр., да и передавать данные мне никуда дальше не надо - только распарсить и сохранить результат. Потом уже глянул у
Andy Korg - а у него по сути также и сделано. Надо было раньше посмотреть и не мучаться.
Вообще, вот это прерывание UART_RXFIFO_FULL_INT_ENA - оно когда должно срабатывать по идее? При заполнении буфера? А почему оно у
pvvx откомментировано как "по приему символа"? (и работает вроде как по приему символа, пока не падает).
И еще: у
Andy Korg, если дефайны раскрыть, вычитывание буфера UART производится так:
while (((READ_PERI_REG(UART_STATUS(UART0)) >> UART_RXFIFO_CNT_S) & UART_RXFIFO_CNT)) { .... RxByte = READ_PERI_REG(UART_FIFO(UART0)) ; .... }
а у меня сейчас так (но это не я придумал, есс-но, скопипастил откуда-то):
while ((READ_PERI_REG(UART_STATUS(UART0))) & (UART_RXFIFO_CNT << UART_RXFIFO_CNT_S)) {... uint8 ch= READ_PERI_REG(UART_FIFO(UART0)); .... }
а еще есть вариант (в новой сборке от pvvx):
while ((UART0_STATUS >> UART_RXFIFO_CNT_S) & UART_RXFIFO_CNT) {
uint8 ch=UART0_FIFO; .... }
Первый и третий вариант - это одно и то же?
Просто UART_RXFIFO_CNT_S - это 0, поэтому первая и вторая запись работаю в этом частном случае одинаково. Но правильно-то как?