Это полёт по инерции уже. По динамике оборота можно предположить, что их убила узкая специализация на поставках западных HSM — не смогли после февраля 2022 переориентироваться и спикировали вниз.
Какая мне разница, есть у вас студбилет или истёк давно, если вы с апломбом лезете обсуждать тему, представление о которой у вас сформировано википедией и какими-то малоосмысленными догматами? Профессионала от студента отличает умение эффективно решать практические задачи — вы им, судя по вашим рассказам, не обладаете.
Впрочем, работал у меня однажды такой программист. Прочитал много книг, очень любил рассуждать, как правильно писать код — настолько, что младших по возрасту этими рассказами в какой-то момент начал явно задалбывать уже.
В первом же полностью самостоятельном проекте на этом месте родил невероятное страшилище, такое, что прямо кровь из глаз.
Нет, если это реальная задача из реальной жизни. Потому как в реальной жизни ждиттер-критичные операции и ОСРВ без иерархии прерываний - очень плохо совместимые понятия. Потому, что тактовая сетка ОСРВ в разы крупнее, чем время выполнения обработчика АЦП, а подавляющее большинство ее системных вызовов привязано к той самой сетке
Вы этот набор слов опять где-то в википедии нашли?..
Я даже затрудняюсь интерпретировать, при чём тут «тактовая сетка ОСРВ». Особенно если мы возьмём ОСРВ без тактовой сетки.
Второстепенная функция АЦП (какое-нибудь измерение напряжения батарейки, температуры или что-то ещё малосущественное), основная риалтайм-функция на прерываниях от таймера, ОСРВ без иерархии прерываний.
И на кой чёрт вам в этом вносить дополнительный джиттер влезающими не к месту прерываниями АЦП? Чтобы что?
Я даже могу привести пример, когда не просто можно, а нужно написать обработчик АЦП без прерываний :)
И в этом вечная проблема с читателями википедий — они какие-то магические заклинания в голове несут, но откуда эти заклинания и зачем вообще нужны, понятия не имеют.
по максимуму использовать ту, которая расходует ресурсы более эффективно
Мне как-то рассказывали про студента, на защите неудачно употребившего это слово, отчего до того момента один не проявлявший большого интереса к защищаемой работе член комиссии внезапно ожил и попросил описать конкретные критерии эффективности.
Нет, студента даже отбили и что-то хорошее поставили в итоге.
Но так-то дедушка был абсолютно прав. Да и сам я студентов честно предупреждаю, что язык их — враг их, и на экзамене валить я буду в основном вопросом «почему?».
Вы можете назвать сферу применимости, где НУЖНО так вот бездумно жрать такты и миллиамперы от источника?
Пока у вас управление питанием на данном микроконтроллере не реализовано — вы эти такты и миллиамперы жрёте совершенно одинаково независимо ни от чего.
А воткнуть сюда жрущий ещё и память printf, чтобы он зачем-то делал какую-то бессмысленную работу ради работы — вот это и есть «религиозные установки». Вот за такое и надо прямо по рукам бить, за подход «не могу объяснить зачем, но наверчу сюда что-нибудь».
И да - здесь ужас в той строке, которая "wait for the conversion to finish". Не надо так. Даже в учебных примерах. Потому как код из них так или иначе оказывается в изделиях.
Нет в этом никакого ужаса. Абсолютно легальная конструкция, сферу применимости которой необходимо понимать точно так же, как необходимо понимать сферу применимости прерываний.
Более того, в любом микроконтроллере внутри вагон событий, которые устанавливают где-то какой-то флаг, но не вызывают прерывание в принципе.
Так что бессмысленный ужас есть только в религиозной установке «всё надо делать только на прерываниях!».
Есть и более тривиальный случай: этот код может быть предназначен для использования инженерами, работающими с данными ЦАП — и хорошо если электронщиками, а не какими-нибудь звукоинженерами, которые от программирования совсем далеки.
Тогда решение даже в одном конкретном чипе параметры вводить через абсолютно точно понятные им дефайны наиболее верное.
Здесь нет нелепого кода. Здесь есть графомания с необоснованными придирками от человека, который в первую очередь сам не умеет делать оформление не то что красиво, а хотя бы осмысленно.
Где-нибудь на пикабу эта статья смотрелась бы органичнее.
О, удивительно, но что в ответ вы сможете только наехать на Яндекс — я предсказал ещё до того, как нажал «Отправить» на предыдущем комментарии. При чём он тут? Это Яндекс заставляет вас рисовать самые нелепые блок-схемы из всего, что я видел в жизни?
Начнём с того, что ничего нелепого в большинстве приведённых примеров попросту нет.
«Нелепое» — это тот вырвиглазный ужас, который вы на блок-схемах в своих статьях рисуете, зачем-то пытаясь пятью размерами шрифта запихнуть в каждый прямоугольник три вагона абсолютно ненужной для блок-схемы информации.
А здесь приведён совершенно рядовой, обычный и понятный код, единственная причина называния которого «нелепым» — ваше неуёмное желание через графоманию строить из себя высокопрофессионального программиста, учащего окружающих, как правильно делать всё.
Ну в целом вы показали наглядный пример, как заваливают собеседования. «Я самый умный и лучше всех знаю, как надо делать» — рецепт, работающий без сбоев.
Продукция AD является подсанкционной. Устройство нужно разрабатывать на доступных компонентах
Устройство нужно разрабатывать на компонентах, имеющихся в цепочке поставок фабрики, которая предполагается производителем данного устройства (модуля). Так как выполняющий задание доступа к фабрике не имеет, нет никакой проблемы в том, что он разработал его на любых не слишком экзотических («нууу, Maxim это выпускал до 1996-го, но ещё можно найти в продаже») компонентах.
Да и по DFM, организации производства, контролю качества и даже немного управлению проектами, если вы на техлида идёте, вас отдельно от схемотехники погоняют.
А от того, что вы его разработаете на компонентах, доступных в Чип-и-дипе, никому не будет ни горячо, ни холодно. Хотя нет: собеседующий может запросто зацепиться взглядом за «на доступных компонентах», и начать вас разбирать на запчасти вопросами про то, как именно вы доступность определяете.
Вполне нормальное решение, в нём нет очевидного безумия, предположения в процессе сделаны вполне разумные (я не говорю, что в реальной задаче они будут такими же — но это не реальная задача, поэтому здесь применяется принцип разумности). Подход интересный, изложение последовательное, есть о чём поговорить.
Несколько избыточно описание в том смысле, что собеседующему всё детальное изложение хода мысли не нужно. Но это на самом деле не проблема, я бы попросил сразу промотать к финальному решению и тезисно пояснить его по кусочкам — а вот если какой-то тезис меня заинтересует, можно уже копнуть поглубже по нему.
Собеседующему, возможно, хочется послушать, осознаёте ли вы отсутствие данных деталей (и каких именно, и как оцениваете их влияние на решение), а также дадите ли всё-таки ответ в рамках некоторых разумных допущений или придёте с «ну нет, я такую задачу решать не буду, тут недостаточно данных!» (и такие случаи бывают).
Переусложнение решения на ровном месте — тоже очевидный минус для собеседуемого.
Более того, между «не знаю ни теорию, ни практику» (а давайте вместо платины этой вашей цифровой датчик бахнем!) и «знаю много теории, но не практику» (а давайте тут в три этажа наворотим непонятно зачем!) нет какой-то принципиальной разницы: оба собеседуемых в первую очередь не понимают границ своих знаний, а значит, не смогут самостоятельно генерировать адекватные решения не только в рамках тестового задания, но и в реальной жизни.
Нет. Вас проверяют на то, осознаёте ли вы, что у такого требования может быть много других причин, кроме «да это просто мудак в соседнем отделе, а мне виднее, я ж инженер, а не мудак какой-то!».
В условиях задачи вам уже дан АЦП с входом от 0 В и жёсткое требование обеспечить сигнал от 0 В. Вполне вероятно, что собеседующий хочет послушать, есть ли у вас в голове понимание связанных именно с этим условием проблем и подходов к их решению.
Спорить с собеседующим о том, не надо ли пересмотреть данные им вам условия задачи, чтобы вам было проще её решать — плохая примета.
Дословная формулировка у вас была: «инженер должен объяснить программистам».
Нет, не должен. Инженер должен оценить разные варианты реализации, их плюсы и минусы, а при необходимости обсудить и согласовать эти плюсы и минусы с другими направлениями (софт, конструкторы, логистика, фабрика, тестирование).
Более того, такая формулировка на собеседовании — это скорее всего красный флаг «скидывает проблемы на других, ставит себя априори выше разработчиков ПО».
Это полёт по инерции уже. По динамике оборота можно предположить, что их убила узкая специализация на поставках западных HSM — не смогли после февраля 2022 переориентироваться и спикировали вниз.
Демос-Интернет при этом кончился ещё раньше.
Какая мне разница, есть у вас студбилет или истёк давно, если вы с апломбом лезете обсуждать тему, представление о которой у вас сформировано википедией и какими-то малоосмысленными догматами? Профессионала от студента отличает умение эффективно решать практические задачи — вы им, судя по вашим рассказам, не обладаете.
Впрочем, работал у меня однажды такой программист. Прочитал много книг, очень любил рассуждать, как правильно писать код — настолько, что младших по возрасту этими рассказами в какой-то момент начал явно задалбывать уже.
В первом же полностью самостоятельном проекте на этом месте родил невероятное страшилище, такое, что прямо кровь из глаз.
Тоже ведь не студент был.
Вы этот набор слов опять где-то в википедии нашли?..
Я даже затрудняюсь интерпретировать, при чём тут «тактовая сетка ОСРВ». Особенно если мы возьмём ОСРВ без тактовой сетки.
Второстепенная функция АЦП (какое-нибудь измерение напряжения батарейки, температуры или что-то ещё малосущественное), основная риалтайм-функция на прерываниях от таймера, ОСРВ без иерархии прерываний.
И на кой чёрт вам в этом вносить дополнительный джиттер влезающими не к месту прерываниями АЦП? Чтобы что?
Я даже могу привести пример, когда не просто можно, а нужно написать обработчик АЦП без прерываний :)
И в этом вечная проблема с читателями википедий — они какие-то магические заклинания в голове несут, но откуда эти заклинания и зачем вообще нужны, понятия не имеют.
Мне как-то рассказывали про студента, на защите неудачно употребившего это слово, отчего до того момента один не проявлявший большого интереса к защищаемой работе член комиссии внезапно ожил и попросил описать конкретные критерии эффективности.
Нет, студента даже отбили и что-то хорошее поставили в итоге.
Но так-то дедушка был абсолютно прав. Да и сам я студентов честно предупреждаю, что язык их — враг их, и на экзамене валить я буду в основном вопросом «почему?».
Пока у вас управление питанием на данном микроконтроллере не реализовано — вы эти такты и миллиамперы жрёте совершенно одинаково независимо ни от чего.
А воткнуть сюда жрущий ещё и память printf, чтобы он зачем-то делал какую-то бессмысленную работу ради работы — вот это и есть «религиозные установки». Вот за такое и надо прямо по рукам бить, за подход «не могу объяснить зачем, но наверчу сюда что-нибудь».
Нет в этом никакого ужаса. Абсолютно легальная конструкция, сферу применимости которой необходимо понимать точно так же, как необходимо понимать сферу применимости прерываний.
Более того, в любом микроконтроллере внутри вагон событий, которые устанавливают где-то какой-то флаг, но не вызывают прерывание в принципе.
Так что бессмысленный ужас есть только в религиозной установке «всё надо делать только на прерываниях!».
Есть и более тривиальный случай: этот код может быть предназначен для использования инженерами, работающими с данными ЦАП — и хорошо если электронщиками, а не какими-нибудь звукоинженерами, которые от программирования совсем далеки.
Тогда решение даже в одном конкретном чипе параметры вводить через абсолютно точно понятные им дефайны наиболее верное.
Здесь нет нелепого кода. Здесь есть графомания с необоснованными придирками от человека, который в первую очередь сам не умеет делать оформление не то что красиво, а хотя бы осмысленно.
Где-нибудь на пикабу эта статья смотрелась бы органичнее.
О, удивительно, но что в ответ вы сможете только наехать на Яндекс — я предсказал ещё до того, как нажал «Отправить» на предыдущем комментарии. При чём он тут? Это Яндекс заставляет вас рисовать самые нелепые блок-схемы из всего, что я видел в жизни?
Начнём с того, что ничего нелепого в большинстве приведённых примеров попросту нет.
«Нелепое» — это тот вырвиглазный ужас, который вы на блок-схемах в своих статьях рисуете, зачем-то пытаясь пятью размерами шрифта запихнуть в каждый прямоугольник три вагона абсолютно ненужной для блок-схемы информации.
А здесь приведён совершенно рядовой, обычный и понятный код, единственная причина называния которого «нелепым» — ваше неуёмное желание через графоманию строить из себя высокопрофессионального программиста, учащего окружающих, как правильно делать всё.
Ну в целом вы показали наглядный пример, как заваливают собеседования. «Я самый умный и лучше всех знаю, как надо делать» — рецепт, работающий без сбоев.
Устройство нужно разрабатывать на компонентах, имеющихся в цепочке поставок фабрики, которая предполагается производителем данного устройства (модуля). Так как выполняющий задание доступа к фабрике не имеет, нет никакой проблемы в том, что он разработал его на любых не слишком экзотических («нууу, Maxim это выпускал до 1996-го, но ещё можно найти в продаже») компонентах.
Да и по DFM, организации производства, контролю качества и даже немного управлению проектами, если вы на техлида идёте, вас отдельно от схемотехники погоняют.
А от того, что вы его разработаете на компонентах, доступных в Чип-и-дипе, никому не будет ни горячо, ни холодно. Хотя нет: собеседующий может запросто зацепиться взглядом за «на доступных компонентах», и начать вас разбирать на запчасти вопросами про то, как именно вы доступность определяете.
Вполне нормальное решение, в нём нет очевидного безумия, предположения в процессе сделаны вполне разумные (я не говорю, что в реальной задаче они будут такими же — но это не реальная задача, поэтому здесь применяется принцип разумности). Подход интересный, изложение последовательное, есть о чём поговорить.
Несколько избыточно описание в том смысле, что собеседующему всё детальное изложение хода мысли не нужно. Но это на самом деле не проблема, я бы попросил сразу промотать к финальному решению и тезисно пояснить его по кусочкам — а вот если какой-то тезис меня заинтересует, можно уже копнуть поглубже по нему.
Собеседующему, возможно, хочется послушать, осознаёте ли вы отсутствие данных деталей (и каких именно, и как оцениваете их влияние на решение), а также дадите ли всё-таки ответ в рамках некоторых разумных допущений или придёте с «ну нет, я такую задачу решать не буду, тут недостаточно данных!» (и такие случаи бывают).
Переусложнение решения на ровном месте — тоже очевидный минус для собеседуемого.
Более того, между «не знаю ни теорию, ни практику» (а давайте вместо платины этой вашей цифровой датчик бахнем!) и «знаю много теории, но не практику» (а давайте тут в три этажа наворотим непонятно зачем!) нет какой-то принципиальной разницы: оба собеседуемых в первую очередь не понимают границ своих знаний, а значит, не смогут самостоятельно генерировать адекватные решения не только в рамках тестового задания, но и в реальной жизни.
Нет. Вас проверяют на то, осознаёте ли вы, что у такого требования может быть много других причин, кроме «да это просто мудак в соседнем отделе, а мне виднее, я ж инженер, а не мудак какой-то!».
Вы — не осознаёте.
В условиях задачи вам уже дан АЦП с входом от 0 В и жёсткое требование обеспечить сигнал от 0 В. Вполне вероятно, что собеседующий хочет послушать, есть ли у вас в голове понимание связанных именно с этим условием проблем и подходов к их решению.
Спорить с собеседующим о том, не надо ли пересмотреть данные им вам условия задачи, чтобы вам было проще её решать — плохая примета.
Дословная формулировка у вас была: «инженер должен объяснить программистам».
Нет, не должен. Инженер должен оценить разные варианты реализации, их плюсы и минусы, а при необходимости обсудить и согласовать эти плюсы и минусы с другими направлениями (софт, конструкторы, логистика, фабрика, тестирование).
Более того, такая формулировка на собеседовании — это скорее всего красный флаг «скидывает проблемы на других, ставит себя априори выше разработчиков ПО».