1. Результат проверил - одинаковый, с точностью до 1 еденицы числа (т.е. если в первом случае 12345678 то во втором и третьем (одинаково) 12345678 или 12345677 - иногда меняеться на 1 еденицу конечный результат - а это +-1 мкВ - меньше чем мзр. АЦП)
2. ImageCraft не требует указания явного обозначения констант, достаточно указать тип переменной и ее значение. (Да и не понимает он таких указаний - я попробывал, препроцессор дает ошибку).
3. Да только в тестовом я так записал константы: реально они пишуться как глобальные константы перед main() - пока ошибок небыло.

Вам должно быть виднее. На сколько, например, 1.077 отражает реальность? Я бы не стал писать больше пяти.


Логично сначала вычесть в целых числах, затем умножить с плавающей запятой.

1. 1,077 отражает разброс С2-29 резисторов в входный аналоговых цепях - расчетное естественно, думаю есть смысл ограничиться 7 знаками (на время не все равно не влияет)
2. Логичнее, да и время выполнения уменьшаться на 21%.
Спасибо.

И все таки хотелось вернуться к первоначальному вопросу:
можно ли уменьшить время выполнения (естественно без учета ожидания флага от UART) кода преобразования и отправки байт по порту в функции void RS232(void) ? (Фактически можно ли как по другому long разбить на 4 байта с большей скоростью и тем же результатам (чтоб не переписывать программу на ЭВМ).

По сравнению со временем ожидания флага все остальные расходы пренебрежимо малы. Фактически более 95% процессорного времени в этой процедуре пускается на ветер.

Да, но пока я жду флаг - работают другие функции (в первую очередь прием новых данных): т.е. я имею ввиду что, написать функциию так, чтобы время ее выполнения равнялось фактически время ожидание флага умноженое на количество переданных байт (близко конечно).

По сравнению с тем временем, что Вы уже отыграли на сокращении вычислений, это 0.

Ну, модифицируйте цикл в передаче, полкопейки может быть выйграете:

Нет, выиграша нет (сдвиг на 24 требует почти 200 циклов).
А если немного переиначить вопрос: весь проект планируеться перевести на Xmega -в нем за счет DMA возможно будет получить выигреш ? Не сильно меняя при этом логику работы программы.

Что-то слабо верится, что компилятор настолько туп. Сдвиг на 24 - это просто взять нужный байт. Или оптимизация выключена?


Ровным счетом то же самое Вы можете получить и сейчас, если перенесете работу с UART на прерывания.

Если вы объявляете их как инициализированные константы, то да, указывать не нужно. Т.к. тип этих констант вы уже определили. А вот если бы вы вдруг воспользовались командами препроцессора то грабли бы сработали в полный рост.

Не сработали , я не люблю #define - через полгода сам не поймешь что писал. (А выдел я таких писателей - переименовывают названия порта чтоб легче - а потом куча вопросов че да как).
Лучше ответить на вопросов - DMA в Xmega может реально ускорить выполнения функции отправки байт (хотя массив с данными и так в ОЗУ находиться) - т.е. делать пересылку автоматом (я запустил и все пока не закончатся).



Оптимизация выключена (не могу обновить свою версию компилятора на расширенную) - так что нечего удивительного.

Выбросьте из процедуры отправки все ожидания флага 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. Если же имеют место тормоза, проблема не в нехватке ресурса, не в проце и не в компиляторе, а неправильном распределении ресурса. (программа построена неверно).