[st256 0]

Если время выполнения задачи ограничено (имеется в виду астрономическое время) то это Real Time. Например, подсчёт зарплаты в конце месяца :-))

 

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

Почти всегда, наряду с hard real time CPU должен выполнять какие-нибудь совершенно не Real Time функции. И для этих целей off the shelf OS весьма хороша.

 

Я не знаю, что такое off the shelf OS. Извините.

[Alex B._ 0]

>> Остается понять, что такое "реакция".

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

 

>> то для меня совершенно понятно, что к real-time Вы отношения не имели.

да нет, конечно, не имел.

 

>> Добавьте еще две недели на флаги, мьютексы, семафоры и API-функции

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

 

В чем вопрос-то, непонятно? При ваших условиях _без_прерываний_ никакая ОС вам не поможет. Должно быть хотя бы прерывание от таймера.

[st256 0]

>> то для меня совершенно понятно, что к real-time Вы отношения не имели.

да нет, конечно, не имел.

 

Тогда не перечьте тому, кто имел.

 

 

 

>> Добавьте еще две недели на флаги, мьютексы, семафоры и API-функции

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

 

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

 

В чем вопрос-то, непонятно?

 

Как я понял, вопросы у Вас (см. Вашу реплику про "анекдот"). У меня все работает без вопросов. Т.е. существуют стандартные документы из соответствующих контролирующих служб и желающие дать мне новую разработку с использованием real-time.

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

[zltigo 1]

Тогда не перечьте тому, кто имел.

Такая спокойная веточка была :-( Все спокойно выкладывали свои критерии перехода.

Дабы спокойно можно было почитать и подумать.

А тут, понимаешь, сезонное обострение и понеслись рассуждения на тему, которая находится за гранью понимания st256 :(. Кому интересно - смогут и без проблем найти Ваши предыдущие рассуждения на эту тему.

Может хватит?

[st256 0]

Тогда не перечьте тому, кто имел.

Такая спокойная веточка была :-( Все спокойно выкладывали свои критерии перехода.

Дабы спокойно можно было почитать и подумать.

А тут, понимаешь, сезонное обострение и понеслись рассуждения на тему, которая находится за гранью понимания st256 :(. Кому интересно - смогут и без проблем найти Ваши предыдущие рассуждения на эту тему.

Может хватит?

 

Г-н Прибалт, я уже знаю, что на любые разумные доводы Вы отвечаете сезонными обострениями. В этой веточке я лишь сказал следующее:

 

1. Когда я применяю RTOS.

2. То, что применяемые мной RTOS оставляют далеко позади все стандартные порты RTOS (типа майкроси, нуклеоса и т.д.) и что сие подтверждено теорией и практикой.

3. Что в RTOS не надо применять прерываний для обмена данных.

4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков. И в Вас, кстати, тоже.

 

У меня еще осталось 70% предупреждений и я хочу получить удовольствие на все, пиная недоучек вроде Вас. А потом зевая уйду на другой форум. Я уже нашел такой - там обитают грузины-националисты :)

[syv 0]

1. Когда я применяю RTOS.

2. То, что применяемые мной RTOS оставляют далеко позади все стандартные порты RTOS (типа майкроси, нуклеоса и т.д.) и что сие подтверждено теорией и практикой.

 

Я вот тоже не могу понять зачем нужна RTOS. До сих пор мне удавалось решать совместно ряд задач управления и коммуникаций в рамках одного МК без всяких RTOS. Изделия работают в условиях сильных электромагнитных полей в составе силового промышленного оборудования.

Зачем нужна RTOS PIC18Fxxx или AVR мне совершенно непонятно. Зачем разбираться в чужой лепнине, которая в общем случае неизвестно кем и как написана, если за то же или чуть большеее время можно просто решить поставленную задачу?

С другой стороны, я четко представляю зачем нужна хотя бы DOS для ПК.

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

 

3. Что в RTOS не надо применять прерываний для обмена данных.

 

Извините, но лично мне кажется, что прерывания это самый быстрый способ обработать, то или иное событие (появление нарастания/спада напряжения на входе, конец цикла АЦП, прием байта по USART и т. д.). До сих пор никогда не имел проблем с прерываниями при обмене данными.

Не могли бы Вы еще раз более развернуто объяснить на чем основан такой Ваш подход и отношение к прерываниям.

 

4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков.

 

Пока Вы окончательно не истратили свои 70%, поясните, пожалуйста, Ваше представление о грамотном разработчике. Интересно узнать, без всяких шуток.

[Artem-1.6E-19 0]

2. То, что применяемые мной RTOS оставляют далеко позади все стандартные порты RTOS (типа майкроси, нуклеоса и т.д.) и что сие подтверждено теорией и практикой.

3. Что в RTOS не надо применять прерываний для обмена данных.

4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков. И в Вас, кстати, тоже.

 

Камсамида¸ в натуре!

 

2. То, что применяемые мной RTOS оставляют далеко позади все стандартные порты RTOS (типа майкроси, нуклеоса и т.д.) и что сие подтверждено теорией и практикой.

3. Что в RTOS не надо применять прерываний для обмена данных.

4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков. И в Вас, кстати, тоже.

 

Камсамида¸ в натуре!

[Alex B._ 0]

2st256

дружище, да тебя всерьез уже никто не воспринимает, как ты не можеш понять? ты, баран, мне не смог на телесистемах ответить, где я смогу в России купить широко тобой рекламируемый, якобы тобой же разработанный проц.

О чем с тобой можно разговаривать, если кроме растопыренных пальцев ничего не видно?

тсссс. спокойно...

[Artem-1.6E-19 0]

2st256

дружище, да тебя всерьез уже никто не воспринимает, как ты не можеш понять? ты, баран, мне не смог на телесистемах ответить, где я смогу в России купить широко тобой рекламируемый, якобы тобой же разработанный проц.

О чем с тобой можно разговаривать, если кроме растопыренных пальцев ничего не видно?

тсссс. спокойно...

Наезд! Конкретный! :excl:

[zltigo 1]

Камсамида в натуре!

Чего-то я не понял.

감사합니다

Вы точно это имели ввиду? А по теме высказаться и не по-корейски?

[st256 0]

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

 

Угу. Именно это я и имею в виду.

 

3. Что в RTOS не надо применять прерываний для обмена данных.

 

Извините, но лично мне кажется, что прерывания это самый быстрый способ обработать, то или иное событие (появление нарастания/спада напряжения на входе, конец цикла АЦП, прием байта по USART и т. д.). До сих пор никогда не имел проблем с прерываниями при обмене данными.

Не могли бы Вы еще раз более развернуто объяснить на чем основан такой Ваш подход и отношение к прерываниям.

 

Сначала вводные: я никогда не работал с двигателями и прочим силовым оборудованием. Потому считаю для себя неправильным лезть на чужую территорию. Но могу объяснить свой тезис на базе того, с чем мне приходилось встречаться - аудиообработка.

 

Представьте, что у Вас следующая часто встречающаяся задача: на вход процессора подается сигнал с частотой дискретизации 44.1 кГц, а на выходе Вы имеете частоту дискретизации 48.0 кГц.

 

Очевидно, что в данном случае, будут наблюдаться "биения" прерываний, или попросту наложение этих прерываний друг на друга. При этом, надо учитывать, что если прерывания (как в моем случае) происходят достаточно часто, то время на обработку этих прерываний могут составлять до нескольких процентов от общего времени работы процессора.

 

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

 

К чему это приводит? А вот к чему: если у меня на одно прерывание от системного таймера уходило только 2% общего времени работы процессора, то уже для двух разных прерываний мне требовалось не 4%, а... 10%!

 

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

 

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

 

Это я привел случай для двух прерываний. Теперь я назову те прерывания, которые могут быть использованы в самой простенькой аудио системе:

 

1. Прерывание на ввод 2 каналов ( это если у Вас еще синхронный ввод по каналам возможен, что не всегда верно).

2. Вывод на 2 канала.

3. Два прерывания на управление стереоэквалайзером.

4. Командный канал (включить-выключить 3D звук, к примеру)

 

Не кисло? Тут пахнет далеко не 2%.

 

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

 

 

Возможно, я чего-то не учитываю или не знаю, но пародокс то в том, что в России практически НИКТО RTOSы не разрабатывает и спрашивать не у кого.

 

 

4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков.

 

Пока Вы окончательно не истратили свои 70%, поясните, пожалуйста, Ваше представление о грамотном разработчике. Интересно узнать, без всяких шуток.

 

 

Ну вот Вам пример: вчера листая Оппемгейма-Шафера нашел, как мне показалось, ошибку в описании дискретизированного сигнала. Так вот, профессионал это тот, с кем я могу аргументированно обсудить этот момент. Может я чего не понимаю, а может это стандартная некорректность, которых полно в радиотехнике, но для ее обсуждения требуются ДОВОДЫ. Профессионал может эти доводы порождать. Вам понятно?

 

2. То, что применяемые мной RTOS оставляют далеко позади все стандартные порты RTOS (типа майкроси, нуклеоса и т.д.) и что сие подтверждено теорией и практикой.

3. Что в RTOS не надо применять прерываний для обмена данных.

4. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков. И в Вас, кстати, тоже.

 

Камсамида¸ в натуре!

 

 

А что ты хочешь, Тёма? Я вот тебе всегда говорил, что голова у тебя хорошая, но учиться она не желает. Потому на аппарату со средней математикоемкостью ее хватит, а при необходимости более серьезной работы начнуться проблемы.

[st256 0]

2st256

дружище, да тебя всерьез уже никто не воспринимает, как ты не можеш понять?

 

Да ну??? Вы уверены?

 

 

ты, баран,

 

Нет, я совсем другой знак Зодиака - водолей. Т.е. я склонен к философствованию, научной работе и обретению контроля над умами широких народных масс...

 

Бараном с вероятностью 1/12 можете оказаться Вы. С той же вероятностью Вы являетесь казлом и свиньей.

 

 

мне не смог на телесистемах ответить, где я смогу в России купить широко тобой рекламируемый, якобы тобой же разработанный проц.

 

В России много чего нельзя купить. Допустим, я не могу купить TFT-дисплеи. Но это не значит, те, кто эти дисплеи использует - недостойные люди. Что же касается Вас то, я вроде предлагал бесплатно выслать экземпляры для макетирования и, если они всех устроят, то можно было поставить и промышленную партию. Но Вы куда-то исчезли - значит так Вам это было нужно.

[Artem-1.6E-19 0]

Камсамида в натуре!

Чего-то я не понял.

감사합니다

Вы точно это имели ввиду? А по теме высказаться и не по-корейски?

По теме, сильно помогает приличная и хорошо написанная ось, в случае

1. Необходимости кооперации, когда несколько человек для одного девайса пишут.

2. Сложный алгоритм работы, когда все эти семафоры, итд нужны.

3. Когда алгорим не сложный, но заказчик постоянно меняет условия, сегодня одно, завтра другое.

 

Это по теме. Ни о каких особых приемуществах BIOS по сравнению с UCOS я не знаю.

 

Возможно, я чего-то не учитываю или не знаю, но пародокс то в том, что в России практически НИКТО RTOSы не разрабатывает и спрашивать не у кого.

Разрабатывают. Но для себя в основном. Я работал с человеком, который наваял себе операционку, и работал с ней. Ну я часто без операционки обхожусь.

 

А что ты хочешь, Тёма? Я вот тебе всегда говорил, что голова у тебя хорошая, но учиться она не желает. Потому на аппарату со средней математикоемкостью ее хватит, а при необходимости более серьезной работы начнуться проблемы.

Я бы не сказал что у меня на прошлой работе была не серьезная математика. Да и не начинаются у меня проблемы. Проверял уже.

[st256 0]

Я бы не сказал что у меня на прошлой работе была не серьезная математика.

 

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

[Artem-1.6E-19 0]

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

Во первых, ты кое что перепутал. А во вторых, я тебе хоть с форточкой разрешаю работать.