Лидеры

Начиная с ATmega128 и ATmega8, ЕМНИП, бит SPIEN недоступен при программировании через SPI. Что-то другое вмешалось, например - RSTDIS.

Самая вишенка на этом торте. Это не просто подготовка проектов, заправка питателей и оператор, но и диагностика неисправностей и их устранение. Значит специалист по точной механике, приводам, пневматике, опыту юстировки конкретного оборудования и все в одном флаконе. Помимо всего прочего имеющий инженерные коды доступа к этим станкам и сервис мануалы, которые просто так никто не дает, ибо имеющий их, может очень неплохо зарабатывать выездным сервисменом. Говорю так, потому что немного знаком со всей этой кухней изнутри.

Это что за ТЗ такое, когда через месяц оказалось, что оно не про то? ТЗ -- серьёзный документ, от него зависит результат чуть не на все 100%. ТЗ -- это отправная точка в разработке. Из него формируются этапы работы. Если через месяц выясняется, что ТЗ не про то, что надо, разработчика ТЗ (или того, кто ему задачу ставил) гнать за профнепригодность. Меняет и дополняет по ходу дела?!!! Серьёзно?! Вот это и корень проблем при использовании IT'шных подходов в разработке железа! Это в софте можно быстро перех..якать, с железом это не прокатывает. Да и с софтом эта практика порочна и является источником массы проблем, просто там последствия ощущаются не так больно. Вместо того, чтобы сразу подумать и спланировать процесс, там доминирует метод "х.як, х..як и в продакшн". Единственный сценарий, где такое оправдано -- это когда задача (что нужно конкретно сделать) недостаточно ясна на старте, и пока не начнёшь, невозможно понять, как конкретно это надо сделать. Поэтому применяется этот метод "тыка" -- сделали что-то, увидели, то или не то. Тут, конечно, нужно всем участвовать -- и заказчику, и разработчику, и периодичность этих контрольных точек должна быть достаточно короткой (1-4 недели) -- те самые спринты. Это как-то работает при разработке софта, но с железом это полный провал. Там нужно всё заранее тщательно проектировать и планировать, потому что перефигачить по ходу дела не получится, т.к. стоимость производства в отличие от софта далеко не ноль. Что знают? Что мешает это знать без скрама? А нужно ли всем участникам это знать? Не будет ли это "знание" отвлекать их от своей конкретной и сложной работы? Это нужно знать всем участникам команды? Зачем? Об этом нужно знать тем, кто к этому причастен. Это узнаётся адресно без всяких скрамов. При правильной организации работы есть её руководитель, который всё аспекты курирует (или назначает ответственных, если задач много). И для этого скрам нужен? А как же без него-то обходились десятки лет и продолжают обходиться? Когда приступать к выпуску КД -- очевидно на этапе РКД. Ну да, тут никак не обойтись без планирования спринта, дейликов, ретры. Ведь все разработчики должны быть в курсе, когда же надо отдать корпус в покраску. И уж стопроцентно это должны знать скрам-мастер и продукт овнер. Ну, если потеря кучи времени и отвлечение на посторонние процессы, зачастую искусственные и бесполезные, как натягивание работы на сторипоинты, никого не расстраивает, то пожалуй поверю. 🙂 Ну, о чём и речь -- годится только для простых и понятных задач, которые ясно, как делать, можно достоверно спрогнозировать трудозатраты и т.п. Словом -- не про разработку. Логистика, снабжение, какие-то уже более-менее отлаженные производственные процессы, когда есть опыт, на который можно опереться. В разработке нового такого опыта как правило нет, поэтому всё это скрам-планирование идёт лесом. Ну, удачи вам

Возьмем на оплачиваемую стажировку студентов технических ВУЗов с минимальным опытом разработки под STM32&ESP. Оплата до 100 тысяч, возможность совмещения с учебой.

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

положительным примером, видимо, был бы такой: и так по 12 часов с перерывом на обед 🙂

А причем тут печки? У меня вот ровно такая плавкапро на пять литров стоит дома для тестов. И? Мне-то контроллер для этой печки нужен. На диапазоне +20;+40 хватит одних коэффицентов pid-а, на +20;+1200 если хочется поддерживать любую температуру, не хватит, нужны разные на разные диапазоны. На +1200 сильно расходуются спирали, на +40 нагреватель с 1мм спиралями будет жить вечно, а на 1200 — часов 300. Причем к концу у него сильно возрастет сопротивление и греть этот обьем он будет в два раза дольше, что скажется на тепловложении в керамику — будет пережженая. Именно для этого нужен расчет "конусов", когда по реальному графику температуры из печи математически можно сказать, что все, несмотря на то, что пиковой температуры не достигли, уже хватит, на 6 конус хватит. А при +40 все это не надо, спирали вечные, или сдохли, или работают нормально, соотвественно, измерения мощности/тока/сопротивление спиралей тупо не нужно.

Что, в каких объемах сделанное вами уже продается? может и начинать не стоит , раз это первый раз. Может поэтому и нет предложений? потому что те кто в теме разработки и дальнейшего продвижения продукта, как говорят "в теме" и не берутся работать с вами.