caxapa.ru :: Правильнее чтобы прием в кольцевой буфер по DMA был включен всегда. А в момент когда надо ловить адресный байт - разрешать прерывания и в обработчике вылавливать принятые по DMA байты. Нет риска пропуска байтов на высокой скорости. Прием по DMA и запросы прерывания дополняют друг друга, а не мешают. На STM32 так, во всяком случае.

il-2 (28.12.2022 18:15, просмотров: 211) ответил my504 на Чего то я сегодня разошелся... ))) Еще вопрос. Работаю с AT32F421. Принимаю по UART1 пакеты по 66 байт в 9-битном режиме. Сначала в прерывании ловлю адресный байт и, если он свой, то запускаю DMA (по UART1_RX) и принимаю оставшиеся 65 байт. Проблема состоит в том, что сразу после запуска DMA происходят все 65 транзакций подряд этим самым адресным байтом без реквестов от приемника УАРТа... Словно включен режим M2M. Но он не включен. Кто может сталкивался? В AT32F407 такого не

Правильнее чтобы прием в кольцевой буфер по DMA был включен всегда. А в момент когда надо ловить адресный байт - разрешать прерывания и в обработчике вылавливать принятые по DMA байты. Нет риска пропуска байтов на высокой скорости. Прием по DMA и запросы прерывания дополняют друг друга, а не мешают. На STM32 так, во всяком случае.

Ответить

- "DMA и запросы прерывания дополняют друг друга" - ты прям серьезно про это? А зачем оно и нахуя? Если есть прерывание - ну тут и обработай... я на с8051 мегабит с ЦРЦ16 успеваю обрабатывать.. Если ДМА используешь, то уж как-то попробуй без прерываний обойтись. - POV(28.12.2022 18:19)
  - Для запуска ДМА нужно либо получить синхронизацию с началом принимаемого пакета, либо обрабатывать кольцевой буфер и там находить начало. Однако ответ устройства должен происходить сразу после получения стартового адресного байта по приемнику. В системе используется RS485 FullDuplex. Поэтому кольцевой буфер не катит. Приняли свой стартовый байт - запустили прием пакета и передачу пакета. Не приняли свой - ничего не запускаем. Принимать по ДМА все подряд - это тупейшее решение my504(390 знак., 29.12.2022 02:49)
    - RS485 FullDuplex - это RS422 ? Приняли свой стартовый байт - запустили прием пакета и передачу пакета - т.е. ответ не зависит от принимаемого пакета, это просто маркер обмена с конкретным устройством? А как обрабатываются возможные ошибки на линии? - =AlexD=(29.12.2022 08:12)
      - Не совсем 422-ой. Хотя физика идентична. Разница в максимальном количестве слейвов в линии. Обычно у Аналог девайса фул-дуплексные драйверы с управлением передатчиком называются 485-ми, а без такого управления - 422-ми. Про ответ в линию. Устройство принимает управляющий пакет (он шифрован динамическим симметричным кодом), а отдает открытый пакет мониторинга параметров устройства. Пакет мониторинга защищен CRC, как и управляющий пакет. Большая часть управляющих пакетов my504(494 знак., 29.12.2022 16:58)
        
        Давай уточню, ты принимаешь решение об ответе на основании первого байта пакета, который может исказиться и ответ придёт в лучшем случае не от того слейва, в худшем - от двух слейвов одновременно. Или я чего то не понимаю? Обычно делают не так, отвечает тот слейв, которого запрашивали в прошлый раз (со всеми контролями ошибок). - =AlexD=(29.12.2022 17:09)
        
        Адресный байт не защищен. Он не входит в расчет CRC. И да, просто нарушится обмен и выпадет пакет ответа. Ну и хрен с ним. В софте будет видно, что связь нарушилась. - my504(30.12.2022 07:42)
        
        Первый байт запроса - адресный. Поэтому ответит только ОДИН слейв. В конфигурации концентратора записан список устройств в линиях. Линий у концентратора четыре по 32 слейва в каждой максимум. Ответ должен быть в любом случае. А реакция на запрос зависит от содержимого запроса. Искажений пакетов нет по определению. Максимальная длина линии - 200 метров при рейте 115200. CRC гарантирует от фатальных ошибок связанных с неверным шифрованием. Такое возможно при апдейте софта. my504(92 знак., 29.12.2022 17:41)
        
        Искажений пакетов нет по определению. - ну собственно всё, я так и понял - =AlexD=(29.12.2022 18:08)
        
        Нет искажений в канале передачи при его целостности. Но если будет обрыв одного провода дифпары или что то подобное, то пакеты начнут выбрасываться на приемной стороне. Основная идея в том, что нет связи между нисходящим и восходящим потоками, кроме как в подтверждении управления (изменили некий параметр в управляющем - результат увидим в мониторинговом). Но нет необходимости делать это в пакете ответа немедленно. Задержка в 1...3 пакета не создает дискомфорта при управлении my504(49 знак., 30.12.2022 07:37)
        
        Пакеты отбрасываются, а адресный байт - нет. Я всё понял, можешь не продолжать. - =AlexD=(30.12.2022 09:57)
  - Задача DMA - принимать байты и не пропускать ни одного. Задача обработчика - анализировать содержимое (когда надо). Это разные задачи, которые на STM32 делаются прозрачно и независимо друг от друга. - il-2(28.12.2022 18:28)
    - Анализировать надо не в прерывании, а в фоновой задаче. А если анализировать надо быстро, и фоновая задача не успевает, то в прерывании и принимать, и анализировать, чтобы не плодить сущности (дма). Если только дма уже сделан и работает, тогда нафиг его ломать... - SciFi(28.12.2022 18:48)
    - Ничего прозрачного там нет. И быть не может. - POV(28.12.2022 18:30)

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