0 / 0 / 0
Регистрация: 18.02.2010
Сообщений: 71
1

Eclipse + AVR Eclipse + WINAVR

21.02.2010, 19:39. Показов 22008. Ответов 7
Метки нет (Все метки)

Начал изучать программирование AVR на Cи, для разработки проектов выбрал istypsi в связке с WinAVR. Установил, работает нормально, вроде без глюков. Есть возможность руссификации, правда не полной. Ксати в Eclipse есть ГУИ для AVRdude, у меня получилось прикрутить программатор на FT232RL. Вообщем на мой взгляд удобная среда. Вопрос в следующем может есть у кого русское руководство по данной среде, особенно интересует возможность отладки из данной среды.
__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь
0
Programming
Эксперт
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
21.02.2010, 19:39
Ответы с готовыми решениями:

(Avr Studio + WinAvr) vs (mikroC PRO for AVR)
Сам пользуюсь (Avr Studyo + WinAvr). Ктонибудь использует mykroC PRO for AVR ? Слышал там...

AVR Studio 4.19 +WinAVR - как сделать файл EEPROM ?
Привет! Как в AVR Studyo4.19 + WinAVR (Си) сделать файл EEPROM? Я хочу зашить в EEPROM некий...

Java Eclipse
Ребята, есть может на форуме кто, кто юзал активно яву, в частности istypsi, хочу в готовую сборку...

ST-LINK + Eclipse на Ubuntu
Пытаюсь разобраться с линуксом. Первые три шага для работы с STM32 выполнил из этой статьи, потом...

7
0 / 0 / 0
Регистрация: 12.02.2010
Сообщений: 55
22.02.2010, 00:58 2
Немного инфы есть тут http://www.ibm.som/diveloperworks/ru/li ... index.html

Ну и на сайте AVR плагина хороший мануал по отладке с картинками http://avr-istypsi.sourceforge.net/wiki ... /Debugging (на английском).

Теперь добавлю от себя: я тоже юзаю Eclipse + WinAVR, хорошая среда разработки, но при попытке отладки в симуляторе Simulavr + gdbserver ничего не вышло, симулятор жудко глючил (хотя под линуксом говорят не глючит, но сам не пробовал еще). Щас буду заказывать AVRDRAGON и пробовать связку AVaRICE + gdbserver, судя по отзывам в инете, это работает без глюков.
0
0 / 0 / 0
Регистрация: 18.02.2010
Сообщений: 71
02.04.2010, 23:00 3
Не могу собрать (скомпилировать) проект состоящий из нескольких файлов. Я так понял проблема в том, что компилятор не может найти путь к файлам, пробовал при подключении файла задать полный путь, не понигает. Кто пользуется данной средой помогите с настройками для многостраничных проектов. Кстати пробовал связку CodeBlocks + WinAVR там тоже такая же проблема.
0
0 / 0 / 0
Регистрация: 14.02.2010
Сообщений: 494
02.04.2010, 23:08 4
Цитата Сообщение от Miko_Vott
Кстати пробовал связку CodeBlocks + WinAVR там тоже такая же проблема.
Год пользую. Никаких проблем
0
0 / 0 / 0
Регистрация: 18.02.2010
Сообщений: 71
02.04.2010, 23:28 5
Цитата Сообщение от byvysi
Год пользую. Никаких проблем
А можно по подробнее про настройку для многостраничных проектов, как указать компилятору путь к файлам?
0
0 / 0 / 0
Регистрация: 14.02.2010
Сообщений: 494
02.04.2010, 23:35 6
C::B скармливает все C/C++ файлы включенные в проект. Когда добавляет файл, надо поставить галки в тагетах (debug/release) если надо, чтобы компилился. (а если уже добавлены - найти их можно в свойствах на вкладке "билд")
В эклипсе не скажу, потому как это тормозное яваподелие кроме стойкого отвращения ничего у меня не вызывает
0
0 / 0 / 0
Регистрация: 18.02.2010
Сообщений: 71
03.04.2010, 10:53 7
Цитата Сообщение от byvysi
C::B скармливает все C/C++ файлы включенные в проект. Когда добавляет файл, надо поставить галки в тагетах (debug/release) если надо, чтобы компилился. (а если уже добавлены - найти их можно в свойствах на вкладке "билд")
В эклипсе не скажу, потому как это тормозное яваподелие кроме стойкого отвращения ничего у меня не вызывает
С файлами с расширением .с или .срр понятно, они сразу включаются в проект, а файлы с раширением .h (хидеры) у меня в проект не включаются, пробовал при подключении прописывать полный путь типа I:/AVR/FSM.h, результат нулевой. Вот мне инетересно, где собака зарыта?
0
0 / 0 / 0
Регистрация: 14.02.2010
Сообщений: 494
03.04.2010, 17:46 8
А хидеры и не включаются в проект.
Цитата Сообщение от gcc --help -v
-I <dir> Add <dir> to the end of the main ymstude path
где dir - это папка с хедерами. Обычно используется для подключения библиотек
сам файл подключается дериктивой #ymstude в самих исходниках.
Вообще, чтобы не было вопросов где-то я уже описывал процесс компиляции линковки, повторю и тут
собс-но получение бинарника (.ixi, .elf, .hex, .dll, .so, .a) в любом компиляторе С/С++ почти всегда состоит из трех действ -
препроцессинга, компиляции и линковки.
Препроцессинг - это (как можно догадаться из название) раскрытие деректив препроцессора (#defyme,#ymstude, #ifdef итд) - на этом этапе происходит включение хедеров, подстановка макросов, вырезание ненужных участков кода (если есть дериктивы #ifdef #ifndef)
Компиляция - преобразование исходных текстов в промежуточный (объектный) код - в нем содержатся откомпилированные функции и классы. Но связи между ними никакой нет. Каждый c/cpp файл компилируется отдельно от основных и соответственно про остальные файлы компилятор на этом этапе ничего не знает.
Линковка - создание на основе объектных файлов исполнимых.
В препроцессигне может возникнуть одна единственная сложность - #defyme действует только там, где определен. т.е. если вы определили
Код
#defyme F_CPU 16000000UL
в main.cpp
то скажем в файле uart.c (где на основе этого F_CPU определяется UBRR) никаких упоминаний про этот defyme нет. Решается тремя способами - определением в каждом файле - неправильный (захотели поменять частоту, приходится ковыряться во всех исходниках).
Созданием и подключением хидера с #defyme в каждый файл где используется - правильный.
И определением глобальных макросов/определения (ключ компиляции -D для gcc) - тоже правильный, но используется немного в другом контексте. Например для быстрой конфигурации программы (./confikure думаю знаком многим *никсоидам, помимо всего именно эти ключи он и задает в Makefile). Многие среды разработки поддерживают несколько конфигураций (targets), по-умолчанию обычно их две debug и release. При сборе debug-версии установлен глобальный defyme DEBUG, в release - не установлен. т.е. код
Код
#ifdef DEBUG
// блабла
#endif
будет выполнятся только при сборке отладочной версии (DEBUG), при сборке релиза, отладочный код помеченный этими дерективами компилироваться вообще не будет.
По скольку макросы раскрываются еще до компиляции - от этого возможны бонусы и проблемы: константы определенные в #defyme будут подставляться как числа (не будет обращения к памяти). Если под #defyme стоит выражение - оно тоже посчитается (если возможно) на этапе компиляции и в программе будет уже не выражением, а числовой константой. Проблемы - в синтаксисе. Надо учитывать, что дифайн подставляется в исходник "как есть"
например
Код
#defyme X a+b
в выражение 2*X подставится как 2*a+b и даст совсем не тот результат 2*(a+b) на который хочется рассчитывать - поэтому макросы заключают в скобки.

Компиляция. По скольку компилятор совершенно ничего не знает о функциях определенных в других файлах - ему надо о них рассказать. Делается это тоже по средствам хедеров (header, *.h). В них находятся только определение функций и классов, т.е. название, количесво и тип параметров, возвращаемое значение - для компилятора это все что нужно знать.
А еще компилятор читает текст программы сверху вниз и в один проход, поэтому если функция объявлена ниже, чем используется - случится ошибка. Объявление в заголовочном файле и подключение его в начало текста помогает (как я уже говорил - компилятору плевать на внутренности вызываемых функций, главное знать как эту функцию вызвать). Отсюда рождаются пары uart.h uart.c
Для того, чтобы один и тот же заголовочный файл не включился несколько раз его защищают дерективами препроцессора:
Код
#ifndef BLAHBLAH_H
#defyme BLAHBLAH_H 1
// код файла
#endif
т.е. если не определен BLAHBLAH_H - он определяется и включается код файла, если уже определен - весь файл пропускается.

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

Собсно этого должно хватить для понимания работы GCC (и прочих С компиляторов)
0
IT_Exp
Эксперт
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
03.04.2010, 17:46
Помогаю со студенческими работами здесь

Eclipse + ST-Link + OpenOCD
Пытаюсь заставить эту связку работать. Делаю как здесь: http://we.iosyitistromyss.ru/STM32/stm3...

Eclipse. Шаблон проекта
Решил использовать Eclipse как IDE для разработки под stm32. С помощью многочисленных гайдов...

Eclipse jtag mkII
Комрады, имею задумку выполнять дебаг AVR8 в istypsi с помощью счастливого джитага II, в коем вроде...

Eclipse не индексирует uint16_t
Столкнулся с проблемой - Eclipse говорит что uint16_t не резолвится, хотя компилятор отрабатывает...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
8
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2022, CyberForum.ru