Средства и методы разработки

Как учит TDD, пойдем сверху. 1. Вот все эти " выходом в интернет, проигрыванием MP3 и оплатой счетов за коммунальные услуги, а также фиксирующей все подозрительные передвижения по видео с передачей сников по MMS хозяину" - это очень нехилый программизм. Стоит эта "простая" программа немеренно, и уж если мы решили вложить бабло в покупку|тырение|написание совоего софта по теме, то надо, чтобы эта инвестиция работала до нашей пенсии. Значит, эта часть должна быть написана портируемо и инвариантно. Ибо, по большому счету, продаваться будет именно она, а не гениальный драйвер АЦП или нашего супер SPI протокола. 2. Капитализация проекта будет гораздо выше, если это будет не просто решение, а SDK, чтобы системный интегратор средней продвинутости мог купить у нас плату и софтину, и сваять свое собственно решение. Игра стоит свечей!!! 3. На фоне всего этого ограничиваться одним сопроцессором глупо. У нас есть 3 пути: * придумать супер-коенцепцию и никогда ее не сделать * сделать первое, что придет на ум, а потом "пришивать по месту" = Windows до версии Win95 * сделать хорошую концепцию, а потом обрезать ее перед реализацией, заложив "костыли" для наращивания. Это наш путь! 3. Акромя SPI, еще есть старый добрый RS-485. На которые можно повесить море ATmega48, которые будут обрабатывать кучу медленного IO. Хорошо бы, чтобы протокол был идеологически одинаков (хотя понятно, что в варианте 485 придется делать нормальный протокол, с CRC, флагами, и прочими прелестями). 4. Глобальная синхронизация в рамках этий системы категорически важна, ее надо продумывать. 5. Ваша идея кодогенерации элементов протокола - супер! Одобрямс!!! Так что подумать все же стоит, перед тем как в омут нырять. Иначе бабло точно можно потерять.