Вопросы
1. Верно ли ограничение «одно принятое сообщение на интерфейс за цикл диаграммы»? Можно ли вычитывать несколько сообщений за цикл или обслуживать приём независимо от полного прохода диаграммы?
2. Какова глубина RX-очереди? Что именно происходит при переполнении: какие сообщения теряются, когда сбрасывается Overflow? Есть ли штатная очистка очереди без отключения передачи?
3. Применяются ли изменения аппаратных фильтров при работающем CAN? Требуется ли переинициализация драйвера, и что происходит с накопленными сообщениями?
4. Можно ли средствами драйвера хранить последнее сообщение отдельно по каждому ID, заменяя старое новым вместо накопления FIFO? Либо ограничивать частоту поступления выбранных ID в диаграмму?
5. Какую архитектуру рекомендуете для такой нагрузки: обычный приём, асинхронный шлюз, упрощённые правила шлюза или их сочетание?
6. Поддерживает ли драйвер автоматические счётчики и контрольные суммы исходящих кадров для разгрузки диаграммы?
7. Дадут ли CANNY 7.2 Gamma или Alfa существенный выигрыш относительно 7.3 Duo именно по скорости исполнения диаграммы и обслуживанию RX, а не только по числу буферов передачи?
8. Реалистична ли такая задача на 7.3 Duo с запасом производительности?

1. В регистры драйверов попадает максимум по одному сообщению с каждого интерфейса за один цикл диаграммы.
2. У данной модели - 16 сообщений. Отбрасываются те, которые пришли когда в буфере не было свободного места.
3. Требуется ли переинициализация драйвера, накопленные сбрасываются.
4. При фильтров CAN или драйвера шлюза CAN каждому фильтру или следящему отбору выделяется свой буфер приёма. Таким образом в диаграмму гарантированно попадает каждое сообщение данного фильтра/отбора пришедшее в то время пока соответствующий буфер не был полностью заполнен.
5. Тщательно подобранное сочетание + ручная оптимизация и сокращение диаграммы до минимума. Если желаемой производительности не удается добиться оптимизацией диаграммы либо изменением подхода к реализации, то задачу можно разделить на два контроллера включенные последовательно.
6. Асинхронно выполняются только битовые операции. Всё остальное - в диаграмме.
7. Не дадут.
8. Про эту конкретную задачу слишком мало известно для уверенного прогноза. Однако, подобные задачи успешно и массово решаются не только на CANNY 7.3 Duo но и на менее производительных контроллерах CANNY с двумя CAN-интерфейсами.

Поздравляю! Успехов вам в ваших проектах!

Контроллер соединяет две отдельные сети Classic CAN, 500 кбит/с. Сообщения преимущественно со стандартными 11-битными идентификаторами, длиной до 8 байт.

Входная нагрузка после фильтрации:
Интерфейс:    Нужные сообщения:                                                    Суммарный поток:
CAN0            3 ID × 100 Гц, 2 ID × 50 Гц, 3 ID × 10 Гц                    около 430 кадров/с
CAN1            3 ID × 50 Гц, 1 ID × 10 Гц                                            около 160 кадров/с

В обеих сетях присутствует дополнительный трафик, который должен отбрасываться аппаратными фильтрами.

Логика конвертора:
- Хранение последних принятых значений с индивидуальными таймаутами.
- Проверка CRC и счётчиков части входящих сообщений.
- Перекладка битовых полей, масштабирование и целочисленные расчёты.
- Формирование исходящих счётчиков и контрольных полей.
- Передача 19 ID суммарно в обе стороны с индивидуальными периодами.
- Передача статических сообщений конфигурации.
- Диагностический CAN-монитор — один дополнительный кадр каждые 50 мс.
- Сон и пробуждение по активности CAN.
Используются 13 буферов асинхронной передачи, остальные сообщения отправляются из диаграммы. Часть вычислений выполняется в составных блоках с EN по событиям приёма/передачи. Диаграмма содержит около 1200 функциональных блоков, из них около 660 вне условных EN-групп.

Наблюдаемая проблема

Время цикла обычно 3–4 мс, зарегистрированный максимум — 6 мс. При входном потоке выбранных сообщений CAN0 около 430 кадров/с диаграмма получает около 312 кадров/с. Регулярно возникает переполнение CAN0. На CAN1 переполнения не наблюдаем; регистры ошибок обоих интерфейсов в выборках монитора равны нулю.

Предполагаем, что диаграмма получает не более одного сообщения каждого интерфейса за цикл. Если это так, увеличение очереди не устранит постоянное превышение скорости поступления над скоростью обработки.

Для восстановления после переполнения пробовали временно настраивать все 16 фильтров CAN0 на один редкий ID, вычитывать старую очередь до опустошения, затем возвращать исходные фильтры. Интерфейс при этом не отключаем.

Однако монитор продолжает показывать приём остальных ID на протяжении десятков секунд. Ожидаемое ограничение потока не наблюдается; причина пока не установлена.

Вопросы
1. Верно ли ограничение «одно принятое сообщение на интерфейс за цикл диаграммы»? Можно ли вычитывать несколько сообщений за цикл или обслуживать приём независимо от полного прохода диаграммы?
2. Какова глубина RX-очереди? Что именно происходит при переполнении: какие сообщения теряются, когда сбрасывается Overflow? Есть ли штатная очистка очереди без отключения передачи?
3. Применяются ли изменения аппаратных фильтров при работающем CAN? Требуется ли переинициализация драйвера, и что происходит с накопленными сообщениями?
4. Можно ли средствами драйвера хранить последнее сообщение отдельно по каждому ID, заменяя старое новым вместо накопления FIFO? Либо ограничивать частоту поступления выбранных ID в диаграмму?
5. Какую архитектуру рекомендуете для такой нагрузки: обычный приём, асинхронный шлюз, упрощённые правила шлюза или их сочетание?
6. Поддерживает ли драйвер автоматические счётчики и контрольные суммы исходящих кадров для разгрузки диаграммы?
7. Дадут ли CANNY 7.2 Gamma или Alfa существенный выигрыш относительно 7.3 Duo именно по скорости исполнения диаграммы и обслуживанию RX, а не только по числу буферов передачи?
8. Реалистична ли такая задача на 7.3 Duo с запасом производительности?