Чтение boot-области из приложения Опции

[Огурцов]

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

[Боинг749]

Может лучше я вам перескажу? Речь в нем идет только о чтении по команде LPM, никаких ограничений на вызов кода загрузчика из приложения нет.
Вчитайте-ка в себя мануал.

Ой
И правда.
Прошу меня простить. Перепутал с блокировкой RWW секции FLASH после команды записи в RWW. Когда если не разрешить доступ к RWW процессор вместо команд из RWW будет читать $FFFF.

Ещё раз прошу извинить.

[Огурцов]

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

Код

ISR(SIG_####)
{
  asm
  {
    pop
    pop
    jmp Get_version
  }
}

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

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

[Сергей Борщ]

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

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

Код

#define VERSION  12345

ISR(SIG_####, ISR_NAKED)
{
    asm volatile ("\n\t"
    "LDI r24, %A0 \n\t"
    "LDI r25, %B0 \n\t"
    "RET \n\t"
    :
    :"i" ((uint16_t)VERSION)
    :r23,r24
    )
}

Но я бы к векторам не пристраивался - мало ли потом переделаете загрузчик и вектора понадобятся. Обычные функции гибче:

Код

uint16_t GetVersion() __attribute__((section(".get_version")));
uint16_t GetVersion() { return VERSION; }
или так:

int16_t GetVersion() __attribute__((section(".get_version")));
uint16_t GetVersion()
{
    uint16_t Version;
    asm volatile ("\n\t"
    "LDI %A0, %A1 \n\t"
    "LDI %B0, %B1 \n\t"
    "RET \n\t"
    :"=r"(Version)
    :"i" ((uint16_t)VERSION)
    )
    return version;
}

[Огурцов]

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

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

Код

#define VERSION  12345

uint16 Get_version()
{
    return VERSION;
}

__attribute__((naked)) ISR(SIG_OVERFLOW0) // ISR_NAKED почему-то не берет
{
    asm volatile
    (
        "rjmp Get_version \n\t"
    );
}

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

[Сергей Борщ]

Теперь остается вопрос, как в приложении красиво вычислить адрес ?
Т.к. размеры вектора в таблице и размеры бутовой области у разных камней разные.

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

Код

*.cpp:
extern "C" uint16_t SerialNo();
*.c:
extern uint16_t SerialNo();

makefile:
LDFLAGS += -Wl,--defsym,SerialNo=0x1FFA
или *.ld:
SECTIONS
{
  ....
}
SerialNo = 0x1FFA;

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

Код

__attribute__((naked)) ISR(SIG_OVERFLOW0) // ISR_NAKED почему-то не берет
{
    asm volatile
    (
        "rjmp Get_version \n\t"
    );
}

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

[Огурцов]

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

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

ISR_NAKED появилось в последних версиях, возможно в вашей еще нет.

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

У вас в области векторов получился rjmp на обработчик, из которого уже rjmp на функцию. Разместите уже всю функцию в обработчик, сэкономите место и время.

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

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

Код

#define GET_VERSION_VECTOR    1

__attribute__((naked)) ISR(_VECTOR(GET_VERSION_VECTOR))
...

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