[dch 0]

оптимальным вариантом

А чем не устраивает eCos?

Большой круг пользователей которые поддерживают саму ОС - вроде самый главный критерий оптимальности. Линковка своих приложений есть, без предоставления кода последних . И GPL на саму операционку.

[slabnoff 0]

А чем не устраивает eCos?

Да в общем-то устраивает. Правда несколько громоздка она для простых применений. В добавок я gcc не люблю, привык к IAR. Хотя вообще говоря на досуге потихоньку с eCos разбираюсь.

[slabnoff 0]

В продолжение...

Разбирался тут с родными семафорами в FreeRTOS. Выяснилась неприятная вещь: ежели шлю сигнал через семафор от прерывания, а в некторой задаче жду его время N тиков операционки, например так:

 

ISR:
....
xTaskWoken=xSemaphoreGiveFromISR(CalcSem,xTaskWoken);
....

Task:
....
if(xSemaphoreTake(CalcSem,N) == pdTRUE)
{
....
}          
....

то семафор реально захватывается задачей через N тиков операционки, а не сразу после того, как он был послан... В общем по-любому похоже надо свои семафоры заканчивать. Если кому интересно - думаю через месяц закончу, попробую заслать автору FreeRTOS. Если кто хочет потестировать - милости просим.

[sergik_vrn 0]

В продолжение...

Разбирался тут с родными семафорами в FreeRTOS. Выяснилась неприятная вещь: ежели шлю сигнал через семафор от прерывания, а в некторой задаче жду его время N тиков операционки, например так:

 

ISR:
....
xTaskWoken=xSemaphoreGiveFromISR(CalcSem,xTaskWoken);
....

Task:
....
if(xSemaphoreTake(CalcSem,N) == pdTRUE)
{
....
}          
....

то семафор реально захватывается задачей через N тиков операционки, а не сразу после того, как он был послан... В общем по-любому похоже надо свои семафоры заканчивать. Если кому интересно - думаю через месяц закончу, попробую заслать автору FreeRTOS. Если кто хочет потестировать - милости просим.

<{POST_SNAPBACK}>

 

гм. а сам автор это как-нить комментирует? это же глюк, получается?

[slabnoff 0]

Руки не дошли пока ему написать, постараюсь в ближайшее время... Да и надо бы детальнее проверить...

[zltigo 2]

В общем по-любому похоже надо свои семафоры заканчивать. Если кому интересно - думаю через месяц закончу, попробую заслать автору FreeRTOS. Если кто хочет потестировать - милости просим.

Просьба держать в курсе!

Я похоже тоже избрал FreeRTOS, как отправную точку для создания

более ориентированной на себя системы. Вполне прозрачна на первый взгляд в своей начальной

простоте, хорошо читаемые исходники. До сих пор (скоро 15 лет) всегда делал более-менее свое ( в приглядку естественно ), а тут резко пошел на ARM...... Слишком бысто я в эту работу не вольюсь -

новый процессор, иннструментарий (правда готовый :-) ) - где-то порядка месяца на разборки :-(

в "рабочем порядке". Пока за вчера собрал (IAR) слегка помxав шашкой порт на LPC2124 - живет и общается с внешним миром.

[zltigo 2]

Основной смысл кооперативной ОС - экономия ресурсов (когда их нет или когда их мало и не хватает для реализации целевой функциональности). Если ресурсов хватает, вытесняющая ОС - самое оно. Какой смысл иметь их обе сразу лично мне не понятно. Объясните, пожалуйста?

В ресурсах и смысл :-(. Например, телефонная станция - сотни-десятки тысяч абонентов.

Процессы обслуживания одного абонента более, чем просты, не требуют много ресурсов но их МНОГО.

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

[dxp 65]

Основной смысл кооперативной ОС - экономия ресурсов (когда их нет или когда их мало и не хватает для реализации целевой функциональности). Если ресурсов хватает, вытесняющая ОС - самое оно. Какой смысл иметь их обе сразу лично мне не понятно. Объясните, пожалуйста?

В ресурсах и смысл :-(. Например, телефонная станция - сотни-десятки тысяч абонентов.

Процессы обслуживания одного абонента более, чем просты, не требуют много ресурсов но их МНОГО.

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

Это что ж, на каждого абонента отдельный процесс? Зачем? Вытесняющая ОС имеет главное преимущество - детерминированное время отклика на событие. Если все абоненты равнозначны по приоритету - то их и должен обслуживать один процесс. Если есть разные группы абонентов - например, есть группа VIP, которая должна быть обслужена вперед других, то ее обслуживание поместить в другой процесс с более высоким приоритетом. Только и всего.

 

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

[zltigo 2]

Это что ж, на каждого абонента отдельный процесс? Зачем?

Процессы ОЧЕНЬ простые, код вылизывается, затрат на переключения контекста практически нет.

Лет ...надцать назад была еще одна причина - 8085/Z80 прцессор с 8K очень дорогой ROM,

ну RAM было больше и дешевле - 256 процессов и заметная экономия кода.

 

Ну а о том, что можно и по другому - я и сам уже писал, да и делал, но уже на AM186CC.

Предстваляю все это себе очень хорошо. В принципе можно считать, что тот самый один процесс,

который их всех одинаковых обслуживает является сам по себе небольшим "кооперативчиком" для

которого и создастся своя "системка".

Пока на подсознательном уровне "хочу", но похоже, что мощность контроллеров растет быстрее,

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

[zltigo 2]

Наступил на проблему - незаметно съел heap, а у автора IDLE Task

создается из vTaskStartScheduler( ) последней! Ну и не хватило памяти под стек и не запустилась,

а за ней и шедулер не стартовал и полетело все далеко.

Три часа пляски - я уже думал отладчиком пользоваться придется :-).

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

В общем для профилактики дописал системный вызов xIdleTaskCreate( ) и поставил его

перед всеми, а в vTaskStartScheduler( ) для совместимости добавил контроль на запущенную

IDLE и создание ее в случае отсутствия. Хотя, наверное, и startup запихнуть можно.

[FreeCoderr 0]

Тож недавно начал юзать эту ось. Портировал на cx805 (ASIC телефона sgh-c100), работает. Были небольшие замороки с частью startup, исправить несложно. Для меня неудобно, что в ходе переключения контекста вызывается SWI (у меня свои виды на использование этого прерывания). А так, в целом нареканий пока нет.

[zltigo 2]

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

Такие большие виды, что 8/24 битного поля 'соmment' не хватает для того, чтобы пожертвовать

одно значение для переключения контекста :-) ? Я понимаю, что текущий "порт" автора под

ARM сделан левой ногой, дабы "был", но подправить с использованием 'comment' что мешает?

 

В "portmacro.h"

#define portYIELD() asm ( "SWI 0" );

 

нолик заменить на любое число которое не жалко....

 

В "startup.s79" что-то типа:

 

ldr r0, [r14, #-4] ; Получить тело SWI инструкции

bic r0, r0, #0xFF000000 ; Почистить поля 'condinion' и 'F'

 

добавить и ветвится по 'r0' как душа пожелает