-
- Шансов для устройства, тактируемого по второму перепаду, мало.
Данные изменяются на 9нс
раньшепосле того, как происходит нештатный, преждевременный тактовый перепад. Вместо требуемых в моём случае 50нс, удержание данных сохраняется лишь 9нс. Это нехорошо. Nikolay_Po(127 знак., 28.04.2025 11:56, картинка)- Ты ниже написал - что тактовая МК 110МГц - т.е. период как раз 9нс.
Можно попробовать посмотреть - изменится ли эта задержка от смены
тактовой МК. Посмотреть - от какой частоты зависит - от AHB или
APB. Если от APB - то можно в принципе снизить ее до 20-30МГц и
таким образом сделать эту задержку более "приличной" - 30-50нс. Так
глядишь - и победить это горе через задний проход :-) - il-2(28.04.2025 18:13)
- Хмм... Спасибо! Гениально! Я сам не догадался. Сейчас проработаю
этот вариант. У меня на этой же шине уже разведённый UART работает.
Но я предусмотрительно сделал тактовую и кварц кратным UART. Должно
сложиться. Мне нужно удержание данных 50нс. Это значит, что
тактовую нужно понизить не выше чем до 1/50нс=20МГц. Системная
частота у меня сейчас 110.592МГц. Значит, нужен делитель не менее
5.5296
МГц. В наличии делители 2, 4, 8 и 16. Беру 8. Nikolay_Po(476 знак., 28.04.2025 22:31)- Сработало! После изменения делителя PPRE2 в регистре CFGR0 модуля
тактирования RCC, частота второй периферийной шины (PB2) поделилась
на 8, стала 13.824МГц. USART-делители пересчитались автоматически,
связь по RS-485 с устройством не нарушилась. Кадровый таймер
интерфейса связи не пострадал - оказался на первой периферийной
шине (впрочем, и он пересчитывается автоматически - стоит лишь
делитель верно задать). Nikolay_Po(435 знак., 28.04.2025 22:46, картинка, картинка)
- Погонял малость. По устранял ошибки. Типа, в режиме только передачи, когда входящие с SPI не нужны, не включал DMA на приём. А в SPI ошибка OVR и её выявлял обработчик состояния SPI. Так же нужно было не забыть добавить очистку лишнего байта в буфере приёма и сброса ошибки последовательным чтением сначала регистра данных, потом статуса. Nikolay_Po(522 знак., 29.04.2025 01:37)
- Если переходить на программный, тогда зачем ДМА? В обычном режиме
оно работает нормально. Ну как, "нормально"... Работает. А я, в
ряде случаев, делаю программный интерфейс для РС232, СПИ, через
ДМА, чтобы не отвлекаться, в процэссе передачи. Формирую в ОЗУ
последовательность установок-сбросов бит порта и травлю на него
ДМА. Много ОЗУ идёт в расход, но щас этого ОЗУ, как у дурака
фантиков. Скорости можно добиться высокой. - mse homjak(28.04.2025 23:17)
- Эта схема понятна. Но вы видели самое первое сообщение? И диаграмму
в нём? У меня не UART. И этим же, дефектным, модулем SPI, подобная
эмуляция нужного, верного сигнала невозможна - просто не хватит
сигнальных линий или будет невозможной своевременная выборка по
приёму. - Nikolay_Po(29.04.2025 01:42)
- Ну это как вариант предложил. Если, например, нужно чота быстро загрузить в ЦАП, по таймеру и чтобы с NSS и минимальным жыттером. А СПИ от СТМ. Он, кстати, когда шлёт 16 бит, все флаги готовности, подымает на 8 бите. В общем, апофигей. У кого они это говно купили? Или сами сделали? - mse homjak(29.04.2025 11:18)
- Эта схема понятна. Но вы видели самое первое сообщение? И диаграмму
в нём? У меня не UART. И этим же, дефектным, модулем SPI, подобная
эмуляция нужного, верного сигнала невозможна - просто не хватит
сигнальных линий или будет невозможной своевременная выборка по
приёму. - Nikolay_Po(29.04.2025 01:42)
- Сработало! После изменения делителя PPRE2 в регистре CFGR0 модуля
тактирования RCC, частота второй периферийной шины (PB2) поделилась
на 8, стала 13.824МГц. USART-делители пересчитались автоматически,
связь по RS-485 с устройством не нарушилась. Кадровый таймер
интерфейса связи не пострадал - оказался на первой периферийной
шине (впрочем, и он пересчитывается автоматически - стоит лишь
делитель верно задать). Nikolay_Po(435 знак., 28.04.2025 22:46, картинка, картинка)
- Хмм... Спасибо! Гениально! Я сам не догадался. Сейчас проработаю
этот вариант. У меня на этой же шине уже разведённый UART работает.
Но я предусмотрительно сделал тактовую и кварц кратным UART. Должно
сложиться. Мне нужно удержание данных 50нс. Это значит, что
тактовую нужно понизить не выше чем до 1/50нс=20МГц. Системная
частота у меня сейчас 110.592МГц. Значит, нужен делитель не менее
5.5296
- Ты ниже написал - что тактовая МК 110МГц - т.е. период как раз 9нс.
Можно попробовать посмотреть - изменится ли эта задержка от смены
тактовой МК. Посмотреть - от какой частоты зависит - от AHB или
APB. Если от APB - то можно в принципе снизить ее до 20-30МГц и
таким образом сделать эту задержку более "приличной" - 30-50нс. Так
глядишь - и победить это горе через задний проход :-) - il-2(28.04.2025 18:13)
- Периферия у меня старый АЦП, у него 50нс требуется удерживать
данные с момента перехода сигнала тактирования. - Nikolay_Po(28.04.2025 09:34)
- Должно всё выдерживаться. Я всегда использовал режимы "0" и "1" в SPI, т.е. данные сразу на шине (CPHA=0), а после клок (защёлка) или положительный или отрицательный. Пин /SS настроен правильно? - vpv.vpv(28.04.2025 09:48)
- Я так думаю, что задержки SPI должны быть равны половине периода
клока. Для этого частота SPI и выбирается (1/2, 1/8, ... 1/64...).
Тут что-то другое. - vpv.vpv(28.04.2025 09:34)
- У меня тактовая 110МГц, делитель 128. А тактов за 5..10, по первому
фронту, DMA успевает загрузить следующий символ. Вроде как фазу
тактового сигнала на выходе (и на входе?) поменяли, а момент
загрузки нового символа остался по первому фронту. - Nikolay_Po(28.04.2025 09:41)
- А каких-нибудь коллизий с флагом "SPI_ENABLE" (или как там его, готовность передачи следующего символа) - нет? Надо аппаратную часть CH32V смотреть, как там буферизация устроена. - vpv.vpv(28.04.2025 09:53)
- У меня тактовая 110МГц, делитель 128. А тактов за 5..10, по первому
фронту, DMA успевает загрузить следующий символ. Вроде как фазу
тактового сигнала на выходе (и на входе?) поменяли, а момент
загрузки нового символа остался по первому фронту. - Nikolay_Po(28.04.2025 09:41)
- Шансов для устройства, тактируемого по второму перепаду, мало.
Данные изменяются на 9нс