Phantom-84
Переходи сюда. Требуется разработать архитектуру и API под уже существующую систему.
Новая ветка ядра
(с) бред - удалено автором
Last edited by VaStaNi on Fri Jan 02, 2015 5:00 pm, edited 1 time in total.
Чем рисовал ?
Принципиально не отличается от того, что сейчас есть в Колибри.
Принципиально не отличается от того, что сейчас есть в Колибри.
(с) бред - удалено автором
Last edited by VaStaNi on Fri Jan 02, 2015 5:00 pm, edited 1 time in total.
10 тем более 100 кГц на PC это горячка и тупое расходование тактов на обслуживание прерываний.
(с) бред - удалено автором
Last edited by VaStaNi on Fri Jan 02, 2015 5:01 pm, edited 1 time in total.
Отвечу, на кой этот самый ACPI нужен. Без него невозможно _стандартным_ (а значит, гарантированно работоспособным образом) узнать про наличие ряда устройств материнской платы. Без него невозможно _стандартным_ образом настраивать некоторые устройства, управлять их состояниями и т.п. В частности, невозможно оптимизировать энергопотребление системы, например, переводить часть процессоров в режим сна, если для них нет работы.VaStaNi wrote:Я бы на ЖРВ хорошо замахнулся и в принципе так оно и есть, но есть мега проблема призвезденый SMM в SMI в бивисе, на котором отчасти и стоит ваш любимый в последнее время ACPI (посты так и блещут фразами, что типа оседладь бы надо, кстати никто вразумительно не написал накой он ему нужен).
Конечно, все эти вещи можно выполнять тем или иным нестандартным образом. Например, если известна точная модель процессора и чипсета, то можно слепить собственные драйверы, которые будут выполнять всё необходимое, прямо работая с соответствующими регистрами. Но, понятное дело, переход на другой тип процессора и/или чипсета делает эти драйверы неработоспособными, если эти регистры поменялись. ACPI избавляет от необходимости знать всё о конкретном железе на конкретной платформе (тем более что железо может быть совершенно нестандартным: мало ли, например, какую хитрую схему управления электропитанием придумает разработчик материнки): часть действий выполняется кодом SMM, другая часть -- кодом ОС, но под управлением таблиц ACPI (в первую очередь -- интерпретатором кода AML).
Теперь насчёт жёсткого реального времени. Понятное дело, что наличие SMM-кода вносит неопределённость в скорость реакции на прерывания и тому подобные вещи, что для подобных систем недопустимо. Однако это уже проблема конкретной аппаратной платформы, а не ОС, поддерживающей ACPI. Грубо говоря, у платформы, пригодной для построения систем жёсткого реального времени, попросту не будет кода режима SMM (он не является абсолютно необходимым; собственно, нужда в нём возникла в те времена, когда никаким ACPI ещё не пахло: просто нужно было обеспечить управление электропитанием для осей, которые сами этого делать никак не умели, причём незаметным для них образом), что не помешает ей оставаться ACPI-совместимой. В общем, это проблема не ОС, а аппаратной реализации и BIOS.
VaStaNi
На диаграмме оно конечно понятней. Еще лучше (совсем идеально) было бы хотя бы некоторые цифирки пояснять текстом.
Основная идея понятна, но имхо чрезмерно наворочена, по крайней мере если сравнивать с примитивным таскменеджером Колибри.
Хочу высказать одну крамольную вещь: я, как инженер-электронщик, осознаю важность RTOS-концепций, но меня воротит от чрезмерно зарегулированной и всёгарантирующей системной опеки ЖРВ.
Если я сомневаюсь в реактивности (или синхронности) ОС, я просто впихиваю критичную по времени функцию в железо (впаиваю подходящий FIFO-буфер или планирую более умный контроль внешнего устройства на ПЛИСах), а компьютеру оставляю компьтерово - сбор и анализ данных.
Чтобы управлять датчиками и релюхами - RTOS не нужен. Нужны ЛАшки, триггера, буферные регистры, текстолит и хлорное железо.
Совсем другая задача: RT-оптимизация ядра - она действительно нужна, но к ЖРВ-системе отношения не имеет.
SII
Уважаю Вашу позицию и (удивительное дело!) согласен со всеми аргументами.
Стоит ли гальванизировать монстра ради управления вентиляторами и батарейками, если того же можно в добиться в 100 байт, напрямую?
Вы аргументированно отвечаете: да. Многие в этом с Вами согласятся.
Я рискую возразить: не обязательно. Для себя я имею право склепать такую систему, которая мне больше подходит.
И на которую я ухлопаю меньше времени, сил и средств.
На диаграмме оно конечно понятней. Еще лучше (совсем идеально) было бы хотя бы некоторые цифирки пояснять текстом.
Основная идея понятна, но имхо чрезмерно наворочена, по крайней мере если сравнивать с примитивным таскменеджером Колибри.
Хочу высказать одну крамольную вещь: я, как инженер-электронщик, осознаю важность RTOS-концепций, но меня воротит от чрезмерно зарегулированной и всёгарантирующей системной опеки ЖРВ.
Если я сомневаюсь в реактивности (или синхронности) ОС, я просто впихиваю критичную по времени функцию в железо (впаиваю подходящий FIFO-буфер или планирую более умный контроль внешнего устройства на ПЛИСах), а компьютеру оставляю компьтерово - сбор и анализ данных.
Чтобы управлять датчиками и релюхами - RTOS не нужен. Нужны ЛАшки, триггера, буферные регистры, текстолит и хлорное железо.
Совсем другая задача: RT-оптимизация ядра - она действительно нужна, но к ЖРВ-системе отношения не имеет.
SII
Уважаю Вашу позицию и (удивительное дело!) согласен со всеми аргументами.
Но справедлива и антитеза: для хорошо документированной платформы можно собрать полноценную и компактную ОС, избавленную от (большинства) ACPI-заморочек.ACPI избавляет от необходимости знать всё о конкретном железе на конкретной платформе
Стоит ли гальванизировать монстра ради управления вентиляторами и батарейками, если того же можно в добиться в 100 байт, напрямую?
Вы аргументированно отвечаете: да. Многие в этом с Вами согласятся.
Я рискую возразить: не обязательно. Для себя я имею право склепать такую систему, которая мне больше подходит.
И на которую я ухлопаю меньше времени, сил и средств.
Естественно, всё задачей определяется.art_zh wrote:Чтобы управлять датчиками и релюхами - RTOS не нужен. Нужны ЛАшки, триггера, буферные регистры, текстолит и хлорное железо.
Абсолютно с Вами согласен. Если исходить из Вашей постановки задачи (ОС узкого применения, заточенная под конкретную хорошо документированную платформу), именно Ваш подход мне представляется оптимальным. Просто у меня ориентир совершенно другой: любой достаточно современный ПК, а тут обойтись без вещей, подобных ACPI, уже нереально (мало того, что железо разнообразно, так оно зачастую и не документировано: попробуй, например, найди спецификации, необходимые для управления питанием процессора на матерях Gigabyte с их технологией DES).Но справедлива и антитеза: для хорошо документированной платформы можно собрать полноценную и компактную ОС, избавленную от (большинства) ACPI-заморочек.ACPI избавляет от необходимости знать всё о конкретном железе на конкретной платформе
Естественно, имеете полное право. Просто Ваша система не будет работать на другой платформе, что для меня (и многих других) неприемлемо. Но, как уже говорил, это определяется самой постановкой задачи, поэтому мы с Вами не непримеримые враги, а просто идущие по разным дорогам в разные конечные пунктыСтоит ли гальванизировать монстра ради управления вентиляторами и батарейками, если того же можно в добиться в 100 байт, напрямую?
Вы аргументированно отвечаете: да. Многие в этом с Вами согласятся.
Я рискую возразить: не обязательно. Для себя я имею право склепать такую систему, которая мне больше подходит.
И на которую я ухлопаю меньше времени, сил и средств.
(с) бред - удалено автором
Last edited by VaStaNi on Fri Jan 02, 2015 5:01 pm, edited 1 time in total.
VaStaNi
Не обижайся, я вовсе не собирался тебя чем-то зацепить.
Ты обращался лично ко мне? -- я изложил свое мнение.
Действительно, с точки зрения инженера некоторые сложнейшие RTOS-проблемы можно более эффективно решить схемотехнически.
Да, в каждом конкретном случае надо будет разводить новую схему.
Но ведь и программист под каждую частную задачу должен разрабатывать особый код, так?
В большинстве случаев решения диктуются соображениями экономической целесообразности и реальными сроками заказа.
_____
P.S. У каждого участника проекта - не только своя точка зрения, но и свои стимулы для работы.
Не все работают ради развлечения или самообразования.
Не обижайся, я вовсе не собирался тебя чем-то зацепить.
Ты обращался лично ко мне? -- я изложил свое мнение.
Действительно, с точки зрения инженера некоторые сложнейшие RTOS-проблемы можно более эффективно решить схемотехнически.
Да, в каждом конкретном случае надо будет разводить новую схему.
Но ведь и программист под каждую частную задачу должен разрабатывать особый код, так?
В большинстве случаев решения диктуются соображениями экономической целесообразности и реальными сроками заказа.
_____
P.S. У каждого участника проекта - не только своя точка зрения, но и свои стимулы для работы.
Не все работают ради развлечения или самообразования.
(с) бред - удалено автором
Last edited by VaStaNi on Fri Jan 02, 2015 5:01 pm, edited 1 time in total.
В качестве рекламной паузы могу сказать, что Mario и SII были правы - с понедельника я работаю в одном из пиар агентств Новосибирска, куда меня взяли в мои 16 лет. Самое интересное, что работа вообще не связана с компьютерами и IT. Они мой проект по корпоративным играм практически купили и заодно взяли меня как реализатора в свое новое подразделение. Так что программирование теперь точно только хобби.
Ну, все будешь теперь как-бы CEOшником.
Ну как бы как ... З/п мне нравится)
Who is online
Users browsing this forum: No registered users and 5 guests