[Rst7 5]

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

 

Ну и что, реальное железо тоже поддается отладке. А, например, может быть и так - вот я тут на днях написал кодер JPEG, и отладил его в AVR Studio. Вообще без железа, но писал сразу для целевого проца, отладил в симуляторе. И ничего, не умер, как ни странно. Хотя, конечно, другим так делать не посоветую ;)

[DogPawlowa 0]

Все зависит от сложности поднимаемых протоколов и вообще возможности их отладки. Даже какой-нибудь до невозможности обсосанный TCP/IP писать и отлаживать на реальном железе просто неудобно. Если говорить о чем-нибудь более сложном, то реальное железо просто будет мешать, ибо на самом деле сколь-нибудь отладить такое возможно только на модели с тестбенчами и прочим. Ни одно "реальное" применение не даст ничего подобного полной картине. Да и не протокольные вещи тоже - классический пример - ну как Вы собираетесь отлаживать, напрмер, какой-нибудь алгоритм сжатия залив его реальное железо?

Удобнее - да, единственно возможно - нет.

Если речь идет о протоколах, то сложные протоколы, как правило, все равно сертифицируются с помощью инструментов, предоставляемых организацией, создавшей стандарт, на реальном устройстве, а все уровни взаимодействия прописаны детально. Модели - это всего лишь костыли :)

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

[GetSmart 0]

А, например, может быть и так - вот я тут на днях написал кодер JPEG,

Да, JPEG идеально ложится на 8-битник :) Там вроде бы пол алгоритма считается на плавучке. Кстати, не поделитесь инфой о быстродействии получившегося алгоритма? Просто любопытно.

[aaarrr 69]

Плавучка для JPEG'а вовсе не обязательна. А вот отлаживать его в симуляторе - это сильно. Не знаю, как в AVR Studio, но под VDSP у меня не хватило терпения: вычисления идут на много (4-6) порядков медленнее, чем в железе.

[Rst7 5]

Там вроде бы пол алгоритма считается на плавучке

 

Только целые. Причем 16 бит.

 

Кстати, не поделитесь инфой о быстродействии получившегося алгоритма? Просто любопытно.

 

А потом Вы будете меня убеждать, что на ARM быстрее? ;)

 

Тестовая картинка 320*240 пакуется примерно за 12 миллионов тактов. Т.е. примерно секунду (кварц планируется 14-16МГц). Для последующей передачи через GPRS, например, такое малокадровое телевидение - самое оно.

[Evgeny_CD 0]

...Это для совместимости с 3.3 В питанием...

Это так. Но есть и еще одно "но". Стоимость масок для "дебаггинга" rev. A -> rev. G для технологии 0.18 и 0.35 сильно разные. Настолько, что для 0.35 Атмел может позволить себе оплатить этот процесс сам. А вот для 0.18 его оплачивать вынуждены мы. :07:

[zltigo 1]

Если речь идет о протоколах, то сложные протоколы, как правило, все равно сертифицируются с помощью инструментов, предоставляемых организацией, создавшей стандарт, на реальном устройстве, а все уровни взаимодействия прописаны детально. Модели - это всего лишь костыли :)

Для тестирования, например, протокольчика SS7 http://en.wikipedia.org/wiki/Signaling_System_7 потребуется в буквальном смысле гора железа c соответствующей стоимостью. К горе железа еще и специалисты по этой горе железа не помешают... Причем все вместе при сертификационных испытаниях проверит далеко даже не на 90%. Оставшихся десять хватит для полного облома...

[Evgeny_CD 0]

Что такое "технологию синтетических портов".

Почитайте PDF в корневом посте топика и поищите мои старые посты по теме.

Еще говорилось где-то, что для XMEGA компилятор IAR в процессе улучшения и нужно еще подождать пока. Т.е. как с доступным софтом?

:07: А чего там отлаживать, если ядро совместимое? Вроде как обычный AVR код должен исполняться. Хидеры написать - так вроде Атмел нам уже помог.

[blackfin 22]

А потом Вы будете меня убеждать, что на ARM быстрее? ;)

Тестовая картинка 320*240 пакуется примерно за 12 миллионов тактов.

Не хочу никого убежать, но на блэкфине для сжатия цветной картинки 320*240 требуется примерно 5 MIPS'ов.. ;)

[Evgeny_CD 0]

Я имею некоторый опыт такого "портирования". Больших преимуществ, кроме удобства отладки целевого кода, быстроты внесения изменений, возможности работы в команде, возможности согласования UI с заказчиком без собственно прибора, он не имеет. Но это не всегда нужно. А ужимать и оптимизировать при переносе - двойная работа и большой риск.

IMHO, список преимуществ исчерпывающий и впечатляющий. :) Действительно, есть простые проекты, в которых это не надо. Но лично у меня таких становится все меньше.

[Rst7 5]

Не хочу никого убежать, но на блэкфине для сжатия цветной картинки 320*240 требуется примерно 5 MIPS'ов..

 

Да я ж не спорю. Можно попробовать асилить на FPGA еще быстрее.

[Evgeny_CD 0]

Да, JPEG идеально ложится на 8-битник :) Там вроде бы пол алгоритма считается на плавучке. Кстати, не поделитесь инфой о быстродействии получившегося алгоритма? Просто любопытно.

Идем к первоистокам http://www.ijg.org и смотрим, что плавучка может быть, а может и не быть. IMHO, очень хорошая либа (да и стиль С программизма там шикарный, хотя с непривычки и несколько тяжеловесный), если ее не использовать "в лоб", то можно использовать как пособие по разработке своего варианта кодека.

[Rst7 5]

если ее не использовать "в лоб", то можно использовать как пособие по разработке своего варианта кодека.

 

В лоб на маленьких камнях ее очень тяжело использовать - например, нужен менеджер кучи. При переработке всего этого дела (особый зачот там людям за быстрый целочисленный DCT 8*8) с отбрасыванием лишнего все вполне хорошо раскладывается - 2килобайта кода, 1.5 килобайта таблиц во флеше, 400 байт данных, 20 байт CSTACK.

[Evgeny_CD 0]

Ну и что, реальное железо тоже поддается отладке. А, например, может быть и так - вот я тут на днях написал кодер JPEG, и отладил его в AVR Studio. Вообще без железа, но писал сразу для целевого проца, отладил в симуляторе. И ничего, не умер, как ни странно. Хотя, конечно, другим так делать не посоветую ;)

Железо разное бывает. Ядро проца, память, таймер в простейшем режиме как правило, достаточно хорошо поддаются симуляции. А вот какой-нибудь таймер с PWM, IMHO, я и не мечтаю увидеть работающим в симуляторе.

 

Можно конечно, запустить на симуляцию HDL код периферии, но так JPEG можно до пенсии отлаживать :)

[zltigo 1]

Да я ж не спорю. Можно попробовать асилить на FPGA еще быстрее.

Тут наверное НАДО помнить о том, что и BF и FPGA уже находятся в одной ценовой категории с атмеловскими средне-старшими восьмибитовиками. Вот такая жизнь настала, пока "будущее, которое ждали" все не наступало и не наступало.