caxapa.ru :: Разговор о том, что флаг RXNE выставляется, по факту не когда происходит завершение приема, а на несколько десятков тактов проца позже (в моем случае гдето 500нС). В результате стоишь тупо ждешь RXNE!=0, как дебил. С флагом BSY та же история.

IBAH (Вчера, 15:18, просмотров: 50) ответил mse homjak на Хз... Мастер, в полнодуплексном режиме, засылает 16 бит в datar(я предпочитаю "0", но надо смотреть документацию оконечного устройства) и, как тока попускает, выгребает из datar данные. При необходимости, повторить. Чота я смотрю на дискуссию и не понимаю, обо што разговор.

Разговор о том, что флаг RXNE выставляется, по факту не когда происходит завершение приема, а на несколько десятков тактов проца позже (в моем случае гдето 500нС). В результате стоишь тупо ждешь RXNE!=0, как дебил. С флагом BSY та же история.

Ответить

- RXNE выставляется после передачи байта. Полюбому, чисто, чтобы вы не забыли вычитать данные(на самом деле, хуй его знает, зачем этот флаг). Смотрите первые два сообщения по сцылке про это. И пофиг, передаётся 8 или 16 бит. Это косяг, ессно. Флаг должэн взводиться после завершения базовой транзакции, т.к. при передаче одновременно идёт и приём. Т.е. сигнала BUSY или TXE достаточно. Хотя TXE тожэ нах не упёрся, они оба-три дублируют друг друга. Нижэ код работы с АЦП. mse homjak(932 знак., Вчера, 18:30, ссылка)
  - Этот код ничего не доказывает. Сколько времени проходит между SPI2->DATAR=(uint16_t)0; и входом в прерывание? я думаю больше 16 тактов SPI, как раз на те самые 500нС - IBAH(Вчера, 18:41)
    - То, что больше, к бабке не ходи, т.к. время на вход, контент, пока доберётся до загрузки. Но тут по другому нельзя было. А по сцылке, я пытался в аппаратный NSS, но уй там. Потому, для многобайтных потоков или программного NSS, нужно просто следить за BUSY безо всяких прерываний. И чем выше скорость SCLK, тем выгоднее тупой поллинг BUSY. - mse homjak(Вчера, 18:47)
      - А вот насчот ДМА я не слышал ничего. Чому бы и ни? Там накладные расходы должны быть минимальными. Да, есть эвенты на чтение и запись. Мож потому и сделали флаги ТХЕ и РХНЕ, вместо одной БИЗИ.. - mse homjak(Вчера, 20:05)
- Это у вас ошибочка. Вы ждёте лишнего следующего символа. Нет у периферии такой памяти, чтобы задержать сигнал на на кучу тактов. Вы просто промахиваетесь с приёмом. Или пропускаете ~~бит~~ байт (тогда будет поднят флаг оверфлоу, проверьте), или принимаете и упускаете один, а потом ждёте лишнего. Nikolay_Po(842 знак., Вчера, 15:38)
  - Я по всякому пробовал... Мне как раз не нужно буферизированное чтение. Я на ходу байты разбираю. А в доке по GD32 так и написано IBAH(236 знак., Вчера, 16:46)
    - Ну да. Не вижу противоречий. Как только взводится TXE, сразу кидайте следующий байт. Но кидать больше байт, чем у вас длина транзакции - не нужно. Кинули последний, выключили прерывание по TXE и ждёте падения BSY. Всё. Транзакция закончилась ровно тем количеством байт, которое отправили в буфер передачи. Так получите полностью слитную посылку. Nikolay_Po(1026 знак., Вчера, 17:46)
      - Я так и делаю... Правда на переполнение Rx чихаю. Может из-за этого проблемы... Попробую не чихать - IBAH(Вчера, 18:24)
        
        Чихайте смело. Дажэ плюйте. Просто контролируйте передачу. mse homjak(317 знак., Вчера, 18:53)
        
        Не катит. ТСу нужна непрерывная передача, а по BSY она будет дырявой. - Nikolay_Po(Вчера, 20:29)
        
        Ну, тогда, канешно, придётся смотреть на ТХЕ. Если он работает как должэн. Тактовая, порты, делим на 2, СПИ тожэ на 2. Это максимальная СЦК. У СПИ есть двойная буферизация, когда идёт передача, в ДАТАР можно записать следующее. Скока там будет, читать статус, проверить флаг, записать новое, подготовить следующее? Думаю, быстрее, чем 16*4 тактов. - mse homjak(Вчера, 22:30)

ARM, RISC-V контроллеры