-
- Всем спасибо! Кажись победил! Путём научного тыка в бубен родил
такой код. Правда пришлось добавить еще одну функцию, занятость
SPI. Немножко придется поправить обмен. IBAH(1313 знак., 05.06.2025 15:24, картинка)
- Хня все это! не работает - IBAH(Вчера, 15:09)
- на стр. 490 при передаче предлагают игнорить RBNE Vit(1 знак., 05.06.2025 13:37, ссылка)
- Ну это понятно, передача у меня так и работает. - IBAH(05.06.2025 14:12)
- что-то там мутное. "в полнодуплексном ведущем режиме (MFD)
оборудование получает следующий кадр данных только тогда, когда
буфер передачи не пуст." Vit(802 знак., 05.06.2025 15:00)
- Хз... Мастер, в полнодуплексном режиме, засылает 16 бит в datar(я
предпочитаю "0", но надо смотреть документацию оконечного
устройства) и, как тока попускает, выгребает из datar данные. При
необходимости, повторить. Чота я смотрю на дискуссию и не понимаю,
обо што разговор. - mse homjak(Вчера, 12:00)
- Разговор о том, что флаг RXNE выставляется, по факту не когда
происходит завершение приема, а на несколько десятков тактов проца
позже (в моем случае гдето 500нС). В результате стоишь тупо ждешь
RXNE!=0, как дебил. С флагом BSY та же история. - IBAH(Вчера, 15:18)
- 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)
- Этот код ничего не доказывает. Сколько времени проходит между
SPI2->DATAR=(uint16_t)0; и входом в прерывание? я думаю больше
16 тактов SPI, как раз на те самые 500нС - IBAH(Вчера, 18:41)
- Это у вас ошибочка. Вы ждёте лишнего следующего символа. Нет у периферии такой памяти, чтобы задержать
сигнал на на кучу тактов. Вы просто промахиваетесь с приёмом. Или
пропускаете
битбайт (тогда будет поднят флаг оверфлоу, проверьте), или принимаете и упускаете один, а потом ждёте лишнего. 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)
- Не катит. ТСу нужна непрерывная передача, а по BSY она будет
дырявой. - Nikolay_Po(Вчера, 20:29)
- Чихайте смело. Дажэ плюйте. Просто контролируйте передачу. mse homjak(317 знак., Вчера, 18:53)
- Я так и делаю... Правда на переполнение Rx чихаю. Может из-за этого
проблемы... Попробую не чихать - IBAH(Вчера, 18:24)
- Ну да. Не вижу противоречий. Как только взводится TXE, сразу
кидайте следующий байт. Но кидать больше байт, чем у вас длина
транзакции - не нужно. Кинули последний, выключили прерывание по
TXE и ждёте падения BSY. Всё. Транзакция закончилась ровно тем
количеством байт, которое отправили в буфер передачи. Так получите
полностью слитную посылку. Nikolay_Po(1026 знак., Вчера, 17:46)
- Я по всякому пробовал... Мне как раз не нужно буферизированное
чтение. Я на ходу байты разбираю. А в доке по GD32 так и написано IBAH(236 знак., Вчера, 16:46)
- RXNE выставляется после передачи байта. Полюбому, чисто, чтобы вы
не забыли вычитать данные(на самом деле, хуй его знает, зачем этот
флаг). Смотрите первые два сообщения по сцылке про это. И пофиг,
передаётся 8 или 16 бит. Это косяг, ессно. Флаг должэн взводиться
после завершения базовой транзакции, т.к. при передаче одновременно
идёт и приём. Т.е. сигнала BUSY или TXE достаточно. Хотя TXE тожэ
нах не упёрся, они оба-три дублируют друг друга. Нижэ код работы с
АЦП. mse homjak(932 знак., Вчера, 18:30, ссылка)
- Разговор о том, что флаг RXNE выставляется, по факту не когда
происходит завершение приема, а на несколько десятков тактов проца
позже (в моем случае гдето 500нС). В результате стоишь тупо ждешь
RXNE!=0, как дебил. С флагом BSY та же история. - IBAH(Вчера, 15:18)
- Спасибо. Совпадает с моими представлениями. Nikolay_Po(295 знак., Вчера, 09:00)
- Хз... Мастер, в полнодуплексном режиме, засылает 16 бит в datar(я
предпочитаю "0", но надо смотреть документацию оконечного
устройства) и, как тока попускает, выгребает из datar данные. При
необходимости, повторить. Чота я смотрю на дискуссию и не понимаю,
обо што разговор. - mse homjak(Вчера, 12:00)
- что-то там мутное. "в полнодуплексном ведущем режиме (MFD)
оборудование получает следующий кадр данных только тогда, когда
буфер передачи не пуст." Vit(802 знак., 05.06.2025 15:00)
- Ну это понятно, передача у меня так и работает. - IBAH(05.06.2025 14:12)
- предложу попробовать поменять строки LL_SPI_Init(SPI2,
&SPI_InitStruct); и LL_SPI_Enable(SPI2); между собой - Vit(05.06.2025 12:21)
- Не катит. Некоторые настройки (регистр CR) можно менять только при выключенном EN - IBAH(05.06.2025 12:25)
- А я вот так с SPI работал vesago(2363 знак., 05.06.2025 11:56)
- Я с этого начал... Проблема в том, что флаг RXNE выставляется с задержкой. И между байтами мы имеем паузы. Я подозреваю проблема в том, что SPI2 сидит на медленной шине. - IBAH(05.06.2025 12:03)
- Но с GD я всеж предпочел кишки на родных китайских либах переделать. Они приятные. А на st у меня cdc не заработал. - vesago(05.06.2025 11:57)
- У тебя между обменами - 500нс, это десятки тактов МК. Что ты еще
хочешь от программного SPI, да еще через библиотеку, да еще с
ожиданием после каждого байта посылки, т.е. без использования
буферного регистра данных SPI. Так оно примерно и будет, так что
все нормально. - il-2(05.06.2025 06:15)
- Херасе нормально! выставление сигнала RXNE идет 32 такта
процессора!!! - IBAH(05.06.2025 11:07)
- Когда я вижу все эти кубические коды, у меня кровь из глаз. Для
простейшей вещи придумывают какие-то структуры, вложенные вызовы
функций и всякое разное. Нет, я не агитирую за преждевременную
оптимизацию, меня лишние слои "абстракции" приводят в недоумение.
Ну а потом, когда всё это хозяйство немного заносит на поворотах,
удивляться нечему... - SciFi(05.06.2025 11:18)
- Нету там "структуры, вложенные вызовы функций"!!! Это LL! все
статик инлайн, тупо пишем в регистры! Листинг я приводил IBAH(452 знак., 05.06.2025 11:35)
- Ну если это не аддитивная задержка от выполнения кода между
передачами - попробуй уменьшить в N раз частоту SPI. Если задержка
тоже растянется в N раз, то - поздравляю, ты выловил баг!!! Я
работал с GD32F1 SPI по DMA - такого не наблюдалось. Возможно
задержка такая есть в начале, а при непрерывной передаче ее между
байтами нет. - il-2(05.06.2025 13:57)
- Баг я и так выловил. Только непонятно чей... Судя по ссылке от POV, таки STMовский - IBAH(05.06.2025 15:27)
- Вот еще: il-2(1 знак., 05.06.2025 14:05, картинка)
- Ну если это не аддитивная задержка от выполнения кода между
передачами - попробуй уменьшить в N раз частоту SPI. Если задержка
тоже растянется в N раз, то - поздравляю, ты выловил баг!!! Я
работал с GD32F1 SPI по DMA - такого не наблюдалось. Возможно
задержка такая есть в начале, а при непрерывной передаче ее между
байтами нет. - il-2(05.06.2025 13:57)
- Нету там "структуры, вложенные вызовы функций"!!! Это LL! все
статик инлайн, тупо пишем в регистры! Листинг я приводил IBAH(452 знак., 05.06.2025 11:35)
- Когда я вижу все эти кубические коды, у меня кровь из глаз. Для
простейшей вещи придумывают какие-то структуры, вложенные вызовы
функций и всякое разное. Нет, я не агитирую за преждевременную
оптимизацию, меня лишние слои "абстракции" приводят в недоумение.
Ну а потом, когда всё это хозяйство немного заносит на поворотах,
удивляться нечему... - SciFi(05.06.2025 11:18)
- Херасе нормально! выставление сигнала RXNE идет 32 такта
процессора!!! - IBAH(05.06.2025 11:07)
- Йа каг-то упоролся с СПИ СТМа. Часть моей боли тут, по сцылке. mse homjak(1 знак., 04.06.2025 23:38, ссылка)
- Помню, был такой СТэМ СПИ. Этo_Я(86 знак., 05.06.2025 00:10)
- СПИ, помню, СТЭМ, не помню. Видать, мимо прошло. - mse homjak(05.06.2025 10:45)
- Помню, был такой СТэМ СПИ. Этo_Я(86 знак., 05.06.2025 00:10)
- от POV(1 знак., 04.06.2025 21:24, ссылка)
- Пионеры какие-то! Решение так и не нашли... - IBAH(05.06.2025 11:09)
- В листинге все ОК, наблюдаю байтовую запись STRB r2,[r4,#0xc] IBAH(442 знак., 04.06.2025 20:54)
- попробуй перед отправкой еще флаг TXE проверять POV(53 знак., 04.06.2025 20:54, картинка)
- Ничего не поменялось... да и не должно... - IBAH(04.06.2025 21:02)
- измени делитель - будет ли пауза пропорционально растянута или
останется той же - POV(04.06.2025 21:20)
- увеличил делитель в 2 раза, пауза осталась такой же - IBAH(04.06.2025 21:33)
- значит не "16 бит", а какие-то косяки по функциям LL. глянь что
внутри, может там проверки лишние или неверные, а большинству
эмбеддеров эти задержки просто побоку, не замечают... POV(113 знак., 04.06.2025 21:55)
- там в этих функциях ничего криминального. Это не баг, это какая-то
аппаратная фича IBAH(720 знак., 04.06.2025 22:16)
- Робот советует )) POV(2 знак., 04.06.2025 22:24, картинка, картинка)
- Кстати "насчет всё пучком у меня" я может и согрешил. Недавно на
100М запускал SPI в AT32, аданные были нужны по 16 бит. Переход с
двух отправок по 8 на одну по 16 ну просто пиздец как ускорил
процесс. Может у клонов STM32 реально есть косяки и с SPI. - POV(04.06.2025 22:19)
- нет, не оно... POV(169 знак., 05.06.2025 11:22, картинка, картинка)
- Попробую переписать через BSY - IBAH(05.06.2025 11:31)
- скорее всего тупит на ожидании RXNE. лучше на без него передавать,
а потом очистить примный буфер и флаги - POV(05.06.2025 12:02)
- Таже хрень, точно также тупит на BSY - IBAH(05.06.2025 12:17)
- Ну ты ожидание RXNE убрал? Там может коллизия из-за невычитанности
своевременной. А если читать не нужно, то сразу (после каждого
байта) и не читай. Жди лишь освобождения буфера передатчика
(буфера, а не окончания физической передачи). - POV(05.06.2025 12:23)
- У меня задача верхнего уровня следующая. Записать в SPI 3 байта,
потом либо читать, либо писать N байт. С записью все в порядке,
если через TXE. С чтением трабл. А мне чтение гораздо важнее. - IBAH(05.06.2025 12:54)
- Что, реально не успевает? - SciFi(05.06.2025 13:02)
- Реально. На софтовом SPI я укладывался в 75-80мкс. Много.
Рассчитывал в десятку уложится, и так прокололся заложил SPI на
медленной шине. - IBAH(05.06.2025 13:15)
- Переделать на регистрах+DMA. Там не страшно, несколько десятков
строк будет, наверное. Если так не взлетит, тогда не знаю... - SciFi(05.06.2025 13:17)
- Да LL это просто обертка над регистрами. Заинлайинится всё только в
путь. Тут не в библле дело. - POV(05.06.2025 13:21)
- Тут другое дело. Когда у меня на DMA было, всё работало. Но у меня
транзакции были по паре байт. И я решил, зачем такой большой объём
кода для настройки и запуска DMI? Nikolay_Po(367 знак., 05.06.2025 14:42)
- Вот это тоже не могу понять "большой объём кода для настройки и запуска DMA". Где большой-то? SciFi(454 знак., 05.06.2025 14:45)
- Тут другое дело. Когда у меня на DMA было, всё работало. Но у меня
транзакции были по паре байт. И я решил, зачем такой большой объём
кода для настройки и запуска DMI? Nikolay_Po(367 знак., 05.06.2025 14:42)
- Да LL это просто обертка над регистрами. Заинлайинится всё только в
путь. Тут не в библле дело. - POV(05.06.2025 13:21)
- Переделать на регистрах+DMA. Там не страшно, несколько десятков
строк будет, наверное. Если так не взлетит, тогда не знаю... - SciFi(05.06.2025 13:17)
- Реально. На софтовом SPI я укладывался в 75-80мкс. Много.
Рассчитывал в десятку уложится, и так прокололся заложил SPI на
медленной шине. - IBAH(05.06.2025 13:15)
- Что, реально не успевает? - SciFi(05.06.2025 13:02)
- У меня задача верхнего уровня следующая. Записать в SPI 3 байта,
потом либо читать, либо писать N байт. С записью все в порядке,
если через TXE. С чтением трабл. А мне чтение гораздо важнее. - IBAH(05.06.2025 12:54)
- Ну ты ожидание RXNE убрал? Там может коллизия из-за невычитанности
своевременной. А если читать не нужно, то сразу (после каждого
байта) и не читай. Жди лишь освобождения буфера передатчика
(буфера, а не окончания физической передачи). - POV(05.06.2025 12:23)
- Таже хрень, точно также тупит на BSY - IBAH(05.06.2025 12:17)
- скорее всего тупит на ожидании RXNE. лучше на без него передавать,
а потом очистить примный буфер и флаги - POV(05.06.2025 12:02)
- Попробую переписать через BSY - IBAH(05.06.2025 11:31)
- нет, не оно... POV(169 знак., 05.06.2025 11:22, картинка, картинка)
- там в этих функциях ничего криминального. Это не баг, это какая-то
аппаратная фича IBAH(720 знак., 04.06.2025 22:16)
- значит не "16 бит", а какие-то косяки по функциям LL. глянь что
внутри, может там проверки лишние или неверные, а большинству
эмбеддеров эти задержки просто побоку, не замечают... POV(113 знак., 04.06.2025 21:55)
- увеличил делитель в 2 раза, пауза осталась такой же - IBAH(04.06.2025 21:33)
- измени делитель - будет ли пауза пропорционально растянута или
останется той же - POV(04.06.2025 21:20)
- вот робот по LL написал POV(1 знак., 04.06.2025 20:57, картинка)
- Ничего не поменялось... да и не должно... - IBAH(04.06.2025 21:02)
- Или проблема в медленной шине APB1 на которой сидит SPI2 ? - IBAH(04.06.2025 20:54)
- Компилятор Кейл. - IBAH(04.06.2025 20:43)
- Всем спасибо! Кажись победил! Путём научного тыка в бубен родил
такой код. Правда пришлось добавить еще одну функцию, занятость
SPI. Немножко придется поправить обмен. IBAH(1313 знак., 05.06.2025 15:24, картинка)