Лидеры

Не все йогурты варнинги одинаково полезны :) У Вас используется аппаратный блок, с его портами ввода-вывода. Может так оказаться, что не все эти порты требуются в Вашем проекте. Вы их не используете (ну, например, не нужен Вам выход lock). Среда разработки честно предупреждает, что такие-то и сякие входные порты аппаратного блока не имеют драйвера, а выходные - ничем не управляют. Вы анализируете эти предупреждения, и поверяете - или у Вас все так и задумано, или Вы что-то забыли подключить к PLL. Ну и если все так и задумано, то оставляете эти варнинги как есть. То есть, другими словами: принять предупреждения к сведению - это не то же самое, что игнорировать предупреждения. Полностью избавляться от варнингов - не самоцель, ИМХО...

Конечно -- некомпетентность руководства в вопросах управления ко всему этому и приводит. В первую очередь -- к внедрению скрама. Потому как если бы руководство было управленчески состоятельно, оно бы выстроило эффективную иерархию управления, найдя, отобрав, поставив на ключевые позиции правильных людей, которые отрабатывают задачи на своём уровне иерархии так, как надо. Поскольку оно этого не смогло, а понимание, что как-то управлять надо, то тут привлекательно выглядит готовая методология. И скрам тут представлен лучше и ярче всех остальных -- реклама, продвижение: на этом немало народу кормится. Скрам-мастера. Это зачем они вообще нужны? Это люди, которые не обязаны быть специалистами в целевой тематике разработки, их задача -- организовывать процесс: проводить дейлики, планирования, ретры. Т.е. это по сути секретарь-стенографист на заседаниях. Дейлики. Зачем они нужны? Зачем обязательно собираться каждый день? Собираться надо по делу -- on demand. Надо если, то хоть три раза за день можно собраться, а не надо, так и неделями можно этим не страдать. Какие-то локальные вопросы люди, работающие совместно над задачей, решают оперативно сами на своём уровне, не отвлекая остальных. Более глобальные вопросы курирует руководитель работы, и если надо, собирает людей -- не всех, а только тех, кто нужен с его точки зрения -- на совещание/планёрку. Когда люди собираются по делу -- для решения возникшего вопроса, это собрание полезное и живое. А когда они собираются, потому что так положено по распорядку -- ну, скрам требует проводить ежедневное собрание (дейлик) -- то это превращается в профанацию, потерю времени и снижение мотивации. Продукт овнер. Он кто? Руководитель работы? Нет! Это типа заказчик или внутренний представитель заказчика. Он озвучивает (ставит) задачи -- в бэклог, а команда выбирает из бэклога те, что считает нужными делать в первую очередь. Команда решает! Да, команда, конечно, лучше знает, что надо делать в первую очередь. Вот прикольно было бы посмотреть, если на корабле команда бы решала, куда плыть, а не капитан. При этом продукт овнер -- не командир над командой (как заказчик не командир над разработчиками), поэтому прямого непосредственного влияния он не имеет. Он не может поручить конкретному человеку делать то или иное, он не может снять исполнителя с задачи и поручить её другому. Это понижает и без того ущербную управляемость. Все эти проблемы решены при правильно выстроенной иерархии управления. Скрам-мастера Секретари там не нужны. Митинги проводятся по необходимости и целевым образом. Вместо продукт овнера там руководитель (группы, работы и т.п.), который персонально отвечает перед вышестоящими уровнями иерархии за результат и облечён властью (т.е. реализуемой на практике способностью управлять) на своём уровне. Он организовывает рабочий процесс, следит за ходом его выполнения, оперативно реагирует на вводные. Всё это даёт реальную эффективность, а не мнимую, как в случае скрама. Потому что у ошибок и успехов есть имя, фамилия и отчество, сиречь, настоящая персональная ответственность, а не мнимая коллективная. И дело не в SCRUM vs Waterfall, а в грамотно выстроенной иерархии управления! Такая иерархия зарулит любой скрам по эффективности на раз. Главная проблема с ней состоит в том, что выстроить её сложно: это требует от управленца ума, опыта (жизненного и управленческого), множества хороших человеческих качеств (таких как настоящая (а не показная) уважительность к людям, мудрость, доброта, строгость-требовательность, дальновидность и справедливость) и умение разбираться в людях. Это редкие умения и это дано далеко не каждому. Такой человек -- это куда более ценный кадр, чем даже очень квалифицированный специалист в предметной области. К сожалению, большинство менеджеров не таковы. И из них ещё изрядный процент тщеславных мудаков, для которых на первом месте стоят личная слава и доходы, а не интересы дела. Такие "управленцы" (а их много -- они активно лезут наверх, к власти, которая для них кормушка и "тёплое место") в принципе не способны эффективно работать в иерархии управления, т.к. они будут решать в первую очередь свои личные карьерные задачи, а не отдаваться интересам дела. Выстраивать иерархию управления должен самый главный босс в организации -- это его прямая и нативная обязанность. От неё зависит вообще всё. Если он этого не может, то и этой системы управления тоже нет. Но управлять-то как-то надо. Вот и хватаются за готовые методологии. Но вместо реального управления там иллюзия оного. В мире софта это как-то едет, т.к. там процессы такие, что многие ошибки сглаживаются (и качество результата оценить сложно (например, если штукатур плохо сделал работу, это сразу видно по кривой стене, но по софту этого сразу не увидишь -- это надо поработать с ним, а т.к. его постоянно правят, то не понятно, какое его состояние надо оценивать), и исправлять ошибки дёшево -- почти бесплатно в том смысле, что не требуется ни затрат материалов, ни значительных временнЫх затрат, нет проблем с логистикой (отзывать бракованную продукцию и заменять её на исправленную) и т.п. В заключение можно отметить, что история знает немало примеров эффективного управления сложными проектами задолго до появления скрамов. Авиация, судостроение, космос, атомная отрасль. И на Западе, и в СССР. И качество процесса определялось исключительно компетентностью кадров. Так было, так есть и сейчас. И так будет и дальше, ибо природа человека не меняется.

А принятые к сведению засапрессить, чтобы не загромождали вывод и не маскировали другие сообщения (предупреждения). Когда в выхлопе болтается три сотни предупреждений, которые просмотрены и приняты к сведению, увидеть новое, возможно, важное, может оказаться затруднительно. Хорошо, если инструмент позволяет это делать. Иначе приходится самостоятельно наворачивать постпроцессинг лога.

В даташитах на некоторые конденсаторы иногда встречал два напряжения - Rated Voltage и Surge Voltage, второе естественно больше и есть ограничение по времени воздействия. У Ничикона это например серия PCR, у керамики тоже такое попадалось, но у кого не могу вспомнить. Кстати для плёночных X и Y конденсаторов эти значения так вообще чуть ли не на порядок могут отличаться.

А смотрели описание раздела STP ? В частности таблицу в нем. В этой таблице нет вашей комбинации. ----------------------------------------------------------------------- https://habr.com/ru/articles/168119/ Посмотрите, может тут что полезное будет для вас.

Это напрягает софт ненужными аппаратными затратами и ненужной трассировкой, лучше оставлять варнинги.

Ничего он не тормознёт, тем более на ARM. Посмотрите в исходниках как он сделан. Да и запись-чтение десятка-другого байт весьма быстрая операция, чтобы просадить процессор МК. Вот именно! Но сначала прочитать теорию, потом посмотреть, как это сделано во FreeRTOS для ARM. jcxz знает, что говорит. Не для jcxz: тут нужно определиться, что важнее, скорость или память. Если скорость, то, войдя в критическую секцию, сразу копируем данные в разделяемую память или из неё и сразу выходим из критической секции, после чего спокойно разбираемся с данными. Если память жмёт, то в критической секции максимально быстро обрабатываем данные.

Если задачи - независимы друг от друга, то критическая секция нужна. Потому как пишущая задача вполне может захотеть обновить данные до того, как предыдущие данные считаны читающей задачей. Так что = критическая секция (для сериализации доступа к данным) + какой-либо механизм нотификации (об обновлении данных) читающей задаче. Второе может быть как простым volatile-флажком, так и каким-то средством из арсенала ОС. А если предыдущие данные ещё не считаны, но пришли новые? Куда их девать? Вот для того и нужны критическая секция + нотификатор. Из контекста вопроса видно, что передаваемые данные - какие-то параметры, которые могут приходить в любое время, асинхронно работе системы. В том числе и прийти несколько раз подряд с коротким интервалом. Неправильный алгоритм. Сперва читающий процесс должен сбросить флажок-нотификатор, и только потом - считывать данные. Так как иначе он может сбросить флаг новых данных, даже не прочитав их. Это не так. Флажков в РТОС бывает много разных. И в любом случае всегда советовать весьма тяжёлый мьютекс - так себе совет. Мьютекс я бы советовал в самом последнем случае. PS: Если не нравится критическая секция или мьютекс (который весьма сложен внутри, намного сложнее критической секции, а потому требует много ресурсов от ОС; и применять его лишний раз в простых случаях - неоптимально), то есть множество других вариантов межзадачной синхронизации. Вместо критической секции (которая может запрещать все прерывания), можно останавливать шедулер ОС на время чтения/записи разделяемых данных (что является аналогом критической секции, но без помех работе прерываний). Кроме того - есть механизмы межзадачной синхронизации вне-РТОС функционала. Спин-блокировка например. Если у ТС процессор = Cortex-M, то для атомизации доступа к разделяемым данным можно использовать механизм эксклюзивного доступа. В случае, если объём передаваемых параметров небольшой (~десятки байт), то эксклюзивный доступ намного легче (по занимаемым ресурсам) чем мьютекс. И при этом совершенно не мешает работе прерываний. При выборе конкретного способа синхронизации в каждом конкретном случае, следует идти от простого к сложному: Сперва примерить самый простой способ. Если не подходит - переходим к более сложному, примеряем его. И так далее... Только так можно создавать оптимальные программы.

На данный момент не могу согласиться, ибо первое является следствием второго. Где руководство умеет эффективно рулить, там никаких скрамов нет и не надо. А зачем эта сущность (скрам) вообще нужна, если руководитель адекватен? Нам-то поют,что скрам сам по себе прекрасен и неимоверно могуч, т.ч. делает хорошо независимо от руководителей. Расскажите, пожалуйста, поподробнее про скрам-мастеров? Что это за роль (по-вашему)? Что значит "нормальных нет"? А какие они -- нормальные? Как скрам-мастер, который, напомню, вообще даже не специалист в предметной области, который не командир (не руководитель) в команде, который по сути никакой власти не имеет и несёт функции организации построений митингов и логирования их результатов, может как-то влиять на эффективность процесса разработки? Из ваших слов получается, что всё упирается в скрам-мастеров, де, от них всё зависит. Я согласен с тем, что зависит от людей, но только если эти люди -- руководители процессов и исполнители. В первую очередь зависит от руководителей, во вторую от исполнителей. Где тут скрам-мастер, мне не понятно. Раскройте, пожалуйста, ваше понимание этой темы?

Нет, скрам -- это методология ведения работы. А система следующий, более низкий уровень иерархии, система управления строится на основе методологии. Что не делает методологию системой. Конечно. Логистика, закупки, отлаженные производственные процессы -- да. Где всё более-менее предсказуемо и поддаётся адекватному прогнозированию. Но не в разработке нового. Серьёзно? 🙂 Ещё как даёт -- просто методы лодыри применяют другие. Например ИБД (имитация бурной деятельности). А в совокупности к хорошо подвешенным языком бездельник вообще может казаться самым деятельным -- скрам предоставляет как раз возможность демонстрировать (дейлики и прочие регулярные митинги). Не даёт лодырничать никакой не скрам. Вообще, никакая методология или система управления не решает сама по себе эту задачу. Её решает конкретный человек -- руководитель. Если он на своём месте, он прекрасно видит, кто что стоит, кто чем занимается, где есть толк, а где пустота (имитация). Потому что принцип "Кадры решают всё!" применим не только к исполнителям, но и (в первую очередь!) к руководителям. Управление -- живой процесс. И всё зависит от квалификации, умений, опыта и адекватности человека, который осуществляет это управление. Никаких других вариантов нет. Полагать, что скрам что-то там кому-то не даёт или наоборот обеспечивает результат -- есть вредная иллюзия. Далее по пунктам. Ещё одна иллюзия. То, что скрам-методология предполагает ежедневные митинги наряду с планированием спринтов и ретрами, никакой вовлечённости не повышает и не обеспечивает: сидят люди на митинге, слушают бубнение очередного выступающего, ждут своей очереди отчитаться и того, когда это бесполезное и бессмысленное мероприятие закончится. Только и всего. Много раз лично участвовал в этих митингах и наблюдал оную картину. Вовлечённость в проект может поднять тот же самый человек, который руководит процессом, применяя три рычага (это известная тема из психологии): поднять интерес подчинённого сотрудника-коллеги, правильно выбирая для него задачи -- далеко не все задачи интересны всем, поэтому тут надо внимательно и чутко подходить. Будет интерес -- будет результат. Интерес -- это самый главный мотиватор; помочь с пониманием трудных моментов (сам или привлекая других, более квалифицированных в вопросе людей). Когда человек имеет хорошее понимание того, что он делает, это тоже прилично мотивирует (повышает вовлечённость), позволяет работать эффективнее, что поощряет исполнителя, который видит позитивный результат своей работы; довести важность дела до сотрудника-коллеги: нужность результата, ответственность перед заказчиком, уважение товарищей и т.п. Всё это -- живая работа с людьми. Только она и даёт результат. А пустая говорильня на дейликах -- просто трата времени и сил. За счёт чего? Что такого уникального даёт скрам для этого? Что собрались и поговорили? Ну, собрались и поговорили. Наговорились, устали, ничего не решили -- это сколько угодно. Даже более того -- это обычный результат, когда толпа пытается что-то решить. "Лебедь, рак и щука". И эта говорильня продолжается из раза в раз без всякого результата. Решение менять курс (адаптироваться) должен принимать тот, кто отвечает за результат. Его ответственность, его и решение. Как правило, это тот же самый руководитель работы. Он может собрать людей, спросить их экспертное мнение, выслушать каждого, и на основании этого, а также своего опыта и знания своих людей (к чьему мнению в какой ситуации нужно прислушиваться больше, а чьё умножать на 0.1) принять решение, за результат которого ему потом отвечать. Никакие общие собрания и пустопорожная болтовня на них не нужны. Соблюдение сроков обеспечивается грамотным разбиением работы на этапы и контролем выполнения работы по этим этапам. А коллективная ответственность -- это миф! За исключением крайних случаев: типа, все мегасознательные и ответственные как главный герой из советского фильма "Коммунист", или когда в случае неуспеха всех расстреляют (лишат премии, уволят и т.п.). Во всех других случаях коллективная ответственность проявляет себя как коллективная безответственность. Всегда в группе (статистически) находятся раздолбаи, тормоза, рукожопы, эгоисты-индивидуалисты и т.п. И без присмотра и персональной ответственности всё это приводит к тому, что результат провальный, с спросить не с кого. Итого, опять всё сводится к компетенции и квалификации управляющего процессом конкретного человека. Работает только в случае простых задач. Проходили не раз. Когда задачи сложные, требующие серьёзного вникания, всё это не работает от слова совсем. Пример из реальности: пилим командой ПЛИСовый проект, я занимаюсь PCIe DMA (на TLP), а коллега -- поиск паттернов в потоке сетевого трафика. У нас задачи не пересекаются вообще никак! И каждая из них требует глубокого погружения. В итоге, все скучают, когда я что-то бубню запросы чтения памяти хоста, проблемы негарантированного порядка прихода CplD от разных запросов, про кредиты non-posted запросов и подобное, а когда коллега говорит про свою работу, я из его рассказов понимаю только, что у него там какие-то блум-фильтры, перфектные таблицы кукбука и ещё какая-то хрень, названия которой я не запомнил. Чтобы мне понимать, о чём он говорит, мне нужно серьёзно погружаться в тематику его работы, но я не могу этого делать -- у меня своей выше крыши. И у него ровно та же ситуация. И у всех в группе. Получается, что все сидят и тупо ждут, чтобы отчитаться, и когда это пустое мероприятие закончится. Скрам-мастер не понимает вообще ничего из того, что там говорят, т.к. он не специалист ни в ПЛИС, ни в тематике проекта. Ну, по скраму он и не должен. Его задача -- быть секретарём заседания. И вот в итоге проектом занимается 8 человек, но задачи у всех перпендикулярные, какие-то общие места есть только на стыковках, а это очень небольшая часть проекта. В итоге, на общие темы мы можем поговорить только про какое-нить CDC FIFO, проблемы с STA, нюансами использования общего инструментария (симулятор, синтезатор и т.п.) и другими общими вопросами, которые к непосредственно проекту имеют опосредованное отношение. Итого, эффективно задачи решаются при правильно организованной иерархии управления, когда все люди -- и специалисты, и руководители (от крупных до тимлидов) на своих местах. Иерархия -- это естественный способ решения сложности в человеческой коллективной деятельности.. Да, тут важно не скатиться в раздувание иерархии на пустом месте, не допустить возникновения и роста бюрократии и формализации. Поддерживать процесс живым -- это достигается только правильным подбором кадров и никак иначе. Скрам же тут не помогает совсем никак. А мешает изрядно. Он размывает ответственность, распыляет цели, место чётко выверенного курса получается "рыскание". На локальном уровне хорошо работает самоорганизация, когда подбираются (или подбирают) люди ответственные, мотивированные, знающие и умеющие -- она сами между собой наладят и взаимодействие, и рабочий процесс. Но это происходит самодвижущимся образом у них без всяких скрамов. Скрам и тут только мешает, пытаясь формализовать этот естественно сложившийся процесс. Когда задача совсем новая и непонятная, то, конечно, никакого внятного ТЗ быть не может. Поэтому ведётся предварительная работа -- например, как вы правильно назвали, выполняется НИР. А потом при выполнении ОКР ещё эскизный проект (ЭП), на входе которого присутствует проект ТЗ, и цель ЭП -- создать технический облик объекта разработки и разработать уже нормальное ТЗ, с которым можно смело идти в технический проект (ТП), коий уже и есть собственно разработка. Где тут рулящая роль скрама? Да без него это сто лет делалось и делается. Он сюда вообще не вписывается. Что же касается корректировки ТЗ по ходу дела, то и это возможно, но не так огульно как это делается со скрамом. Если заказчик предлагает (просит) что-то поменять, это рассматривается, и если принимается, то выпускается специальные документ: дополнение к ТЗ. Все эти доп. хотелки отражаются там. И всегда видно, что было исходно, а что изменилось по ходу дела. Отдельный документ позволяет хорошо видеть, сколько чего, когда и как изменилось. И это позволяет эффективно пресекать излишнюю тягу заказчика к фантазиям . При разработке софта эти изменения реализуются ещё как-то более-менее безболезненно. При разработке железа -- это как правило боль, и часто оказывается неприемлемым. Иначе разработка затягивается на годы. Это проблема, когда софтовая контора берётся делать железо: тематика и средства радикально другие, а подходы те же самые. Я работал в софтовой IT комании, которая взялась разрабатывать железо (для себя, для своего продукта), в итоге 6 лет хардварному отделу, объём работы проделан колоссальный, сами разработки технически очень достойные (специалисты высокого уровня там трудятся -- контора может себе таких позволить), но в серии и у клиентов по истечении этого срока нет ни одного из полудюжины разрабатываемых изделий. Это происходит именно по причине постоянных корректировок хотелок, отрицания ТЗ как такового, отсутствия этапности в работе, зато есть скрам во всей его красе с коллективной ответственностью безответственностью и прочим. Да и странно предъявлять ответственность исполнителям, если от них тут мало что зависит -- каждый из них на своём месте свою работу сделал хорошо. Подводя итог Скрам, возможно, неплохо себя проявляет при разработке, например, веб-приложений, когда результат работы можно сразу предъявить, и заказчик видит его, может попросить что-то поменять или откорректировать -- вот тут спринты, как контрольные точки, помогают. Но когда ведётся разработка материнской платы сервера (со 128-ядерным процессором и 16 планками DDR4), где работа схемотехника и конструктора ПП занимает по полгода, какие нафиг спринты?! То же самое и с ПЛИС: тот же PCIe DMA я пилил несколько месяцев, и эта работа почти никак не пересекалась с другими -- она несмотря на известную сложность, является локальной, законченной в себе -- ни вводные никакие снаружи тут не нужны, ни результат показать в конце спринта невозможно (вряд ли кому будет интересно смотреть на очередной добавившийся тест того или иного модуля). По итогу пристального наблюдения за этой темой и невольного участия в ней, для себя я сделал следующий вывод: скрам -- это вредная иллюзия управляемости процесса, которая проникла глубоко в сфере IT. Секрет успеха этого внедрения состоит из двух частей: Потребность руководства IT компаний в инструментах управления, которые оное руководство само создать не смогло, но тут ему предложили готовое "решение". Агрессивная реклама этой методологии со стороны консалтинговых агентств и лавок вроде AgileLab, желающих рубить немалые деньги на некомпетентности, доверчивости и легковерности руководителей IT контор. Ну, почему руководители контор ведутся на это -- это Даннинг-Крюгер в полный рост: уровень управленческой компетентности не позволяет ни организовать процесс эффективно, ни понять, что предлагаемое тоже не решение. Процесс разработки и продвижения софта сам по себе прощает многие косяки -- цена ошибки невелика, стоимость производства ноль, сроки производства -- тоже почти нулевые (сколько на пересборку требуется), возможность отлаживаться на клиентах и т.п. Всего этого нет в теме разработки железа, там всё эти ошибки стоят дорого. Поэтому там этот подход не работает совсем. Если в какой-то конторе ввели Scrum, это по факту и по сути является ничем иным как росписью руководства этой конторы в собственной управленческой несостоятельности. Не больше, не меньше.

Так пожалуйста. Можем предложить консультацию по введению скрама. Месяц поработать с Вами. Не в форуме же