Как лучше всего реализовать мою программу для оценочной платы Keil MCB1700?

Я хочу разработать программу для оценочной платы MCB1700. Клиентское программное обеспечение ПК считывает изображение с жесткого диска. Затем он отправляет изображение на оценочную плату MCB1700 через разъем (Ethernet). Сервер MCB1700 принимает изображения с ПК через Socket-соединение и отображает их на ЖК-дисплее.

Также сервер должен выполнять такие задачи:

  • Сохранить картинку на USB-накопитель;
  • Считывать картинку с USB-флешки и отправлять ее клиенту через разъем;
  • Отправлять и получать информацию через CAN
  • COM-логирование.
  • и т.п.

Подключение к сокету может быть реализовано с помощью библиотек CMSIS и RL-ARM.

Но, насколько я понял, в обоих случаях программное обеспечение должно прослушивать входящее TCP-соединение и обрабатывать сетевые события в бесконечном цикле - все примеры Keil основаны на таком принципе.

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

«безусловно, можно создавать программы реального времени без ОСРВ (выполняя одну или несколько задач в цикле)»

Я считаю, что лучше обрабатывать все события прерываниями.

Можно ли использовать соединение сокетов библиотек CMSIS и RL-ARM и организовать все мое программное обеспечение, обрабатывая прерывания? Мой сервер (на MCB1700) должен выполнять множество задач. Думаю, мне следует использовать RTOS RTX в своем программном обеспечении. Не правда ли? Лучше ли реализовать мое программное обеспечение без RTX?


person Lucky Man    schedule 07.01.2012    source источник


Ответы (1)


Простые системы реального времени часто работают в архитектуре «большого цикла», где некоторые критические по времени события обрабатываются прерываниями. Это неплохая архитектура, но она несколько негибкая, плохо масштабируется, и любое изменение может повлиять на синхронизацию или все части системы.

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

Вы можете разработать систему, в которой весь код вашего приложения выполняется в обработчиках прерываний, а сетевой стек представляет собой службы в бесконечном цикле в контексте потока, но с архитектурной точки зрения это, вероятно, намного хуже, чем архитектура «большого цикла», поскольку вы можете закончить с очень длинными обработчиками прерываний, при этом более высокоприоритетные обработчики не работают и влияют на реакцию в реальном времени более низкоприоритетных. В итоге вы получаете систему, которую трудно запланировать удовлетворительно. Более того, не все библиотечные подпрограммы подходят для выполнения в обработчике прерывания, так что это будет довольно ограничительным.

Возможно обслуживание сетевого стека в потоке с низким приоритетом в ОСРВ. Структура такой операции описана в документации в разделе: Использование RL- TCPnet с ядром RTX.. Это потребует от вас понимания и использования библиотеки ядра RL-RTX, но с учетом ваших оговорок по поводу кода «большого цикла» и описания задач, которые ваша система должна выполнять, похоже, что это то, что вы хотите делать в любом случае. Если вы решите использовать другую ОСРВ, тогда RL-TCPnet может работать аналогичным образом с любой ОСРВ.

person Clifford    schedule 07.01.2012
comment
Моя задача выглядит так: 1) Сервер (на MCB1700) читает пакет данных. 2) Если сервер не выполняет никакой команды, специальная функция анализирует этот пакет (например, массив символов char) и определяет, какую команду нужно выполнить. В другом случае программа читает пакеты в рамках определенной команды и определяет, что с ними делать. 3) Команда завершается. Вернитесь к (1). Другие задачи: события от CAN, ADC могут обрабатываться прерываниями (обработчики имеют несколько строк кода), сохранение изображения на USB-накопитель и отображение его на ЖК-дисплее происходит сразу после чтения пакета (так что это выглядит как одна задача. ). - person Lucky Man; 08.01.2012
comment
Одновременное выполнение двух заданий исключено. Как я понял в моем случае приемлема архитектура с большим циклом? Существуют ли другие типы архитектуры встроенного программного обеспечения? Является ли архитектура большого цикла наиболее подходящей в моем случае? - person Lucky Man; 08.01.2012
comment
@ Lucky Man: Нет, RTOS - это самая подходящая архитектура IMO. Вы сказали, что можете использовать библиотеку RL-ARM, так почему вы сейчас исключаете ее !? Вы немного сдвинули стойку ворот! Глядя на ваши требования, я бы предположил, что есть как минимум 4-5 задач. Стеки CAN и USB также потребуют регулярного обслуживания. Если у вас нет какого-либо многозадачного ядра, у вас должен быть какой-то бесконечный цикл, поскольку при завершении main () ваша система остановится. В ОСРВ задачи обычно представляют собой отдельные неопределенные циклы, запускаемые исполнителем. - person Clifford; 08.01.2012