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

Если собрать без оптимизации, вызов начинается как и положено с main. Почему такое может быть?

Компилирую такой командой -
`which avr-gcc` -ggdb3 -Wall -std=c99 -mmcu=avr25 -DF_CPU=8000000UL -D__AVR_ATtiny85__ main.c USI_TWI_Slave.c -o main.elf

Дальше запускаю в симуляторе simavr -f 8000000 -m attiny85 -g 1234 ./main.elf
Захожу в gdb и вижу, что запущен не main.

На железке соответственно все висло. Сейчас я железку немного испортил , поэтому бинарник без оптимизации проверить не могу. Но очень похоже что там тоже самое происходит.

Вот main, ожидается, что инициализируется twi и будет мигать светодиод. Сначала я подумал что вызывается обработчик прерываний, и в нем вызываются USI_TWI_On_Slave_Transmit, USI_TWI_On_Slave_Receive, но если первые три строки закомментировать происходит тоже самое.

Ну, возможно это глюк симулятора конечно. Но тогад не понятно почему в железе светодиод не мигал..

Добавлено after 9 hours 8 minutes 43 seconds:
Примерно понял - ассемблерный код разный получается, и видимо я gcc неверный mcu указываю. Сегодня еще поэксперементирую.

Первое за что зацепился глаз - странные настройки компилятора. Попробуйте без извращений:
avr-gcc -Wall -std=c99 -mmcu=attiny85 -DF_CPU=8000000UL main.c USI_TWI_Slave.c -o main.elf

Сами перемудрили. В mmcu надо напрямую название камня указывать. И -D__AVR_ATtiny85__ main.c - явно лишнее. Если сразу камень указать, а не базовую архитектуру, то подтянется всё, что нужно для нормальной сборки.

Да, камень я указал неправильно, в доке на gcc этот раздел как-то не очень понятно выглядит - написано avr25, и дальше перечислены поддерживаемые камни. Я подумал что это название для всего списка

А теперь хочу разобраться в чем дело.

Есть ли отличия в "устройстве" памяти на разных attiny? В смысле они все начинают исполнение с одного места, или могут быть нюансы? Просто поведение давольно подозриетльное. Основное отличие после дизассемблирования в том что первой функцией идет либо main либо нет.

А для моего камня в принципе тоже самое, но еще раньше идет таблица с векторами прерываний. И ничего сузественного не заметил.

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

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

Почему лишнее? Если его не указать, то много что не работает. Есть способ указать по другому? Или оно должно включиться при выборе -m attiny85 ?

Это базовые архитектуры. GCC знает именно отдельные камни. Когда вы указываете конкретную модель МК, дальше тулчейн подтянет всё, что нужно. attiny85 включает в себя avr25 как бы уже.


И в main.c вначале сделайте #include <avr/io.h> и оно само включится.


Тулчейн - это не только gcc. Это еще и базовая либа crt (инициализация) и заголовки (.h), которые определяют нужные вещи. Линкер подтягивает нужный объектный файл .crt, который генерит правильный стартовый код. Правильно цеплять как я уже написал выше - в -m точная модель, и #include <avr/io.h>. Если интересно что получается - да просто сделайте main() с пустым бесконечным циклом и через avr-objdump посмотрите выхлоп дизассемблера. Увидите, что сделал компилятор в таком случае, и что делал в вашем.