[bmf 0]

Хотел попробовать, стал разбираться и не нашел семафоров.

Может я чего не понял?

Есть TEventFlag - но это немножко другое (после "сигнала" все процессы,

ожидающие указанное событие, будут переведены в состояние готовых к выполнению)

Более похож TMutex - но тоже вроде не то.

Кто работал? В чем фишка?

[ig_z 0]

Хотел попробовать, стал разбираться и не нашел семафоров.

Может я чего не понял?

<{POST_SNAPBACK}>

 

Так ведь автор вполне ясно сказал, что семафоры в любом виде совершенно бесполезны в той области, для которой scmRTOS предназначена.

Это его (автора) имхо и я согласен с его доводами (в смысле, что пока не попадались ситуации где без них никак)

[bmf 0]

Так ведь автор вполне ясно сказал, что семафоры в любом виде совершенно бесполезны

Блин. Нет такого в доке.

И не может быть.

Наоборот из ядра и семафоров можно сделать все остальное. Это базовые составляющие минимального размера. В принципе и мне нужно только ядро и семофор, кстати часто вызываемый из прерывания (и в других ОС специально делается легковесный код семафора для вызова из прерывания, чтобы не нагружать стек, здесь такого нет).

 

Надо дудет разбираться в исходниках: может вместо семафора он подрузамевает TEventFlag (хотя по устоявшейся терминологиии это должны быть разные вещи)

 

Вообще не умаляя достоинств автора, чувствуется некоторая безапеляционность в сужденияж

Как то:

Второй «кривой» момент AVR – это его убогий указатель

стека....

.....

1 Интересно, куда они смотрели, когда два норвега разрабатывали сам МК, ведь по информации от про-

изводителя AVR разрабатывался как процессор, ориентированный на применение его с языками высоко-

го уровня и в тесном сотрудничестве с фирмой-разработчиком компиляторов ЯВУ для МК???

Типа: Ну конечно они дураки, а мы умней

[ig_z 0]

Так ведь автор вполне ясно сказал, что семафоры в любом виде совершенно бесполезны

Блин. Нет такого в доке.

И не может быть.

 

Вообще не умаляя достоинств автора, чувствуется некоторая безапеляционность в сужденияж

Как то:

Второй «кривой» момент AVR – это его убогий указатель

стека....

.....

1 Интересно, куда они смотрели, когда два норвега разрабатывали сам МК, ведь по информации от про-

изводителя AVR разрабатывался как процессор, ориентированный на применение его с языками высоко-

го уровня и в тесном сотрудничестве с фирмой-разработчиком компиляторов ЯВУ для МК???

Типа: Ну конечно они дураки, а мы умней

<{POST_SNAPBACK}>

 

=============================================

Как видно из приведенного выше списка, отсутствуют счет-

ные семафоры. Причина этого в том, что при всем желании не

удалось увидеть острой необходимости в них. Ресурсы, которые

нуждаются в контроле с помощью счетных семафоров, находятся

в остром дефиците в однокристальных МК, это прежде всего —

оперативная память. А ситуации, где все же необходимо контро-

лировать доступное количество, обходятся с помощью объектов

типа TChannel и MemoryManager, внутри которых в том или ином

виде уже реализован соответствующий механизм.

================ Версия 1.01 25 =================

 

Оказывается может :)

И я бы сказал что это вы злоупотребляете безапеляционностью. Можете сделать лучше - сделайте

 

А насчет АВР - это еще мягко сказано. Неуклюжая архитектура и все тут. Сравните порт для МСП и для АВР и все вопросы отпадут.

Насколько мне известно автор портировал ОС на АВР не из-за "красоты изящества и оптимальности" архитектуры последнего, а по просьбе своих коллег.

 

Что касается личности автора, я имел удовольствие обсуждать некоторые общие темы и могу сказать, что это вполне приятный человек и очень опытный разработчик. Не в пример многим звездам 3.14здабольства с телесистем, кичащимся своими "тяжеловесными" никами.

[bmf 0]

В доке к версии 2.0 такого обзаца нет.

Думаю что как раз реализация семафора будет по коду гораздо меньше и эффективней чем TChannel и MemoryManager, а не наоборот, делать элементарный семафор из них. Ведь мы работаем при недостатке памяти и ресурсов.

 

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

А убогость архитектуры с одной стороны, может выливаться преимуществом в другой. Это вопрос сложный. И с одной колокольни об этом судить не стоит, надо учитывать доводы всех сторон. Но это совсем другая история.

 

В общем, теперь ясно что имеем. Thanks.

[dxp 65]

Так ведь автор вполне ясно сказал, что семафоры в любом виде совершенно бесполезны

Блин. Нет такого в доке.

Есть. :)

 

И не может быть.

Наоборот из ядра и семафоров можно сделать все остальное. Это базовые составляющие минимального размера. В принципе и мне нужно только ядро и семофор, кстати часто вызываемый из прерывания (и в других ОС специально делается легковесный код семафора для вызова из прерывания, чтобы не нагружать стек, здесь такого нет).

Надо бы уточнить, что Вы понимаете под термином "семафар". Мутекс - семфор. И флаг события тоже семафор. Нет счетных семафоров? Да, нету. А они нужны? Приведите реальный пример на мелкой однокристаллке, где они нужны.

 

Вообще не умаляя достоинств автора, чувствуется некоторая безапеляционность в сужденияж

Как то:

Второй «кривой» момент AVR – это его убогий указатель

стека....

.....

1 Интересно, куда они смотрели, когда два норвега разрабатывали сам МК, ведь по информации от про-

изводителя AVR разрабатывался как процессор, ориентированный на применение его с языками высоко-

го уровня и в тесном сотрудничестве с фирмой-разработчиком компиляторов ЯВУ для МК???

Типа: Ну конечно они дураки, а мы умней

<{POST_SNAPBACK}>

А что, не так, что-ли? AVR (ядро) по некоторым данным разработатли два студента из Норвегии. И задумка у них неплохая была, но вот реализация подкачала. Вот этот самый указатель стека - совершенно убогий! Ведь именно из-за этого IAR городит отдельный стек для данных. Два стека - это криво, преимуществ никаких, одни недостатки. А ведь будь указатель стека нормальный, то и не было бы никакой необходимости в отдельном стеке данных. Для стека данных нужно, чтобы указатель стека поддерживал расширенные режимы адресации (со смещениями) и адресную арифметику. Т.е. по-нормальному указатель стека должен быть регистровой парой. А в таком виде, как он есть - отстой.

 

Второй момент. У AVR слишком дофига регистров при том, что работа с ними неортогональна (младшая половина не работает, например, с константами). Гораздо лучше было бы если бы было регистров вдвое меньше (16), но все они были одинаковы и все они могли образовывать регистровые пары при адресации (т.е. быть указателями) и при адресной арифметике. Анализ кода показал, что в AVR заметный оверхед на пересылках адресов между регистрами, а нормальных поинтеров только два (из которых один отдан по указатель стека - Y). Реально в программе доступен только один Z, а X - недоделанный, не поддерживает адресацию со смещением. Вся эта кривизна очень распрекрасно видна при сравнении, например, с MSP430.

 

Третий момент - работа с памятью. Она медленная. Для Load/Store архитектуры работа с памятью должна быть максимально быстрой - ведь это ключевой момент, определящий быстродействие. Два такта на одно обращение - никуда не годится. Элементарный инкремент переменной в памяти занимает 5 тактов. из которых 4 - это накладные расходы на пересылку. Никуда не годится!

 

Это только основные моменты, но они, имхо, определяющие. Недоделанный он, AVR этот.

[dxp 65]

В доке к версии 2.0 такого обзаца нет.

Все есть. Дока версии 2.0, ревизия 22, страница 25.

 

Думаю что как раз реализация семафора будет по коду гораздо меньше и эффективней чем  TChannel и MemoryManager, а не наоборот, делать элементарный семафор из них. Ведь мы работаем при недостатке памяти и ресурсов.

Естественно, что семафор легче канала. Но у него и функциональность другая. Их нельзя сравнивать. Если реализовать ту же функциональность - т.е. кольцевой буфер (фифо) на основе семафора, то и получится где-то так же, если не хуже.

 

В версии 2, кстати, лучше уже не юзать TChannel (а MemoryManager'а там вообще нет - не нужен он стал при наличие подержки шаблонов). Есть шаблон channel, на нем все прекрасно реализуется и пользоваться им проще и безопаснее. Единственно, что надо помнить - это то, что на шаблонах очень легко и просто нагенерить горы кода. Поэтому тут надо прявлять осмотрительность (в частности, не городить каналы на объекты типов со значительным размером - ведь проталкиваение через канал производится путем копирования. Тут накладные расходы на копирование могут быть весьма неслабыми).

[bmf 0]

Надо бы уточнить, что Вы понимаете под термином "семафар". Мутекс - семфор. И флаг события тоже семафор. Нет счетных семафоров? Да, нету. А они нужны? Приведите реальный пример на мелкой однокристаллке, где они нужны.

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

 

По поводу безапелляционности высказываний автора, меня больше задело не содержание(хотя здесь можно поспорить), а форма и категоричность высказываний: "убогий", "два норвега" "о чем думали" - для официальной документации в русском языке есть более мягкие выражения, а то создается впечатление, что все кто юзает ATMEL тоже убогие и недалекие.

 

По архитектуре: - я в основною юзаю DSP - там тоже применяют два стека (реально даже больше - еще для аппаратных циклов)- только это преимущество - быстрее реакция на прерывание

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

Так что все дело с какой стороны смотреть.

И все вышесказонное естественно ИМХНО.

[dxp 65]

Надо бы уточнить, что Вы понимаете под термином "семафар". Мутекс - семфор. И флаг события тоже семафор. Нет счетных семафоров? Да, нету. А они нужны? Приведите реальный пример на мелкой однокристаллке, где они нужны.

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

Флаг - да. А если события ожидают несколько процессов, то как их все проинформировать? Заводить для каждого объект и сигналить всю пачку? Некузяво. Но если вас такое устраивает, то и заводите просто для каждого процесса свой TEventFlag, получите ровно то, что хотите. Флаг событий не заставляет использовать его одного.

 

У меня, кстати, за все время работы ни разу не возникло необходимости (ситуации) в той функциональности, за которую Вы ратуете - чтобы событие обрабатывал только один процесс. Ведь тут пролучается непредсказуемость: если события ждут несколько процессов, какой из них получит управление?

 

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

 

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

 

Каких сервисов Вам не хватает?

 

По поводу безапелляционности высказываний автора, меня больше задело не содержание(хотя здесь можно поспорить),

У Вас есть дельные возражения по существу сказанного в моем предыдущем посте (об указателе стека, регистрах...)? Изложите, интересно узнать.

 

а форма и категоричность высказываний: "убогий", "два норвега" "о чем думали" - для официальной документации в русском языке есть более мягкие выражения,

Ну вообще-то, это не официальный документ, а частное описалово. Стиль там вполне свободный и даже анекдоты кое-где в качестве эпиграфов присутствуют. Т.ч. все вполне в "духе". :)

 

а то создается впечатление, что все кто юзает ATMEL тоже убогие и недалекие.

А вот это Вы зря - ничего подобного там нет и не просматривается. Есть только то, что сказано. И сказано по делу: в AVR указатель стека кривой! Это факт! Указатель стека - это один из ключевых компонентов процессора, "заточенного" под использование ЯВУ Си - об этом (особенно первое время) Атмел свистел на всех углах, заявляя, что, дескать, соорудили офигительно эффективный для С процессор, не в последней степени благодаря тесному сотрудничеству со специалистами по компиляторам фирмы IAR Systems. Как же так?!! Они его (процессор) специально делали эффективным для С, а указатель стека - ключевой компонент для эффктивной косвенной адресации, которую интенсивно используют С-компиляторы, - сделали убогим (именно убогим, если выражаться цензурно :)). Что-то тут не складывается.

 

По архитектуре: - я в основною юзаю DSP - там тоже применяют два стека (реально даже больше - еще для аппаратных циклов)- только это преимущество - быстрее реакция на прерывание

Извините, у DSP стек возвратов частенько аппаратный. Либо имеет отдельную память со своими шинами для этого. Чтобы параллельности достичь. А на AVR два стека тут совершенно ничего не дают - шина-то одна, все равно адрес возврата в память последовательно складыватся/извлекается - из-за чего и время реакции на прерывание 4 такта. Никакой параллельности нет. Недодуманный он, недоделанный.

 

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

Так что все дело с какой стороны смотреть.

<{POST_SNAPBACK}>

А с какой не смотри - вон у ТМСов с черными финами тактовые не в пример выше, а в память за такт лазят. Да еще и два раза (параллельно). Какая проблема за такт обратится к памяти? Частоты, можно сказать, детские. И ограничиваются они не логикой, а флешью. Вон FPSLIC из ОЗУ весь работает, так там он с самого начала, afair, за 30 МГц имел частоты. Не проблема. Думается, что и этот момент просто недодуманный, недоделанный. Как и перебор с регистрами и их функциональность.

[bmf 0]

Спасибо за идеи.

В принципе если есть исходники, то реализация семафора по аналогии с флагом и мютекс вроде не сложна. У меня вопрос только почему этого нет в базовом наборе? В моем коде и то что я видел как раз 99% занимают обычные и счетные семафоры. Например возмите любой TCP порт для RTOS, как пример функционального применения мзаимодействия между процессами. Заменять где возможно это на мютекс и на использование несколько флагов - извращение.

Растет память, мютекс вообще не имееет состоятия "сигнал" и таймаутов. Флаг уже не используешь в теле функции, которую могут вызывать несколько процессов.

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

 

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

Свое ИМХНО я сказал, еще раз спасибо за уделенное время, успехов.

[dxp 65]

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

<{POST_SNAPBACK}>

С++ в данном случае на самом деле дает не столько "красивость" сколько простоту использования. Есть объект, его потроха пользователя не интересуют. Пользователь работает через интерфейс. Интерфейс очень простой. Я знаю несколько человек, которые вообще С++ почти не знают, только С, но они вполне успешно и безо всяких трудностей используют данную ОС. Говорят, что пользоватся очень просто и комфортно, с чем согласен - это и есть главная цель использования ++ в данном случае.

[bmf 0]

Не знаю, впринципе всего десяток функций, там и собственно скрывать нечего.

А C++ можно натянуть на любую реализацию, как например ADSP VDK Kernel -хочеш юзай ассемблер, хочешь С или классы C++, а под низом ассемблерный код без потери эффективности. Это я в тему изначальной красивости (но с реальной потерей производительности и ресурсов). Всетаки ниша этой ОС слабые микроконтроллеры, ниже работают кооперативные OC, а ваше уже можно использовать и посолидней типа uCos. Прослойка очень тонка. У меня например использование для ATMEGА8.

[dxp 65]

Не знаю, впринципе всего десяток функций, там и собственно скрывать нечего.

...

Всетаки ниша этой ОС слабые микроконтроллеры, ниже работают кооперативные OC, а ваше уже можно использовать и посолидней типа uCos. Прослойка очень тонка. У меня например  использование для ATMEGА8.

<{POST_SNAPBACK}>

Десяток - не десяток, а реально чем проще использование, тем лучше. Сравните, что проще, наглядее и удобнее - создать флаг в этой ОС или семафор в uCOS. Там для этого вызывается отдельная функция с кучей параметров - попробуй еще ошибись, проверки все, afair, на рантайме (а кто их на рантайме чекает?). И pend там тоже тяжелее, замороченнее - надо адрес руками передавать. А тут не надо - this компилятор автоматом мечет. Вот и преимущество. Мелочь, а удобно.

 

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

 

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

[bmf 0]

Ну например, для тойже uCos - реакция на прерывание - только установка семафора из макроса(не из функции!, с целью уменьшения загрузки) и вызов IntExit(). А здесь сколько пройдет времени для вызова системной функции, полная перезагрузка стека, потом C++ хрен знает что наворочает, потом восстановление стека. Раз в 10 набежит.

Опятьже в uCos полный базисный набор функций для взаимодействия, и вообще то набор этих функций берется не от балды а в соответствии с индустриальнымы стандартом. Чем он шире, тем естесвенно и более тежеловеснее будет OC, но пользователь все их может не использовать.

Почитайте например спецификацию uTRON, это то что японцы требуют для ОС ембеддед систем (например для использования обычном автомобиле), даже uCos не потянет.

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

А чтоб объективно полность сравнить, набо провести тест, и замерить реакцию на прерывание, время переключения задач, занимаемая память и др, возможности API.

[bmf 0]

И еще, посмотрите как в uCos ищется самая приоритетная задача, и как в smcRTOS или freeRTOS и увидите что время поска при любом переключении (через swithtask или при установке семафора) будет в 10 раз меньше.