Board.KolibriOS.org

VaStaNi wrote:я могу понять твою эйфорию, но ты искжаешь действительность или ее принципиально не хочешь видеть. Листинги=техдоки, потом сам приводишь файл, который у них у него был, есть! Как же ты говоришь слово "без"! Другое дело откуда, как, что было источником информации. Линукс драйвер портировали, я так думаю, ну здорово, молодцы! Но зачем же искажать! От этого слаще что ли будет? Кому?

VaStaNi wrote:Не понятно чего ты как самый заинтересованный, не хочешь выполнить это ниже (NDA) и тихо-тихо дать на прочтение доверенным разработчикам? Все преступники и сволочи и сразу выложат что ли если ты по почте зашифрованным мылом пришлешь? Там отпечатки пальцев нужны??? Ты же заинтересован вроде... че то мутишь, темнишь все...

VaStaNi wrote:да не не путай ты драйвер-офисные вещи и успешных роботов, успешние RT вещи в которых знают толк некоторые, с ними, как минимум сталкивающиеся. Управление, регулирование... и просто TCP пакетик принять с погрешностью "+" "-" (1-2) секунды... разные айсберги!
Вот слова горбатость и т.д. это туда! Под "успешными" нужно понимать не просто проползти, проехать как нибудь, а например пролететь, прошагать... "эффектно", так сказать внешне это проявляется, не тяп-ляп это делается.
Правильно многие тут сказали (а им не внимают некоторые) ТЗ, условия, параметры... Габариты корпуса... равно, как и его цвет, не определяющие параметры проекта и выяснять их 125-й пункт ТЗ.... Вопросы так и "висят" ведь...
И ваще, я так понял, раз ты и Gluk одно лицо(или ты главный у него... слушай ты не тот профессор? А? ), так тогда его тут мы больше не увидим? Ты рулить ТЗ будешь? Ну так изложи.

yogev_ezra wrote:Этот файл мы нашли после того, как драйвер HDA Audio уже был полностью готов

yogev_ezra wrote:если даже он помог, то он не был непременным условием написания драйвера (как ты его тут выставляешь).

yogev_ezra wrote:который вообще стандарт для всех компьютеров мира

yogev_ezra wrote:Если честно - в тебе лично я не уверен

yogev_ezra wrote:так зачем тогда документ этот просить

yogev_ezra wrote:и тихо-тихо дать на прочтение доверенным разработчикам

yogev_ezra wrote:Ты так ничего и не понял: Колибри поддерживает eBox => Я продаю и показываю на выставках eBox + Колибри дешевле, чем eBox + Windows CE (например) => Больше людей пользуются Колибри => Больше людей узнают про Колибри => Больше людей придут в проект Колибри => Больше кода будет написано для Колибри => Колибри будет уметь больше чем, сейчас => И так далее, по принципу снежного кома...

VaStaNi wrote:В твоей - точно нет.

VaStaNi wrote:ШИМ бывает аппаратный (к стати в Vortex86 он есть), а бывает программный. То, что ты привел является базовым программным механизмом получения ШИМа. Естественно он (программный ШИМ) опирается на максимально жесткий такт (IRQ0), прямой доступ к портам из ядра и... модуляция импульсов по оси времени, которая называется скважностью импульсов. Статические DIO данных - это тоже ШИМ, только с очень большим периодом изменения сотояния пинов(бит). В обычных архитектурах ОС ядер (Колибри не исключение) приложение вынуждено постоянно через API OS "прорываться к телу" портов и модифицировать биты портов (ключей), создавать высокоприоритетные "нити"... это масса накладных расходов на производительность, прежде всего. И это очень заметно, тормозит, замораживается... Это следствие "перебора" по тактам, особенно если процесс много их жрет. В задачах регулирования посредством портов, особенно непрерывных, бывает несколько портов, несколько пинов, несколько зависимостей(!) между воздествием и регулированием... Разумному кодеру понятно куда эта дорожка ведет.
Итак, есть несколько портов, несколько приложений с ними связанных. Возникает и суперпроблема строгой тактовой синхронизации (тактовая "пин-привязка") даже при событийном механизме в ОС...
В КПСВВ я вынес это "за пределы приложения". Приложение делает "заявку" на обслуживание такого то порта, с таким то "заданием по дискретному сигналу", на такую то его длительность(бесконечно - частный случай), начиная с.....
Т.е. по сути ставит "в очередь", допустим, задачу генерировать меандр для битов 2,4 (какие нибудь пин-выводы GPIO), с периодом 23 такта IRQ0, длительностью 5 секунд (NNN периодов IRQ0. Пусть это внешне - крутим колеса вперед, например), все!!! Приложение БОЛЬШЕ ЭТИМ НЕ ЗАНИМАЕТСЯ, переключения контекта НА "ЭТО" НЕТ, синхронизация обеспечена, межбитовые задержки минимальны (джиттер!), процессорное время (а оно ведь общее на все задачи и ядерные и аппликухи!) расходуется минимально, минимально возможное, т.к. это часть обработчика прерывания. Но и это не все! В одной обработке прерывания мы в состоянии обработать все порты, требующие RT обслуживания в соответствии "с заявками телезрителей" от аппликух... но и это не все! Ладно..., базовые основы я изложил внятно кажется.

VaStaNi wrote:

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

непонял тут про "конкурентов раскрутить" это кто если не секрет? Они у тебя есть личным образом? У команды? У Колибри? Очем это?

Знакомьтесь, кто не в курсе, монстр рок-н-ролла: