[akivas 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. Что говорить об этом на этом форуме бесполезно, ибо не вижу я тут грамотных разработчиков. И в Вас, кстати, тоже.

 

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

 

 

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

 

1)Ага. Простенькую аудио систему (так как она описана выше) действительно можно построить без операционной системы - этакий loop ввод-обработка-вывод. Опрос (polling) в RISC процессорах чаще всего гораздо эффективнее чем прерывание. Только вот ... есть ещё и командный канал. Если он - RS-232 или I2C, то можно обойтись без мультизадачности, но если кому-нибудь вздумается управлять такой системой с помощью TCP/IP, то тут услуги готовой ОС (покупной, freeware) весьма кстати.

 

2) "в России практически НИКТО RTOSы не разрабатывает и спрашивать не у кого" . Может быть. Но за пределами России разрабатывают. IMHO Можно найти кого спросить...

[syv 0]

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

 

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

 

 

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

 

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

 

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

 

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

 

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

Опять же глупые вопросы.

Процессор обязательно должен быть столь сложным или имеется возможность применить девайс попроще?

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

 

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

 

А чем плохи прерывания от аппаратных таймеров? Происходят всегда в одно и то же время +- несколько командных циклов.

 

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

 

Так, беда в том, что на свете вообще мало народа, разбирающегося до тонкостей в описании дискретизированного сигнала Оппемгеймом-Шафером. Откуда взяться ДОВОДАМ в этом конкретном случае? Но, ИМХО, это не критерий профессионализма.

 

В связи с этим пример из жизни. Довелось наблюдать лично...

Сварочный аппарат на основе инвертора. Занимается этим делом два индивидуума одновременно.

 

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

 

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

 

Оба укладываются приблизительно в одинаковые сроки, однако у первого индивидуума из десятка проданных аппаратов взрываются все 10 в течение 3 месяцев, а ко второму к этому сроку выстраивается очередь, потому как все его 10 аппаратов работают, при этом обладают достаточно хорошими характеристиками.

 

Однако, первый индивидуум может квалифицированно поговорить о краевых условиях при решении полевых задач, прекрасно представляет себе операторное счисление и при этом виртуозно владеет рядом профессиональных пакетов для ПК, включая IAR для ARMов.

Второй за это время с трудом овладевает PCADом 2002, получает патент на способ намотки силового трансформатора и остается девственно чист по отношению к высшей математике как таковой, поскольку высшее образование у него отсутствует напрочь.

Так вот вопрос. Кого можно считать профессионалом, а кого нет?

[Artem-1.6E-19 0]

Однако, первый индивидуум может квалифицированно поговорить о краевых условиях при решении полевых задач, прекрасно представляет себе операторное счисление и при этом виртуозно владеет рядом профессиональных пакетов для ПК, включая IAR для ARMов.

Второй за это время с трудом овладевает PCADом 2002, получает патент на способ намотки силового трансформатора и остается девственно чист по отношению к высшей математике как таковой, поскольку высшее образование у него отсутствует напрочь.

Так вот вопрос. Кого можно считать профессионалом, а кого нет?

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

[syv 0]

Истина, как водится, где-то посредине.

Согласен.

Но вопрос задан конкретно. Кто профессионал?

Варианты ответов: 1 и 2.

 

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

Переходного этапа я не видел.

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

 

Многие, увы путают причину и следствие. Моделирование это следствие. А эксперимент причина.

 

На мой взгляд тут дело в подходах, а не в причинно-следственных связях.

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

 

То же самое касается и RTOS. Если человек пишет программу для некоторого девайса на МК, т. е. идет сверху вниз, то RTOS ему остро необходима. А вот если человек делает девайс в целом, т. е. идет снизу вверх, то в этом случае создание софта обойдется без RTOS.

Путь сверху вниз проще, поскольку исключает гаражный этап и в случае неответственных устройств типа "глючащего" сотового телефона однозначно приводит к получению денег в сжатые сроки.

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

[Artem-1.6E-19 0]

Истина, как водится, где-то посредине.

Согласен.

Но вопрос задан конкретно. Кто профессионал?

Варианты ответов: 1 и 2.

Тот у кого работает, тот и профессионал. У того у кого не работает называется банкрот.

 

Переходного этапа я не видел.

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

переходный период завершился. Я когда занимался SMPS, так всегда знал, когда у меня транзистор может сгореть а когда нет. (IGBT сборка 50 баксов). Но это с очень большим радиолюбительским опытом. Правда я не на помойку их выкидывал, а на провод нанизывал и на окно вешал. :)

На мой взгляд тут дело в подходах, а не в причинно-следственных связях.

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

Плюс еще ИМХО привычка, которая идет от винды, не вникать в проблему а старься найти "особую", "умную" программу, которая ему решение подскажет.

То же самое касается и RTOS. Если человек пишет программу для некоторого девайса на МК, т. е. идет сверху вниз, то RTOS ему остро необходима. А вот если человек делает девайс в целом, т. е. идет снизу вверх, то в этом случае создание софта обойдется без RTOS.

Бред. Иногда она полезна, иногда нет. Если делать что-то БОЛЬШОЕ, то вероятность что она будет полезна повышается.

Путь сверху вниз проще, поскольку исключает гаражный этап и в случае неответственных устройств типа "глючащего" сотового телефона однозначно приводит к получению денег в сжатые сроки.

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

Тут я вашу мысль не понял. Я сейчас железяку делаю. Первый этап - запуск того, в чем я не до конца уверен. Второй - проверка на глючность. Если эти не пойдут, то и дальше идти смысла нет. Хотя, вот к примеру корейский подход - это начать с самого простого, а потом искать всяких профессоров, которые им будут помогать, за безумные деньги AFAIK.

[path_finder 0]

Все критерии уже давно продуманы и сказаны:

например здесь хороший размышлизм

http://www.ganssle.com/articles/artos.htm

(обратите внимание на дату)

или вот здесь:

http://linuxdevices.com/articles/AT9560688601.html

или вот:

Любой такой продукт дешевле купить, чем создавать заново. Даже при цене 100 000

долларов купленный продукт стоит примерно столько, сколько годовое содержание

программиста. И поставка немедленная! Немедленная, по крайней мере, для реально

существующих продуктов, проспект которых разработчик может послать счастливому

пользователю. Более того, такие продукты обычно гораздо лучше документированы

и несколько лучше сопровождаются, чем доморощенные программы.

 

Мифический человеко--месяц

ииллии ккаакк ссооззддааютссяя ппррооггррааммммнныыее ссиисстееммыы

Фредерик БРУКС

стр. 110

[syv 0]

[Бред. Иногда она полезна, иногда нет. Если делать что-то БОЛЬШОЕ, то вероятность что она будет полезна повышается.

 

Почему это бред? Что такого БОЛЬШОГО Вы собрались делать?

Никогда не испытывал доверия к БОЛЬШИМ устройствам. На мой взгляд они вторичны и, как правило, в подавляющем большинстве случаев просто не нужны. Практически всегда можно найти простой выход. Редкие исключения в виде PLC, частотных инверторов лишь подтверждают этот тезис. Да и в этих случаях у девайсов имеется богатая история по которой можно отследить путь, по которому шли люди их создававшие. И мне кажется, что RTOS в данном случае дело не десятое, а тысячное.

 

 

Тут я вашу мысль не понял. Я сейчас железяку делаю. Первый этап - запуск того, в чем я не до конца уверен. Второй - проверка на глючность. Если эти не пойдут, то и дальше идти смысла нет. Хотя, вот к примеру корейский подход - это начать с самого простого, а потом искать всяких профессоров, которые им будут помогать, за безумные деньги AFAIK.

 

Да мысль проста и тривиальна. То, что хорошо для софта сотового телефона, абсолютно не подходит для баллистической ракеты.

По поводу Вашей железяки. С первым этапом все понятно. А вот второй вызывает сомнения. Лично мне кажется, что абсолютной уверенности Вы не получите. Так, что можно не делать и первого этапа. Смысла нет изначально.

На эту тему история из жизни.

Человек занимается моделированием термодинамических процессов в очень ответственном устройстве. Работа ведется много лет и регулярно поведение модели сравнивается с поведением этого ответственного устройства в реальности. В последнее время расхождений между моделью и реальным девайсом практически не обнаруживается. Сама модель применяется в настоящее время в виде учебного пособия для обслуживающего сей девайс персонала.

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

 

С корейским подходом не знаком. Но лично я берусь только за то, что на 100% могу сделать сам, не прибегая к посторонней помощи. И только с помощью лично проверенных методов. Дядин софт априори считается ненадежным, в том числе и RTOS.

[Artem-1.6E-19 0]

Любой такой продукт дешевле купить, чем создавать заново. Даже при цене 100 000

долларов купленный продукт стоит примерно столько, сколько годовое содержание

Это значит только то, что программиста нужно содержать в Индии.

Более того, такие продукты обычно гораздо лучше документированы

и несколько лучше сопровождаются, чем доморощенные программы.

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

 

 

Почему это бред? Что такого БОЛЬШОГО Вы собрались делать?

Ну, к примеру осцилограф. Типа тетроникса.

Никогда не испытывал доверия к БОЛЬШИМ устройствам. На мой взгляд они вторичны и, как правило, в подавляющем большинстве случаев просто не нужны. Практически всегда можно найти простой выход. Редкие исключения в виде PLC, частотных инверторов лишь подтверждают этот тезис.

Сложность програмной части частотного инвертора, ИМХО сильно привеличина. По поводу ПЛС, могу сказать что там в основном очено тупая, хотя и трудоемкая программа.

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

Да.

Да мысль проста и тривиальна. То, что хорошо для софта сотового телефона, абсолютно не подходит для баллистической ракеты.

Так прямо категорично?

По поводу Вашей железяки. С первым этапом все понятно. А вот второй вызывает сомнения. Лично мне кажется, что абсолютной уверенности Вы не получите. Так, что можно не делать и первого этапа. Смысла нет изначально.

На эту тему история из жизни.

Человек занимается моделированием термодинамических процессов в очень ответственном устройстве. Работа ведется много лет и регулярно поведение модели сравнивается с поведением этого ответственного устройства в реальности. В последнее время расхождений между моделью и реальным девайсом практически не обнаруживается. Сама модель применяется в настоящее время в виде учебного пособия для обслуживающего сей девайс персонала.

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

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

Дядин софт априори считается ненадежным, в том числе и RTOS.

А если есть исходники? И эти исходники ОЧЕНЬ не плохо написаны? Я к пимеру очень многому научился с мюкосом.

[syv 0]

Ну, к примеру осцилограф. Типа тетроникса.

 

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

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

 

Сложность програмной части частотного инвертора, ИМХО сильно привеличина.

 

Ну а сервопривод?

 

Да мысль проста и тривиальна. То, что хорошо для софта сотового телефона, абсолютно не подходит для баллистической ракеты.

Так прямо категорично?

 

А как должно быть по Вашему? Телефон имеет полное право глючить, что он время от времени и делает, а ракета нет.

 

Про человека с ответственным девайсом. А какая разница, чем мотивируется поступок? Результат ведь тот же - модель отдельно, ответственный девайс отдельно. Потому как страшно по-любому.

 

 

Дядин софт априори считается ненадежным, в том числе и RTOS.

А если есть исходники? И эти исходники ОЧЕНЬ не плохо написаны? Я к пимеру очень многому научился с мюкосом.

Тут я с Вами соглашусь. Учиться на чужом хорошем софте, как впрочем и на схемотехнике - дело полезное.

Но я то имел ввиду совершенно бездумное использование RTOS, так как мы все привыкли делать это в Винде и к чему призывают здесь некоторые.

Сказали бы честно, что мол прежде, чем использовать ОС ее надо приготовить, съесть и выс...ть хотя бы один раз. Я тогда и не выступал бы вовсе.

[Artem-1.6E-19 0]

Ну, к примеру осцилограф. Типа тетроникса.

 

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

RTOS не всегда приводит к ускорению. Насчет ответсвенности, то если он будет глючить, то фирма обонкретится.

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

На рынке нет приличного осцилографа за несколько сот долларов. Для стран "золотого миллиарда" несколько тыс. на такое вот "хобби" не дорого. Для нас часто неподъемно. (я спектрумы и усилители делал без осцилографа. )

Сложность програмной части частотного инвертора, ИМХО сильно привеличина.

 

Ну а сервопривод?

Чего? Крышки унитаза или стержней в ядерном реакторе?

Если первое, то безопасность достигается ограничением мощьности двигателя. Если во втором случае, то RTOS (и компютеров) там скорее всего вообще нет. Тоесть любой глюк не приведет к катастрофе.

А как должно быть по Вашему? Телефон имеет полное право глючить, что он время от времени и делает, а ракета нет.

Почему? Вы - Бог? Вы не можете сделать безглючный агрегат? Если можете, то как вы докажете что он безглючен?

Про человека с ответственным девайсом. А какая разница, чем мотивируется поступок? Результат ведь тот же - модель отдельно, ответственный девайс отдельно. Потому как страшно по-любому.

Вы о чем? Модель обычно используется для отладки девайса.

 

Тут я с Вами соглашусь. Учиться на чужом хорошем софте, как впрочем и на схемотехнике - дело полезное.

Но я то имел ввиду совершенно бездумное использование RTOS, так как мы все привыкли делать это в Винде и к чему призывают здесь некоторые.

Чтобы использовать, что-то нужно и понимать как оно работает. В проинципе RTOS - фикция. Абстракция.

Сказали бы честно, что мол прежде, чем использовать ОС ее надо приготовить, съесть и выс...ть хотя бы один раз. Я тогда и не выступал бы вовсе.

Вы uCOS видели?

[syv 0]

На рынке нет приличного осцилографа за несколько сот долларов. Для стран "золотого миллиарда" несколько тыс. на такое вот "хобби" не дорого. Для нас часто неподъемно. (я спектрумы и усилители делал без осцилографа. )

И что? Думаете, будут брать?

 

А как должно быть по Вашему? Телефон имеет полное право глючить, что он время от времени и делает, а ракета нет.

Почему? Вы - Бог? Вы не можете сделать безглючный агрегат? Если можете, то как вы докажете что он безглючен?

 

Но не глючат ведь. Стоят себе в своих пусковых шахтах и не взрываются, на команды отвечают. Уже много лет... Вот и все доказательство.

Еще один способ - выпуск большой партии агрегатов и их продажа большому числу клиентов. Если возвратов нет и все клиенты живы и здоровы, значит не глючит.

 

 

Про человека с ответственным девайсом. А какая разница, чем мотивируется поступок? Результат ведь тот же - модель отдельно, ответственный девайс отдельно. Потому как страшно по-любому.

Вы о чем? Модель обычно используется для отладки девайса.

 

А как же многоконтурные регуляторы с наблюдателями? Не всегда модель используется только для отладки, нередко и для обеспечения функционирования. Сам не проверял, но пишут, что регуляторы с наблюдателями обеспечивают наилучшее качество регулирования.

 

Чтобы использовать, что-то нужно и понимать как оно работает. В проинципе RTOS - фикция. Абстракция.

С первым предложением согласен. А вот второе не понял. В чем Вы видите "абстрактность" и "фиктивность " RTOS?

 

Сказали бы честно, что мол прежде, чем использовать ОС ее надо приготовить, съесть и выс...ть хотя бы один раз. Я тогда и не выступал бы вовсе.

Вы uCOS видели?

Нет не видел в силу ряда причин. Но пойду гляну.

[st256 0]

1)Ага. Простенькую аудио систему (так как она описана выше) действительно можно построить без операционной системы - этакий loop ввод-обработка-вывод. Опрос (polling) в RISC процессорах чаще всего гораздо эффективнее чем прерывание. Только вот ... есть ещё и командный канал. Если он - RS-232 или I2C, то можно обойтись без мультизадачности, но если кому-нибудь вздумается управлять такой системой с помощью TCP/IP, то тут услуги готовой ОС (покупной, freeware) весьма кстати.

 

TCP/IP это не real-time. А оси для него не нужно. Нужно только приблуду из этой оси, которая драйвером называется и ее можно утянуть в комплекте с более-менее известной ОС. Потому мы для сих делов Linux используем. Именно из-за дармового софта, а вовсе не из-за его крутости или нужности.

 

Ну таких простеньких аудиосистем я никогда не реализовывал. Обычно полная и совершенно конкретная мультизадачность, причем с задачами не только тобой писаными. И задач таких в одном процессоре может крутиться до десятка. Возмите Ваш сотовый - это и есть "простенькая аудиосистема" - всякие mp3, midi и т.д.

 

2) "в России практически НИКТО RTOSы не разрабатывает и спрашивать не у кого" . Может быть. Но за пределами России разрабатывают. IMHO Можно найти кого спросить...

 

Ну в Ницце, наверное, делают RTOS, а еще где?

[st256 0]

Допустимы ли локальные колебания периодов входной и выходной частот? Если да, то какими они должны быть?

 

Допустимы. Например, Вы слушаете по сотовому mp3 файл и в этот момент поступает звонок - т.е. midi-поток накладывается на mp3.

 

Процессор обязательно должен быть столь сложным или имеется возможность применить девайс попроще?

 

DSP это не процессоры в полном смысле этого слова. Это скорее контроллеры. Т.е. они очень просты и дешевы от 2 до 5 долларов.

 

 

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

 

Грубо говоря, для конкретного DSP круг решаемых задач уже очерчен разработчиками. Смотришь на рекламку чипа, и там говориться - способен потянуть несколько вокодеров. Делаешь выводы.

 

 

А чем плохи прерывания от аппаратных таймеров? Происходят всегда в одно и то же время +- несколько командных циклов.

 

А я только одно прерывание от таймера и испульзую. Для создания системных тиков. Как я уже говорил, ОДНО прерывание - не страшно. Страшно когда их много и они накладываются.

 

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

 

Так, беда в том, что на свете вообще мало народа, разбирающегося до тонкостей в описании дискретизированного сигнала Оппемгеймом-Шафером. Откуда взяться ДОВОДАМ в этом конкретном случае? Но, ИМХО, это не критерий профессионализма.

 

 

Таких конкретных примеров слишком много. Вот недавно было: у человека с ЦАП сигнал глуховатый шел. Все вроде правильно, а звук глухой. Оказалось не разобрался мужик в тонкостях дискретизированного сигнала и не ввел предискажения. И таких примеров когда из-за не знания "тонкостей" у людей ничего и подолгу не работает - тьма.

 

 

В связи с этим пример из жизни. Довелось наблюдать лично...

Сварочный аппарат на основе инвертора. Занимается этим делом два индивидуума одновременно.

 

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

 

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

 

Оба укладываются приблизительно в одинаковые сроки, однако у первого индивидуума из десятка проданных аппаратов взрываются все 10 в течение 3 месяцев, а ко второму к этому сроку выстраивается очередь, потому как все его 10 аппаратов работают, при этом обладают достаточно хорошими характеристиками.

 

Однако, первый индивидуум может квалифицированно поговорить о краевых условиях при решении полевых задач, прекрасно представляет себе операторное счисление и при этом виртуозно владеет рядом профессиональных пакетов для ПК, включая IAR для ARMов.

Второй за это время с трудом овладевает PCADом 2002, получает патент на способ намотки силового трансформатора и остается девственно чист по отношению к высшей математике как таковой, поскольку высшее образование у него отсутствует напрочь.

Так вот вопрос. Кого можно считать профессионалом, а кого нет?

 

Знаете, силовые агрегаты и DSP вещи разные. Не хуже, не лучше, а просто разные.

У меня такой пример. Как-то я управлял самолетом. Знаете, а ведь управлять им гораздо проще, чем автомобилем - нет необходимости быть постоянно наготове притормозить или объехать. Не надо смотреть в зеркало заднего вида, переключать пердачи, жать на тормоз. Лети и все дела.

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

 

Так и у Вас: где все определяет практика, а где-то в, основном, как у меня - теория.

[Artem-1.6E-19 0]

Но не глючат ведь. Стоят себе в своих пусковых шахтах и не взрываются, на команды отвечают. Уже много лет... Вот и все доказательство.

Потому что, никто ничего сложнее топора, в цепи отвечающие за запуск ракеты не поставит. Это просто не надежно.

Еще один способ - выпуск большой партии агрегатов и их продажа большому числу клиентов. Если возвратов нет и все клиенты живы и здоровы, значит не глючит.

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

 

А как же многоконтурные регуляторы с наблюдателями? Не всегда модель используется только для отладки, нередко и для обеспечения функционирования. Сам не проверял, но пишут, что регуляторы с наблюдателями обеспечивают наилучшее качество регулирования.

Используются.

 

С первым предложением согласен. А вот второе не понял. В чем Вы видите "абстрактность" и "фиктивность " RTOS?

В том, что РТОС это просто название. Если я что-то такое напишу, но не назову это РТОС, то это будет РТОС или нет?

Вы uCOS видели?

Нет не видел в силу ряда причин. Но пойду гляну.

Обязательно посмотрите.

[Сергей Борщ 143]

Истина, как водится, где-то посредине.

Согласен.

Но вопрос задан конкретно. Кто профессионал?

Варианты ответов: 1 и 2.

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