Выбросьте из процедуры отправки все ожидания флага UART, и подсчитайте симулятором, что останется.
Еще раз говорю: это 0, ловить тут абсолютно нечего.

Я уже это сделал, но на переключенния задач все равно уходит время, а так его можно было бы уменьшить. И второе: думаю добавить простой цифровой фильтр: (режекторный готов - но он огромен для МК (на первый взгляд): необходимо перемножать массив на матрицу коэффициентов - явно могу не уложиться в 200-300 мс ) и второй - попробовать использовать медианный фильтр (может получиться меньше). Хотя этот вопрос еще требует проработки - какой из двух вариантов имеет наименьшую фазовую нелинейность.

А может, взять нормальные средства (можно и бесплатные) и, возможно, контроллер помощнее? На AVR и ICC свет клином не сошелся, как это ни странно.

AVR не хочеться без нужды менять (тем более я его использую процентов на 20-30), думаю возможностей Xmega должно хватить на простой цифровой фильтр.
ICC сейчас меняю на новую версию с оптимизацией (кода и глобальной), но пока ну очень трудно обяснить нашему дистрибьютеру что хочу - у них человек уволился, а нового кто сображает пока нет - радует что еще и макетки не готовы по Xmega.

Поменять AVR на XMega и поменять на что-то другое (дешевле и лучше, ага) - по-моему, принципиальной разницы по трудозатратам нет.

Особенно на ICC

Кстати, адептам целочисленных вычислений хотелось бы напомнить, что правильное умножение float*float практически эквивалентно перемножению long*long. В реализации для процессоров, не имеющих аппаратного деления (AVR в их числе) деление float'ов и long'ов тоже несильно отличается. О(1), не побоимся этого слова.

Зато есть финансовая разница! (Уже сейчас по Xmega есть все для начала работы (кроме макеток конечно - но я уже писал, это не просто макетка - на ней будет все чтобы сделать готовое изделие (то же направление)).
Основным сдерживающим фактором перехода на другой МК - это требования заказчика (по направлению измерения сейсмосигналов) - НИ какой цифровой обработки!!! (Не знаю, согласиться на простой фильтр или нет - а то может зря код оптимизировали). А без цифры - AVR за глаза хватает.
Да и переход на Xmega - вообще то довольно таки не трудный (DMA я и так не знаю в любом МК -все равно изучать, а шифрование - мне даром не нужно - специфика применения устройства) - остальные вопросы: АЦП, ЦАП, таймеры, порты, UART, SPI, прерывания, часы .... простые программы уже написал - жду железа чтоб пробовать. А большая часть кода - вообще не будет меняться при переходе.

Зато появляется некоторый оверхед на перегнать туда-назад.


Это, скорее, не сдерживающий фактор
Просто колупаться с обкоцанным ICC - это как-то уж совсем не комильфо.

Думаю что ни на сколько.
На мой взгляд основной тормоз у вас это блокировка отпраки данных длинным обработчиком INT6 (SPI +вычисления).

Если переделать алгоритм работы программы, а именно.

1. передачу по UART сделать по прерыванию.
2. Int6 сделать максимально возможно коротким - только взводить флажек готовности считывания АЦП.
3. Всю галиматью, с вычислениями и считыванием данных с АЦП через SPI, переместить в основной цикл программы. Выполнять ее тогда когда флажек готовности считывать АЦП установлен, после чего сбрасывать этот флажек.

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


Даже начальный вариант с 2971 циклов, с лихвой годится для обработки любого тормозного сигма-дельта АЦП.
Банальная арифметка.
У Вас 3 АЦП, пусть 1KSPS, тогда всего циклов нужно:
2971 * 3 * 1000 = 8.913M

т.е. если будете тактировать МК частотой 14.7456Mhz, МК должен простаивать ~50% времени, даже в первоначальном варианте.
У вас же я так понимаю вообще 500SPS. Если же имеют место тормоза, проблема не в нехватке ресурса, не в проце и не в компиляторе, а неправильном распределении ресурса. (программа построена неверно).