Доброе время суток всем. Работаю с пакетом AVRStudio 4.13 build 528 и компилятором avr-gcc 4.1.2 (WinAVR 20070525). После компиляции кода появляется сообщение

Где data, как я понимаю, размер занимаемой RAM памяти.
Что можете сказать по поводу сообщения компайлера, коллеги?
Использую в программе глобальные переменные, к сожалению без них никак, все техтовые данные (char) занесены в FLASH память. Как мне уменьшить размер используемого RAM? Возможна ли еще какая-нибудь оптимизация кода?

и еще:

Порывшись в avr-lib ничего не нашел по этому поводу. Возможно ли это силами winavr.

В одном из форумов выплывал подобный вопрос, но ответа я так и не услышал.
Заранее спасибо.

Сообщение отредактировал namelos - Sep 20 2007, 13:08

На счёт-

Program: 7092 bytes (43.3% Full)
Data: 41 bytes (4.0% Full)
EEPROM: 54 bytes (10.5% Full)

Я так и не понял - что вы хотите этим сказать?

На счёт - "Как мне уменьшить размер используемого RAM?" - могу выдвинуть на рассмотрение эмпирическое предложение - уже сдесь неоднократно обсуждалось - ГЦЦ интересно заносит данные во флеш - с дубляжом в РАМ. Поисчите - где то здесь вроде обсуждалось как от этого избавится.

На счёт оптимизации - на мой взгляд - Os - самое то, хотя если хитрая программа - приёдётся повозится с кодом - подправить его чуть чуть, а то работать перестанет.

На счёт наставлений Pat`a - то это в принципе давно всем известно, хотя я включал бод и более менее стабилизировал питане - и всё было как по маслу - не нужно было так извращаться с ЕЕПРОМом.
А если всё же интересно как это - НЕ запысывать в 0 ячейку ЕЕПРОМА - пишется за 2-5 минут своя процедура обращения в авр-овскому еепром(основное время уходит на нахождение в ДШ нужной страницы ) - и проблема решена.

По поводу gcc обыскал форум, но ничего не нашел, к сожалению.
Kuzmi4, a что за бод вы включали? И мне бы еще ссылочку на ДШ...

2 namelos -
На счёт ГЦЦ - "...Пилите Шура , пилите.."(С)

На счёт БОДА - Исчите в ДШ на ваш камень в разделе фузов(в ДШ на мегу 48/88/168 это можно найти на странице 287).

Если же вы имелли ввиду работу с ЕЕПРОМ - то например в ДШ на мегу 48/88/168 это можно найти в разделе 6.6, но вам нужна страница 25..

У вас и так используется всего 4% от всей памяти данных, куда ж еще уменьшать то?

2 defunct, да заинтриговал меня Kuzmi4 этой фразой еще на другой ветке, вот и пытаюсь выяснить, он "пилите, Шура, пилите"..

Сообщение отредактировал namelos - Sep 20 2007, 21:24

2 namelos - ну где то тут встречал я рассдуждения по поводу , как говорится , поставил галочку, а где это было нету времени вспоминать и искать..

Пользуюсь avr-gcc где-то с 2001-2002 года. Впервые слышу о таком "интересно заносит данные во флеш" - или это кривые руки, или кто-то "слышал звон" и раззвенел дальше, а народ и повёлся.

Если я чего не понял, то речь о том что Gcc в стартапе копирует все константные переменные
в RAM из Flash, делает он это только с одной целью, ускорить обращение к этим константам.
Просто автар написав const перед константной переменной, видимо решил что эта константа
будет хранится в флеш...
В Gcc для того что бы константы не перегружалась из флеш в RAM об этом нужно явно указать.

Кто о чем
Вроде речь о RAM и EEPROM шла, а не о флеш.
Данные EEPROM в GCC не дублируются в RAM.


Дык, файл <eeprom.h> к вашим услугам. Посмотрите, поизучайте, и меньше на интриги поддавайтесь.

Перечитайте с начала, вопросов было 2,
один про флеш, другой про EEPROM

"ах, так вы об этом..."

const указывает только на запрет изменения переменной из программы, а не на то, что она должна быть размещена во флеше. Стандарт есть стандарт и все вне-стандартные вещи (стандарт ничего не знает о флеше) нужно явно указывать.
Надеяться на то, что const автоматически поместит переменную во флеш можно только на неймановской архитектуре (единое адресное пространство) - компилятор может "соптимизировать" константную переменную и разместить её во флеше ("раз её всё равно не будут менять - пусть лежит там, где это невозможно и не занимает память дважды").
Если это происходит на гарварде без дополнительных компиляторо-зависимых слов code / __flash / __attribute__((__progmem__)), то компилятор не прав.

И дело тут вовсе не в "ускорении доступа" как таковом, а в том, что указатель на тип T должен без проблем передаваться как указатель на const T и присваиваться соответствующим указательным переменным.
Например, имеем функцию с таким прототипом (функции стандартной библиотеки имеют стандартизованные прототипы).
char *strcpy(char *s1, const char *s2);
Указатель s2 квалифицирован как указатель на константный объект, функция его не изменяет. Но в качестве s2 должно быть можно передавать и указатель на неконстантный объект - как следствие, char[] и const char[] должны лежать в одном пространстве памяти.

Хотя, конечно, вопрос можно свести к "быстродействию" - если все указатели в программе для гарвардской архитектуры сделать универсальными, несущими в себе признак адресного пространства (3-байтовыми для AVR), то ничего никуда не надо будет копировать, всё будет практически работать одинаково медленно . Но если указатели на данные имеют "родной" размер, то компилятор обязан const размещать там же, где и не-const.

Попробйте добавить в CFLAGS:



Но я это не тестировал.

Анатолий.

Сообщение отредактировал aesok - Sep 22 2007, 07:21

Поступил просто. Ввел еще одну константу в самом начале и после каждой операции чтения или записи ЕEPROM обнуляю указатель


Ну и конечно, благодарю всех за ответы.

Сообщение отредактировал namelos - Sep 24 2007, 13:35

У меня с константой не прошло. Работает только при O0. При Os уже мои данные в 0 адресе