caxapa.ru :: Хмм... Спасибо! Гениально! Я сам не догадался. Сейчас проработаю этот вариант. У меня на этой же шине уже разведённый UART работает. Но я предусмотрительно сделал тактовую и кварц кратным UART. Должно сложиться. Мне нужно удержание данных 50нс. Это значит, что тактовую нужно понизить не выше чем до 1/50нс=20МГц. Системная частота у меня сейчас 110.592МГц. Значит, нужен делитель не менее 5.5296МГц. В наличии делители 2, 4, 8 и 16. Беру 8.

Nikolay_Po (28.04.2025 22:31, просмотров: 131) ответил il-2 на Ты ниже написал - что тактовая МК 110МГц - т.е. период как раз 9нс. Можно попробовать посмотреть - изменится ли эта задержка от смены тактовой МК. Посмотреть - от какой частоты зависит - от AHB или APB. Если от APB - то можно в принципе снизить ее до 20-30МГц и таким образом сделать эту задержку более "приличной" - 30-50нс. Так глядишь - и победить это горе через задний проход :-)

Хмм... Спасибо! Гениально! Я сам не догадался. Сейчас проработаю этот вариант. У меня на этой же шине уже разведённый UART работает. Но я предусмотрительно сделал тактовую и кварц кратным UART. Должно сложиться. Мне нужно удержание данных 50нс. Это значит, что тактовую нужно понизить не выше чем до 1/50нс=20МГц. Системная частота у меня сейчас 110.592МГц. Значит, нужен делитель не менее 5.5296~~МГц~~. В наличии делители 2, 4, 8 и 16. Беру 8.

Тактовая на PB2 становится 110.592МГц/8=13.824МГц. Идеально подходит для USART!

Что приятно - у меня все делители задефайнены и прописаны в вычислениях времянок и делителей тактовых. Мне достаточно поправить биты делителя в настройках тактирования и поменять дефайн с 1 на 8. Пересчитаются даже прескалеры таймеров. Если они задаются не табличными значениями, а могут быть вычислены, всегда закладываю вычисления.

Пробую.

P.S. Приехала жена. Забрала с работы. To be continued...

Ответить

- Сработало! После изменения делителя 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)

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