Добрый день.

Впервые приступаю к использованию RTOS и сразу же возник вопрос системного плана - как разбить свою задачу на процессы?
Примеры к любой оси очень уж простые и не дают полного понимания подхода.
У меня же устройство будет довольно сложным:
1. Работа с Ethernet.
2. Работа с 3-мя UART.
3. Работа с USB, как Host, так и Device, т.е. OTG
4. Обслуживание TFT-индикатора с тачскрином
5. Обслуживание светодиодов
6. Обработка аналоговых входов
7. Обработка дискретных входов
8. Ну и до кучи внешняя по отношению к МК FLASH-память

В общем все, что есть в Luminary LM3S9B90

И как весь этот зоопарк организовать - даже не представляю

Может кто поможет советом. Буду очень признателен.

А вообще к "осям" есть не только "примеры", но и документация. Читать надо. Ну и думать потом СВОЕЙ головой. После чего можно отдельные нюансы обсуждать.

У меня подход простой - каждому процессору свой процесс. И по одной плате добавлять в общую кучу. Это не экономично, но зато реально.
З.Ы Невольно вспоминается одна песня металлики...

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

Увы - сложные задачи одному человеку не под силу - тут нужен коллектив.Предпочитаю разбить одну сложную задачу на много простых и потихоньку.... А там может кто присоединится и доведут до ума.

Вовсе не обязательно.


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

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

Ну по-крайней мере три первых пункта я бы вынес в отдельный процессор - не вяжутся они с RTOS. А всё остальное можно в ось. А 8-ой пункт это наверно USB флешка?

Обосновать можете?

При всём уважении к Вам, я не собирался обсуждать нюансы, по крайней мере, не в этом посте . Я только хотел услышать о методике решения подобных задач.
А по поводу документации... Возьмем руководство пользователя к типичной ОС:
- управление задачами, временем, памятью
- синхронизция процессов и межпроцессный обмен
- руководство по системному API

То есть описывается КАК это работает, но нет ни слова по интересующему меня вопросу.


Нет, имелось в виду пара-тройка микросхем FLASH на SPI


PS. Может перенести эту тему в раздел "для начинающих"? Не думаю, что я единственный у кого возникает подобный вопрос.
PPS. Кстати, мне так и не удалось найти полного руководство по любимой всеми uc/OS-II

Так возьмите НЕ типичное. Хотя и типичное, например, на FreeRTOS содержит раздел "Design Tips" не говоря уже uC/OS к которой в довесок идут горы мукалатуры..

Да,да ознакомьтесь с форумом.

Методика стара, как Мир -задачи, минимум на 50% решатся собственной головой, после чего задаются вопросы.



Вы же понимаете, что не сможет ничего обосновать.. Хотя уровень "ответа" полностью соответствует уровню "вопроса"
- Петька - прибор!
- 50
- Что 50?
- А что прибор?

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

И опять же, по поводу ucOS - во всех архивах, которые мне удалось нарыть на просторах Интернет, из документации были только файлы, описывающие характерные отличия конкретного порта, а полноценного User Guide я так и не увидел. Не сочтите за нахальство, но не могли бы Вы дать ссылку на такой документ?

Могу предложить почитать книгу "uCOS, The Real-Time Kernel.pdf"

Спасибо, читаю. Я просто думал, что есть еще что-нибудь

Я во FreeRTOS делал отдельно поток для Ethernet (uIP), для UART, и один поток для PIO - светодиоды, зуммер. При проектировании я считаю надо вначале на бумаге выделить модули программы, если между ними возможно синхронное взаимодействие - то в один процесс, если проще асинхронное - тогда в разные.

Продолжаю бороться с RTOS
Очередная задача - реализация часов/календаря. Разработчик uCOS в своей книге "Building System Blocks" предлагает 2 подхода:
1. Задержка процесса на 1 с - плохо в нагруженной системе
2. Внедрение счетчика+семафора в прерывание системного таймера.

Мне не хочется модифицировать ядро системы, как того требует 2-й вариант. Поэтому возникли еще две идеи:
3. Использование программного таймера + семафор в callback функции.
4. Использование отдельного аппаратного таймера и прерывания от него.
Насколько я понимаю, вариант 3 практически не отличается от варианта 2, ведь программные таймеры тоже обрабатываются
в системном прерывании. Но тогда непонятно, почему этот вариант не представлен автором. Может я чего-то упускаю?

А вообще, хотелось бы разработать универсальный модуль, способный работать как без оси, так и с оной (наподобие того, как это сделано в стеке lwIP).

Неужели за целую секунду не найдется времени увеличить несколько счетчиков?
Если рассматривать FreeRTOS, то при использовании vTaskDelayUntil проблем нет.

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