Мда... Теперь ясно...





Базара нет. Я не знаю TCP/IP, а Вы не знаете, что он не реал-тайм...
Ну давайте на этом и разойдемся.

Сообщение отредактировал st256 - Feb 21 2006, 13:28

st256, Вам вроде и нужна была критика

Вот эта мысль тоже хорошая:

Или исполнительный монитор ЦОС. А средства поддержки проектирования есть (2 альтернативы: в ОС - библиотеки системных функций, в ЯВУ или case-системах - само описание уникально). Даже макросы и то инструмент.

Сообщение отредактировал Vic1 - Feb 21 2006, 13:58

Понимаете, леди, критика хороша когда она идет из хорошего источника. А когда человек знает ноль, то и энтропия его постов (мат. ожидание количества информации) - тоже ноль. Есть моменты, которые я не понимаю. Например, я не понял Вашего поста. Ну просто не понял. Без второго дна, как говориться. Тогда я пытаюсь разобраться или хотя бы понять, что мне тут не надо разбираться, не мой профиль, не моя компетенция. Но объяснять неучу, что TCP/IP не реал-тайм, простите, не стану. Потом ему придется объяснять правила сложения и конца этому не будет.

На счет ЖАБЫ или CASE.... Ну это точно не ко мне. У меня конвейер, у меня суперскаляр, у меня страшные ограничения на память, я даже не могу позволить писать себе на Си...

Такая тяжелая судьба у специалистов по Цифровой Обработке Сигналов. Потому нас так мало

Ну, вы пока можете попытаться объяснить, в меру понимания, хоть то, что есть профиль - что такое риал-тайм... А там и я, может быть, объясню, почему и TCP/IP даже, при определённых условиях - может быть компонентом очень даже hard realtime системы ...



Это что? : "сам себя с утра не похвалишь - весь день как оплёванный ходишь?"
А кто вам сказал, что вы "волшебник"? Вы - только учитесь (с)

Сообщение отредактировал Olej - Feb 22 2006, 07:00

По-моему, автор дал описание архитектуры "cyclic executive".
Которая обеспечивает жесткое РВ для выделенного круга задач.
Не понимаю, правда, причем тут ОС.
Т.е. неясно, зачем сохранять и восстанавливать контекст, если задачи и драйверы не вытесняют друг друга...
Противоречие какое-то.

st256, спасибо за леди (а то как уж тут только не обижала молодежь зеленая).
Вообще то, лучше Olej критику Вам никто и не скажет. Для того, чтобы заявлять "Я написал RTOS" нужно по минимуму хоть архитектуру операционных систем знать. Ответы в форуме - короткие по форме (доброжелательные по содержанию), не рецензию же Вам на статью писать. Умейте читать между строк, уточняйте, если кажется, что Вас не понимают. А разводить базар, как Вы говорите, на пустом месте - пользы для Вас точно не будет (желания беседовать/критиковать пропадет). Уж лучше тогда с Olej побеседовать на более захватывающие темы (место ОС в мире Embedded: когда есть необходимость в ОС, а когда нет; ОС - это не только (наверно и не столько) real time, сколько концепция ввода/вывода, модульность, многопроцессность и т.п.; какую дополнительную технологичность представляет ОС разработчику).
У Вас, повторюсь, проблемно-ориентированное ПО (под определенную задачу). Для того, чтобы понять эту задачу, Вам и задают вопросы.

Olej Иванович, не горячись. 256-ой известный корейский провокатор. Бывший с Самсунга . Но специалист он грамотный. Только зря он заговорил про RTOS. То что он описывает всегда называлось framework.

Попробую объяснить, что в DSP считают real-time, чтобы вернуть дискуссию в конструктивное русло.
Реальное ВРЕМЯ в отличии от физической абстракции как известно не однородно. Оно имеет абсолютное начало координат (настоящее) и однородную ось повёрнутую в прошлое. Будущего строго говоря не существует. Компьютеры используют для сбора информации её обработки и использования в корыстных целях. Информация представляется в виде функций. Если эти функции не зависят от времени - то нет никакого совсем смысла говорить про real-time. Но даже если они есть функции времени (т.е. представлены дискретными парами (value, time-stamp) то говорить о real-time в большинстве случаев, когда о нём говорят, нет смысла. Смысл говорить о жёстком реале есть только тогда когда для решаемой задачи значения меток времени time-stamp имеют абсолютное, но не относительное значение, т.е. начало координат нельзя сдвинуть по смыслу задачи. Вернее его можно сдвинуть только в пределах незначительных допустимых deadline обработки. Запаздывание обработки позже dead-line делает саму обработку бессмысленной, это программа лузер и её лучше было бы вообще никогда не запускать и не писать. Синхронность или асинхронность не является признаком real-time, признаком real-time является существование дэдлайнов в течении которого обработка должна быть выполнена. Поэтому система реального времени должна характеризоваться максимальными, а не средними временами отклика. Поэтому возможность вытеснения для таких задач действительно существенно ограничены.

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

Передача речи UDP-дэйтаграммами, конечно, уже есть задача реального времени. А передача файлов - наоборот нет.

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

Большинство если не все знаменитые коммерческие РТОС (WxWorks, pSOS) в действительности не гарантируют максимальное время реакции, обеспечивая только среднее (во всяком случае в масштабе мсек или даже десятков мсек), поэтому настоящие универсальные РТОС так не популярны в мире DSP. Хотя если говорить о таких гарантиях - то их может обеспечивать только программно-аппаратный комплекс, но никак не универсальная РТОС самостоятельно.

Сообщение отредактировал fontp - Feb 22 2006, 08:53

Представьте, что на время выполнения каждой задачи отводится фиксированный фрейм, а выполняется задача гораздо дольше. В следующем фрейме будет выполняться уже другая задача. Т.е. необходимо сохранить/восстановить, регистры и т.д.



Да фиг его знает, что это такое... Вроде - фрукты...




Не утруждайте себя. Я уже понял, что это тот самый реал-тайм и есть, собственной персоной...

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



Вот я о том же и говорил: "... почему и TCP/IP даже, при определённых условиях ...". Только не нужно так сужать к конкретностям: а что, если поток поступает не в UDP-дэйтаграммах, а через TCP-поток, или вообще совершенно другим протоколом ... или если это не передача речи, а поток радиолокационного скана - то от этого что-то меняется? И как только появляется асинхронный поток внешних событий - то же поступление блоков данных - и синхронным полингом round-robin, по крайней мере без развитого API примитивов взаимной синхронизации (что тоже всегда "вытеснение") N задач - не обойтись. А что касаемо "одноприоритетности"? ... то почти всегда и в исполняющей системе, допускающей множество приоритетов - можно реализовать и одноприоритетное построение (просто не использовать), и часто такие решения оказываются особенно "красивыми" (кстати, Дейкстра свои "взаимодействия последовательных процессов", откуда всё и пошло - всегда описывал в безприоритетной абстракции), но ... роль и разнообразие примитивов синхронизации и изощрённость (или тщательность?) их использования - намного возрастает. И такая реализация уже становится ближе к области "искусства", но и гарантия обеспечения deadline-ов в любых стечениях обстоятельств - относится на совесть "художника". А в том же Частотном Монотонном Анализе (одна из моделей, которые я упоминал), обязательным условием реализации которого является: "для каждой параллельной ветки - свой уровень приоритета, отличный от всех других" - гарантия обеспечивается (и доказывается!) строгой математической моделью.

Не, тут такое дело, я только с леди разговариваю. А если она не леди, то я с ней не общаюсь. Незачем.



Да уж...




Поэтому, я не заявляю, а тихо пишу. Прям щас. А архитектуры, которые я знаю (правда я мало их знаю), для DSP очень неудачные. Вы думаете, я сам такие вещи делаю от неимения, чем заняться? Увы, это не так... Просто, сравнительный анализ портов чужих RTOS приводит меня в депрессию. А работу надо сдавать в любом случае....

Хотя между собой, то, что я описал мы зовем scheduler (планировщик). RTOS это исключительно для яркости оперения.





Дык пока я перед всеми расшаркиваться буду, меня подпишут на бесплатное преподавание DSP. Я этим и так в двух ВУЗах занимаюсь... А так: сказал, что TCP/IP - реал тайм, и сразу свободен.



Я просто экономлю свое время. Зачем мне говорить про ввод/вывод, модульность и многопроцессность (и даже многопроцессорность), если про это я знаю (из-за специфики работы) и так совсем неплохо?

[quote name='fontp' date='Feb 22 2006, 17:47' post='89265']
Olej Иванович, не горячись. 256-ой известный корейский провокатор. Бывший с Самсунга . Но специалист он грамотный. Только зря он заговорил про RTOS. То что он описывает всегда называлось framework.
[/qoute]

Ув. г-н Фунт... т.е.Фонт... в смысле fontp!

Во-первых, я никогда не работал в Самсунге, т.е. Вы обманываете.
Во-вторых, то про что я заговорил framework-ом никак быть не может. Что это такое, рекомендую узнать в словаре, или на худой конец в ближайшем офисе Майкрософт, где Вы получите первичные сведения о MFC т.е. Вы обманываете вторично.
В-третьих... Т.к. Вы обманули дважды, то, сами понимаете, вероятность того, что Вы надули аудиторию, называя меня провокатором, очень высока. И тогда с Ваших слов получается, если провокатор один из нас, то это именно Вы.
В-четвертых. Ничего не имею против Вашего понимания Real-Time.

Сами Вы Фунт

А что такое Майкрософт? У нормальных людей scheduler есть часть framework.
Или теперь TI и AD называют ЭТО Real-Time Kernel (DSP/BIOS и VDK, соответственно).
Кстати на них отлично строится одноприоритетная система. Но они не имеют такой
наглости называть ЭТО RTOS

Сообщение отредактировал fontp - Feb 22 2006, 12:18

Что такое реал тайм? Вообще-то это очень просто. Пусть у Вас на проце одновременно работают МР3 и эквалайзер. Теперь представте, что кто-то перестроил эквалайзер. Т.е. была запущена (параллельно проигрыванию трека) задача пересчета коэффициентов. Так вот система Real-Time только тогда если Вы гарантируете, что звук НИКОГДА не будет прерываться (из-за загрузки проца пересчетом, это очень вероятно). Если гарантируете ( а не говорите, что этого не случится с вероятностью 90%) то сее - real-time. Не можете гарантировать? Ну тогда и TCP/IP можно назвать реалтайм... Только заказчики Вас, боюсь, поймут превратно. Примерно как я.
Кстати, забудьте про "развитый API примитивов взаимной синхронизации". Я ограничился только одним флагом (0 или 1). Все прекрасно работало.




Попробуйте это сделать в uCOS



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

Вы ошибаетесь. Жестоко. Могу только пожелать со временем понять это с минимальными последствиямми для Вашей собственной шкуры.

Нет, я - st256. Это у меня в паспорте записано. Техническом.



Не скажу. А Вы будете теперь мучиться любопытством. Причем в конвульсиях.



Значит Linux делали ненормальные люди. Я им передам Ваше мнение о них.




ДА НУ??? Про AD не знаю, но TI прямо-таки надрывается в своих буклетах, говоря о некой навороченной RTOS. Но Вы им не верьте. Такую гнусь как DSP/BIOS не то, что операционной, а просто системой назвать нельзя. У меня при ее упоминании повышается психомоторика, слюноотделение и уровень желчи в организме. Со мой так нильзя. Меня так испортить можно...