По теме:
Подробно не смотрел, времени особо не было, да и АВР как-то неактуален пока.
Какие есть сервисы межпроцессного взаимодействия? (сообщения, очереди и т.д.)
При беглом осмотре не нашёл упоминания. (кроме эвентов)

ОС была намеренно минимизирована. Чтобы уместилась даже на малые AVR типа 2313. Поэтому средства межпроцессорного взаимодействия такие, как сообщения, очереди, mailbox отсутствуют. В документации есть упоминание о том, как используя event организовать все это самостоятельно.

Асинхронно, синхронно. Асинхронно формируются(могут формироваться) event(прерывание). Синхронно передается управление. Это кооперативная операционная система - это + код вносят некоторые возможности RTOS.

Приоритеты. Кооперативная операционная система это сама ОС + прикладной код. Только тогда она может в какой мере заменить preemtive систему. Мой подход к проектированию таков - предположим есть 4 задачи. Есть период времени T приблизительно определенный суммой приоритетов процессов. Одна (первая) главная, вторая за период T может сгенирить 3 события, третья 2, четвертая 1. Назначаем приоритеты 1-ой 200, 2-ой 150, 3-ей 100, 4-ой 50. За время T каждой равномерно будет передано управление исходя из приоритетов. Приведенная схема проектирования упрощена. Но даже так работает!

Сохранение и восстановление статусного регистра. Сохраняем состояние процесса. Даже синхронно передавая управление, процесс может остаться в разных состояниях. При возврате анализируем статусный регистр. Иначе для сохранения состояния пришлось использовать статическую переменную. Экономия - не знаю? Но работает. Накладные расходы на это ничтожны. А возможность использования остается.

Сообщение отредактировал LVII - Nov 2 2009, 11:37

Да не нужен он, поскольку состояния описываются однозначно набором локальных переменных и счетчиком команд. Передача управления реализуется в точках, доступных на уровне сишного текста и прерывать выполнение сишного выражения никто не будет. А также глобально разрешать /запрещать прерывания и отдавать управление, не выходя из критической секции - такая свобода действий не нужна задачам.
Для preemptive -версии он только нужен - также, как и сохранять все регистры, РС и указатель стека.

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

Я прошу конкретный пример, а не "есть возможность".

А теперь смотрим код:
Перед вызовом dispatch_task(switch_buf cpu_state) надо вычислить адрес начала массива cpu_state типа switch_buf.
для чего в регистры будет загружено значение переменной current_task, умножено на sizeof(struct TCB) и сложено с адресом начала массива tasks и смещением offsetof(struct TCB, cpu_state).
Таким образом, при входе в dispatch_task в регистре SREG всегда будут флаги, оставшиеся от этих вычислений, а не мифическое "состояние процесса". Я думал, что после критического замечания "по сути", которое Вы просили, Вы сможете сами критически глянуть на свой код.
Ещё понятно было бы, если бы dispatch_task() не принимал аргументов (какая разница - всё равно макрос берёт их из тех же глобальных параметров, кстати, это тоже несколько уменьшило бы код), тогда действительно в SREG был бы результат последних операций процесса перед вызовом диспетчера. Ну и как это применать? Так, чтоли?


Байт на задачу, при 4 задачах - больше 3% ОЗУ упомянутой tiny2313

Я бы хотел ось, которая поддерживает все. Опциями конечно, а не все сразу. Например, последовательные порты, работа с файловой системой, с ммс, с флешью, с озу, с индикаторами и т.д. А в урезанных осях против "своего цикла" я смысла не вижу.

Тогда уж и волшебное слово впридачу к нему: mbandala

Вы были полностью правы. Непростительная небрежность с моей стороны. Как при написании, так и при тестировании.
Также правы в том, что это никому не надо. Пообщался с народом использующим mRTOS и уже наклепавших кучу проектов, проектиков. Так они даже и не знали о сохранение и восстановлении SREG - потому как оно им совершенно не нужно! И как использовать тоже не понимают. У них и так все хорошо работало и работает.
Когда я писал этот код, то как приверженец автоматного стиля программирования для микроконтроллерных систем считал, что сохранение состояния процесса в момент передачи управления - это хороший стиль. Но в данном случае - действительно ни к чему.
Переписал, протестировал. Экономия небольшая - откомпилировал последний проект на ATMega162.
Старая версия - 2997 words 36.6% Flash
Новая версия - 2989 words 36.5% Flash
Но убран лишний код.

Перепаковал и залил на сайт. Доступно по прежней ссылке.

Благодарю за конструктивную критику!

Спасибо, очень полезная книга

Сообщение отредактировал RA3WUM - Nov 3 2009, 10:59

А вы могли-бы выложить её в этом топике?
С рапиды доступно скачивание только преиум-пользователям по этому скачать не получилось.

Вопрос снят - с работы удалось зайти и скачать

To plus спасибо за волшебное слово

Сообщение отредактировал mempfis_ - Nov 3 2009, 11:57

ОС создает скелетон кода. Далее подключайте необходимые драйвера. Для последовательных портов, параллельной и последовательной FLASH, параллельной и последовательной ОЗУ, индикаторами, разнообразными дачиками написал сам. Драйвера для контроллера Ethernet предоставляются фирмой-производителем. На просторах Интернета огромное количество разнообразных открытых библиотек, особенно под компилятор WinAVR, просто портируемых на CodeVision. Если очень упрощенно, то далее так - для отдельного устройства(драйвера), отдельный процесс(ы) с приоритетом(и), установленным по степени важности событий происходящим на этом устройстве.

"Embedded Multitasking with small microcontrollers" Keith E. Curtis. - http://www.onlinedisk.ru/file/257940/

Сообщение отредактировал LVII - Nov 3 2009, 11:44

А то я не знаю. Но вот собрать все вместе, оттестировать и опубликовать (бесплатно!) желающих не видно - место вакантно, занимайте. И в минусе не останетесь - найдутся желающие на заплатить за бесплатное, но адаптированное специально под них.

Давайте не будем забывать о качестве хлама кода, болтающегося по просторам инета. Место Сизифа всегда вакантно

Nut/OS (ethernut), если если говорить о кооперативных ОС. Но она "тяжёлая" в том смысле, что в мелкий кристалл всё равно не полезет.

Так и не надо в мелкий. Надо мало секса с этими камнями и осями.


Так и я о том же. Достойно будет собрать под одним, а не говорить, что де мол поищи оно в инете.

Ну так вещь вроде как проверенная временем. Даже платы продаются в терре и у нас в имраде, но схемы открыты все и ось открыта.
Я давно смотрел, по железу там только два варианта, кажется, было (ethernut1 на мега103 с последующим апгрейдом на мегу128 и ethernut2 на атмеловском АРМ at91r4008, если не путаю), сейчас больше.
Управление памятью, система драйверов к железу, разные дополнительные платки, включая mp3-шную на VS1001
Всё подробно описано.
www.ethernut.de

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