Всем привет. Пожалуйста подскажите как перенести обработчики прерываний в бутлоадер. Atmega16. Я знаю что там есть какой-то бит IVSEL для этого. Меня интересует как прописать все это на си в AVR GCC. Какие есть там подводные камни. Где можно про это почитать?

Сообщение отредактировал Skaf - Nov 4 2010, 18:19

Почитать в даташите, конечно! Там и пример должен быть! Во всяком случае, на 128 мегу примеры есть и на Си, и на ассеблере, вот выдернул на Си.

Камень - единственный, надо посмотреть, чтобы второй оператор успел выполниться за 4 тактовых цикла после первого. Я думаю, Си это вполне умеет, но можно проверить, какие реально коды сгенерированы, чтобы быть спокойным. Прерывания запрещаются автоматом после первого оператора, так что с этой стороны все в порядке

Ну это все понятно. А компилятор сам разместит процедуры обработки прерываний в области бутлоадера?

ISR(TWI_vect){
...
}

Уже бы давно попробовали сбилдить тестовый проектик, да в AVR-studio пошагать - многие вопросы бы отпали...

Да, в том случае, если этот проект вы компилируете как бутлоадер, передавая gcc параметр , указывающий линковщику разместить весь код вместе с таблицей векторов начиная с адреса 0xXXXX (в байтах!).
Вот даже есть makefile для бутлоадера: http://easyelectronics.ru/img/AVR_kurs/Bootloader/makefile
А вот неплохой FAQ для gcc: http://blog.schicks.net/wp-content/uploads...tloader_faq.pdf

Сообщение отредактировал artymen - Nov 5 2010, 18:59

У меня возникла проблема с тем, что компилятор оптимизирует мой код и



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

Между ними, наверное, команда ldi ? В четыре такта укладываетесь - что же Вам ещё нужно?

Я понял почему не работало ничего... В ATmega16 эти биты находятся в другом регистре. В GICR... А я и не посмотрел сначала...

Сообщение отредактировал Skaf - Nov 7 2010, 18:55

В любом случае доверять такие "ответственные" операции сишному компилятору не стоит, а уж тем более при оптимизации. Начиная с какой то версии 4.х.х в GCC появилась возможность устанавливать аттрибуты оптимизации для отдельных функций. Не знаю, кому как, но фича весьма и весьма полезная. Делаем вот так:
и можем быть почти уверены, что защитили код функции он извратных посягательств оптимизатора

---
Пардон, забыл, что регистры объявлены как volatile и тем самым защищены уже. Просто я с этой оптимизацией до конца не разобрался, и на мой взгляд, gcc параноик, скока не отключай оптимизацию, он все равно будет оптимизировать. Точно, маньяк И меня параноиком сделал. Я чуть ли не каждую переменную с volatile объявляю :D

Сообщение отредактировал artymen - Nov 8 2010, 18:18

Не все йогурты одинаково полезны...
Ни разу не было нужно. Могу лишь предположить, что может потребоваться оптимизация по скорости для какой-то критичной функции, да и то это ИМХО означает, что выбран неверный алгоритм или дохлый контроллер.
Ибо выигрыш будет совсем незначительным - в пределах погрешности измерения.
Так, что не стоит засорять код лишней фигнёй и пудрить мозги себе и людям.
А уж компилить функции с нулевым уровнем оптимизации считаю бредом сивой кобылы.

Я считаю, вопрос весьма и весьма спорный. Когда я еще только начинал работать с ассемблером, я бы тут полностью с вами солгасился, на все 100%. Однако ! Когда я открыл ассемблерный листинг скомилированного с нулевой оптимизацией кода, я просто дико разочаровался. Я, конечно, не сравнивал еще с листингами других компиляторов, возможно, где-то еще хуже, но это не умалило бы моей абсолютной оценки - тихий ужас. Простейшее присваивание значения регистру вылилось в целое жонглирование значением между несколькими регистрами. То есть он воспринял отсутствие оптимизации уж слишком вольно, позволив себе ну просто возмутительные злоупотребления ресурсами. Желаемого я добился только с оптимизацией -O3 и -Os, но вот ведь беда: первое приводит к таким диким оптимизациям, что уследить за тем, чтобы получить ожидаемое вместо противоположного, становится дико трудно; а второе, например, приводит к отказу от инлайновых функций (вроде как можно форсировать инлайн-аттрибут, но черт знает, какие сюрпризы еще впереди). Если же изучать все многочисленные индивидуальные опции оптимизации, то вся работа встанет. Да, GCC мощный инструмент, и даже черезчур, я считаю. С ним управиться сложно.

Сообщение отредактировал artymen - Nov 8 2010, 19:06

А я нет.
Просто нужно знать свой инструментарий как "Отче наш".
Ваши высказывания вызывают недоумение!
Я всегда получаю именно то что хочу - иначе это бы не называлось программированием.
Какой смысл использовать O0, если все релизы билдятся с Os?
Зачем смотреть на листинг, который не будет греть кремний?
Пока будете считать компилятор умнее себя ничего хорошего не выйдет.
Выход один - изучать инструментарий, планомерно и постоянно.
Поверьте, Вашей работе это будет лишь в плюс.

Ну вот я и изучаю. А пока вот такие мыслеизлияния у меня...
А вообще чуть ли не с каждым проектом и/или МК надо осваивать новый компилятор, так что "Отче наш" тонет в этой каше в голове.
В конечном то счете я получаю, то что хочу, но какой ценой...
Насчет того, чтобы задавать функцию с нулевой оптимизацией, это конечно, изврат. Я просто разок в отладочных целях применил это, но, к счастью, этот дурной метод не прижился в коде.