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

Question

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

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

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

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

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

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

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

• http://www.keil.com/support/man/docs/rlarm/rlarm_ar_artxarm.htm Итак, как я понял, это нормальная практика - выполнять много задач в цикле?

  while (1) {task1 (); task2 ();... taskN (); }

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

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

Answer 1

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

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

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

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