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