Denis пишет:

Как движется проект?

Да пока пауза - появились другие неотложные проекты, возобновлю - напишу

У меня есть ещё пара идей, когда проект станет актуальным, я их напишу.

Как движется проект?

Да пока пауза - появились другие неотложные проекты, возобновлю - напишу

Или как-то можно связать Eclipse с Yagarto. Проект в Eclipse открывается, а вот как его сбилдить, получить  bin-файл - непонятно

Я настраивал интеграцию только с VisualStudio. Использовал Post-Build Event скрипт, преобразующий строки с описанием ошибок компиляции (у gcc и cl они немного разные). Особой пользы мне это не принесло, удобней оказалось создать в каталоге с проектом файл “_make_.cmd” состоящий из двух строчек “make” и ”pause”. Команду “make template” вообще надо вызывать всего раз в начале создания проекта, и автоматизировать её нет смысла.

PS. Если кто-то знает и проверял на личном опыте удобный способ интеграции gcc c VisualStudio отпишитесь, а лучше создайте на форуме отдельную тему. Буду благодарен :)

А кроме yagarto кто что использовал? Например IAR Embedded Workbench for ARM?

Тут лучше использовать yagarto, не потому что он лучше или хуже, а потому что  на нём уже откатали кучу тестов с ключами Code и шанс нарваться на подводные камни значительно ниже. Другие сборки и компиляторы, возможно, тоже буду работать, но при каждой неочевидной ошибке, придётся рассматривать эту замену, как одну из возможных причин. Если всё-таки для такой замены есть весомые причины, это можно будет сделать, когда проект заработает, и для него будут написаны тесты. Для Code первого поколения я пробовал Sourcery, вроде всё работало.

ЗЫ. Первое правило радиолюбителя: Не крути две ручки одновременно :)

на более быстром ключе, сказать сложно, лучше сделать пример.

Вот собственно этим я и займусь. Продумал сегодня всю защиту в деталях, думаю что будет супер. А главное, что экзешник можно распространять и не бояться - вся логика то в ключе!!! Без ключа вообще непонятно как ломать прогу, проще новую написать :)

Только я так и не понял сколько в моем случае будет выполняться с буфером 30 байт, автомат - без циклов тупое сравнение если-то штук 10 выполнится и присвоить, добавить в выходной буфер и всё. Никаких математических и прочих операций.

Я думаю, в этом случае основное время уйдёт на накладные расходы вызова, т.е. 20мс. Но тут надо учитывать, что моё защищенное приложение работало на Core3i, а ключ был более медленный. Как изменится время на более медленном процессоре PC (я так понимаю, что в embedded-системы Corei3 не ставят:), но при этом на более быстром ключе, сказать сложно, лучше сделать пример.

PS. OMG! 38 новых сообщений из них 4 по теме :)

Это чтоб я не расслаблялся :)

ёси баси, сотни миллисекунд это ....

Известные мне этапы работы функции GrdCodeRun:
1. Шифрование входного буфера (выполняется в коде API на PC)
2. Передача по USB
3. Расшифровка входного буфера (выполняется в ключе)
4. Вызов пользовательского кода (выполняется в ключе)
5. Шифрование выходного буфера (выполняется в ключе)
6. Передача по USB
7. Расшифровка выходного буфера (выполняется в коде API на PC)

1 и 7 пункты замедляются ещё и тем, что они защищены от дизассемблирования и отладки виртуальной машиной. Скорость их работы напрямую зависит от производительности процессора, на котором выполняется защищенное приложение.

Я делал замеры на ключах Code первого поколения.
1. Сделал 5 версий загружаемого кода, в которых выполнялась простая мат.операция, в первом 1 раз, во втором 10 раз, в третьем 100 раз и т.д.
2. Далее выполнил каждый из них 100 раз, откинул одно самое долгое выполнение для каждой прошивки, чтобы хоть как-то уменьшить погрешность в многопоточной среде.
3. Вычислил для каждой прошивки среднее время выполнения.
4. Составил систему уравнений, где Y - время выполнения моего кода в ключе (этап 4), X - накладные расходы на вызов этого кода (этапы 1-3,5-7):
    X + 1*Y = t1
    X + 10*Y = t2
    X + 100*Y = t3
    и т.д.

На моей машине X получился около 20 мс, а Y был настолько мал, что терялся в погрешности измерений, оказывая влияние только в 100 и более итерациях.

Нынешнее второе поколение ключей должно работать быстрее, т.к. ускоряются шаги 3 – 5.
Но мне вполне хватало и тогдашних показателей.

PS. OMG! 38 новых сообщений из них 4 по теме :)

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

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

Vladimir Ivanov пишет:

Там кроме мигания светодиодом ничего нет.

Там загружается код, замените его на нечто читающее ячейки и все что после него в области кода и все дела.

Так там загружается зашифрованный и подписанный код, а не какой угодно. Как я уже писал, без знания ключей шифрования и подписи нельзя подготовить gcexe-файл, который корректно загрузится. Это может сделать только разработчик. Кроме того, загружаемому коду не позволяется делать в ключе все, что угодно - существуют ограничения.

Там кроме мигания светодиодом ничего нет.

Там загружается код, замените его на нечто читающее ячейки и все что после него в области кода и все дела.

romik пишет:

Можно уточнить, в каком примере показана дозапись в ячейку с загружаемым кодом, и передача управления дописаному коду?

Samples\ARM\05 - LED Control\

Там кроме мигания светодиодом ничего нет.