AVR-GCC (Linux) не видит заголовочные файлы.

[NStorm]

Eddy_Em, на самом деле более-менее норм, с учетом разношерстности их экосистемы. Там же помимо AVR еще и SAMD, STM32, ESP8266, ESP32 бывают и теоретически всё, что угодно. Поэтому у IDE есть свой конфиг, на основании которого она знает для какой платформы какой тулчейн нужен, и какие опции использовать.

[BOB51]

Я как-то изначально понял, что речь не об адуриноIDE, а о AVRGCC под линуксом идет...
Ежли таки именно адуринка под линуксом - там надо звать oleg110592 - только у него опыт с подобным применением имеется...

[Eddy_Em]

Однажды я имел дело с этой дрянью. F_CPU просто прописал в Makefile.

[Shuspano]

А вот еще такой вопрос. Скомпилял я значит, свою горе-прожку:

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

avr-gcc -Os -mmcu=attiny13 avr_test.c -o 1ms_led.out

И успешно скормил ее дудке, та в свою очередь, не ругнувшись, залила ее в МК. И все заработало.
Еще пару раз перекомпилял - и тоже все нормально. И вдруг замечаю вот что: что заливаю я не HEX, сделанный через avr-objcopy - я про это забыл, а тот файл, что выдал непосредственно компилятор. Открываю в редакторе этот out, и удивляюсь: текстово-бинарная мешанина, с линуксовыми путями, с именами файлов, и даже зачем-то, с полным наименованием ядра моего линукса со всеми приставками. А самое главное - файл больше флэша контроллера.
Но программа работает на МК возмутительно нормально.
Как так получилось: 1. контроллер как-то сам нашел свой код в этой каше. 2. дудка умнее меня, и как-то сделала hex самостоятельно?
Или где?

[Eddy_Em]

Просто "заливатор" вызвал objcopy и т.п.

[NStorm]

Shuspano, это формат ELF на выходе. Дудка понимает и его, и HEX и просто бинарник. И умеет корректно с ними работать. HEX ведь тоже не "прямой" формат, его обрабатывать тоже нужно.

[COKPOWEHEU]

gcc создает файлы *.elf - обычные исполняемые файлы. Точно такие же, как во "взрослой" операционной системе. Там содержится не только бинарный исполняемый код, но и заголовок (первые три байта, равные, внезапно, 'E', 'L', 'F'), адрес начала исполняемых данных, некоторые зависимости, адреса перемещаемых данных (во "взрослых" ОС ведь не одна программа выполняется, надо как-то распределять общую память) и много чего еще.
А avrdude, как и многие другие программаторы, штука умная и понимает множество форматов: и "сырые" прошивки (*.bin, там вообще только бинарное представление, даже без адресов), и intel hex (*.hex, бинарный файл, записанный текстом, плюс контрольная сумма, плюс адрес), и собственно исполняемые файлы (*.elf).

[Shuspano]

Я почему так удивился. У меня есть другие программаторы, и софт к ним ведет себя иначе. Для них bin - это все что не hex, и они зальют все что им не дай как есть, если это лезет в микруху. Я предпполагал такое поведение и здесь.
Щас слил прошивку МК - ровно 74 байта, что совпадает с выводом avr-size. Дудка хорошая, дудка умная.

[NStorm]

Shuspano, man avrdude почитайте. Там ведь всё написано.

Добавлено after 1 minute 53 seconds:

Provided libelf(3) was present when compiling avrdude, the input file can also be the final ELF file as produced by the linker. The appropriate ELF section(s) will be examined, according to the memory area to write to.

Спойлер

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

                   The filename field indicates the name of the file to read or write.  The format field is optional and contains the format of the file to read or write.  Format can be one of:

                   i    Intel Hex

                   s    Motorola S-record

                   r    raw binary; little-endian byte order, in the case of the flash ROM data

                   e    ELF (Executable and Linkable Format)

                   m    immediate; actual byte values specified on the command line, separated by commas or spaces.  This is good for programming fuse bytes without having to create a single-byte file or enter terminal mode.

                   a    auto detect; valid for input only, and only if the input is not provided at stdin.

                   d    decimal; this and the following formats are only valid on output.  They generate one line of output for the respective memory section, forming a comma-separated list of the values.  This can be particularly useful for sub‐
                        sequent processing, like for fuse bit settings.

                   h    hexadecimal; each value will get the string 0x prepended.

                   o    octal; each value will get a 0 prepended unless it is less than 8 in which case it gets no prefix.

                   b    binary; each value will get the string 0b prepended.

                   The default is to use auto detection for input files, and raw binary format for output files.  Note that if filename contains a colon, the format field is no longer optional since the filename part following the colon would
                   otherwise be misinterpreted as format.

                   When reading any kind of flash memory area (including the various sub-areas in Xmega devices), the resulting output file will be truncated to not contain trailing 0xFF bytes which indicate unprogrammed (erased) memory.  Thus,
                   if the entire memory is unprogrammed, this will result in an output file that has no contents at all.

[xVekx]

Может кому понадобится имеем linux mint 18, Qt Creator 3.6.1, используем систему сборки qbs, пример .