[Kopa 0]

Что то изменилось, в понимании данного вопроса участниками дискуссии, по прошествию n-го времени и реалий текущего "бытия"?

 

P.S. Время самый "безжалостный" судья и палач.

Изменено 25 сентября, 2012 пользователем Kopa

[Hmm 0]

Kopa

Наконец до "всех дошло", что:

1. ООП - это тупиковое направление;

2. Все средства (ЯВУ, поддержка скриптов и т.п.) - для "ленивых";

3. Попытка стандартизовать методологию и средства реализации "изделия" служат для контроля работы ИТР и мерилом их средней квалификации/зарплаты.

Т.е. - всё это попытки обойти понимание предмета и лихо гнуть пальцы, вешая "начальству" терминологическую лапшу и прикрываясь поверхностной эрудицией.

Во всяком случае я вынес из прочтения топика похожее на это :)

Ну а ОС РВ мне ещё не была нужна, т.к. это доп-й источник проблем. Пусть их продолжают исп-ть в китайских телефонах, а я воздержусь. Удачи!

[Axel 1]

Kopa

Наконец до "всех дошло", что:

...в названии топика присутствует ошибка - не "Когда" а "Кому".

[_Pasha 0]

Наконец до "всех дошло", что:

Проблема не в "тупиковых направлениях" а в путях развития. Если мейнстрим развивается так, что использовать его не представляется возможным, приходится ваять своё и видеть страшных сон о том, что делать, если придешь к тому, что без оных средств - никак, и как справляться со сторонними программами, экспоненциальным ростом писанины, вниканием в "чуждые" причуды типа MISRA итд.

[Виктория 0]

Что то изменилось, в понимании данного вопроса участниками дискуссии, по прошествию n-го времени и реалий текущего "бытия"?

 

P.S. Время самый "безжалостный" судья и палач.

 

Для вновь прибывших, прочитайте весь топик, чтобы не возник "бесконечный цикл".

 

Для меня лично всплыл такой важный момент, над которым стоит размышлять при принятии решения ЗА и ПРОТИВ при выборе инструментария. Это вопрос валидации/верификации программного обеспечения, обсуждаемый в наше неспокойное время и метрологами (http://vniim.ru/annot-slaev.html, http://metrologu.ru/index.php?showtopic=6429) и научной общественностью.

 

Тема оказалась многогранной. Мне тоже было бы интересно мнение прежних участников.

 

 

 

[_Pasha 0]

Верификация ПО методом анализа исходников - это как раз то направление, в котором мифотворчество прекрасно себя чувствует :)

[Виктория 0]

Верификация ПО методом анализа исходников - это как раз то направление, в котором мифотворчество прекрасно себя чувствует :)

Не ехидничайте, Паша. Метрологи как и психиатры - шутки не любят.

 

Тема оказалась многогранной. Мне тоже было бы интересно мнение прежних участников.

 

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

Olej вроде мелькал...

[_Pasha 0]

Не ехидничайте, Паша. Метрологи как и психиатры - шутки не любят.

Да какие уж шутки: законодательно обязать всех использовать MISRA образца 2004года - и будет не до шуток. В нашей глобальной палате номер 6 такое возможно. И что самое главное: MISRA - это самые известные из правил, которые не помогают избежать ошибок. :) Т.е. результата не будет, зато статистика/отчетность - будет на высоте. :)

PS выросло огромное кол-во людей, у которых реакция на "bare-metal" примерно такая же, как у налогового инспектора на слово "недоимка" :)

Изменено 26 сентября, 2012 пользователем _Pasha

[juvf 17]

1. ООП - это тупиковое направление;

вообще странно подобные заявления слышать. наверно они делаются ради троля. тут где-то был спор по поводу с++ на мк. Почему-то сразу пошел срач про ООП, люди почему-то считают что с++, ООП, СТЛ, шаблоны, паттерны и т.п. - это всё одно и тоже, синонимы. Конечно в с++ есть over9000 способов выстрелить себе в ногу, но это не значит что ооп не оправдан. Где-то ООП даёт ++, а где-то его бездумно используют создавая оверинженеринг. Надо уметь его готовить и использовать.

 

2. Все средства (ЯВУ, поддержка скриптов и т.п.) - для "ленивых";

"Лень - двигатель прогресса"

"Хороший программист - ленивый программист"

 

Ну а ОС РВ мне ещё не была нужна, т.к. это доп-й источник проблем.

Каких проблем? Писать свой говновайл(1) планировщик - вот это проблема. Две оси использую - никаких проблем. Как может человек обсуждать вкус свинины, не разу не попробовав её. Или может он просто не умеет её готовить?

 

[_Pasha 0]

Две оси использую - никаких проблем. Как может человек обсуждать вкус свинины, не разу не попробовав её. Или может он просто не умеет её готовить?

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

[juvf 17]

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

ээээ..... ну например некий пульт:

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

 

и что с этого списка? конечно это всё прекрасно без оси будет работать. через свой for(;;). Но ос позволяет раздробить весь проект, выделить из него узкую задачу, например контроль модбус, и сфокусировавшись на этой задаче написать её раз и забыть про неё. Написав одну задачу по обслуживанию модбуса, запускаю два экземпляра этой задачи.

Но, приходилось мне чужие тяжелые проекты поддерживать, расширять функционал. Писали фатаны :\m/: . Сишные "Атцы", презирающие с++ и ооп. Ну и? шаг вправо шаг в лево - траблы. Выявляются баги в ихнех самописных вечновайловых планировщиках. Есть и ОС индусами писанные, там тоже можно подчерпнуть немало траблов, но допустим µC/OS там уж всё вычещенно. ММдддаааа платная и дорогая. Чем FreeRTOS не вариант? всем миром тестится на всех платформах и во всех режимах. Я пока в этих осях багов не нашол. Да и на форуме по FreeRTOS скука.... о че там тусить, если проблем с ней нет? (хотя мож ни кто не пользует?)

 

ps правильно где-то было сказано что после освоения ртос вы уже не захотите while(1) писать. И действительно..... понадобилось для простенького девайса на атмеге169 написать прогу - ткнул туда ос, а она возьми да влезь... да ещё и работает, и имею все прелести вытесняющей многозадачности и разделения ресурсов. что в этом плохова?

 

Конечно есть бюджетные проекты и задачи там простые, однозадачные скажем, там и проц ставят 8-ног 1 кб пзу. там тока с++ или вообще асм без всяких ос. но если чуть посложнее.... и бюджет позволяет..... таже атмега128 - там не плохо уживётся ртос, ну а если вместо меги за теже деньги заложить стм32 - так там вообще ос без проблем. Если при разработке, понимаешь что с ос на заложенном камне будет тесно.... ну заложи проц чуть подороже. Щас благо дело маленькое удорожание проца дает несоизмеримобольшое увеличение вычеслительных ресурсов.

 

Я не кого не собираюсь вербовать в ртосоводов и оопэшников. Каждый сам делает выбор для себя. Но заявления типа

1. ООП - это тупиковое направление;

...

...ОС РВ ... это доп-й источник проблем.

мне не понятны :laughing:

[_Pasha 0]

ээээ..... ну например некий пульт:

Хех! Вот-тоже самое, но вместо gui - "на закуску" GSM-модем, два лога и файловая система . У меня два дня голова пухла, когда весь функционал тупо не влезал с фриртосью из-за большого "сцепления" по данным.

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

Как только переделал под прототреды с глобальной "бордой" данных - всё сразу стало на свои места. И стека хватает :) И не нужно обращать томный взор на более старший камешек.

 

И я тоже не понимаю, что такое планировщик вида while(1), зато хорошо понимаю атмосферу, в которой подобные "читки для приезжих" рождаются.

 

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

Изменено 27 сентября, 2012 пользователем _Pasha

[juvf 17]

Как только переделал под прототреды с глобальной "бордой" данных - всё сразу стало на свои места.

Ну.... я же говорю - каждый делает выбор для себя.

 

 

что такое планировщик вида while(1)

вечный вайл

 

int main()
{
init();
while(1)
{
//какойто полезный код...... по сути аналог планировщика задач в ОС
}
}

[ViKo 1]

Пробовал Keil RTX в качестве развлечений-упражнений. Понравилось. Теперь в реальном проекте буду использовать. Смысл вижу в том, что на кнопки изделие будет реагировать с незаметной для пользователя задержкой, не дожидаясь окончания обработки чего-то там...

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

[_Pasha 0]

вечный вайл

Есть предложение обходиться без тривиальностей, тем более, когда while(1) хоть один раз да присутствует.

Ага, вот она, ссылка полугодичной давности - Who-wins-when-Cortex-M-adds-RTOS-abstraction-layer

An RTOS abstraction layer will, by its very nature, not add to the RTOS functionality, but will make the code bigger and the execution slower. The RTOS abstraction layer will always be a prime candidate for removal.

 

Я нахожу в этой цитате логическое продолжение тому, о чем тут говорится.

Т.е. невозможность стричь всё под одну гребёнку. Любая абстракция без изменения инструментария(языка программирования) - сталкивается с подобной проблемой: Bigger Code, Slower Time, Worse Things! - предлагаю слоган :) В пику филипсовскому "Let's make things better!"

 

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

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

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

2. Изоляция процессов - это как раз второй смысл РТОС.

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

Изменено 27 сентября, 2012 пользователем _Pasha