my504 (28.12.2022 13:28, просмотров: 3752)-
- А отладчик какой пользуешь? POV(171 знак., 27.03.2023 11:34)
- Вначале купили пару ATlink-ов, но потом как то незаметно перешли на
Jlink. ATlink-и остались только на производстве - ими шьют
продукцию через Artery ISP Programmer (родную утилиту
производителя). А так у нас все сидят на Кейле. Artery предлагает
либо свою IDE (эклипсовую), либо Кейл. - my504(27.03.2023 11:57)
- jlink имеется. Но раз у вас Keil, то openocd не используется? - POV(27.03.2023 11:58)
- Нет. - my504(27.03.2023 12:00)
- jlink имеется. Но раз у вас Keil, то openocd не используется? - POV(27.03.2023 11:58)
- Вначале купили пару ATlink-ов, но потом как то незаметно перешли на
Jlink. ATlink-и остались только на производстве - ими шьют
продукцию через Artery ISP Programmer (родную утилиту
производителя). А так у нас все сидят на Кейле. Artery предлагает
либо свою IDE (эклипсовую), либо Кейл. - my504(27.03.2023 11:57)
- Правильнее чтобы прием в кольцевой буфер по DMA был включен всегда.
А в момент когда надо ловить адресный байт - разрешать прерывания и
в обработчике вылавливать принятые по DMA байты. Нет риска пропуска
байтов на высокой скорости. Прием по DMA и запросы прерывания
дополняют друг друга, а не мешают. На STM32 так, во всяком случае. - il-2(28.12.2022 18:15)
- "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)
- Нет искажений в канале передачи при его целостности. Но если будет
обрыв одного провода дифпары или что то подобное, то пакеты начнут
выбрасываться на приемной стороне. Основная идея в том, что нет
связи между нисходящим и восходящим потоками, кроме как в
подтверждении управления (изменили некий параметр в управляющем -
результат увидим в мониторинговом). Но нет необходимости делать это
в пакете ответа немедленно. Задержка в 1...3 пакета не создает
дискомфорта при управлении my504(49 знак., 30.12.2022 07:37)
- Искажений пакетов нет по определению. - ну собственно всё, я так и понял - =AlexD=(29.12.2022 18:08)
- Давай уточню, ты принимаешь решение об ответе на основании первого
байта пакета, который может исказиться и ответ придёт в лучшем
случае не от того слейва, в худшем - от двух слейвов одновременно.
Или я чего то не понимаю? Обычно делают не так, отвечает тот слейв,
которого запрашивали в прошлый раз (со всеми контролями ошибок). - =AlexD=(29.12.2022 17:09)
- Не совсем 422-ой. Хотя физика идентична. Разница в максимальном
количестве слейвов в линии. Обычно у Аналог девайса фул-дуплексные
драйверы с управлением передатчиком называются 485-ми, а без такого
управления - 422-ми. Про ответ в линию. Устройство принимает
управляющий пакет (он шифрован динамическим симметричным кодом), а
отдает открытый пакет мониторинга параметров устройства. Пакет
мониторинга защищен CRC, как и управляющий пакет. Большая часть
управляющих пакетов my504(494 знак., 29.12.2022 16:58)
- RS485 FullDuplex - это RS422 ? Приняли свой стартовый байт - запустили прием пакета и передачу
пакета - т.е. ответ не зависит от принимаемого пакета, это просто маркер
обмена с конкретным устройством? А как обрабатываются возможные
ошибки на линии? - =AlexD=(29.12.2022 08:12)
- Задача DMA - принимать байты и не пропускать ни одного. Задача
обработчика - анализировать содержимое (когда надо). Это разные
задачи, которые на STM32 делаются прозрачно и независимо друг от
друга. - il-2(28.12.2022 18:28)
- Анализировать надо не в прерывании, а в фоновой задаче. А если анализировать надо быстро, и фоновая задача не успевает, то в прерывании и принимать, и анализировать, чтобы не плодить сущности (дма). Если только дма уже сделан и работает, тогда нафиг его ломать... - SciFi(28.12.2022 18:48)
- Ничего прозрачного там нет. И быть не может. - POV(28.12.2022 18:30)
- Для запуска ДМА нужно либо получить синхронизацию с началом
принимаемого пакета, либо обрабатывать кольцевой буфер и там
находить начало. Однако ответ устройства должен происходить сразу
после получения стартового адресного байта по приемнику. В системе
используется RS485 FullDuplex. Поэтому кольцевой буфер не катит.
Приняли свой стартовый байт - запустили прием пакета и передачу
пакета. Не приняли свой - ничего не запускаем. Принимать по ДМА все
подряд - это тупейшее решение my504(390 знак., 29.12.2022 02:49)
- "DMA и запросы прерывания дополняют друг друга" - ты прям серьезно
про это? А зачем оно и нахуя? Если есть прерывание - ну тут и
обработай... я на с8051 мегабит с ЦРЦ16 успеваю обрабатывать.. Если
ДМА используешь, то уж как-то попробуй без прерываний обойтись. - POV(28.12.2022 18:19)
- Разобрался... ))) Долбанная система реквестов ДМА... Случайно включил в модуле SPI1_TX разрешение ДМА, а SPI1_TX оказался на том же канале ДМА, что и UART1_RX. Вот он и реквестил прием по RS485 с частотой дискретизации внешнего 16-разрядного АЦП... ))) - my504(28.12.2022 16:21)
- А отладчик какой пользуешь? POV(171 знак., 27.03.2023 11:34)