Несколько моментов про Ваш код:
- вместо цикла for лучше использовать do..while c проверкой size_t n == 0 только в самом начале..
- написав отдельно src++ и вызывая стандартные функции Вы сами себя лишили возможности
пользоваться автоинкрементом при доступе к данным в RAM
- каждая из функций eeprom_xxx будет ждать флага освобождения EEPROM
- каждая из функций eeprom_xxx будет прописывать один и тот же адрес в EEAR

попробуйте это отрихтовать и удивитесь лаконичности полученого кода...

Нашел. Это паскалевский стиль. Обнаружился древний, почти безусловный рефлекс: как только в программе забрезжит хоть какой-то намек на ввод-вывод, бежим как от огня от перечислительных типов. Применительно к "С" это распространилось и на битовые поля. Так что, могу на любом языке, как на паскале.

Кстати, был еще один рефлекс: клавишу F2 нажимать каждые 15 секунд. Ох и долго избавлялся!


Спасибо! Рихтуем, удивляемся...

Вотъ, это тоже хотелось бы обсудить, хотя конкретно это, я уже пытался обсуждать,
но большинство опонентов высказалось в том смысле, что в IAR удобно обращаться к
таким(EEPROM) переменным и все тут...

А сейчас я вот задался интересным вопросом, если кто еще не заметил, в новых AVR (mega48/88/......)
есть такая фича, можно отдельно стирать ячейку и можно отдельно ее программировать...

Вопрос:
кто-нить уже пробовал записать в ячейку 2 раза без стирания ?
ИМХО, это открывает новые возможности для увеличения количества записи в eeprom,
но конечно, этот факт, требует дополнительной проверки, добровольцы есть ?

Ребята, может бить мой вопрос покажетса смехотwорным
но все- таки.
Если нужно умножить два восьмибитних числа и получить 16 битный результат достаточно написать
что то вроде
mul r16, r17 (конечно только для mega AVR)
и читать результат из пары r0,r1.
На C приходится писать
int result = (int)a * (int)b; или int result = (int)a * b; (a и b 8 битные)

Так как если написать int result = a * b то компилятор согласно правилам языка C сначала генерирует mul а потом обнуляет старший байт (результат умножения двух char получается в виде char и потом толко присвоивается int у)

А код скомплированный в результате int result = (int)a * (int)b; получаетса очень громоздкий, так как умножаяютса два 16 битных числа не обращая внимания на то что в старших байтах нули

чтобы решить проблему скорости мне пришлось в проекте написанном на C писать int result = a * b потом из сгенерированного асм листига вручную удалить clr r1 после mul-а и сгенерировать hex фаил в AVR Studio

А есть вообще грамотный способ решения таких проблем в C коде?

Сообщение отредактировал Artak - Feb 21 2008, 23:28

В IAR'е можете написать __multiply_unsigned( a , b ) - это непосредственно сгенерит mul. Для портабельности не забудьте на этапе компиляции проверить текущий процессор и компилятор, и если это не AVR и не IAR, сделать #define __multiply_unsigned(var1,var1) ((var1)*(var2)). Про остальные умножения можете прочитать в доке по IAR'у, ключевое слово "Intrinsic functions"

Велосипед уже изобретён. Atmel AN "AVR103"

Поменял for() на while() и убрал лишнее копирование параметра size_t n . Т.е. while(n){}
Дальнейшее улучшение усиливает зависимость от железа, поэтому в данном случае (не библиотечном) не имеет смысла.
Бухгалтерия -12 байт. Итого в гору не более 24 байт на "крайне нежелательную" на первый взгляд функцию.

Спасибо за наводку,
этот апликайшн как-то мимо меня пролетел...

Теперь про асм.
В контексте многопоточного программирования очень полезно использование итераторов.
Пример:


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


В приведенном примере внешний цикл описан в func3, в котором вызывается внутренний цикл, описанный func2. Примерный сишный эквивалент

... но в условиях кооперативного распределения ресурсов

P.S. Исправил примеры func2, func3. Была ошибка в загрузке Z. Кому интересно, обратите внимание.

По стандарту языка С те два a,b обязаны быть приведены к int до выполнения команды умножения. Т.е. явне приведения не нужны, результат должен быть правильным. Иначе - в топку компилятор, С хорош стандартом, если для каждого компилятора надо менять привычки - то тогда проще на асме писать.





avr-gcc -O2 -S -mmcu=atmega8

Ну да, clr r1... Но уже после переноса результата умножения в пару R25:R24, так как по соглашениям avr-gcc регистр R1 содержит константу 0 (я бы предложил попробовать переделать это хозяйство на два временных регистра __tem_reg_l__, __temp_reg_h__ и R2 как константу 0, чтобы не мучиться каждый раз после умножения, но неизвестно, как занятие R2 скажется на остальном).

В общем, наигрался я с "С". Память заканчивается, а проект лежит. Теперь переписываю на асме. Размер кода обещает быть в 2 раза короче (к слову о больших проектах). Да и пишется все по-быстрому, если знаешь, что делаешь. После чего все эти компиляторы, расплодившиеся в последнее время у меня в компе, летят в корзину. То же самое, кстати, касается и pic18 и dspic30/33 и HCS08, коими я иногда страдаю. Компилятор-то, оказывается, в голове...

Совет для того чтобы память не заканчивалась в проектах на "C"
1. Делать стек большим, а глобальных переменных поменьше.
2. Использовать heap.

Такая разница может получиться ТОЛЬКО на вычислительных алгоритмах и в основном
в местах где при использовании С необходимо делать преобразование типов,
ну или для вариантов когда просто в С нет соответствующего размера типа,
например в С нет 3-байтовых переменных...

Для остальных вариантов..., ну показывайте код что ли, думаю что после некоторой оптимизации
он Вас опять же сможет удивить...


Вот здесь хотелось бы разъяснений и поподробнее...(без подколок...),
я не понимаю как уменьшить количество глобальных переменных.
Я не понимаю как можно использовать heap для уменьшения расхода памяти вместо
использования глобальных переменных...

хм, а чего тут не понятного?

Содержательный ответ, а примерчик не подкините ?