ОК Что может быть проще.
Берем M8515 @16Mhz. Включаем внешнюю шину. Стоит ли продолжать?


предварительно заполняем массив из 37 элементов данными которые хотим слать и передаем указатель на этот массив в IO_Transfer. PC7 - признак работы нашего "serial" канала.

Строб снимаем с сигнала W. Данные с ШД.

Ну, а если перенести на другой проц, будет та же самая программа? А там ШД нет, и W тоже нет, как быть? Да и на "нарезку" данных у вас уйдёт вагон времени, мы так не договаривались(:-).

Думать. В каждом конкретном случае - думать. И написав десяток строк даже самых лучших строк на ASM не закрывать глаза и уши на то, что программы по нынешним временам не состоят из нескольких десятков команд и занимаются не только ногомаханием. И контроллеров вокруг изрядное количество всяких и выбирать нужно подходящий не только по приципу знакомого ASM.
P.S.
Сейчас глянул, какой максимальный функциональный кусок на ASM я написал за последние несколько лет - ровно 50 команд . Причем это не из-за скоростных наворотов - это минимальный обработчик exceptions для ARM. На алгоритмических языках такое просто нормально не пишется.

Задачи такого рода, можно сказать классический пример задач для FPGA/CPLD.
Отдавать всю производительность МК под эмуляцию железа конечно можно, но это не всега будет рациональным решением.

Если эта функция - самоцель (i.e. это ВСЯ или значительная часть работы которую должен делать МК), то я не побрезгую написать всю такую небольшую программу на асм'е. Если же это только 1% или меньше от всего задания, я предпочту аппаратное решение интерфейса и простую программную обертку на C.

Краткие выводы из всех наших долгих разговоров.

1) Эксперимент показал (Юра, извини), что сишные программы не так уж и переносимы, как принято думать.
2) На переносимость влияет не только периферия, но и архитектура процессора. Например, один из самых простых алгоритмов в моём проекте - вычисление комплексного спектра аналитической функции - практически невозможно переложить с си-программы авр на си-программу дсп, ручками придётся добиваться "адекватности" алгоритма системе команд и архитектуре.
3) Из порядка 100 файлов проекта примерно 70 написаны на асме, причем последние занимают 90% процессорного времени. Поэтому каждую асм-программу приходилось тщательно вылизывать.
4) Применение аппаратных решений в виде FPGA приветствуется, но дорого, особенно для больших серий.
5) Пожелание начинающим имбеддерам: знание ассемблера применённого проца обязательно.
6) Из моего опыта. Все асм-программы я оформляю в соответствии с конвенциями вызова из си-программы, очень удобно, не надо беспокоиться, из какой программы они вызываются.

Из 138 файлов текущего проекта c размером бинарника 202623 байта работающего на контроллере ценою менее 6USD на ASM писаны три:
- стартап;
- переключатель контекста;
- memcpy/memmove/memset (на самои деле традиция оставшиеся со времен хреновенькой библиотеки IAR V4 - убрать можно)
В сумме байт 300. Процентов 55 проекта это просто ранее работавший код на 51, 186 контроллерах и 486 под линуксом. Остальной просто новый . Дописав/переписав не более 1000 строк из 65333 я перенесу его на, практически любой приличный контроллер.

Вот такие выводы , понимаш.... Посему с очередными рассуждениями о писательстве на ASM, тем более в совершенно не для этого созданной ветке завязываем.

Я бы ещё отметил, в дополнение к сказанному, что есть мелкие камни стоимостью менее 1$. Та же м8 к примеру. Есть и другие аппаратные решения. В связи с этим необходимо осмыслить необходимость вылизывания задачи до уровня загрузки проца 99%, что приведёт к некоторым сложностям по развитию проекта. А попробовать разбить задачу на несколько. Либо подобрать такой МК, который будет соответствовать решаемой задаче с некоторым запасом производительности.

Безусловно, что выбор за разработчиком.

Вообще, так и делалось. Сначала был выбран TMS320F2812, 150 МГц такт, 128 Кб флеши, потом по мере выработки и устаканивания концепции плавно опустились до TMS320F2810 и TMS320F2808, и наконец, до TMS320F2801, куда планируется заливать фирменный софт, уже масочный. Даже в последнем проце ресурсы задействованы примерно на 80%. По стоимости первый проц и последний различаются раза в 4. А вылизывания особого не было, как писалось, так и писалось, с максимальным быстродействием по возможности.

В массовых изделиях, совершенно обосновано максимальное вылизывание проекта, включая ассемберные вставки. Безусловно это оправдано только в случае стопроцентной уверенности в "правильности прошивки". А это предполагает чёткий алгоритм тестирования всего изделия.

Если брать саму тему, то приятно что в моделях XMEGA данная проблема решена со всех сторон.
1) Предусмотрены приоритеты прерывания, что избавляет от необходимости разрешать вручную влож. прерывания
2) Увеличена тактовая частота, что позволяет быстрее обработать прерывание
3) Тактирование таймера предусматривает возможность умножения частоты
(Я о первоначальной задаче)