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

il-2 (28.04.2025 18:13, просмотров: 119) ответил Nikolay_Po на Шансов для устройства, тактируемого по второму перепаду, мало. Данные изменяются на 9нс ~~раньше~~ после того, как происходит нештатный, преждевременный тактовый перепад. Вместо требуемых в моём случае 50нс, удержание данных сохраняется лишь 9нс. Это нехорошо.

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

Ответить

- Хмм... Спасибо! Гениально! Я сам не догадался. Сейчас проработаю этот вариант. У меня на этой же шине уже разведённый 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)

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