Портирование кода для AVR с IAR под GCC Опции

[cvv]

Вобщем после удачной компиляции и прошивки схема перестала работать. Такое впечатление что IAR выполнил какую-то неявную дополнительную настройку или что-то подобное

подскажите с чего начать разруливать ситуацию ато в микроконтроллерах я новичок

[Сергей Борщ]

Такое впечатление что IAR выполнил какую-то неявную дополнительную настройку или что-то подобное

В IAR иначе ("прямее") организована работа с данными в флеш и eeprom. Ищите в коде ключевые слова __eeprom, __flash, читайте WinAVR/DOC/avr-libc/FAQ.html и WinAVR/DOC/avr-libc/index.html.

[cvv]

В IAR иначе ("прямее") организована работа с данными в флеш и eeprom. Ищите в коде ключевые слова __eeprom, __flash, читайте WinAVR/DOC/avr-libc/FAQ.html и WinAVR/DOC/avr-libc/index.html.

ключевые слова eeprom && flash заменил на аналоги GCC.

кстати пользую не WinAVR а cdk4avr который в частности содержит более свежий GCC

ключевые слова eeprom && flash заменил на аналоги GCC.

но Это повлияло только на то что прошивки стали влазить во флеш и епром соответсвенно.

Пишу для ATMega48

[Сергей Борщ]

ключевые слова eeprom && flash заменил на аналоги GCC.
но Это повлияло только на то что прошивки стали влазить во флеш и епром соответсвенно.

Прочитайте FAQ по приведенной мной ссылке в папке документации WinAVR (или где в вашем пакете лежит документация на avr-libc). Замены ключевых слов недостаточно - надо изменить и обращения к таким переменным.

[mdmitry]

кстати пользую не WinAVR а cdk4avr который в частности содержит более свежий GCC

По поиску cdk4avr ссылки на середину 2007 г, а WinAvr 2007-12-20

[733259]

По поиску cdk4avr ссылки на середину 2007 г, а WinAvr 2007-12-20

В последних WinAvr gcc 4.x.x - ИМХО не лучший вариант, код больше, оптимизация хуже.

[cvv]

В последних WinAvr gcc 4.x.x - ИМХО не лучший вариант, код больше, оптимизация хуже.

Поддерживаю... gcc 4.x.x - редкий sucks

а вообшето я поначалу собирался сам скомпилить gcc но потом передумал.

[733259]

а вообшето я поначалу собирался сам скомпилить gcc но потом передумал.

Может стоит собрать gcc 3.4.6 и новые binutils для собственного спокойствия от багов (в cdk4avr вроде 3.4.5).

[cvv]

Может стоит собрать gcc 3.4.6 и новые binutils для собственного спокойствия от багов (в cdk4avr вроде 3.4.5).

Если необходимость встанет ребром то придется...

[cvv]

* Главная проблема была в кривизне прошивки - она не стартовала до получения команды с последовательного порта

[gte]

Надо разместить таблицу с двухбайтными значениями в памяти программ (WINAVR).
Почитал FAQ, конференцию, Яндекс. Написал следующий код.
При трансляции ошибок нет.
Значения с таблицы не считывет.

Код

{
unsigned int dac_cod = 0;
const unsigned int *data = table_v;

uint16_t table_v[] = {0xAAAA,0x0600,0x5B00,0x4F00,0x6600,0x6D00,0x7D00,0x0700,0x7F00,0x6F00,0x8000,0x
7D00,0x0700,0x7F00,0x6F00,0xAAAA};

dac_cod =pgm_read_word(data);
}

Где ошибка?

[ReAl]

Значения с таблицы не считывет.

Код

uint16_t table_v[] = {0xAAAA,0x0600,0x5B00,0x4F00,0x6600,0x6D00,0x7D00,0x0700,0x7F00,0x6F00,0x8000,0x
7D00,0x0700,0x7F00,0x6F00,0xAAAA};

Где ошибка?

const uint16_t table_v[] PROGMEM = {0xAAAA,0x0600,0x5B00,0x4F00,0x6600,0x6D00,0x7D00,0x0700,0x7F00,0x6F00,0x8000,0x
7D00,0x0700,0x7F00,0x6F00,0xAAAA};

или

const prog_uint16_t table_v[] = {0xAAAA,0x0600,0x5B00,0x4F00,0x6600,0x6D00,0x7D00,0x0700,0x7F00,0x6F00,0x8000,0x
7D00,0x0700,0x7F00,0x6F00,0xAAAA};

[MrYuran]

У меня была проблема при переходе с ИАР на MSPGCC (под MSP430)
идеальный код, зацепиться не за что.
А в девайсе не работает ни в какую.
Мучался с неделю, пока один старший товарищ не заметил (опыт не пропьёшь!), что ИАР формирует файл прошивки несколько иначе, чем средства GCC.
Проблема была в формате текстового файла (hex,ti-text - не суть)
GCC формирует текстовик в линуховом формате - то есть в конце строки ставится только один символ - 0x0D, в то время как в формате MS(DOS,Win - не важно) положено 2 символа - 0A 0D.

А прошивал я старыми привычными средствами.
В результате загрузчик не находил конца строки (0А), а 0D прошивал в процессор, в результате там оказалась полная лажа.

Короче, резюме: при использовании GCC загрузчик должен быть соответствующий, либо нужно преобразовывать формат файла прошивки.

Не совсем в тему, конечно, речь-то идёт об AVR, но может кому пригодится, чтобы не страдали как я

[gte]

На конструкцию
const uint16_t table_v[] PROGMEM =
дает сообщение
* um_mega8.c, line 268: warning: '__progmem__' attribute ignored

вторую взял,
Static variable address beyond the RAM limit: table_v -> :0x800060
но с предупреждением
Repeated variable name table_v within block. Rename it
Я, так понимаю, пытается в RAM массив определить.

Короче, резюме: при использовании GCC загрузчик должен быть соответствующий, либо нужно преобразовывать формат файла прошивки.

Спасибо. Прошивать буду AVReal, посмотрю за этим моментом.

[xelax]

подключи
#include <avr/pgmspace.h>

Должно всё быть ок.

[gte]

Все стоит в начале файла

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <stdio.h>

Я все запускал из под VMLAB с ее стандартным make
Уже пробую запустить из самого WINAVR.

[gte]

Решение оказалось весьма простым.
Нельзя вставлять определение такого массива в тело main.
Как только я вынес определение из main в начало файла, все стало на свои места.

Может кто дать комментарии к оставшимся мообщениям?

Converting to AVR COFF: um1.cof
avr-objcopy --debugging --change-section-address .data--и т.д.
Warning: no "data" section found in output file
Warning: file C:/WINDOWS/TEMP/cciw0ld7.s not found in symbol table, ignoring
Warning: ignoring function __vectors() outside any compilation unit
Warning: ignoring function __bad_interrupt() outside any compilation unit
c:\winavr\bin\avr-objcopy.exe: --change-section-vma .eeprom+0xff7f0000 never used

и еще 5 предупреждений.

[cvv]

Решение оказалось весьма простым.
Нельзя вставлять определение такого массива в тело main.
Как только я вынес определение из main в начало файла, все стало на свои места.

скорее всего его надо было пометить как static так как любые массивы обьявленные без статик внутри ф-и располаются *исключительно* в стеке а ты хотел во флеш.

Сообщение отредактировал cvv - Mar 24 2008, 12:51

[gte]

скорее всего его надо было пометить как static так как любые массивы обьявленные без статик внутри ф-и располаются *исключительно* в стеке а ты хотел во флеш.

Попробовал.
На PROGMEM не ругается, но пишет
Repeated variable name table_v within block. Rename it

[Сергей Борщ]

На PROGMEM не ругается, но пишет

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

[mdmitry]

Попробовал.
На PROGMEM не ругается, но пишет
Repeated variable name table_v within block. Rename it

Попробуйте переименовать название вашей таблицы. Внутри gcc в библиотеке возможно есть служебный буфер с таким именем.

[gte]

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

Код

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>

const uint16_t table_v[] PROGMEM = {0xAAAA,0xAAAA,0x0000,0xAAAA,0x0000,0xAAAA,0x0000,0xAAAA,0x0000,0xAAAA,0x0000,0x
AAAA,0x0000,0xAAAA,0x0000,0x0000};

int  main (void)
{
//const  uint16_t table_v[] PROGMEM = {0xAAAA,0xAAAA,0x0000,0xAAAA,0x0000,0xAAAA,0x0000,0xAAAA,0x0000,0xAAAA,0x0000,0x
AAAA,0x0000,0xAAAA,0x0000,0x0000};
const unsigned int *data = table_v;
const unsigned int *dat_car;

while (0)
        {
           dat_car = data;
        }
}

В main пробовал разные варианты, не проходило, вынес работает.

Может кто дать комментарии к оставшимся мообщениям?

Converting to AVR COFF: um1.cof
avr-objcopy --debugging --change-section-address .data--и т.д.
Warning: no "data" section found in output file
Warning: file C:/WINDOWS/TEMP/cciw0ld7.s not found in symbol table, ignoring
------------

пропадают если выйти и снова запустить VMLAB.

[Сергей Борщ]

Переменные, объявленные вами внутри функции (автоматические переменные), размещаются на стеке. Вы же пытаетесь заставить компилятор разместить переменную во флеш. Но это нонсенс - она не может быть одновременно и на стеке и во флеше. Если вы хотите, чтобы переменная была во флеше и ее область видимости была ограничена функцией, то объявлять эту переменную внутри функции надо с атрибутом static:

Код

int  main (void)
{
    static const  uint16_t table_v[] PROGMEM =

Код

const unsigned int *data = table_v;
const unsigned int *dat_car;

while (0)
        {
           dat_car = data;
        }
}

Здесь вы объявили указатель на int в ОЗУ. К большому сожалению, avr-gcc не отслеживает смешивание обычных указателей и указателей на флеш, хотя фактически это разные указатели Т.е. то, что вы написали, avr-gcc проглотит, но не забудьте потом данные по этому указателю доставать при помщи pgm_read_xxx, а не *data. Лучше такие указатели сразу объявлять как const unsigned int PROGMEM *dat_car; - вам самому потом будет легче читать программу. А когда avr-gcc научится отличать указатели на флеш от указателей на ОЗУ - не придется править старые исходники.

[gte]

Увы, я пробовал разные варианты объявления, в том числе и static (пост 19). Закоментированная строка - копия верхней.

Чтение у меня, действительно, pgm_read_xxx. Делал, как написано в описании WINRAR. Спасибо за совет.

[Сергей Борщ]

Увы, я пробовал разные варианты объявления, в том числе и static (пост 19). Закоментированная строка - копия верхней.

Код

int main (void)
{
    static const  uint16_t table_v[] PROGMEM = { 1,2,3 };
    const unsigned int *data = table_v;
    pgm_read_word(data);
}

Только что откомпилил. Никаких ошибок и предупреждений. WinAVR 20070725. Видимо причина кроется в другой части вашего исходника, которую вы нам не показали.
Откомпилировал и текст из поста 19. При объявлении table_v внутри main как static тоже никаких предупреждений.

[gte]

Я работал из VMLAB.
При компиляции моего примера и Вашего (только примеров, я при удалении остальной части проекта проверял одинаковость сообщений). В VMLAB по прежнему выдается предупреждение, но оно оказалось не при компиляции, я на это не обратил внимание. В WINAVR этого, естественно, нет. Изменение имени таблицы ничего не меняет. При обьявлении таблицы вне main никаких сообщений нет.
Сообщение следующее

Loading COFF file: um1.cof
Flags: Structures/unions info | Default pointers size | Absolute paths
File: um_mega8.c
Function: main
Repeated variable name table_v within block. Rename it
Extracting line nr. to code x-refs
COFF file contains inconsistencies or unsupported features. Debug info could be wrong or incomplete

[cvv]

Repeated variable name table_v within block. Rename it

это не варнинг насколько я понял.

а последняя строчка лично меня смущает

[gte]

Repeated variable name table_v within block. Rename it - слева восклицательный знак шелтый
COFF file contains inconsistencies or unsupported features. Debug info could be wrong or incomplete - слева восклицательный знак красный

[AHTOXA]

Repeated variable name table_v within block. Rename it - слева восклицательный знак шелтый
COFF file contains inconsistencies or unsupported features. Debug info could be wrong or incomplete - слева восклицательный знак красный

Это значит, что при такой конструкции отладочная информация принимает вид, не понятный вмлабу. Ну не умеет вмлаб понимать такие вещи:-)
А почему надо именно в теле функции объявлять этот массив? Это так принципиально?

[gte]

Да нет, я сразу же вынес, откомпилил и зашил в контроллер. Просто за простыми сообщениями иногда кроются большие проблемы.
Кстати, про размер кода. Транслировал из VMLAB, WINAVR, AVRStudio, компилятор тот-же. Настройки, естественно разные, большинство по умолчанию, так как размер кода в данном случае не интересует. Так вот, умудрялся получать размер кода и 8 и 2,5 и 1,3 килобайт. Последний из AVRStudio с оптимизацией Os. Вот в одной известной книге по ARM и пишут, что GCC дает код, который работает на порядок медленнее, чем коммерческие компиляторы.

Понравился осциллограф в VMLAB. Можно быстро визуально оценить результат.

[gte]

В следующей программе переношу код работы с АЦП.
В теле обработчика прерываний (первое и единственное использование) определяется

static unsigned char n_adc;

В WINRAR код разрушен.
Запускаю из VMLAB.
Дает сообщение

Код

Loading COFF file: det_8302.cof
----
---
! Static variable address beyond the RAM limit: n_adc -> :0x800062
-Extracting line nr. to code x-refs
! COFF file contains inconsistencies or unsupported features. Debug info could be wrong or incomplete

. Перенес
static unsigned char n_adc;
в начало файла - все стало нормально. WINRAR -20071221.

[Сергей Борщ]

В следующей программе переношу код работы с АЦП.

Запускаю из VMLAB.

Я думаю, что VMLAB - это не показатель. Надо смотреть листинг и реальную работу в железе. Как вариант - загрузить .elf в студию.

[gte]

Так я обнаружил в AVRStudio4. В общем, когда отлажу программу, еще раз проверю.
Сейчас код уже другой и накладываюся еще какие то проблемы, которые выползают при не нулевом уровне отимизации.

Вы не знаете, стоит использовать sqrt() из gcc с точки зрения скорости выполнения?
Используется в ATMega88.

[Сергей Борщ]

Для "дружбы" с AVRStudio естественным является формат elf. Насколько я понял из документации gcc, coff является несколько устревшим форматом.

Вы не знаете, стоит использовать sqrt() из gcc с точки зрения скорости выполнения?

со слов aesok:

И если будете использовать float подключите 'libm.lib' библиотеку, добавте ключик -lm.
......
Дело в том что есть 2 варианта функций выполняющих действия (+, -, .. сравнения, преобразования в/из int) над float. В libgcc написанные на С и в libm написанные ассемблере. Для того чтобы использовались ассемблерные варианты этих функций нужно подключить libm в командной строке линкера после libgcc.

[gte]

Спасибо, подключил библиотеку результат положительный.
Для AVRStudio использую elf, а coff в VMLAB.

По поводу места определения static unsigned char n_adc;
В отлаженной программе вернул определение переменной в тело подпрограммы. Нормально работает в студии до -О3, код, вероятно правильный. А в VMLAB ругается в том же месте.