Rst7 5 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба ну как Вы собираетесь отлаживать, напрмер, какой-нибудь алгоритм сжатия залив его реальное железо? Ну и что, реальное железо тоже поддается отладке. А, например, может быть и так - вот я тут на днях написал кодер JPEG, и отладил его в AVR Studio. Вообще без железа, но писал сразу для целевого проца, отладил в симуляторе. И ничего, не умер, как ни странно. Хотя, конечно, другим так делать не посоветую ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба Все зависит от сложности поднимаемых протоколов и вообще возможности их отладки. Даже какой-нибудь до невозможности обсосанный TCP/IP писать и отлаживать на реальном железе просто неудобно. Если говорить о чем-нибудь более сложном, то реальное железо просто будет мешать, ибо на самом деле сколь-нибудь отладить такое возможно только на модели с тестбенчами и прочим. Ни одно "реальное" применение не даст ничего подобного полной картине. Да и не протокольные вещи тоже - классический пример - ну как Вы собираетесь отлаживать, напрмер, какой-нибудь алгоритм сжатия залив его реальное железо? Удобнее - да, единственно возможно - нет. Если речь идет о протоколах, то сложные протоколы, как правило, все равно сертифицируются с помощью инструментов, предоставляемых организацией, создавшей стандарт, на реальном устройстве, а все уровни взаимодействия прописаны детально. Модели - это всего лишь костыли :) Что касается непротокольных вещей, то отладка через JTAG дает пусть неудобный и недостаточный, но достаточно эффективный контроль целевым устройством. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба А, например, может быть и так - вот я тут на днях написал кодер JPEG,Да, JPEG идеально ложится на 8-битник :) Там вроде бы пол алгоритма считается на плавучке. Кстати, не поделитесь инфой о быстродействии получившегося алгоритма? Просто любопытно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба Плавучка для JPEG'а вовсе не обязательна. А вот отлаживать его в симуляторе - это сильно. Не знаю, как в AVR Studio, но под VDSP у меня не хватило терпения: вычисления идут на много (4-6) порядков медленнее, чем в железе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба Там вроде бы пол алгоритма считается на плавучке Только целые. Причем 16 бит. Кстати, не поделитесь инфой о быстродействии получившегося алгоритма? Просто любопытно. А потом Вы будете меня убеждать, что на ARM быстрее? ;) Тестовая картинка 320*240 пакуется примерно за 12 миллионов тактов. Т.е. примерно секунду (кварц планируется 14-16МГц). Для последующей передачи через GPRS, например, такое малокадровое телевидение - самое оно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба ...Это для совместимости с 3.3 В питанием...Это так. Но есть и еще одно "но". Стоимость масок для "дебаггинга" rev. A -> rev. G для технологии 0.18 и 0.35 сильно разные. Настолько, что для 0.35 Атмел может позволить себе оплатить этот процесс сам. А вот для 0.18 его оплачивать вынуждены мы. :07: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба Если речь идет о протоколах, то сложные протоколы, как правило, все равно сертифицируются с помощью инструментов, предоставляемых организацией, создавшей стандарт, на реальном устройстве, а все уровни взаимодействия прописаны детально. Модели - это всего лишь костыли :) Для тестирования, например, протокольчика SS7 http://en.wikipedia.org/wiki/Signaling_System_7 потребуется в буквальном смысле гора железа c соответствующей стоимостью. К горе железа еще и специалисты по этой горе железа не помешают... Причем все вместе при сертификационных испытаниях проверит далеко даже не на 90%. Оставшихся десять хватит для полного облома... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба Что такое "технологию синтетических портов".Почитайте PDF в корневом посте топика и поищите мои старые посты по теме.Еще говорилось где-то, что для XMEGA компилятор IAR в процессе улучшения и нужно еще подождать пока. Т.е. как с доступным софтом? :07: А чего там отлаживать, если ядро совместимое? Вроде как обычный AVR код должен исполняться. Хидеры написать - так вроде Атмел нам уже помог. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 26 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба А потом Вы будете меня убеждать, что на ARM быстрее? ;) Тестовая картинка 320*240 пакуется примерно за 12 миллионов тактов. Не хочу никого убежать, но на блэкфине для сжатия цветной картинки 320*240 требуется примерно 5 MIPS'ов.. ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба Я имею некоторый опыт такого "портирования". Больших преимуществ, кроме удобства отладки целевого кода, быстроты внесения изменений, возможности работы в команде, возможности согласования UI с заказчиком без собственно прибора, он не имеет. Но это не всегда нужно. А ужимать и оптимизировать при переносе - двойная работа и большой риск.IMHO, список преимуществ исчерпывающий и впечатляющий. :) Действительно, есть простые проекты, в которых это не надо. Но лично у меня таких становится все меньше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба Не хочу никого убежать, но на блэкфине для сжатия цветной картинки 320*240 требуется примерно 5 MIPS'ов.. Да я ж не спорю. Можно попробовать асилить на FPGA еще быстрее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба Да, JPEG идеально ложится на 8-битник :) Там вроде бы пол алгоритма считается на плавучке. Кстати, не поделитесь инфой о быстродействии получившегося алгоритма? Просто любопытно.Идем к первоистокам http://www.ijg.org и смотрим, что плавучка может быть, а может и не быть. IMHO, очень хорошая либа (да и стиль С программизма там шикарный, хотя с непривычки и несколько тяжеловесный), если ее не использовать "в лоб", то можно использовать как пособие по разработке своего варианта кодека. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба если ее не использовать "в лоб", то можно использовать как пособие по разработке своего варианта кодека. В лоб на маленьких камнях ее очень тяжело использовать - например, нужен менеджер кучи. При переработке всего этого дела (особый зачот там людям за быстрый целочисленный DCT 8*8) с отбрасыванием лишнего все вполне хорошо раскладывается - 2килобайта кода, 1.5 килобайта таблиц во флеше, 400 байт данных, 20 байт CSTACK. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба Ну и что, реальное железо тоже поддается отладке. А, например, может быть и так - вот я тут на днях написал кодер JPEG, и отладил его в AVR Studio. Вообще без железа, но писал сразу для целевого проца, отладил в симуляторе. И ничего, не умер, как ни странно. Хотя, конечно, другим так делать не посоветую ;)Железо разное бывает. Ядро проца, память, таймер в простейшем режиме как правило, достаточно хорошо поддаются симуляции. А вот какой-нибудь таймер с PWM, IMHO, я и не мечтаю увидеть работающим в симуляторе. Можно конечно, запустить на симуляцию HDL код периферии, но так JPEG можно до пенсии отлаживать :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 19 мая, 2008 Опубликовано 19 мая, 2008 · Жалоба Да я ж не спорю. Можно попробовать асилить на FPGA еще быстрее. Тут наверное НАДО помнить о том, что и BF и FPGA уже находятся в одной ценовой категории с атмеловскими средне-старшими восьмибитовиками. Вот такая жизнь настала, пока "будущее, которое ждали" все не наступало и не наступало. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться