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

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

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

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

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



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

Пишу для ATMega48

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

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

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

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

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

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

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

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

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


Где ошибка?

или

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

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

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

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

На конструкцию
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 массив определить.




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

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

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

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

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

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

Решение оказалось весьма простым.
Нельзя вставлять определение такого массива в тело 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 предупреждений.

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

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

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

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

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


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

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

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

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

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

Я работал из 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

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

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

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

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

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

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

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

static unsigned char n_adc;

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

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

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

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

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

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

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

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