Ирония в том, что расчёт power dissipation был одним из требований, и он даже был сделан и соответсвующим образом подобран импульсный преобразователь, а вот при выборе LDO человек уже про всё это забыл. У меня самого времени на тщательную проверку не хватило (урок усвоен, чужие шедевры нужно проверять ещё тщательнее, чем свои). Тем не менее девайсину собрали и запустили, конечно не без мата и посиделок с паяльником, но тем не менее оно зажило, пока худо-бедно работает и ждёт реинкарнации.
Проблема подтяжек была в том, что они были сделаны не к неправильному уровню, а к неправильной цепи (reset и sleep драйвера подтянуты к выходу стабилизатора этого же самого драйвера). Так что мозг выключать нельзя, как бы соблазнительно это не было.

Жму руку. Вы занимаетесь тем, что Вам действительно нравится.

Есть вот узкие места, которые ещё и не измеришь абы как. Вот тут проблема. Нужно наперёд думать, как диагностировать косяк, о котором ты даже не знаешь. Кстати, здесь симуляции как раз зачастую здорово помогают

С питанием более-менее понятно, можно и в excel "симуляцию" сделать, но вот как симулировать обвяз МК или драйвера?

На уровне .IBIS?
Средствами САПР

По документам. Разбираться отдельно с каждой микросхемой. Это и есть ревизия

Делать по ref   из dataasheet

Не, ибисы не особо работают с силовыми драйверами. Спайс работает, но он ужасно тяжёлый

Проще грамотно разбить железо на блоки, проверять сперва внутренности блоков, хоть по референтам/ДШ, хоть через суппорт производителя, а потом постепенно переходить на системный анализ

Потом, если сильно нужно, пост-топологическая симуляция SI (тут как раз ибисы), PI (импеданс PDN), можно даже термическую. Ну, это типичный flow через гиперлинкс

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

Давайте я вас явно поддержу, чтобы вам не казалось, что тут все за узкую специализацию. :)

Тогда уж и монтажников разделять надо по типам компонентов, с которыми они работают. :D

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

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

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

Хотелось бы узнать, каким образом ML интегрируется в embedded.

Реальность такова, что нормально сделанное может уже быть не нужным через 1-2 месяца, а нужно что-то здесь и сейчас. Потому что возможно изначальные требования неверны и ждать ещё 1-2 месяца нереально. Проблема в том, что если делаешь новое, а не узел IoT или супер уникальный SBC, то иногда приходится перебрать несколько вариантов, а с учётом изменяющихся требований, потому что сам комплекс развивается и эволюционирует, приходится частенько менять дизайн.
Вот к примеру, как бы Вы коммутировали LiFePo батареи на 48В, 480 А*ч? Готовы с первого раза сделать дизайн, который будет надёжным и не гореть при отключении нагрузок по 200А, а также позволять осуществлять аварийное обесточивание? Подозреваю, что превым решением будет взять готовый ключ и прикрутить к нему релюшку, но при запуске возникнут масса казалось бы второстепенных вопросов как то: как обеспечить защиту от КЗ в коммутируемой цепи, как предотвратить пиковые токи при включении, как не дать нагрузке, коей являются электромоторы, спалить себя при переключении на рекуперацию, как ко всему этому впоследствии подключить вторую батарею да так, чтобы они не пытались зарядить друг друга. А батарея нужна здесь и сейчас, чтобы моторчики закрутились, машина поехала и можно было проверять другие части системы. Вот и приходится поступаться принципами "не делать гуано" и решать проблемы здесь и сейчас, макетируя, склеивая отдельные куски воедино, находя и исправляя ошибки, и двигаться дальше в поисках новых ошибок.

Это, интересно, рынок такие условия диктует или руководство так работает?)

Руководство под влиянием рынка. Чтобы реализовать своё технологическое преимущество нужно выйти на рынок как можно быстрее,  но не в ущерб customers experience. Мы просто очень бедные люди, не пилим бюджеты и гранты, и поэтому должны максимально быстро довести продукт до готового состояния,  а не пилить его годами.

Без придирок и негатива, просто интересно. Наверняка оба фактора играют роль, но бывает всякое.

А разработчикам зачем в это вписываться?

Только за повышенную относительно других зарплату