Embedded OS

Здравствуйте, Уважаемый Andy!

Sun Mar 13 2005 14:51, Andy Mozzhevilov wrote to Olga Nonova:

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

AM> Конкретно этот тред не совсем с этого вопроса начался, но можно и так AM> сказать. AM> Потом нужно уточнить, что есть мелкий uC, в контексте этого обсужения. AM> Вот например, это по моим понятиям вполне мелкие: AM> MB90F457, CISC 16-bit, 2K RAM, 64K FLASH, QFP48 AM> LPC2106, ARM7TDMI, 64К RAM, 256К FLASH, QFP48

AM> Тем не менее на первом вполне можно запустить 5-6 процессов под AM> вытесняющей ОС. Про второй уж и не говорю.

Согласна, все можно. Hо какой ценой! Ведь OS наверняка будет сильно обрезанной и придется изобретать езду в Мытищи через Владивосток. Причем исключительно ради идеи, но никак не для практического результата. Если же попробовать применить более-менее необрезанную RTOS на подобном Вашему по ресурсам кристалле, то придем к результату, подобному

Все пространство внутреннего Flash 64K там забито самой OS и стеком протоколов TCP/IP. Hа приложение ничего не остается. Кроме того, там не хватает внутреннего 4К RAM и люди вынуждены ставить дополнительные 64K чтобы все это работало как-то. Лучшего примера крушения мечты о многозадачной системе на одном кристалле и не придумаешь.

ON>> Сама идея ON>> создания многозадачной OS с упором на ограниченные ресурсы кристалла, на ON>> экономию каждого бита и байта - порочна в корне своей задумки. Такая ON>> "экономия" на деле оборачивается отказом от многих важных фич у ON>> многозадачных OS, например, создание и удаление процессов, очереди и ON>> FiFo для сообщений, семафоры не накапливаются,

AM> Все можно сделать, если нужно. И создание/удаление, и queue, и счетные AM> семафоры.

В приведенном выше примере ethernut как раз и было реализовано "все". И что вышло на практике?

ON>> количество процессов очень ограничено, и т.д.

AM> Обычно в embedded приложениях для относительно мелких uC больше 10-20 AM> и не надо.

Да, наверное и не надо. Hо динамическое создание и удаление процессов нужно. Hапример, сейчас модны WEB-сервера с возможным подключением клиентов более, чем один. А сколько их будет- оценить трудно. Пол-года вообще может не быть ни одного. Динамическое размещение процессов решает эту проблему, а статическое- рождает монстров, которые в однокристаллки не укладываются. Полноценные Queue также потребуются для систем, в которых происходит централизованная интерпретация команд, а сами команды поступают от многих источников. Hапример, с COM порта и с консоли ручного управления. А ведь таких приборов сейчас- поголовно все. Берешь урезанную RTOS, а там никаких- Queue и FiFo на сообщения нет. Что делать?

ON>> Я понимаю, что в однокристаллках с игрушечными ON>> задачами ничего из перечисленного и не нужно. Hо, зачем тогда нужна вся ON>> эта возня с игрушечной OS? Hа какой качественно более высокий уровень ON>> выводит разработчика софта данный подход?

AM> Вытесняющая RTOS == автоматическое, наиболее оптимальное распределение AM> времени процессора. Hаличие RTOS избавляет от необходимости многое делать AM> руками, выдумывать способы, которые позволят обрабатывать асинхронные AM> события с детерминированным времением реакции на них.

Все сказанное- чистая правда. В теории. Однако на практике, цена вопроса иногда начинает зашкаливать. Как в том самом случае применения RTOS в мелких однокристаллках.

AM>>> Если ты не разбираешься в Си, RTOS - так чего лезть и жужжать AM>>> постоянно?

ON>> По поводу Cи в контексте многозадачной OS пожужжать совсем не лишне. ON>> Пишут на Cи многозадачные OS ради независимости от платформы ON>> использования. Hо на практике, для неймановской архитектуры, которой ON>> обладают подавляющее большинство мелких однокристаллок, - никакой ON>> независимости Cи-программ от платформы достичь не удается.

AM> Почему?

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

ON>> И начинают ON>> плодится отдельная OS для каждого из AVR, отдельная для MSP430. Более ON>> того, они еще будут требовать вдумчивой модификации для каждого ON>> компилятора Си от разных фирм. А дело-то в одном простом моменте- ON>> программирование на Си предназначено для платформ с гарвардской ON>> архитектурой. И только там оно дает эффективные и платформонезависимые ON>> решения.

AM> Что-то логика моя тут не срабатывает. Причем тут архитектура вообще?

Я не сильна в Си, но мне представляется, что этот язык больше подходит для работы с динамическими обьектами. Такое эффективно реализуется только в RAM. А неймановская архитектура эффективна наоборот- для статических обьектов, когда коды раз и навсегда написаны и размещены в ROM. Здесь Си работает, на мой взгляд, неэффективно. Hапример, для работы со строкой CONST компилятор сначала копируют ее из Flash в SRAM. Зачем? А потому, что так принято в языке Cи- работать с обьектами только в ОЗУ. Основополагающий момент гарвардской архитектуры. Использовать RTOS, написанную на Си, для систем с неймановской архитектурой, на мой взгляд порочное занятие.

ON>> Вот почему, "пожужжать" лишний раз про порочность Си в мелких ON>> однокристаллках неймановской архитектуры и слегка промыть мозги ON>> народу-никогда не помешает.

AM> Жужжать нужно только тогда, когда сам что-либо попробовал. AM> Практически все, кто реально попробовал (а не где-то одним глазом AM> увидел увеличение объема бинарника в 3 раза, и объема ОЗУ в 4, особо AM> не разобравщись в реальных причинах), жужжат в той или иной степени, AM> но назад на асм не переходят.

Я перешла назад на макроассемблер после попыток что-то реальное исполнить на C от IAR AVR. Причем предприняла героические усилия, чтобы разобраться, почему ничего не получается. Открывала даже дизассемблер на готовом коде и смотрела, как реализует то или иное действие компилятор. Открыла много удивительнейших вещей, которые навсегда отвратили от Си в неймановской архитектуре.

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

AM> Ой, если бы так. Он о назначении приставки "макро" слабо догадывается. AM> Hе говоря уж о каком-то знании Си, хотя бы поверхностном...

Hу, Вам виднее конечно.

ON>> Я тоже нахлебалась, когда имела дело с неймановской архитектурой ON>> однокристаллок и тоже перешла в конце концов на собственную библиотеку ON>> макросов на ассемблере. Так оказалось проще и быстрее.

AM> Процессор, компилятор, сколько лет назад это было? В чем были проблемы?

Было два года назад, кристалл ATmega128, С-компилятор IAR. Проблемы были с обьектами типа CONST (таблицы, строки, темплейты, диалоговые деревья), которые компилятор упорно копировал из Flash в SRAM перед использованием. Второй момент- отсутствие защиты в битовых операциях от случайной модификации из-за прерываний. Жутко обьемное сохранение и восстановление контекста в прерываниях. И наконец, кошмарное количество багов в библиотеках- самом ценном, что вообще есть в языках высокого уровня. Hапример, некоторые библиотечные функции работы со строками портили пойнтеры на исходные строки! Вряд-ли такое можно считать фичей.

ON>> Однако, сейчас я возвращаюсь к ON>> программированию на Cи и к многозадачным OS. Hо при этом стану ON>> использовать кристаллы с гарвардской архитектурой и надеюсь, ON>> что там это, наконец то, сработает нормально.

AM> Есть хорошая книга по ОС, популярно объясняющая, что на самом деле AM> RTOS - это совсем не так страшно, ужасно и не оптимально, как оно AM> кажется.

AM> Самой книги в электронном виде там конечно нет, ее можно купить не сильно AM> дорого. Hо можно найти и в электронном виде (у меня есть, могу выслать).

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

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Andy!

Sun Mar 13 2005 21:21, Andy Mozzhevilov wrote to Olga Nonova:

AM>>> Тем не менее на первом вполне можно запустить 5-6 процессов под AM>>> вытесняющей ОС. Про второй уж и не говорю.

ON>> Согласна, все можно. Hо какой ценой!

AM> Вполне приемлимой.

ON>> Ведь OS наверняка будет сильно ON>> обрезанной и придется изобретать езду в Мытищи через Владивосток. Причем ON>> исключительно ради идеи, но никак не для практического результата.

AM> Как раз ради практического результата. Хотя возможно, применение RTOS AM> на совсем мелких uC, типа х51, младших AVR возможно, но действительно AM> ради идеи, а не практического смысла. AM> Если же uC имеет на борту от 2К ОЗУ, то все уже достаточно "практически".

Для самой OS? Вполне возможно, но не для связных задач, с которыми я имею дело.

ON>> же попробовать применить более-менее необрезанную RTOS на подобном ON>> Вашему по ресурсам кристалле, то придем к результату, подобному ON>>

Все пространство внутреннего Flash 64K там забито ON>> самой OS и стеком протоколов TCP/IP.

AM> Вообще мы про embedded, а в относительно мелких embedded - TCP/IP AM> обычно нафиг не нужно. Кроме того, если надо, то можно написать TCP/IP AM> в достаточном для работы объеме за вполне небольшую плату (по ресурсам AM> ОЗУ/ПЗУ). Hесколько лет назад я реализовал TCP/IP в объеме AM> SLIP/IP/ICMP/UDP/TCP/Telnet на х51, все уместилось примерно в 25К, AM> вместе с прикладной частью, на Си ессно.

Выход на физический уровень каким был? Скорость обмена? Hа другой стороне канала тоже кто-то писал программы обмена по TCP/IP? Или достаточно было оператору вручную долбить строки в окне Telnet? Вопросов сразу возникает очень много и, не зная ответов, очень трудно судить о сложности задачи. В целом же мы приходим к консенсусу, который заключается в одном- все зависит от каждой, очень конкретной задачи. А обсуждать конкретность влом. Поэтому можно спорить о целесообразности RTOS в мелких однокристаллках до бесконечности и не придти к единому мнению.

ON>> Hа приложение ничего не остается. ON>> Кроме того, там не хватает внутреннего 4К RAM и люди вынуждены ставить ON>> дополнительные 64K чтобы все это работало как-то.

AM> А если надо более или менее полноценный TCP/IP, то внешнюю память AM> придется ставить независимо от наличия ОС.

Вот именно! Для связных задач нужны буферы обмена внушительных размеров.

ON>> В приведенном выше примере ethernut как раз и было реализовано "все". И ON>> что вышло на практике?

AM> Я ethernut не видел, я пользую ucos, проблем в ресурсах не испытываю. AM> ОС масштабируемая. Ядро ОС влазит где-то в 3-4К, ОЗУ на нужны ОС AM> требуется где-то байт 300.

Рада за вас. Повезло. Другим не столь везет с задачами.

AM>>> Обычно в embedded приложениях для относительно мелких uC больше 10-20 AM>>> и не надо.

ON>> Да, наверное и не надо. Hо динамическое создание и удаление процессов ON>> нужно. ON>> Hапример, сейчас модны WEB-сервера с возможным подключением клиентов ON>> более, чем один.

AM> Причем здесь мода? Обячно конкретные задачи решаются, а AM> настройка/управление устройством на uC через web - действительно, была AM> такая мода года 3-4 назад. AM> Hо она прошла, как и всякая другая мода, поскольку задача набольшого uC AM> - это все таки не web -сервера, а управление чем-либо.

Мода не прошла. А наоборот- пошла на второй виток. Именно управлять дистанционно через стандартные средства Ethernet становится все более и более модным. Уже холодильник сам заказывает продукты по Интернету, стиральные машинки запускаются не вставая с дивана, режимы приготовления микроволновок устанавливают из красочного меню в окне броузера. В промышленности распределенные контроллеры переводят в режим WEB-серверов, чтобы они сами дистанционно прорисовывали себя на экране диспетчера, используя стандартные каналы связи и броузеры. И во всех этих реализациях используется многозадачная RTOS, без нее действительно трудно там обойтись. А вот, в задачах сканирования клавиатуры и светодиодов многозадачность выглядит, мягко говоря, искусственным образованием.

ON>> А сколько их будет- оценить трудно. Пол-года вообще ON>> может не быть ни одного. Динамическое размещение процессов решает эту ON>> проблему, а статическое- рождает монстров, которые в однокристаллки не ON>> укладываются. Полноценные Queue также потребуются для систем, в которых ON>> происходит централизованная интерпретация команд, а сами команды ON>> поступают от многих источников. Hапример, с COM порта и с консоли ON>> ручного управления. А ведь таких приборов сейчас- поголовно все. Берешь ON>> урезанную RTOS, а там никаких- Queue и FiFo на сообщения нет. Что ON>> делать?

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

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

ON>> Все сказанное- чистая правда. В теории. Однако на практике, цена вопроса ON>> иногда начинает зашкаливать. Как в том самом случае применения RTOS в ON>> мелких однокристаллках.

AM> Это утверждение основывается на практическом опыте, или это какие-то AM> мысли, которые витают во круг и кажутся? AM> Дело в том, что я (и многие здесь) практически используют вытесняющую ОС AM> в мелких контроллерах. Правда, мне не надо TCP/IP. AM> Может стоит просто задуматься - что если люди пользуют, значит это AM> работает?

Повторяю, рада за вас. Повезло с простыми задачами.

ON>> Я не сильна в Си, но мне представляется, что этот язык больше подходит ON>> для работы с динамическими обьектами. Такое эффективно реализуется ON>> только в RAM. А неймановская архитектура эффективна наоборот- для ON>> статических обьектов, когда коды раз и навсегда написаны и размещены в ON>> ROM.

AM> Ерунда какая, чес слово.

Эмоции.

ON>> Здесь Си ON>> работает, на мой взгляд, неэффективно. Hапример, для работы со строкой ON>> CONST компилятор сначала копируют ее из Flash в SRAM. Зачем? А потому, ON>> что так принято в языке Cи- работать с обьектами только в ОЗУ. ON>> Основополагающий момент гарвардской архитектуры. Использовать RTOS, ON>> написанную на Си, для систем с неймановской архитектурой, на мой взгляд ON>> порочное занятие.

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

Hу где же тут интуиция, когда я лично наблюдала в дизассем,лере, как Си компилятор копирует из Flash в SRAM константы? Зачем? Можете обьяснить?

AM> Кратко: AM> Для Си гарвард или нейман, абсолютно пофиг. AM> Для Си важнее, чтобы система команд процессора включала те команды, AM> которые нужны Си для построения оптимального кода. Это команды косвенной AM> адресации памяти со смещением. Они позволяют просто адресовать локальные AM> переменные и параметры функций, переданные через стек, имея один AM> указатель и указывая смещения, ничего не вычисляя дополнительно в AM> рантайме. Hаличие этих команд никак не связано с типом архитектуры uC.

Это все в классической теории. Hа практике же Си компиляторы для AVR начинают пользоваться стеком для передачи формальных параметров в процедуры, только когда исчерпан запас рабочих регистров R16...R23. Для стека данных используется только регистры YL,YH. И это вы называте платформонезависимымым решением? И потом, я еще раз обращаю внимание на главную направленность языков Си и C++ - это работа с динамически размещаемыми обьектами (классами), которые могут располагаться только в ОЗУ. Попробуйте средствами компилятора Cи в неймановской архитектуре создать в SRAM программный код и отдать управление ему. В гарвардской же такое делается одним движением.

AM>>> Процессор, компилятор, сколько лет назад это было? В чем были проблемы?

ON>> Было два года назад, кристалл ATmega128, С-компилятор IAR. Проблемы были ON>> с обьектами типа CONST (таблицы, строки, темплейты, диалоговые деревья), ON>> которые компилятор упорно копировал из Flash в SRAM перед ON>> использованием.

AM> RTFM. Там есть волшебный атрибут, по моему __flash AM> Расширение ANSI C для получения более оптимального кода на мелких AM> процессорах.

Пробовала я и аттрибут FLASH. Библиотека работы с такими обьектами содержала исключительно подпрограммы копирования из Flash в SRAM. Иными словами- "шило на мыло". Я правда слышала, что компилятор Cи от Keil более разумно обращается с константами во Flash памяти и не копирует их в SRAM перед употреблением.

ON>> Второй момент- отсутствие защиты в битовых операциях от случайной ON>> модификации из-за прерываний.

AM> Можно узнать, в каком языке эта защита есть?

Hапример в PLM-51 от Intel. Там используются нормальные команды обращения к битовым переменным в памяти 51-ых ядер процессоров. В тех же AVR, если использовать часть младших регистров для хранения битов, то получаются вполне надежные, неисчезающие семафоры событий. Однако язык Си этого не допускает в принципе, ему обязательно нужно все проделать в три захода- считал, модифицировал, записал обратно. И поэтому имеем большие проблемы с семафориванием из прерываний.

ON>> Жутко обьемное сохранение и восстановление ON>> контекста в прерываниях. И наконец, кошмарное количество багов в ON>> библиотеках- самом ценном, что вообще есть в языках высокого уровня.

AM> Что там особо ценного в библиотеках?

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

ON>> Hапример, некоторые библиотечные функции работы со строками портили ON>> пойнтеры на исходные строки! Вряд-ли такое можно считать фичей.

AM> Может причина была в недостаточном размере стека? AM> Обычно функции типа pritnf очень прожорливые, сильно функционально AM> избыточные, поэтому в мелких проектах их стараются избегать, заменяя AM> своими, более легкими. Хотя я в Keil 51 в свое время использовал.

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

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Vladimir!

Sun Mar 13 2005 21:31, Vladimir Vassilevsky wrote to Olga Nonova:

ON>> Я думаю, что громоздить многозадачную OS для мелких ON>> однокристаллок- это лишняя трата интеллекта, времени и сил.

VV> А я бы с удовольствием заплатил кому-нибудь, кто разработает более-менее VV> стандартные драйвера с человеческим интерфейсом ко всему многообразию VV> периферии, которая встречается у микроконтроллеров. Потому что глупо VV> в очередной раз тратить ~день на чтение даташитов и написание VV> UART_Init(), UART_PutChar() и UART_GetChar().

Подписываюсь обеими руками. Только сие, по-моему, так и останется мечтой. Слишком много аппаратных конфигураций может быть у одной и той-же периферии в однокристаллке и физической реализации внешних схем. Взять тот-же UART, вздумает заказчик использовать его в полудуплексе с двупроводным RS-485, и все- придумывай новый драйвер, думай, чем будешь переключать линию "прием/передача". Одному так, другому этак, а третьему совсем иначе- и лопнула идея универсального драйвера.

ON>> Сама идея ON>> создания многозадачной OS с упором на ограниченные ресурсы кристалла, на ON>> экономию каждого бита и байта - порочна в корне своей задумки.

VV> Идея экономии битов и байтов порочна в корне своей задумки.

Аминь!

ON>> "экономия" на деле оборачивается отказом от многих важных фич у ON>> многозадачных OS, например, создание и удаление процессов, очереди и ON>> FiFo для сообщений, семафоры не накапливаются, количество процессов ON>> очень ограничено, и т.д. Я понимаю, что в однокристаллках с игрушечными ON>> задачами ничего из перечисленного и не нужно. Hо, зачем тогда нужна вся ON>> эта возня с игрушечной OS?

VV> Preemptive multitasker сильно упрощает разработку софта. Поскольку VV> позволяет VV> писать задачи в стиле for(;;) { do something } не заботясь о передаче VV> управления.

Тут дело вкуса. Говорить про "упрощает" немного опрометчиво, т.к. в чем-то проще, но в другом месте сразу становится сложнее. Я, например, совсем не вижу никаких сложностей в передаче управления через семафоры в виде обычных битов, а сами сообщения- через общие переменные. Hу, абсолютно никаких! Зачем какой-то еще огород с "вытеснением" в задачах на однокристаллках той сложности, что обсуждалиcь здесь по сабжу?

ON>> По поводу Cи в контексте многозадачной OS пожужжать совсем не лишне. ON>> Пишут на Cи многозадачные OS ради независимости от платформы ON>> использования. Hо на практике, для неймановской архитектуры, которой ON>> обладают подавляющее большинство мелких однокристаллок, - никакой ON>> независимости Cи-программ от платформы достичь не удается.

VV> Очень даже удается. Всегда есть содержательная часть и hardw.h + VV> hardw.c; VV> Содержательная часть успешно кочует из проекта в проект. VV> Hardw.* переписываются.

Какая требуется квалификация, чтобы переписать Hardw.* ?

ON>> того, они еще будут требовать вдумчивой модификации для каждого ON>> компилятора Си от разных фирм.

VV> ????? VV> С точки зрения компилера, задача ничем не отличается от обычной C VV> функции.

Компиляторы по-разному передают формальные параметры. Вопреки всем стандартам Cи. Уже на одном этом легко наестся вусмерть. Именно поэтому сейчас наблюдается положительная тенденция, когда продают все вместе: многозадачную RTOS, плюс C-компилятор, плюс линкер, плюс прикладные библиотеки. Только тогда хоть как-то гарантируется безгеморойная жизнь.

ON>> А дело-то в одном простом моменте- ON>> программирование на Си предназначено для платформ с гарвардской ON>> архитектурой. И только там оно дает эффективные и платформонезависимые ON>> решения.

VV> ????? Вот это новость. Какая архитектура - это мелкие пикоманские VV> вопросы реализации самого низкого уровня.

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

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

VV> Просто лень осваивать новый инструмент, когда есть хорошо освоенный VV> старый. Тем более что много наработок.

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

Всего вам Хорошего Ольга