|
WinAVR(avr gcc 4.1.2): использование RAM и ЕЕПРОМ, компилятор |
|
|
|
Sep 20 2007, 12:34
|
Частый гость
 
Группа: Свой
Сообщений: 77
Регистрация: 4-08-06
Пользователь №: 19 324

|
Доброе время суток всем. Работаю с пакетом AVRStudio 4.13 build 528 и компилятором avr-gcc 4.1.2 (WinAVR 20070525). После компиляции кода появляется сообщение Цитата Program: 7092 bytes (43.3% Full) Data: 41 bytes (4.0% Full) EEPROM: 54 bytes (10.5% Full) Где data, как я понимаю, размер занимаемой RAM памяти. Что можете сказать по поводу сообщения компайлера, коллеги? Использую в программе глобальные переменные, к сожалению без них никак, все техтовые данные (char) занесены в FLASH память. Как мне уменьшить размер используемого RAM? Возможна ли еще какая-нибудь оптимизация кода? и еще: Цитата Pat: Желательно и необходимо после операции записи чтения EEPROM указатель адреса EEAR = 0 Нулевую ячейку EEPROM соответственно не использовать. Порывшись в avr-lib ничего не нашел по этому поводу. Возможно ли это силами winavr. В одном из форумов выплывал подобный вопрос, но ответа я так и не услышал. Заранее спасибо.
Сообщение отредактировал namelos - Sep 20 2007, 13:08
|
|
|
|
|
Sep 20 2007, 13:27
|

Гуру
     
Группа: Свой
Сообщений: 3 304
Регистрация: 13-02-07
Из: 55°55′5″ 37°52′16″
Пользователь №: 25 329

|
На счёт- 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 минут своя процедура обращения в авр-овскому еепром(основное время уходит на нахождение в ДШ нужной страницы  ) - и проблема решена.
|
|
|
|
|
Sep 20 2007, 21:22
|
Частый гость
 
Группа: Свой
Сообщений: 77
Регистрация: 4-08-06
Пользователь №: 19 324

|
Цитата(Kuzmi4 @ Sep 20 2007, 17:27)  На счёт - "Как мне уменьшить размер используемого RAM?" - могу выдвинуть на рассмотрение эмпирическое предложение - уже сдесь неоднократно обсуждалось - ГЦЦ интересно заносит данные во флеш - с дубляжом в РАМ. Поисчите - где то здесь вроде обсуждалось как от этого избавится. 2 defunct, да заинтриговал меня Kuzmi4 этой фразой еще на другой ветке, вот и пытаюсь выяснить, он "пилите, Шура, пилите"..
Сообщение отредактировал namelos - Sep 20 2007, 21:24
|
|
|
|
|
Sep 21 2007, 20:08
|
дятел
    
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065

|
Цитата(ReAl @ Sep 21 2007, 23:32)  Пользуюсь avr-gcc где-то с 2001-2002 года. Впервые слышу о таком "интересно заносит данные во флеш" - или это кривые руки, или кто-то "слышал звон" и раззвенел дальше, а народ и повёлся. Если я чего не понял, то речь о том что Gcc в стартапе копирует все константные переменные в RAM из Flash, делает он это только с одной целью, ускорить обращение к этим константам. Просто автар написав const перед константной переменной, видимо решил что эта константа будет хранится в флеш... В Gcc для того что бы константы не перегружалась из флеш в RAM об этом нужно явно указать.
|
|
|
|
|
Sep 21 2007, 22:58
|

кекс
     
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326

|
Цитата(singlskv @ Sep 21 2007, 23:08)  в RAM из Flash Кто о чем  Вроде речь о RAM и EEPROM шла, а не о флеш. Данные EEPROM в GCC не дублируются в RAM. Цитата(namelos @ Sep 21 2007, 00:22)  да заинтриговал меня Kuzmi4... Дык, файл <eeprom.h> к вашим услугам. Посмотрите, поизучайте, и меньше на интриги поддавайтесь.
|
|
|
|
|
Sep 22 2007, 07:19
|

Нечётный пользователь.
     
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417

|
Цитата(singlskv @ Sep 21 2007, 22:08)  Если я чего не понял, то речь о том что Gcc в стартапе копирует все константные переменные в RAM из Flash, делает он это только с одной целью, ускорить обращение к этим константам. Просто автар написав const перед константной переменной, видимо решил что эта константа будет хранится в флеш... В Gcc для того что бы константы не перегружалась из флеш в RAM об этом нужно явно указать. "ах, так вы об этом..." 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.
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
Sep 22 2007, 07:21
|
Знающий
   
Группа: Участник
Сообщений: 596
Регистрация: 26-05-06
Из: Москва
Пользователь №: 17 484

|
Цитата(namelos @ Sep 20 2007, 16:34)  Цитата Pat: Желательно и необходимо после операции записи чтения EEPROM указатель адреса EEAR = 0 Нулевую ячейку EEPROM соответственно не использовать. Порывшись в avr-lib ничего не нашел по этому поводу. Возможно ли это силами winavr. В одном из форумов выплывал подобный вопрос, но ответа я так и не услышал. Попробйте добавить в CFLAGS: Код -Wl,--section-start=.eeprom=0x810001 Но я это не тестировал. Анатолий.
Сообщение отредактировал aesok - Sep 22 2007, 07:21
|
|
|
|
|
Sep 24 2007, 13:30
|
Частый гость
 
Группа: Свой
Сообщений: 77
Регистрация: 4-08-06
Пользователь №: 19 324

|
Цитата Pat: Желательно и необходимо после операции записи чтения EEPROM указатель адреса EEAR = 0 Нулевую ячейку EEPROM соответственно не использовать. Поступил просто. Ввел еще одну константу в самом начале и после каждой операции чтения или записи ЕEPROM обнуляю указатель Код uint8_t zero EEMEM=0; void write(void) { eeprom_write.. EEAR=0; } Ну и конечно, благодарю всех за ответы.
Сообщение отредактировал namelos - Sep 24 2007, 13:35
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|