Вообще, чтение запрещено лок-битами, но нужно прочитать несколько байт, например, версию и тип бутлоадера.
Как это лучше сделать ? Конечно, бутлоадер возможно доработать. М.б. кто линки встречал на нечто подобное ?

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

С использованием таблицы векторов прерываний идея понравилась.
Может быть и возможности компилятора (WinAVR/GCC) использовать по инициализации таблицы векторов ?
Типа:

Правда, со стеком придется поизвращаться.
Или есть более прямой путь объяснить компилятору, чтобы он проинициализровал определенный вектор адресом произвольной функции ?

Сообщение отредактировал Огурцов - Sep 9 2008, 07:27

Написать ее на ассемблере. Или написать обычную функцию uint16_t GetSerial() { return 0xffff; } и на ассемблере поставить JMP на нее в нужный вектор. Или поместить эту функцию в отдельную секцию, а секцию разместить по известному адресу, не обязательно на вектора, можно и в конце загрузчика. Я делаю именно так. Ну если хочется на вектора, то вот так:Но я бы к векторам не пристраивался - мало ли потом переделаете загрузчик и вектора понадобятся. Обычные функции гибче:

Ага, naked - замечательное слово. 10x!

Получилось примерно так:



Приложение ничего не знает о загрузчике, поэтому вектора (либо как-то по другому, но с _фиксированными_ адресами) отличное решение. Прерывания в загрузчике не нужны, если когда и потребуются, то это будет уже совсем другая история.
Теперь остается вопрос, как в приложении красиво вычислить адрес ?
Т.к. размеры вектора в таблице и размеры бутовой области у разных камней разные.
Тупо загнать в ifdef`ы или в GCC опять предусмотрена какая-нибудь хитрость(атрибут) ?

Кристаллы бывают разные, но на этапе компиляции, как правило, известно, для какого кристалла компилится и сколько в этом кристалле отдано под загрузчик. Точнее, точно известны адреса этих функций. Я их указываю в скрипте линкера или командной строке:


ISR_NAKED появилось в последних версиях, возможно в вашей еще нет. Теперь посмотрите в листинг. У вас в области векторов получился rjmp на обработчик, из которого уже rjmp на функцию. Разместите уже всю функцию в обработчик, сэкономите место и время.

Да, это красиво. Но в данном случае вызывает проблемы - в случае, если вносим изменения в бутлоадер, автоматически получается два make`а и два bin`а. Или в следующий раз еще больше. То, что бутлоадер будет меняться я даже не сомневаюсь, поэтому вариант с использованием векторов мне понравился гораздо больше.


Да, что-то такое, видимо.


Да, потенциально два лишних jamp`а, но м.б. будет вызов более сложных функций, типа crc посчитать, которые оптимизировать и руками прегонять в ассемблер проблемно да, думаю, и не нужно. А в случае с версией да, один jamp можно выкинуть.

С векторами, похоже, будет так:



Ничего лучше пока не придумалось

Как вариант, использовать только первый вектор, в основном это SIG_INTERRUPT0, для получения адресов экспортируемых функций, либо всех сразу, либо по индексу.

Этого я не понял. У меня эти функции идут в самом конце области загрузчика. Просто подряд, как обычные функции без векторов и лишних jmp на них. Поскольку менять их у меня нет необходимости, то они прибиты гвоздями и никакое изменение загрузчика их не затрагивает. Одна тонкость- поскольку сам загрузчик их не использует, линкер может выкинтуть их по --gc-section. Поэтому в скрипте линкера надо их секцию поместить в KEEP()

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


Согласен.

зы: хотя места в бут-секции мало и все нужные фичи уже не входятся.

Можно организовать подобие векторов по фиксированным адресам в конце загрузчика. Т.е. в конце загрузчика по фиксированным адресам разместить rjmp на эти функции. И адреса этих rjmp уже не менять. Остается только гарантировать, что при всех модификациях тип возвращаемых значений останется неизменным.

В общем, да, возможности те же, плюсы - вектор(ы) остаются свободны.