Типы файлов, используемые в программировании МК

[Necroteeth]

давайте все-таки разберемся, какие бывают типы файлов, как они используются и т.д.
на данный момент известны:
.hex - файл для прошивки в сам контроллер, генерится ассемблером
.asm - программа на ассемблере
.с - программа на Си
.h - ?
.o - ?
.a - ?
.elf - ?
.aws - ?
.map - ?

и что за makefile, отличия от Build, Compile.
что откуда растет, что для чего нужно и как с этим всем работать.
помогите, пожалуйста!

[ARV]

так и быть
hex - генерируется КОМПИЛЯТОРОМ (для ассемблера - им самим, для Си - линкером, частью компилятора)
h - от слова header - заголовок. заголовочный файл программы на Си
о, а - промежуточные файлы (объектные и др.), создаются компилятором. вам они до лампочки, не обращайте на них внимание
elf - объектный модуль с информацией для отладчика. этот файл используется при отладке, в том числе в протеусе. еще его могут понимать продвинутые программаторы. содержит в себе очень много полезной и не очень инфы.
aws - по-моему, это имеет отношение к проекту AVR Studio - ее файл, к компилятору не имеет отношения
map - файл-карта, содержит сведения об адресах всех используемых в программе функций, переменных и т.п. вещей. очень может быть полезен при отладке и анализе своего кода.
lss - листинг avr-gcc, содержит строки Сишного исходника, его ассемблерные эквиваленты и машинные коды программы, а так же ряд вспомогательной инфы. очень полезен при отладке и анализе кода.

[Necroteeth]

о, а - промежуточные файлы (объектные и др.), создаются компилятором. вам они до лампочки, не обращайте на них внимание

вот проблема-то как раз в том, что из-за одного файла с расширением .a у меня не компилилась программа для робота pololu 3pi robot. в примерах с их сайта я нашел в разделе project->configuration options->libraries ссылку как раз на файл *.a
а когда пытался сам написать программу, то подключения <orangutan.h> оказалось недостаточно - ошибки вылезали из файла *.o и *.elf
все это мне взорвало мозг и я подумал, что подобный faq окажется однажды полезным любому новичку

[coredumped]

вот проблема-то как раз в том, что из-за одного файла с расширением .a у меня не компилилась программа для робота pololu 3pi robot. в примерах с их сайта я нашел в разделе project->configuration options->libraries ссылку как раз на файл *.a
а когда пытался сам написать программу, то подключения <orangutan.h> оказалось недостаточно - ошибки вылезали из файла *.o и *.elf
все это мне взорвало мозг и я подумал, что подобный faq окажется однажды полезным любому новичку

.a - скомпиленная библиотека, на самом деле представляет из себя запакованный объектный файл. Вам нужно собрать библиотеку из исходничков, чтоб получить этот .a, или взять готовый, скомпиленный файл библиотеки. Обычно так распространяют коммерческие библиотеки, чтоб скрыть исходники. Т.е. библиотека состоит из хидера .h, в котором описаны экспортируемые функции и .a - сама библиотека. Поясню на простейшем примере.

1. Пишем библиотеку libtest
lib_test.c

Код: Выделить всё

#include <stdlib.h>
int test_add(int a, int b)
{
   return a+b;
}
int test_sub(int a, int b)
{
   return a-b;
}

к ней пишем заголовок test.h

Код: Выделить всё

extern int test_add(int a, int b); 
extern int test_sub(int a, int b);

2. Собираем библиотеку libtest.a из файлика lib_test.c
gcc -c lib_test.c -o lib_test.o // компилим, получаем lib_test.o
ar rcf libtest.a lib_test.o // делаем libtest.a
На данном этапе мы получили libtest.a и test.h - этого достаточно, чтоб собирать проекты с нашей библиотекой
3. Собственно приложение test.c

Код: Выделить всё

#include <stdlib.h>
#include <test.h> 

int main(void)
{
   int a,b,c;
   a=1; b=2;
   c=test_add(a,b);
   c=test_sub(a,b);
   return 0;
}

4. Собираем наше приложение
gсс -с test.c -o test.o //компилим
gcc -llibtest test.o -o test //линкуем с нашей библиотекой, получаем прожку test

В нашем мини-примере взят абстрактный компилятор gcc. Все это написано на колене, так сказать для понимания...
На практике это может быть, например avr-gcc, который потребует дополнительных ключей, например avr-gcc -mmcu=atmega8 ...
Для того, чтобы не писать все эти комманды в консоль, умные люди придумали тулзовину make. Пишем Makefile и потом просто запускаем make. Написание мэйкфайлов заслуживает целлой статьи, коих в сети - огромное количество уже написано - google рулит
Если че непонятно - вопрошайте, попробуем растолковать

[Necroteeth]

вот проблема-то как раз в том, что из-за одного файла с расширением .a у меня не компилилась программа для робота pololu 3pi robot. в примерах с их сайта я нашел в разделе project->configuration options->libraries ссылку как раз на файл *.a
а когда пытался сам написать программу, то подключения <orangutan.h> оказалось недостаточно - ошибки вылезали из файла *.o и *.elf
все это мне взорвало мозг и я подумал, что подобный faq окажется однажды полезным любому новичку

.a - скомпиленная библиотека, на самом деле представляет из себя запакованный объектный файл. Вам нужно собрать библиотеку из исходничков, чтоб получить этот .a, или взять готовый, скомпиленный файл библиотеки. Обычно так распространяют коммерческие библиотеки, чтоб скрыть исходники. Т.е. библиотека состоит из хидера .h, в котором описаны экспортируемые функции и .a - сама библиотека. Поясню на простейшем примере.

1. Пишем библиотеку libtest
lib_test.c

Код: Выделить всё

#include <stdlib.h>
int test_add(int a, int b)
{
   return a+b;
}
int test_sub(int a, int b)
{
   return a-b;
}

к ней пишем заголовок test.h

Код: Выделить всё

extern int test_add(int a, int b); 
extern int test_sub(int a, int b);

2. Собираем библиотеку libtest.a из файлика lib_test.c
gcc -c lib_test.c -o lib_test.o // компилим, получаем lib_test.o
ar rcf libtest.a lib_test.o // делаем libtest.a
На данном этапе мы получили libtest.a и test.h - этого достаточно, чтоб собирать проекты с нашей библиотекой
3. Собственно приложение test.c

Код: Выделить всё

#include <stdlib.h>
#include <test.h> 

int main(void)
{
   int a,b,c;
   a=1; b=2;
   c=test_add(a,b);
   c=test_sub(a,b);
   return 0;
}

4. Собираем наше приложение
gсс -с test.c -o test.o //компилим
gcc -llibtest test.o -o test //линкуем с нашей библиотекой, получаем прожку test

В нашем мини-примере взят абстрактный компилятор gcc. Все это написано на колене, так сказать для понимания...
На практике это может быть, например avr-gcc, который потребует дополнительных ключей, например avr-gcc -mmcu=atmega8 ...
Для того, чтобы не писать все эти комманды в консоль, умные люди придумали тулзовину make. Пишем Makefile и потом просто запускаем make. Написание мэйкфайлов заслуживает целлой статьи, коих в сети - огромное количество уже написано - google рулит
Если че непонятно - вопрошайте, попробуем растолковать

а это все в какой-нибудь книге есть? собственно я незнаком с понятиями "собирать" и "линковать". я вообще раньше только на паскале и бейсике писал и потому терминология ассемблера и си для меня пока что чужда и зачастую непонятна. начал читать K&R, но что-то там про эти вещи пока не вычитал, может, конечно, дальше будут...

[urry]

как много нам открытий чуждых готовит просвещенья дух...
меня рассмешила, простите, сама постановка вопроса - ...
Это как бы радует, что Вы читаете Кернигана, а собственно, ну зачем ..
что он вам даст для мк , на который Вы акцентируетесь...
ничего...
а, ну да, линукс, простите тогда сюда http://www.remexpert.com/ipb/ipb.html?a ... howfile=76

[coredumped]

Поржал А теперь по теме...

Обычно проект состоит более чем из одного файла с программной писаниной, так называемых модулей программы.
Так вот, не зависимо от платформы и ОС, программы, написанные на языках под компиляцию (в отличие от скриптов и интерпретаторов) собираются из модулей и библиотек. Программы на паскале, кстати, тоже.
Поясню как это делается.
1 этап - препроцессор - заменяет макросы, на их тела, вставляет "инклуды" - короче, такой себе, автоматический текстовый редактор -на выходе текстовый файл, содержащий только конструкции языка.
2 этап - каждый программный модуль (отдельный файл) компилируется отдельно - на этом этапе все конструкции языка переводятся в машинный код, и на выходе - объектые файлы - куски готовой программы - такие себе блочки.
3 этап - линковка - куски (объектные файлы) клеятся вместе, также приклеиваются необходимые библиотеки, и самое главное устанавливаются связи между функциями и данными, а именно устанавливаются реальные адреса переходов и переменных. Это собственно последний этап.
Вот 3 источника и 3 составные части... Хотя многим эти слова могут быть и не знакомы

[ARV]

вот здесь в первых главах я немного рассказывал о работе компилятора и т.п. тонкостях - капельку, только для общего представления. зато попроще, чем Керниган

[Necroteeth]

Это как бы радует, что Вы читаете Кернигана, а собственно, ну зачем ..
что он вам даст для мк , на который Вы акцентируетесь...
ничего...

а как я могу писать на си для мк, если не знаю си вообще?

Поржал А теперь по теме...

Обычно проект состоит более чем из одного файла с программной писаниной, так называемых модулей программы.
Так вот, не зависимо от платформы и ОС, программы, написанные на языках под компиляцию (в отличие от скриптов и интерпретаторов) собираются из модулей и библиотек. Программы на паскале, кстати, тоже.
Поясню как это делается.
1 этап - препроцессор - заменяет макросы, на их тела, вставляет "инклуды" - короче, такой себе, автоматический текстовый редактор -на выходе текстовый файл, содержащий только конструкции языка.
2 этап - каждый программный модуль (отдельный файл) компилируется отдельно - на этом этапе все конструкции языка переводятся в машинный код, и на выходе - объектые файлы - куски готовой программы - такие себе блочки.
3 этап - линковка - куски (объектные файлы) клеятся вместе, также приклеиваются необходимые библиотеки, и самое главное устанавливаются связи между функциями и данными, а именно устанавливаются реальные адреса переходов и переменных. Это собственно последний этап.
Вот 3 источника и 3 составные части... Хотя многим эти слова могут быть и не знакомы

хоть и поржали, но ведь внесли какую-то ясность! спасибо!

вот здесь в первых главах я немного рассказывал о работе компилятора и т.п. тонкостях - капельку, только для общего представления. зато попроще, чем Керниган

спасибо! обязательно почитаю!