Обновить
33
0.2
Михайлов Алексей Анатольевич@MinimumLaw

Linux Kernel, Bare metal, Embedded developer

Отправить сообщение

<САРКАЗМ>

Пузырь блокчайна уже лопнул? Никому ножки не обожгло?

</САРКАЗМ>

Кажется современный мир научился справляться с пузырями достаточно эффективно. Остальное списывается на особенности строя. Но это уже тема совсем другого разговора.

Несомненно. Я с этим даже спорить не пытаюсь. Да и вопрос был про операционные системы, а не про квалификацию пректировщика.

... C это поле граблей ...

Можно свалить все на С. Но это не его проблема. Это проблема специфики аппаратуры. В данном случае ARM7TDMI (ARMv4T) просто аппаратно не поддерживает такое и сваливается в DATA ABORT. А дальше есть варианты... Либо ловить это исключение и в нем исправлять особенности архитектуры или править код, усложняя его. Сам по себе язык тут не при делах. Он как раз делает ровно то, что должен.

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

А по упаковке... Ну взять тот же ModBus. Там даже добавление лидирующего паддинга не всегда решает. К счастью с появлением семейства Cortex-M эта проблема в контроллерах ушла. Потому и исходный вопрос был бы задан только тем, у кого в резюме есть опыт работы с соответствующими чипами. И да, это реально вопрос "со звездочкой" который добавить баллов может, а отнять точно нет.

Самое главное пропустил.

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

Нет. Компилятор сделает ровно тот код, который от него просят. Размер t_quest будет ровно 7 байт. А var будет выровнена в соответствии с правилами выравнивания по умолчанию (обычно 4 байта). Во всяком случае я другого никогда не встречал. И передать или принять такую структуру, скажем через тот же UART можно запросто.

Да, компилятор даже не поперхнется (надо только добавить забытый мной stdbool.h). В тот момент, когда это было актуально никакие -WExtra -Wpedantic и их аналоги для компиляторов других производителей ситуацию не исправляли. Код собирался предельно чисто. Что доставляло интересных моментов в процессе отладки.

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

Например, уточняющий к одному из моих вопросов (со звездочкой)
#include <stdint.h>

extern uint8_t  ext_get_byte(void);
extern uint16_t ext_get_word(void);
extern uint32_t ext_get_dword(void);

#pragma pack(push,1)
typedef struct s_quest {
  uint8_t  byte;
  uint16_t word;
  uint32_t dword;
} t_quest;
#pragma pack(pop)

volatile t_quest var;

void main(void)
{
  while(true) {
    var.byte = ext_get_byte();
    var.word = ext_get_word();
    var.dword = ext_get_dword();
  }
}

Правда ли, что этот "Hello, World" будет работать на любых ARM'ах?

А с учетом специфики здешней аудитории, простой ответ невозможен. Вон @aabzelна один из вопросом ответ на целую статью в формате long-read выдал. Мне на собеседовании так подробно не надо. А тут менее подробно могут не понять.

Я, как правило уточняю - если я задаю абстрактный вопрос, меня устроит абстрактный ответ. Если что, я уточню. А если вопрос конкретный, то и ответ ожидается максимально конкретный. Конкретных вопрос в начальном списке нет. Они все абстрактные. Вам нужны абстрактные ответы? Можно, но зачем? (с) Конкретные, с разбором... Ну если очень интересно подсветите вопросы. Потому как это точно long-read и точно в формате статьи.

Условной ОС "самого реального времени" на вход условно одновременно приходит два события с одинаковым приоритетом. Вопрос - как она обеспечит не плавающую задержку реакции на каждое из них без использования магии? И чем тогда она отличается от ОС "менее реального времени"?

Да, мне нравится это решение. Особенно нравится рассуждение о FIFO в конце. Вот тут, правда, чуть-суть бы поподробнее. Например, почему FIFO а не другие способы организации буферов? Почему, допустим не связанные списки или кольцевые буфера?

Вопрос может содержать миллион подвохов, и вы ни за что не угадаете где, если вопрос задан с целью подвоха.

Ну данный вопрос, судя по ответу, подвохов и не подразумевал. Подвохи вскрывает практика. А вопрос был про знание простого факта - отрицательные числа, как правило, хранятся в обратном дополнительном коде. Скорее всего я бы именно так и ответил. И ответ был бы признан неправильным. В идеальном мире, следом должен был быть вопрос "А зачем так сложно?" но... Видимо задающий этого и сам не знает.

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

Да. Но код тоже важен. Хороший, понятный, сопровождаемый. Баланс должен соблюдаться. Совсем "универсальный солдат", как правило одинаково плох во всем. А это не интересно настолько, что приносит проблем больше, чем решает. Опять же мало решить задачу. Важно, чтоб через год, два, три ты сам (или твой последователь) мог ее как-то адаптировать под современные реалии. Денрофекальный метод хорош для прототипов, но даже делая прототип всегда надо держать необходимость сделать "из кирпича, не по ламерски" (с)

Можно подробнее, которые из моих тараканов не адаптированы под какие именно условия?

А я не знаю. Я просто оцениваю ваши ответы на вопросы, которые задало Yadro. Мои типовые вопросы представлены ниже и весьма разительно отличаются от тех, что в статье.

У вас каждый вопрос по сути оставляет несколько трактовок и подразумевает знание банальных ответов, но ожидает не только лишь их )

Да, наверное. Мои вопросы призваны отсеять "проходимцев собеседований" и выловить людей "с практикой". Без привязки к конкретным работам, ибо они бывают очень и очень разные. С другой стороны толковый джун ими тоже хорошо подсвечивается. Они все скорее не "вопросы из теста", а "сочинение на тему". Тесты можно заучить, а сочинение надо уметь писать (к слову о софт-скилах из соседней ветки).

на секундочку, в контексте динамических. И с динамическим же выделением памяти. Что не так?

Вопрос в тексте был "Что такое static?" Где здесь хоть что-то про динамическое выделение памяти? Совершенно очевидно что вы пытаетесь отвечать на вопрос, который не задавался. Согласен, не самая удачная формулировка, но... Она не настолько плоха, чтоб быть настолько неправильно понятой.

 И меня сильно напрягают вопросы, которые регулярно используются в качестве вопроса с подвохом.

Вопрос о том, как битово представляется чиcло -2 в памяти содержит подвохи в другом месте. Например в том, char это int (а может long или даже long long). И не используется ли ненароком BigEndian в данном контроллере. А это не тот ответ, который дали вы упомянув троичную (чего троичную - давайте сразу нечеткую?) логику.

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

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

взять условного меня... или взять студента ...

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

  • Можно, а зачем? (с)

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

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

Думайте, может лучше оставить это как хобби. Радости не меньше и ответственности (почти?) никакой.

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

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

По списку вопросов - повторю то, что писал выше. Их много, и они по большей части бестолковые. А набор вопросов по специфике CAN говорят либо о том, что меня собеседует человек который совсем недавно открыл для себя этот интерфейс, или о том, что он очень активно применяется в работе. И этот момент я бы обязательно уточнил. Что до остальных вопросов - может оно и норм. Ну не используют люди RZ/NRZ и прочие MIPI/DP вместе с PCIe. Им нужны те, кто уже знает про I2C и SPI. Что ж в этом плохого? Вопросов про USB с его SOF и суперфреймами нет. Значит и не надо.

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

Отличные вопросы, для тех кто идет уверенно! Хотя, справедливости ради, MMU не частый гость в мире микроконтроллеров.

Да, к сожалению и Yadro начинает обрастать жирком...

Чем отличаются жесткий и мягкий real time?

Количеством маркетинг-часов, затраченных на продвижение. Ибо real-time это всегда про "не терять события", а жесткий и мягкий чаще всего про время между событием и реакцией на него.

Чем отличается биполярный транзистор от MOSFET?

MOSFET в девичестве назывался полевым транзистором и имел индуцируемый канал, т.е. изолированным затвором. И именно это отличает его от биполярного. А выводы микросхемы нумеруются в соответствии в документацией производителя.

Мой круг вопросов другой. У меня, конечно, не чистые контроллеры - скорее Embedded Linux + контроллеры, при чем прикладное ПО пишут коллеги, но...

  • Вы написали "hello world" для микроконтроллера. Расскажите как он будет выполняться с момента подачи питания.

  • Как по вашему мнению должна выглядеть идеальная функция min() в коде для микроконтроллера без использования RTOS

  • Зачем нужен аппаратный таймер и что делать если встроенных в контроллер таймеров не хватает?

  • На осциллографе вы видите очень короткий импульс, вместо ожидаемого длинного - что это может быть?

  • Как делается отладочный ввод-вывод? Что можно сделать, чтобы он минимально влиял на работу основной программы?

  • Как критические исключения позволяют обнаружить проблемное место в коде?

Если опыт позволяет, и в резюме есть опыт работы с ARM до эпохи Cortex, я спрошу еще

  • Почему необходимо выравнивать данные? Чем может быть опасен доступ к не выровненным данным? Как добиваться выравнивания?

  • Что думаем про битовые поля? Как физически компилятор с ними работает? Где их стоит применять, а где лучше воздержаться?

Если заявлено знание схемотехники

  • Нарисую RC-цепочки разного вида и попрошу рассказать как через них проходит аналоговый и цифровой сигнал.

  • Спрошу про погрешности, вносимые измерительными приборами в процессе измерения.

Ну и уточню, что у нас принят Linux Kernel coding-style.

В принципе, ответов на эти вопросы мне будет достаточно. Особенно если они будут сопровождаться комментариями о том, где и при каких обстоятельствах эти грабли топтались.

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

Так и подбивает спросить - старый вирус эмулируете. Тот, который под DOS прерывание клавиатуры перехватывал, и заменял "," на ", бл*,"? Что сильно позже породило пост на небезызвестном ресурсе.

Senior-уровень сегодня — это не потолок, где можно остановиться и просто делать свою работу хорошо, а это развилка. Либо ты расширяешь своё влияние и ответственность, либо застываешь в позиции «я просто пишу код».

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

И да, бизнес стал другим. Он перестал быть нацеленным на результат. Теперь всем рулит его величество процесс, в котором проблемы, легко предсказываемые технической эспертизой, становятся "инцидентами" с четким регламентом их решения. Пусть и неправильного, плодящего эти "инциденты" как снежный ком. Зато все при деле - менеджеры рисуют диаграммы Ганта, мастера с видом индийских йогов проводят митинги, кодеры пишут код с помощью искусственного интеллекта. Зачем в этой системе сеньоры и техническая экспертиза? Потому никакой я не сеньор. Я просто пишу код. Я ведь даже не мидл, а по сути джун. Ровно потому что мой код лучше, чем тот, который пишет ИИ, но появляется он медленнее. И лишает работы всех, кто вокруг - от мастеров и DevOps'ов (что бы это не значило), до менеджеров, которым неоткуда становится брать новый "инциденты" и показывать свою значимость. И да, я и не делаю из этого секрета - поэтому я мало того, что хуже джунов, так я еще и величайший токсик в компании.

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

Например, чтобы более качественно и с меньшим числом ложных срабатываний находить слово «Алиса» в окружающем шуме.

Ох уж мне этот Яндекс... Эта фильтрация привела к тому, что для моей Midi, как для тупых - дважды и с четкой дикцией. И первый раз с вероятностью 40% будет проигнорирован. Что характерно, запинающиеся, плохо сформулированные детские вопросы станция распознает лучше, чем четкие взрослые указания (правда брошенные походя).

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

"... Бывший наркоман на стимуляторах. Сейчас на седативах, чтобы мозг не разгонялся до состояния "всё и сразу, но ничего конкретного". Гиперчувствительность к среде. Социальная батарейка на 15 минут в день..." - ну прямо типовая картинка хакера несколько лет назад. Достаточно вспомнить ту же Матрицу. Да и суда по отзывам пользователей о всяких корпоративных софтинках, не только хакера.

А можно спросить не "как?", а "зачем?" Все в этой жизни можно, если очень захотеть. И в первую очередь интересны не средства, а мотивация.

Тема интересна с другой стороны. Нас тут уверяли, что ВЕСЬ трафик фильтруется. И все гадали, как же такое можно физически реализовать и на каких мощностях. А тут получается что не весь. И трафик Yandex'а или VK остается нефильтрованным... Что в принципе ставит под сомнению всю идею "белых списков" (если, конечно, она соответствует заявленной, а не реально работает на самоизоляцию). И да, в этом смысле интереснее а что там с Великим Китайским файрволом? Какой-нить TaoBao или 163 тоже имеет нефильтрованный доступ?

1
23 ...

Информация

В рейтинге
2 845-й
Откуда
Пушкин, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Инженер встраиваемых систем, Архитектор программного обеспечения
Старший
От 350 000 ₽