Все хитрее. Есть две крайности. Первая, это Высшая Математика. У человека происходит отрыв от реальности, бесконечные токи, напряжения итд. Это не лечится. Это путь в Торсионные поля итд. Вариант номер два, это когда поверхностные знания теории, но понимание "на пальцах" что происходит когда транзистор отпускает реле. Нужно будет, человек и с математикой этого разберется (а куда он денется). Но когда он будет разбираться, он будет помнить и о том что и диод не идиален.

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

Если разбираться по учебникам из СССР, то не разберется. А когда человеку к примеру ну ОЧЕНЬ нужен фильтр, а в аналоге у него все хар-ки плывут, то разберется. По себе знаю.

Ядро Linux может и стоило написать самому. Один горячий финский парень так и сделал. А вот не стоило самому писать стек TCP/IP, который и привел к использованию LINUX. Но речь шла все-таки о RTOS, а ни TCP/IP, ни LINUX к real-time не относятся.



Обычно, на сам планировщик недели две у меня уходит. Я уже писал об этом.



Минут 30. Может 45...



В Алабаме не был. Даже никого оттуда не знаю и не в курсах, что там пишут. А в Ницце ресоч-центр TI находится.

Учебники по высшей математике из СССР ,особенно 40-50-60- х годов
написаны так,что лучше и не нужно.
Не учебники виноваты в этом случае.

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

Поверьте, разберется, я же разобрался хотя меня это очень мало интересовало в застенках ВТУЗа . Я почти неспособен (из-за какого то внутреннего протеста, что ли) усваивать знания практическое применение которых я не нахожу или не понимаю, но только я пойму для чего это надо, и это уже совсем другой я . Эдакий эгоизм в познании, если угодно...


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


Позволю с Вами немного не согласиться, хотя в принципе сразу я хотел одобрить Ваш тезис, но после некоторого раздумия... Теория и практика неразделимы в своей диалектической борьбе, это как освещенная и теневая сторона одного предмета - человеческой деятельности.
Вот вспомнил я некоторые предметы, такие как теория радиоцепей и сигналов, теория цепей, теория автоматического управления... Если бы не огромный радиолюбительский опыт и книга В.Т.Полякова "радиолюбителям о технике прямого преобразования" где я все прочел сначала упрощенно и уже сформировал круг задач, научился прикидывать спектры, оценивать сложности получения и детектирования тех или иных способов модуляции нифига бы я там не понял! С теорией цепей было гораздо грустнее, создалось такое впечатления чо препода здорово задели, мол, он не может ввести взрослого человека в заблуждение и он решил исправиться . Разобрался гораздо позже, почитав книжку Константина Гомоюнова "Транзисторные цепи". Судя по тексту, автор старой советской закалки, но зато все толково и понятно. Хоть в книге далеко не все вопросы освещены, но как раз это бы ее и убило бы, превратив в никому не нужный талмуд. Кстати это основная черта бездарности препода, когда человек думает что он все знает, и стремится все это втиснуть в 40 лекций. Получается полный гной, причем абсолютно бесполезный. Ибо сейчас включил комп в инет и нашел все что тебе надо, время когда в ВУЗ приезжал выходец из простой узбекской деревушки которого следовало "прогрузить" давно прошли и я вообще сомневаюсь, что в технической области сейчас реально рассказать все... надо скорее научит человека думать в эту сторону, интересоваться и творчески подходить к проблеме. А это даже не пытаются делать, ибо сами никогда так не делали... Да я еще эту ТАУ забыл упомянуть. Курс был не столь глубокий но я как вспомню эту декларацию незыблемых истин. Ужжжас. Однажды, сидя на лекции, я вдруг понял, что нам рассказывают о возможном возникновении генерации в цепи обратной связи, и это так близко к будущим будням радистов - самовозбуждение в АРУ - но ведь нет же, надо это рассказывать так, что бы если в ряды студентов вдруг затесался потенциальный враг - то не смог бы вынести военную тайну буржуям .
Так вот о чем это я. А о том, что все эти бесконечные токи и напряжения имеют место быть на практике (хотя бы в эскизном проектировании устройств на полевых транзисторах), мало того если они появились в нашей истории то значит кому-то в чем-то помогли . Просто научить их понимать может только тот кому они и помогли, а не первый попавшийся бюрократ от науки обвешанный титулами которые у работников высшей школы появляются видимо за выслугу лет, а не за ясный и светлый ум

To: ALL

Наболтал не по-теме аж самому страшно , что бы вынести хоть что-то полезное самому себе спрошу у вумных товарищей, а где можно посмотреть какой-нибудь бук или ресурс по методах реализации ОС под «ембадед» проекты (не только RTOS) Форум не предлагать, ибо мне бы что-то более абстрактное, это раС, а еще в форуме никогда не приходят к единому мнению, это дваС . Описалово работы уже существующих ОС тоже не так интересно, интересует какой-либо учебник…

Это все мне знакомо, однако есть у меня и противоположный опыт - в школе математика давалась на "ура" в ВУЗе вышка не пошла вообще - трояк с натягом, сейчас она мне очень нужна, и книжки читаю, а все равно "не доходит". Приходится методом тыка.
Рискну предложить-приложить МГУ, К.Ю.Богачев, ОСРВ предварительные материалы лекций. Судя по оглавлению толковая книжка.
P.S. Если кто желает - киньте в ваши закрома на фтп.

Если в ладах с английским -
/pub/DOC/Books/OS/OS_incl_RTOS/Li-EmbSyst.chm
про RTOS применительно к embedded.
И вообще в той папочке поройся

2 Сергей Борщ - принудительно перевел в "свои"

:-) Спасибо. Может пригодится.

К сожалению, мои сведения по этому вопросу ограничиваются учебником по пром. электронике и Datasheet'ами на стандартные промышленные сетевые фильтры. Если Вас это устроит, могу дать ссылки на эти данные.

Я не понял что вы написали. Вы написали конечного много, но я ниасилил.
Я сразу напишу все что думаю, чтобы у вас было еще больше поводов для несогласия. Я считают что образование в СССР было гавно. По крайней мере тогда, когда я в нем учился (1976г.р.) Я понял что нам расказывал старый маразматик на ТАУ, только спустя несколько лет после окончания института, когда в книжке от АД нашел знакомые формулы. Но вот в отличии от ТАУ, я понял что в них написано, и ужаснулся, до чего же все просто, не взирая на то, что инглишя тогда знал ну ОЧЕНЬ паршиво.

Так что. 1. Практика. И теория для того чтобы понять как работает практика. Именно так всегда двигалась наука. Сначала - эксперимент - потом теория его объясняющая. Так и нужно учится.
2. Практика для того чтобы зарабатывать бабло. К примеру сегодня считал индуктивность. У меня на компе несколько гигабайт книжек разных. Много очень умных. Но вот если там вместо того чтобы расказать как считать индуктивность, начинают расказывать про Максвелла, то у меня сразу начинали возникать сомнения, что этот человек действительно знает как считать индуктивности. Про Максвела он знает, я не спорю. может много чего расказать. А вот если ему сказать, мне нужен один генри, который будет работать при токе в один ампер, и частоте один герц, то думаю что закончится все проектом создания витка из сверхпроводника в космосе.

А можете ли вы "выделить" планировщик (надеюсь, вместе с механизмами синхронизации и intertask communication) и положить его куда нибудь как freeware ? По следам горячего финского парня? Ведь это ж RTOS которую можно изучить за полдня!



В Алабаме Mentor Graphics делают RTOS Nucleus (не верх совершенства, IMHO)

Увы, меня не интересуют сами сетевые фильтры. Меня интересует, что будет, если эти фильтры не поставить. Мне не понятно, почему нефтянники так парятся по поводу 7-ой гармоники. Т.е. парятся они совершенно конкретно, но толком объяснить почему парятся - не могут. Я не могу даже понять, с какой точностью эту гармонику измерять. 0.1% хватит? А может хватит и 1%? И вообще, почему только седьмая? А остальные как? И т.д.



А сами коды Вам не помогут. Это ассемблер. Правда есть концепция, которая позволяет наваять очень быстро реал-тайм планировщик. Ну ее (концепцию) я уже тут размещал. Кстати, синхронизации и intertask communication вместе у меня решается одной приблудой - флагами, на которые можно воздействовать API-функциями. Т.е. Планировщик сам по себе, а API-ф-ции сами по себе...

Я не помню, но там какая-то возникает при трехфазном выпрямители.


Все нужны. К примеру посчитай какой у нее скин-эффект.

Открыл учебник по пром. электронике и прочел следующее.

Ниже написано

Далее следует описание системы поддержания коэффициента мощности на максимальном уровне при изменении реактивной мощности, потребляемой преобразователями. Присутствует и простая мат. модель.
Т. е. насколько я понял измерять 7-ю гармонику необходимо для того, чтобы улучшить качество регулирования т. наз. управляемого конденсаторно-тиристорного источника реактивной мощности.
Отсюда, я думаю, можно получить и желаемую точность. Впрочем, могу быть неправ.
Вот название учебника.
Горбачев В. Г., Чаплыгин Е. Е. Промышленная электроника: Учебник для вузов/ Под ред. В. А. Лабунцова. - М.: Энергоатомиздат, 1988 - 320 с.: ил.
Вам может понадобиться глава 7 и в частности параграф 7.3 на стр. 269.

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

P.S.
Может стоит ее перименовать в "Зачем попу гармонь", ну или
"Критерии использования RTOS служителями культа при отправлении обрядов"?

Нет, не надо ее переименовывать. Вы даже не представляете, как близки между собой измерение гармоник в силовый сетях и RTOS. Во всяком случае, когда от нефтянников поступает заказ на проектирование многоканальных регистраторов. Учитывая Ваш высокий вкус к графике, я б и дальше рекомендовал Вам углубленно заниматься творчеством Жана Эфеля и не лезть сюда со своими безусловно мудрыми мыслями. А то оскорбленной воинствующей серости тут хватает и топик могут действительно прикрыть, как не соответствующий...



Спасибо, лезть не надо. Теперь ясно, что гармошки, в основном, накодятся от 2-ой до 13-ой (старый ГОСТ 13109-97)
убираем четные (симметричный относительно нуля сигнал) и кратные трем. Остаются всего четыре:

5,7,11,13

На седьмую и пятую падает основная мощща. Спасибо.

Вопрос о многоканальном регистраторе. Если этот проект выполнять на МК c DSP ядром или чистом DSP, то каково должно быть тех. задание, чтобы RTOS стала необходимостью? И в чем близость между гармониками и RTOS? Без шуток...
Лично для себя я решил, что в своих проектах на МК с ограниченными внутренними ресурсами постараюсь обойтись вовсе без нее. Причины этого могу изложить по пунктам, если кому будет интересно.

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




Всегда рад оказать посильную помощь.

Интересно. Часто RTOS позволяет лучше использовать ресурсы, и их нужно меньше, чем без RTOS (если программист не опытный).

Сразу оговорюсь, что все нижеизложенное отражает только лишь мое личное мнение.
1. Использование RTOS снижает надежность системы на МК, поскольку сама она вещь в себе и кроме этого есть порты неизвестно кем и как писанные.
2. Использование RTOS снижает производительность системы хотя бы из-за необходимости сохранения достаточно обширного контекста задач.
3. Большинство RTOS принуждает использовать ЯВУ, в частности С, даже там, где для этого нет необходимости. В нашей ситуации это приводит к воровству софта, что после в ступления в ВТО может пагубно отразиться на многих из нас. Исключение GCC для AVR и частично MCC18 и С30 для PIC.
4. Использование RTOS в общем случае замедляет работу системы на время обслуживания собственных процессов.
5. Использование RTOS уменьшает доступные ресурсы системы. В частности уменьшает доступную память на величину, необходимую для хранения ядра и на хотя бы один таймер, используемый для службы времени.
6. Использование RTOS принуждает к изучению вторичной информации о ее функциях, методах и событиях, никак не связанных с решаемыми реальными задачами. Это непроизводительные временные затраты и необходимость хранения "в голове" абсолютно бесполезной информации.
7. Использование RTOS приучает к определеннму стилю программирования, на мой взгляд не очень красивому и эффективному. Пример этого стиля - использование замкнутых на себя циклов в качестве задержек.
8. RTOS зачастую не всегда хорошо отображается на архитектуру конкретного МК. Может я в чем-то не разобрался, но на мой взгляд RTOS только мешает эффективному использованию системы прерываний, особенно векторной.
9. RTOS приводит к появлению новых сущностей, таких как семафоры, мьютексы, майл-боксы, планировщики заданий и т. д. и т. п. На мой взгляд все это лишнее и только уводит разработчика от "железа" МК и внешнего оборудования, а это плохо.
Пока все. Если что появится, тогда добавлю еще.

Нет. Это часто просто кусок уже написаной программы. Зачем писать то, что уже неписано. Разумеется, RTOS ДОЛЖНА быть в исходниках.

Если контекст задачи нужно сохранять, то его нужно сохранять. Будет называться та часть программы РТОС, или нет, на производительность не влияет.

Еще есть SDCC и GCC для ARM и MSP. Остаются DSP. Стоимость компилятора - несколько килобаксов. Воровство софта прекратится, как только З.П. дойдет до уровня к примеру Бангалора.

Что за собственные процессы? Если брать UCOS то там их я не помню. Если к примеру линукс, и брать к примеру дисковый кеш, то ничто не мешает монтировать диски в снхронном режиме, правда вот скорости это обычно не прибавляет.

Тоже что и пункт два.

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

РТОС предоставляет очень эффективный способ формирования задержек - путем отдачи не используемого времени другой задаче.

Есть МК на которые вообще С не отображается.

Юкосу нужно только одно прерывание. Остальные остаются у пользователя.

Весьма удобные вещи. Если задача сложная. Использование готовых сущьностей освобождает время для траха с железом и внешним оборудованием. Коме того, дает стандартный интерфейс для этого.

Хорошие РТОС - могут быть полезны. Но не всегда. Если задача взять поток из одного ДМА, пересемплировать, и запихать в другой ДМА, то никакие оси там не нужны.
Если задача - сложный технологический процесс, есть граф. интерфейс, файловая система, (не просто мерять токи и транзисторами хлопать) то нужна.

Когда и кем написанная? Кем написаны порты? К примеру, в порте uCOS для PIC18 я нашел принципиальный недочет, приводящий к фатальной ошибке при определенных условиях. Это раз.
А во-вторых, зачем мне кусок ничего не делающей программы, которая не решает ни одной из поставленных задач?


Есть стили программирования, когда даже нет понятия о контексте задачи. Да и понятия задачи тоже.
Сначала надо определиться с подходом, и при его правильном выборе вопрос о RTOS отпадает сам собой.


Не будет этого никогда. З. П, разработчиков будет только уменьшаться по отношению к остальным. Это общемировая тенденция. И кто такой Бангалор?


О дисках речи нет, поскольку лично я подразумеваю МК с ограниченными ресурсами. Я так понял, что Вы утверждаете, что машинное время МК совершенно не тратится на обслуживание разных семафоров, мьютексов и прочей ерунды? Между прочим, судя по порту uCOS для PIC18, простое переключение между задачами - это 10 команд и 20 машинных циклов. Всегда. Для меня лично это непозволительная роскошь.


Значит Вы утверждаете, что ядро RTOS никакого места в памяти программ не занимает? А где оно хранится тогда?


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


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


А что - это проблема? Есть Паскаль, Бэйсик, ну и Ассемблер. На мой взгляд человек, не освоивший Ассемблер выбранного МК, не имеет права применять ЯВУ, а тем более надстройку над ним в виде RTOS для создания встроенных систем, как не освоивший архитектуру системы. Это, естесственно, не касается инструментальных систем на РС. Там совершенно иные правила.



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



Ну да. Трах с железом абсолютно неизбежен, но к нему добавляется еще и трах с RTOS. Смотрел я на этот стандартный интерфейс к железу...



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

[quote name='Прохожий' date='Dec 10 2006, 16:21' post='185726']
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Нет. Это часто просто кусок уже написаной программы. Зачем писать то, что уже неписано. Разумеется, RTOS ДОЛЖНА быть в исходниках.
[/quote]
Когда и кем написанная? Кем написаны порты? К примеру, в порте uCOS для PIC18 я нашел принципиальный недочет, приводящий к фатальной ошибке при определенных условиях. Это раз.
[/quote]


Ну? Я в порте для АВР нашел. И что с того?
[quote]
А во-вторых, зачем мне кусок ничего не делающей программы, которая не решает ни одной из поставленных задач?
[/quote]
Она их помогает решать.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Если контекст задачи нужно сохранять, то его нужно сохранять. Будет называться та часть программы РТОС, или нет, на производительность не влияет.
[/quote]
Есть стили программирования, когда даже нет понятия о контексте задачи. Да и понятия задачи тоже.
Сначала надо определиться с подходом, и при его правильном выборе вопрос о RTOS отпадает сам собой.
[/quote]
Согласен.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Еще есть SDCC и GCC для ARM и MSP. Остаются DSP. Стоимость компилятора - несколько килобаксов. Воровство софта прекратится, как только З.П. дойдет до уровня к примеру Бангалора.
[/quote]
Не будет этого никогда. З. П, разработчиков будет только уменьшаться по отношению к остальным. Это общемировая тенденция.
[/quote]
Значит что в будущем разработчиков не будет.


[quote]
И кто такой Бангалор?
[/quote]
Город в Индии. Где софт пишут для США.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Что за собственные процессы? Если брать UCOS то там их я не помню. Если к примеру линукс, и брать к примеру дисковый кеш, то ничто не мешает монтировать диски в снхронном режиме, правда вот скорости это обычно не прибавляет.
[/quote]
О дисках речи нет, поскольку лично я подразумеваю МК с ограниченными ресурсами. Я так понял, что Вы утверждаете, что машинное время МК совершенно не тратится на обслуживание разных семафоров, мьютексов и прочей ерунды?
[/quote]
Тратится, но какая разница на что его тратить, на свой самафор или на Юкосный?


[quote]
Между прочим, судя по порту uCOS для PIC18, простое переключение между задачами - это 10 команд и 20 машинных циклов. Всегда. Для меня лично это непозволительная роскошь.
[/quote]
Может вы просто не так пишете софт?


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Тоже что и пункт два.
[/quote]
Значит Вы утверждаете, что ядро RTOS никакого места в памяти программ не занимает? А где оно хранится тогда?
[/quote]
Занимает.

[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Да но снижает время на изобретение велосипеда. Вопрос что лучше - изобретать велосипед или воспользоваться готовым - вопрос сложности задачи. Если она достаточно сложная, то оно оправдывает.
[/quote]
Смотря что понимать под велосипедом. Мне кажется, что время, потраченное на RTOS, лучше потратить на освоение методик программирования при которых потребность в оной отпадает, даже при задачах любой степени сложности.
[/quote]
Попробуйте работать без операционки на персоналке.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
РТОС предоставляет очень эффективный способ формирования задержек - путем отдачи не используемого времени другой задаче.
[/quote]
Для того, чтобы организовать оптимальное взаимодействие между различными задачами (по-вашему, поскольку у меня другое определение для этой сущности) даже при большом их количестве вполне достаточно здравого смысла и правильной методики программирования.
[/quote]
Согласен. Но операционку тоже можно использовать.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Есть МК на которые вообще С не отображается.
[/quote]
А что - это проблема? Есть Паскаль, Бэйсик, ну и Ассемблер. На мой взгляд человек, не освоивший Ассемблер выбранного МК, не имеет права применять ЯВУ, а тем более надстройку над ним в виде RTOS для создания встроенных систем, как не освоивший архитектуру системы. Это, естесственно, не касается инструментальных систем на РС. Там совершенно иные правила.
[/quote]
Я не согласен. Досконально изучать ассемблер смысла нет. Достаточно разобраться что так к чему, чтобы можно было разобраться в листинге.



[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Юкосу нужно только одно прерывание. Остальные остаются у пользователя.
[/quote]
Я так и говорил, что одно как минимум прерывание потеряно. Для меня это существенно. И еще большой вопрос как это все будет между собой взаимодействовать.
[/quote]
Может вы что-то не так делали? К примеру время вам нужно считать? Интервал в 1 милисекунду достаточен? Вот и используйте интервал в 1 мс, и для шедулера.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Весьма удобные вещи. Если задача сложная. Использование готовых сущьностей освобождает время для траха с железом и внешним оборудованием. Коме того, дает стандартный интерфейс для этого.
[/quote]
Ну да. Трах с железом абсолютно неизбежен, но к нему добавляется еще и трах с RTOS. Смотрел я на этот стандартный интерфейс к железу...
[/quote]
Не стандартный интерфейс к железу, а к взаимодействию разных частей программы. Семафоры итд, уже давно придумали и продумали.


[quote]
[quote name='Artem-1.6E-19' post='185645' date='Dec 10 2006, 09:50']
Хорошие РТОС - могут быть полезны. Но не всегда. Если задача взять поток из одного ДМА, пересемплировать, и запихать в другой ДМА, то никакие оси там не нужны.
Если задача - сложный технологический процесс, есть граф. интерфейс, файловая система, (не просто мерять токи и транзисторами хлопать) то нужна.
[/quote]
Еще раз напомню, что речь шла о встроенных системах без файловых систем и сложных графических интерфейсов. Обычно в пром. автоматике эти вещи разъеденины. Управление машиной - это PLC с примитивным языком или простой МК, а визуализация - PC с полноценной ОС. И где тут место для RTOS?
[/quote]


Нужно по задаче смотреть.

Не факт. Абсолютно. Здесь Вы меня не убедите никогда. Поэтому предлагаю ничью по этой части дискуссии. Каждый остается при своем.


В том виде, как мы с Вами представляем, к сожалению, нет. Я, лично, уже около 10 лет таковым не являюсь. Стремление к мат. благам перевесило. Пошел сменным инженером на крупное производство. Занимаюсь техническим творчеством только, когда сильно попросят или для души.
Зато могу взглянуть на процесс разработки со стороны. Да и подходы, принятые в пром. автоматике, оказали свое воздействие...


Ну вот Вам и капец нашим разработчикам. Индусов много, процент дураков среди них такой же, как среди нас. По-любому дешевле...


У меня нет семафоров. Есть входные переменные.


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


Пробовал. Был такой зверь - "Электроника 60" назывался, PDP/LSI-11 по-ихнему. Я на нем в юности программки валял прямо в кодах, даже без Ассемблера.
А сейчас даже и пытаться не буду. Я больше скажу. Я и Visual С++ пользоваться не буду. Потому как человеко-машинный интерфейс там не очень. По мне так Borland C++ Builder самое то.
Но одно дело встроенные системы, которые должны быть особо надежными и совсем другое системы на основе РС, обеспечивающие HMI. У них иные требования, и надежность среди них - не самое первое.
Хотя справедливости ради отмечу, что в свое время наблюдал создание полноценной системы визуализации с нуля на процессоре I80186 без всяких встроенных RTOS и ОС.


Так наизусть никто и не заставляет... Здесь важно осознать, я бы сказал, "почувствовать" архитектуру определенного класса МК. А для этого надо навалять пару, тройку не очень сложных программуль на Ассемблере, желательно с использованием прерываний и каких нибудь внутренних переферийных узлов МК.


Я вообще время не считаю. Временные переменные (разных типов) ничем не хуже и не лучше всех остальных.


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


Пересмотрел хренову тьму пром. оборудования. Везде одно и то же. Концептуально от задачи ничего не зависит. Меняется мощность PLC и размер панели.

Если будет идея "по существу", пишите. Возрастом махать, как-то не конструктивно.

Сразу - всё ИМХО, не больше. Наверно...
Не так давно появился термин BSP (Board Support Package) - он вместил в себя дрова и подсистему синхронизации/времени (не часы-календарь, а системного). Причём эта штуковина предполагает дрова незавязанные на ОС (ОС не участвует в решении внутренних проблем драйверов), а предоставляющие себя. Соответственно дрова обеспечивают некоторый сервис, в том числе разделение/совмещение/преобразование потоков и блочных данных. На уровне взаимодействия с ОС становятся необходимыми быть какие-либо достаточно привычные способы взаимодействия, например IOCTL или "обычные" семафоры, мейлбоксы... Так вот ежели линуксовый люд и мелкомягкие всё чаще имеют одно мнение (помотрите факты отсутствия термина HAL во многих современных реализациях и линухов и виндовсэмбеддед и замена на BSP), то вопросов становится только больше.
Я считаю, что нужно так реализовывать дрова, чтобы максимально ОС там нафиг не была нужна, но спокойно могла ими пользоваться - тогда ОС и частный случай - RTOS - простой и унифицированный способ написания/выполнения прикладных задач. Конечно дрова не бывают одинаковыми под все ОС
Мне, правда, чаще хватает механизма сопрограмм и round robin, чем полноценной RTOS, но когда нужно хоть что-то, типа файловой системы, то реализация без ОС может быть относительно безболезненна только в очень узкоспециализированных задачах.
Ежели есть PC и ОС для него, то дрова и ОС завсегда завязаны - традиция установки костылей, и выбор ОС есть вопрос анализа преимуществ и недостатков не просто ОСей, а вместе с дровами... и их глюками... известными и неизвестными... Это отдельная тема для больших диссертаций и криков "ацтой"

Извините, вы оптимист или просто человек со странностями?

Считайте лучше, что со странностями.
Пример.
Нужен драйвер UART с кольцевыми буферами и управлением передачей (программно). Рассмотрим механизм передачи (чуть-чуть).
Вариант 1.
Наполнение/опустошение буфера передачи реализуем с семафорами, по окончании выгрузки из буфера передачи в аппаратное FIFO взведём событие. ОС поднимет ожидающую задачу, которая в свою очередь запустит отсчёт времени на выключение передачи и уйдёт ждать события таймера.
Вариант 2.
Флаг блокировки вынесем в интерфейс драйвера. Де-факто не будем пытаться разделять ресурс. "Часть от семафора" - локальный счётчик понадобится для работы с головой/хвостом буфера. По окончании выгрузки из буфера передачи в аппаратное FIFO добавим в слот таймера в список нашу маленькую функцию (в обработчике прерывания таймера двигаем однонаправленные списки, пустые или не совсем - махонький локальный жесткий планировщик) переключения передачи. Вуаля - ОС нифига не знает об этой локально решённой задаче - она не есть полноценный task - это её в task можно завернуть, ну и тягать за собой честный шедулер ОС, TCB и т.д.
Т.е. я не говорю, что можно сделать независимость нашару. Какие-то абстрактные уровни - низ/верх, железо/апликейшн - реализуются часто одними и теми же средствами/методами. Дороговато обходится бисером телогрейки вышивать

Ну про необходимость и достаточность я не говорил. Я говорил только о том, что мне удобнее и быстрее написать RTOS. Возможно я уподобляюсь своему тренеру. Как-то его подбежали бить несколько бультерьерообразных мужчин. И он, чинивший свою развалюху монтировкой, эту монтировку отложил в сторону... Зачем же он это сделал??? А чтобы руки были свободными!

Вот мое ТЗ:

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

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



Да вот не могу я заниматься гармониками без RTOS! Хоть ты тресни. Пробывал - не получается.



Изложите, пожалуйста.




Ну нада-а-а-а-ел он мне! Его манера лезть не имея достаточных DSP навыков в дискуссию надоела. Лез бы он хоть с идеями (пусть неправильными), а он лезет с философскими изысками типа острот. При этом меня раздражает его подспудная аппеляция к господам модераторам: ну я же свой! Я ж вас всех всегда хвалю! Это ничего, что я слабо шарю, главное во мне не это...

В принципе, один товарищ в подобной ситуации выразился гораздо лаконичнее: любителя бьют!!!

...т.е. радиолюбителя

Я так понял, что Ваш регистратор будет снабжен собственной оригинальной RTOS, написанной специально для этого случая?



Уже сделал. Пост №81 в этой теме.
Однако сразу скажу, что все, что там написано, касается только МК с ограниченными скоростями и внутренними ресурсами, т. е. достаточно дешевых. Ваш случай отличается в сторону сложности задачи. Тут и математика, и флэш, и съемный диск...
Не знаю как у Вас, но обычно я стараюсь разделить задачи физически. Задачи реального времени, такие, как управление объектом, сбор данных, их первичная обработка, решаются с помощью МК, которых может быть несколько, а задачи работы с дисками с помощью компьютера, снабженного полноценной ОС.



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

Ну RTOS или не RTOS, но что-то в этом роде. Правда, скорее всего на этот раз я писать не буду, а возьму что-то из себя раннего Т.е. у меня есть заготовки.



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



Разве я напрягаю нервы? Наоборот, я развлекаюсь! Еще мне интересно на сколько хватит местного модератора меня почитывать. Любителя Графики и Научного Атеизма ес-но жалко, но что делать? Он мне разонравился за совершенно конкретные деяния.

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

Здравствуйте.
Поделитесь опытом как наиболее безболезненно что ли перейти на ОС.

У меня мало опыта.
Первый мой проект был на MSP430F149. Тогда я только занакомился с МК и об ОС даже не задумывался. Он был простенький - я справился.

Второй (и текущий) на C167(+сетевушка реалтек).
Сначала это был интерфейс Ethernet-LPT, для управления некой аппаратурой с компа.
Я соорудил простенький TCP/IP стек.
Но потом стали добавлятся новые задачи, кот рушили мой "стройный" алгоритм.
Я решил что пора переходить к "системным вещам"

Что посоветуете?

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

Наиболее безболезненно это постепенно.
Очень стоит также почитать литературу об ОС вообще и о выбранной в частности. А также запустить у себя работающие примеры.

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

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

Так что я хочу всетаки написать свою простенькую, "учебную" ОС.



Вы я так понял тоже не сразу стали использовать гатовые ОС, а написали свои причем даже не только простые но и "более сложные".

Подскажите где найти материялы, кот помогли бы при написании ОС

Именно как учебник для написания своей РТОС (весьма не сложной и доступной для понимания) может служить неоднократно поминаемая на этом форуме scmRTOS (исходники, порты, документация, немного теории).

У нас студенты пишут такие штуки эпизодически. Присоединяйтесь http://embedded.ifmo.ru/index.php/project

Проект как раз недавно начался.

Некоторые чуть ли не Windows XP норовят поставить