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

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

и еще:

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

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

На счёт-

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 этой фразой еще на другой ветке, вот и пытаюсь выяснить, он "пилите, Шура, пилите"..

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:



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

Анатолий.

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


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

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

Странно. И куда же записывалась первая константа? Я проверил, запись констант EEPROM при Os начинается с 0 адреса, ввел в начале дополнительную константу, она размещается под 0-адресом.

Ну вот примерно так:

#include <avr/io.h>
#include <avr/eeprom.h>


uint8_t EEMEM non_zero = 31;
uint8_t EEMEM store = 6;
unsigned int tmp;

int main (void)
{
tmp = eeprom_read_byte(&store);
while(1)
{
;
}
return (1);
}

В результате при оптимизации О0 еепром выглядит правильно 0x0000 0x1F 0x06
При Os все не так радужно 0x0000 0x06 0x1F
WinAvr20060421.

Попробуй так

по-моему должно сработать...

Так сработает, но уж очень способ неудобный. А если переменные разных типов, то что - структуру вместо массива???? Тогда уж можно просто eeprom_write_block использовать... В общем удобного решения так и не найдено. Я пробовал секции в еепром создавать, указывая стартовый адрес, но что-то лыжи не едут, а так было бы самым красивым решением. Надо попробовать то,что aesok предложил...

Такие "забобоны" как проблемы с адресом 0 считаю надуманными.
Поступаю так:
Конфигурация устройства с которой я работаю хранится в ОЗУ, в eeprom записывается две копии кофигурации защищенных CRC8. При стартапе хоть одна копия да будет целой, она и читается в ОЗУ целиком, сбойнувшая перезаписывается целой. Если слетели обе копии конфигурации (такого у меня на счету не бывало) - устанавливаются параметры по-умолчанию.

В дополнение к сказанному defunct.
Деле так: пишется блок данных с CRC три раза. Считывается все при старте. Проверяется CRCблока, а далее мажоритарная схема 2 из 3. Проблем не было.