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\
Там кроме мигания светодиодом ничего нет.
]]>