Буду очень рад если кто то переработает или дополнит вышеописанное
В целом правильно. Только одно "но": разработка схемы это в общем случае тоже творческая задача, как и создание алгоритма.
Но вообще, на более высоком уровне философской абстракции, все это конечно сводится к понятию, называемому декомпозицией задачи, а также последующему синтезу решения на основе уже известных фактов. Алгоритма ли, схемы ли - тут уже не так важно.
Смысл такой - на этапе декомпозиции мы думаем, как разбить задачу на кусочки, которые мы уже умеем решать. А на этапе синтеза - складываем из имеющихся кусочков решение по тем правилам, которые придумали на первом этапе.
Есть такая занимательная штука, теория научного познания. Там много внимания уделяется в частности и декомпозиции/анализу/синтезу.
YS спасибо!
Ой, не за что.
почувствовал себя приматом
Не обижайтесь, просто ув. Леонид Иванович бывает несколько склонен к фатализму.
Я всегда удивляюсь, когда говорят о программировании МК как о чем то особенном.
Ну, там, несомненно, есть своя специфика - это видно хотя бы по тому, что программисты-прикладники, успешно "щелкающие задачки", чаще всего испытывают неслабый шок при знакомстве с эмбедом.
Хотя отчасти это, конечно, связано с тем, что эмбед предполагает прежде всего знание схемотехники, которого у большинства прикладников нет.
Но что правда, так это то, что, если освоить специфику, переход между семействами МК и языками/средами уже не пугает.
Разница между теорией и практикой на практике гораздо больше, чем в теории.
и сразу нашел 
- метод Прямого Доступа в Память используется давно и в разных конструкциях (начиная с первых самоделов с микропроцессорами и ПК). Только у конкретных современных МК требуется конкретный даташит "перелопатить" из-за дополнительных аппаратных наворотов и рекламной "шелухи" производителя.
