[MrYuran 29]

По теме:

Подробно не смотрел, времени особо не было, да и АВР как-то неактуален пока.

Какие есть сервисы межпроцессного взаимодействия? (сообщения, очереди и т.д.)

При беглом осмотре не нашёл упоминания. (кроме эвентов)

[LVII 0]

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

 

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

 

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

 

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

Изменено 2 ноября, 2009 пользователем LVII

[_Pasha 0]

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

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

Для preemptive -версии он только нужен - также, как и сохранять все регистры, РС и указатель стека.

[ReAl 0]

Асинхронно, синхронно. Асинхронно формируются(могут формироваться) event(прерывание). Синхронно передается управление.

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

 

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

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

 

А теперь смотрим код:

// Макрос - контекст текущей задачи                  
#define CPU_STATE (tasks[current_task].cpu_state)
// Макрос - переключатель задач
#define DISPATCH dispatch_task(CPU_STATE);
...
// Номер текущей задачи
extern char current_task;
// Массив структур TCB
extern struct TCB tasks[MAXTASKS];

Перед вызовом dispatch_task(switch_buf cpu_state) надо вычислить адрес начала массива cpu_state типа switch_buf.

tasks[current_task].cpu_state

для чего в регистры будет загружено значение переменной current_task, умножено на sizeof(struct TCB) и сложено с адресом начала массива tasks и смещением offsetof(struct TCB, cpu_state).

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

Ещё понятно было бы, если бы dispatch_task() не принимал аргументов (какая разница - всё равно макрос берёт их из тех же глобальных параметров, кстати, это тоже несколько уменьшило бы код), тогда действительно в SREG был бы результат последних операций процесса перед вызовом диспетчера. Ну и как это применать? Так, чтоли?

    c = a + b;
    DISPATCH;
    if( SREG & (1<<SREG_Z) ) {
         // c присвоен 0 перед вызовом диспетчера
    }

 

Накладные расходы на это ничтожны

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

[VCucumber 0]

ОС была намеренно минимизирована

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

[plus 0]

попался линк на "Embedded Multitasking with small microcontrollers" Keith E. Curtis.

hчсp://rapidshare.com/files/123380312/Embedded_Multitasking_with_small_microcontrollers.rar

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

[LVII 0]

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

Ещё понятно было бы, если бы dispatch_task() не принимал аргументов (какая разница - всё равно макрос берёт их из тех же глобальных параметров, кстати, это тоже несколько уменьшило бы код), тогда действительно в SREG был бы результат последних операций процесса перед вызовом диспетчера. Ну и как это применать? Так, чтоли?

    c = a + b;
    DISPATCH;
    if( SREG & (1<<SREG_Z) ) {
         // c присвоен 0 перед вызовом диспетчера
    }

 

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

 

Вы были полностью правы. Непростительная небрежность с моей стороны. Как при написании, так и при тестировании.

Также правы в том, что это никому не надо. Пообщался с народом использующим mRTOS и уже наклепавших кучу проектов, проектиков. Так они даже и не знали о сохранение и восстановлении SREG - потому как оно им совершенно не нужно! И как использовать тоже не понимают. У них и так все хорошо работало и работает.

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

Переписал, протестировал. Экономия небольшая - откомпилировал последний проект на ATMega162.

Старая версия - 2997 words 36.6% Flash

Новая версия - 2989 words 36.5% Flash

Но убран лишний код.

 

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

 

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

[ra3wum 0]

Не буду разбираться кто где плагиатор. Вот попался линк на "Embedded Multitasking with small microcontrollers" Keith E. Curtis.

hчсp://rapidshare.com/files/123380312/Embedded_Multitasking_with_small_microcontrollers.rar

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

Изменено 3 ноября, 2009 пользователем RA3WUM

[mempfis_ 0]

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

А вы могли-бы выложить её в этом топике?

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

 

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

 

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

Изменено 3 ноября, 2009 пользователем mempfis_

[LVII 0]

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

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

 

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

Изменено 3 ноября, 2009 пользователем LVII

[VCucumber 0]

На просторах Интернета огромное количество разнообразных

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

[_Pasha 0]

место вакантно, занимайте.

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

[ReAl 0]

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

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

[VCucumber 0]

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

 

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

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

[ReAl 0]

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

Ну так вещь вроде как проверенная временем. Даже платы продаются в терре и у нас в имраде, но схемы открыты все и ось открыта.

Я давно смотрел, по железу там только два варианта, кажется, было (ethernut1 на мега103 с последующим апгрейдом на мегу128 и ethernut2 на атмеловском АРМ at91r4008, если не путаю), сейчас больше.

Управление памятью, система драйверов к железу, разные дополнительные платки, включая mp3-шную на VS1001

Всё подробно описано.

www.ethernut.de

 

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