Лидеры

Видимо для снижения порога входа малограмотных бейсиководов ))

https://www.google.ru/search?q=nanocrystalline+common+mode+choke

Common mode (power line) choke. Внутри может быть как феррит, так и аморфный нанокристаллический материал (лентой).

В 100% нужно делать свои библиотеки, ничего сложного там нет.

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

Ну если вы косячно напишите, то конечно "сбойнет" 🙂 Ну и учитывая, что I2C очень медленный интерфейс, ожидание прихода байта поллингом - очень нерациональное решение. Есть же для этого прерывания, DMA в конце концов. Никаких сложностей, надо просто понимать, как что делать рационально. Конечно, если понимания этого нет, тогда FreeRTOS услужливо подставляет костыль для обхода сей некомпетентности кодописателя. "Удобно-неудобно"... Неудобно срать спать стоя, остальное фигня, как у нас говорили 🙂 Во многих случаях FreeRTOS - всего лишь маркетинг, предложенный как "удобно". На самом деле, если разобраться, в ней хватает "неудобных" моментов даже более чем. Ох мать, еще одна надстройка... Дааа, Куб услужливо подставил еще один костыль для не слишком смышлёных тушканчиков 🙂

А самое смешное, что задача с УАРТом, И2Ц, АЦП и таймером решается без каких-либо РТОС 🙂 По крайней мере, мы раньше на такие темы даже и не заморачивались. Это вот сейчас стало модно крутить РТОС даже в светомигалку. Использование ДМА и прерываний, вкупе с системным таймером позволит устаканить указанные четыре вещи без РТОС как за нефик делать. Перечисленные модули все равно же будут работать примерно поочередно, типа пока не будет готов результат АЦП, УАРТ не будет начинать передачу. И наоборот, пока по УАРТу не придет команда запуска АЦП, он не будет запускать процесс измерения. И2С - это наверно какой-нить OLED 128х64. В лучшем случае 🙂 Ну это так, для справки, примерно плюс-минус както так.