Оптимальный размер для кольцевого буфера с одним производителем и одним потребителем - PullRequest
0 голосов
/ 25 января 2019

У меня есть один производитель, проблема с одним потребителем, которую (я считаю) можно решить с помощью кольцевого / кольцевого буфера.

У меня есть микроконтроллер, работающий в ОСРВ с ISR (подпрограмма обработки прерываний), обрабатывающая прерывания UART (последовательный порт). Когда UART вызывает прерывание, ISR помещает полученные символы в кольцевой буфер. В другой задаче RTOS (называемой package_handler) я читаю из этого кольцевого буфера и запускаю конечный автомат для декодирования пакета. Допустимый пакет имеет 64 байта, включая все байты кадрирования.

UART работает в 115200, и пакет приходит каждые 10 мс. Package_handler запускается каждые 10 мс. Однако этот обработчик может иногда задерживаться планировщиком из-за выполнения другой задачи с более высоким приоритетом.

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

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

Ответы [ 4 ]

0 голосов
/ 24 марта 2019

Это просто вопрос определения максимально возможной задержки - суммы времен выполнения всех задач с более высоким приоритетом, которые могут выполняться - и деления этого на интервал прибытия пакета.

Это может быть непросто, но можно упростить, сделав только самые детерминированные задачи более приоритетными и переместив менее детерминированные и более длительные задачи в более низкие приоритеты в соответствии с монотонными принципами скорости Задачи, которые часто выполняются в течение короткого времени, но время от времени более длительный запуск - это кандидаты для разделения на две задачи (и дополнительные очереди), чтобы перенести более длительное выполнение в более низкий приоритет.

0 голосов
/ 25 января 2019

Вы никогда не будете в безопасности, поскольку имеете дело со случайным процессом (согласно вашему объяснению). Отвечая на ваш вопрос: вам понадобится бесконечный буфер на тот случай, если задача потребителя находится в состоянии готовности в течение бесконечных секунд. Итак, вам придется что-то изменить в вашем первоначальном подходе:

  • Увеличить приоритет потребителя, чтобы обеспечить выполнение 10 мс (самый маленький буферный подход, но он может быть невозможен).
  • Постарайтесь получить лучшую характеристику вашей модели, чтобы предсказать максимальный промежуток времени, в течение которого потребительская задача не будет выполнена (сделайте вашу систему максимально предсказуемой).
  • Потерять пакеты со случайным размером буфера (это может быть небезопасно)
0 голосов
/ 11 февраля 2019

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

Некоторые модели массового обслуживания могут использоваться для теоретического анализа рассматриваемой проблемы и определения подходящего размера кольцевого буфера.

Более прагматичный подход - начать с большого буфера, затем определить максимальный размер используемого буфера в реальном тестовом примере (этот процесс называется водяными знаками) и использовать этот рисунок в конечном коде.

0 голосов
/ 25 января 2019

Я бы рассчитал так:

64 байта получено, просто знаю
64 байта еще в кольцевом буфере
+ 100% к экономии
===================
256-байтовый буфер

Но это всего лишь предположение. Вы должны были провести тест в худшем случае с вашим буфером, а затем потратить + 100% на сохранение.

...