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

микроконтроллер это же просто железка, как шкафчик, двери прикрутил полки поставил и клади туда вино бродить

чую волну элитизма, ушел спать )))

ну или он дид, который кучу архитектур повидал и уже не особо напрягаясь под новую пишет

ну по вот запускали тут проц российский, разработка алгоритма и кодирование с тестированием 4 месяца, запуск зелезки 1 неделя

Кстати, колупаю тут драйвер для ADIN1110. В примере, который они предоставляют, как раз-таки наверчено десять абстракций, HAL на HAL'е.

Еле разобрался, как его портировать. :)

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

То есть, вообще говоря, архитектура софта в продукте может разрастись как гриб ))
И там ОЧЕНЬ много может происходить в софте. Вот в подобных кейсах как раз в 10% кода нужно отличное знание аппаратной части. Дальше уже другие мозги работают

правда тут вот не взлетает кан, и так и сяк ну никак, а нашел что драйвер контрафактный=) Rx пашет а Тх нет

ну тестирование, это отдельная песня. Я к тому, что все еще сильно зависит от архитектуры слоя абстракции, ее поддержки. Чтобы не приходилось всякое на пути подхачивать.

Но в целом да, я соглашусь - это меньшая часть задачи. С бизнес-логикой любви обычно сильно больше.


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

Но все оно сильно от задач зависит, это очевидно

ну тут не поспоришь

Ну так это поломка уровнем ниже. Если все правильно абстрагировано, починил и радуйся жизни. А не так, что "ой, тут в прерывании мы проводим на 100 наносекунд больше и ничего не успевает отработать, все сломалось, все пропало" :D

Да, тут согласен также полностью. Что все зависит от частей, над которыми работаешь и размера команды, кроме всего прочего

тут больше про знание что куда в целом.

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

т.е. ты предлагаешь придходить к тому, кто тебе дал драйвер - и говорить: "чел/учиваха, твой код говно. Сделай с ним что-то"

ЭТо если и работает, то на крупных проектах, где команда много человек и есть команды, которые LL и бизнес-логику отдельно делают

а если ты в одно рыло/два-три рыла пилите то это не так работает. И в первом случае да, прикладной программист, который даже толком может не понимать как работает низкий уровень будет ОК

как по мне

Как ни странно, да. Я в целом за такой подход. Одно большое НО - если там опенсорс, то уж извольте есть говно и править сами.. Ну и коммитить, ессно