[lavrik 0]

надо сложить не 5 значений!

а всю таблицу векторов, то есть 8 значений (c 0 gj 7), но пропустить 5 слово.

а потом инвертировать....

 

Вам надо сделать так, чтобы сумма первых 8 чисел (32 битных чисел) в итоге давала 0. Вот и рассчитайте какое там должно стоять число чтобы после суммирования стало 0.

 

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

то есть если в памяти лежит 0x11 0x22 0x33 0x44, то это число 0x44332211

 

откуда ж я знал что там Little Endian... :(

 

спасибо! теперь все стало на свои места! :)

[jcxz 243]

А на ARM7 вообще не вижу проблемы - там области векторов всегда лежит один и тот же кусок кода, его контрольная сумма - константа, которую можно посчитать вручную и прибить в соответствующее место гвоздями.

Чаще всего, но не всегда. Чаще всего там конечно набор из LDR PC, [PC, #24], но никто не мешает сделать переход на один адрес из 2-х и более векторов или расположить код сразу за таблицей ISR, сделав переход обычным B.

[Golikov 0]

откуда ж я знал что там Little Endian... sad.gif

Чем более вероятно событие - тем оно менее информативно, так что еще можно вопрошать "откуда же я знал что там Big Endian?", но обратное стыдно:). Наиболее понятный и удобный формат для техники процессоров именно LittleEndian и если это не так об этом пишут ОГРОМНЫМИ БУКВАМИ!

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

но никто не мешает сделать переход на один адрес из 2-х и более векторов

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

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

Каждый сам себе злобный Буратина. Или приведенный простой кусочек кода, который решает проблему контрольной суммы и делает программу чуть короче и быстрее, либо выдумываем себе трудность и героически ее преодолеваем. Имея на выходе результат заведомо худший, потому что добавляется один лишний переход здесь и какое-то дополнительное количество кода на чтение VIC_ADDRESS и дальнейшее ветвление по нему. Я не вижу абсолютно никакого смысла в этих лишних движениях в программе, кроме как сделать из маленькой быстрой программы большую медленную.

 

В общем, обсуждавшуюся три страницы задачу я для себе решил минимальными усилиями. Кому не нравится - пусть делает лучше.

[lavrik 0]

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

Каждый сам себе злобный Буратина. Или приведенный простой кусочек кода, который решает проблему контрольной суммы и делает программу чуть короче и быстрее, либо выдумываем себе трудность и героически ее преодолеваем. Имея на выходе результат заведомо худший, потому что добавляется один лишний переход здесь и какое-то дополнительное количество кода на чтение VIC_ADDRESS и дальнейшее ветвление по нему. Я не вижу абсолютно никакого смысла в этих лишних движениях в программе, кроме как сделать из маленькой быстрой программы большую медленную.

 

В общем, обсуждавшуюся три страницы задачу я для себе решил минимальными усилиями. Кому не нравится - пусть делает лучше.

 

 

Этот процесс (подсчета и перезаписи контрольной суммы векторов прерываний) будет автоматизирован при помощи софта, который будет подготавливать прошивку, переводя её из традиционного HEX-вида в необходимый и удобный для записи + ещё будет шифроваться ключом AES (пока не решили какой битности). Дешифровка прошивки будет производиться в программаторе, который будет знать ключ шифрования, программатор будет защищён от чтения.

 

Такие пироги :laughing:

[jcxz 243]

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

Использовать не косвенный переход (LDR), а прямой - B. И выиграть не байты, а такты. Что в таких местах (прерывания) может быть очень актуально.

Мне случалось писать ISR с частотами до единиц МГц. Там каждый такт на счету.

 

Да и тут вроде разговор о прошивке сторонней программы посредством ISR. А как в той программе описана таблица векторов - заранее не известно я так понимаю.

 

Этот процесс (подсчета и перезаписи контрольной суммы векторов прерываний) будет автоматизирован при помощи софта, который будет подготавливать прошивку, переводя её из традиционного HEX-вида в необходимый и удобный для записи + ещё будет шифроваться ключом AES (пока не решили какой битности). Дешифровка прошивки будет производиться в программаторе, который будет знать ключ шифрования, программатор будет защищён от чтения.

Что помешает злоумышленнику воткнуться сниффером между вашим программатором и прошиваемым устройством и перехватить прошивку?

 

Каждый сам себе злобный Буратина. Или приведенный простой кусочек кода, который решает проблему контрольной суммы и делает программу чуть короче и быстрее, либо выдумываем себе трудность и героически ее преодолеваем. Имея на выходе результат заведомо худший, потому что добавляется один лишний переход здесь и какое-то дополнительное количество кода на чтение VIC_ADDRESS и дальнейшее ветвление по нему. Я не вижу абсолютно никакого смысла в этих лишних движениях в программе, кроме как сделать из маленькой быстрой программы большую медленную.

Какой лишний переход??? ISR располагаем сразу за таблицей прерываний, никакой VIC_ADDRESS не нужен (один источник прерывания).

Разработчики ARM7/9 видели смысл создать даже отдельный FIQ со своим контекстом только для того, чтобы как можно лучше минимизировать затраты времени на вход/выход в ISR.

А Вы не видите... :laughing:

Для FIQ вообще всё шоколадно - вообще никакой B даже не нужен - ISR для него сразу с вектора можно расположить, сдвинув вниз все остальные адреса.

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

Использовать не косвенный переход (LDR), а прямой - B. И выиграть не байты, а такты. Что в таких местах (прерывания) может быть очень актуально.

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

ISR располагаем сразу за таблицей прерываний, никакой VIC_ADDRESS не нужен (один источник прерывания).

...

Для FIQ вообще всё шоколадно - вообще никакой B даже не нужен - ISR для него сразу с вектора можно расположить, сдвинув вниз все остальные адреса.

Если программист сможет реализовать такое - посчитать контрольную сумму для него не составит труда. В моем случае подсчет контрольной суммы векторов нужен для самописного загрузчика, в котором не стоит задачи экономить такты. Экономить такты можно в приложении, но в нем не нужна контрольная сумма векторов, потому что его запускает самописный загрузчик.

 

[IgorKossak 0]

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

[jcxz 243]

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

Обычно - да, но бывают исключения :laughing:

Платформа выбирается под задачу, но вот задача сама имеет свойство меняться (разрастаться) в по ходу жизни изделия. :(

[KRS 1]

а потом инвертировать....

не инвертировать!

нужно дополнение до двух, а не до еденицы

 

Использовать не косвенный переход (LDR), а прямой - B.

Кроме IRQ где сразу из VIC грузится так и делаю!

у LPC не так много флеша что бы 23 бита смещения не достали.

 

А то что стандартный startup так не делает, говорит только или о его низком качестве или о том что он слишком универсальный.

 

 

[Golikov 0]

под инвертировать имел ввиду, конечно, инверсию знака, блин как это правильно то называется? Отрицательнить:) взять со знаком минус, вот. Так правильнее...