zltigo 1 5 февраля, 2006 Опубликовано 5 февраля, 2006 · Жалоба ...но что под ней понимать, работает ведь. Такая "Официальная" точка зрения излагалась не раз, однако кроме официальной есть еще точки зрения рядовых потребителей...... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
electrovenic 0 6 февраля, 2006 Опубликовано 6 февраля, 2006 · Жалоба Что то с такими настроениями придется копить деньги на J-link, я чувствую. Как частник не купиш, официальной поддержки нет, в наличии нет (обешали в начале февраля (я конечно понимаю, что до 15 числа еще только начало )). Посоветуйте пожалуйста, что лучше: дожтаться MT-link или поднатужиться и взять J-link(как я уже говорил, я частное лицо, для меня это почти хобби и не хочется пустить деньги на ветер). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 6 февраля, 2006 Опубликовано 6 февраля, 2006 · Жалоба Что то с такими настроениями придется копить деньги на J-link, я чувствую. Как частник не купиш, официальной поддержки нет, в наличии нет (обешали в начале февраля (я конечно понимаю, что до 15 числа еще только начало )). Посоветуйте пожалуйста, что лучше: дожтаться MT-link или поднатужиться и взять J-link(как я уже говорил, я частное лицо, для меня это почти хобби и не хочется пустить деньги на ветер). Я J-Link в руках не держал :-(( Но собираюсь, как только подвернется. MT-Link в подавляющем большинстве случаев вполне работоспособен. Явно отсутствуют полько несколько фич второго плана. По утверждению DASM родной J-Link периодически ему доступен (правда какого-то старого варианта исполнения по железу) и ведет у него так-же. Полагаю, что во многих случаеях это так и есть, но в некоторыех случаях (например поведение MT-Link+Драйвер при железном сбросе отлаживаемого устройсва или запуск при отсутствии питания на устройстве) в это уже верится с трудом - уж больно ситуация лежит на поверхности. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 6 февраля, 2006 Опубликовано 6 февраля, 2006 · Жалоба ...в некоторыех случаях (например поведение MT-Link+Драйвер при железном сбросе отлаживаемого устройсва или запуск при отсутствии питания на устройстве)... Не очень понимаю, какую ценность для отладки имеют описанные Вами ситуации? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 6 февраля, 2006 Опубликовано 6 февраля, 2006 · Жалоба Не очень понимаю, какую ценность для отладки имеют описанные Вами ситуации? Это вызывает НЕУДОБСТВА, например при перезапусках системы и отладки процесса инициализации, калибровки и прочего, который зачастую составляет ЛЬВИНУЮ долю кода. Нажал кнопочку сброс и .... получил выпадение с воплем о потере MT-Link - "удобно" до невозможности. При этом установках J-Link имеется возможности настойки перехватов reset и еще массы других которые НЕ РАБОТАЮТ с MT-Link. Что их туда напмхали для тго, чтобы пользователи могли наезжать на поддержку J-Link с вопросами о неработосбособности? Сомневаюсь. Аналогичная ситуация и с запуском MT-Link при случайно отключеном питании - получаем честное сообщение об отсутствии оного, но на этом все и кончается - далее на любую попытку продолжить MT-Link+Драйвер падают. Это смертельно? - нет конечно! Но присходят такие эффекты с родным J-Link - Сомневаюсь, ибо уж больно они заметны невооруженным глазом. Меня, больше беспокоят другие проблемы о которых я писал на этом форуме, которые повторились у Автора и.... остались :-( они гораздо более неоднозначны :-(. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
electrovenic 0 9 февраля, 2006 Опубликовано 9 февраля, 2006 · Жалоба Похоже всетаки МТ-Линк ждать буду. J-Link доступен только с TMS-FET470R1A256 который стоит у нас 17000руб. Для меня будет очень накладно. :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alex03 0 9 февраля, 2006 Опубликовано 9 февраля, 2006 · Жалоба Есть ещё непонятный момент - это скорость в CW. Один и тот-же проект 84.6kB записываем по флэш LPC2292. Виглер Erasing completed in 4.1 s — 21,335 bytes/sec Programming completed in 5.3 s — 16,457 bytes/sec Verifying completed in 657 ms — 131,908 bytes/sec MT-Link Erasing completed in 4.1 s — 21,168 bytes/sec Programming completed in 22.3 s — 3,878 bytes/sec Verifying completed in 671 ms — 129,156 bytes/sec Т.е. скорость записи флэша более чем в 4 раза медленней чем у виглера. По версии DASM-а CW дробит данные при программировании на пакеты по 30 байт. Я покапавшись немного обларужил что CW при программировании вызывает JLINKARM_WriteDCC() (из jlinkarm.dll) с 2.5КилоСлова (10КБайт). И именно эта JLINKARM_WriteDCC() выполняется несколько секунд. Т.е. если кто и дробит на пакеты так это segger-овская jlinkarm.dll. DASM по Асе мне на это ничего не ответил. Поэтому вопрос к владельцам оригинального J-Link-а какова у вас скорость записи в CW. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 февраля, 2006 Опубликовано 9 февраля, 2006 · Жалоба Я покапавшись немного обларужил что CW при программировании вызывает JLINKARM_WriteDCC() (из jlinkarm.dll) с 2.5КилоСлова (10КБайт). И именно эта Насколько я знаю, поддержки канала DCC в MT-Link нет вообще. Что там получается в результате вызова - неизвестно. А если попрробовать поддержку DCC отключить? Или этой возможности нет в CW? Лично у меня (IAR) реальная скорость закачки может ОЧЕНЬ прыгать - тоже бывае шьется буквально несколько байт в секунду, потом устаканивается. Проявляется чаще на более слабых машинах. Шьется в том числе и LPC2294. Обычная реальная скорость порядка десятков килобайт. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 10 февраля, 2006 Опубликовано 10 февраля, 2006 · Жалоба поясняю. DCC канал поддерживается ровно настолько, насколько он он поддерживается драйверами джлинка. Никаких специальных запросов к джлинку не делается - все идет как обычно. Просто в ОЗУ необходимо загрузить код, который будет работать через DCC канал. Все это хорошо видно на примере JFlash, при установке галочки Use DCC скорость программирования возрастает в 1.7 раза. По поводу Catch Exception - пожалуйста, сообщите номера страниц в описании джлинк как именно и в каких условиях они должны работать Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 10 февраля, 2006 Опубликовано 10 февраля, 2006 · Жалоба Есть ещё непонятный момент - это скорость в CW. Один и тот-же проект 84.6kB записываем по флэш LPC2292. Виглер Erasing completed in 4.1 s — 21,335 bytes/sec Programming completed in 5.3 s — 16,457 bytes/sec Verifying completed in 657 ms — 131,908 bytes/sec MT-Link Erasing completed in 4.1 s — 21,168 bytes/sec Programming completed in 22.3 s — 3,878 bytes/sec Verifying completed in 671 ms — 129,156 bytes/sec Т.е. скорость записи флэша более чем в 4 раза медленней чем у виглера. По версии DASM-а CW дробит данные при программировании на пакеты по 30 байт. Я покапавшись немного обларужил что CW при программировании вызывает JLINKARM_WriteDCC() (из jlinkarm.dll) с 2.5КилоСлова (10КБайт). И именно эта JLINKARM_WriteDCC() выполняется несколько секунд. Т.е. если кто и дробит на пакеты так это segger-овская jlinkarm.dll. DASM по Асе мне на это ничего не ответил. Поэтому вопрос к владельцам оригинального J-Link-а какова у вас скорость записи в CW. А какой номер аси ? Вроде всем всегда отвечаю, если на месте Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alex03 0 11 февраля, 2006 Опубликовано 11 февраля, 2006 · Жалоба Ася 66740044, но спрашивал я перед НГ. В общем получается так: Для записи флеша CW в цикле вызывает 1. JLINKARM_WriteDCC() с буфером в 2 слова В первом слове типа кода команды и длина Во втором слове адрес 2. JLINKARM_WriteDCC() с буфером в 0x0A00 слов или 10килобайт собственно данных. Эти 10кБ пишутся несколько сек. Всё это один в один приходит в loader который в RAM ARM-а загружен. Так что на CW я в этой части не грешу. Осталось выяснить где собака порылась в софте ceggera c их сотней вызовов в jlinkarm.dll или в MT-LINK-е. До кучи сейчас ещё один эксперимент провёл. CW со своим лоадером умеет двумя способами общаться 1. Через ARM debug comms channel (По дефолту для большинства процев) 2. Через буфер в RAM. Исходников лоадера под кучу платформ навалом. Вот я и скомпилял лоадер под использование буфера в RAM. Но..., Факир был пьян, фокус не прокатил, скорость ещё меньше оказалась около 3кБ/сек. При этом CW не хорошо поступает. 1. Для загрузки лоадера вызывает JLINKARM_WriteMem с буфером размером с сам лоадер, поэтому лоадер грузится моментально. 2. Сами данные для записи во флэш пихает в RAM через вызов JLINKARM_WriteU32 т.е. по одному слову! :( Гады! Думаю теперь мож во враппере jlinkarm.dll отлавливать JLINKARM_WriteU32 со смежными адресами и группировать их в один вызов JLINKARM_WriteMem, надеюсь прокатит! :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 11 февраля, 2006 Опубликовано 11 февраля, 2006 · Жалоба ну что я могу сказать. "Нет, я не плачу и не рыдаю, На все вопросы я открыто отвечаю, Что наша жизнь игра, и кто ж тому виной, Что я увлекся этою игрой? И перед кем же мне извиняться? Мне уступают, я не в силах отказаться. И разве мой талант и мой душевный жар Не заслужили скромный гонорар?" :-))) Update для 300-ых версий дров от сеггера будет в понедельник - они пошустрее кстати. Но CW это вряд ли поможет Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yuri_t 0 11 февраля, 2006 Опубликовано 11 февраля, 2006 · Жалоба По поводу J-Link и CrossWorks... Я никогда не работал с МТ-Link,а вот с J-Link(производитель -Segger) приходится иногда работать. И скорости загрузки из CrossWorks у меня получались практически такими-же, как и у Alex03... Просто J-Link в CrossWorks работает очень медленно(зато как он работает с родной утилитой J-Flash - very impressive!) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 11 февраля, 2006 Опубликовано 11 февраля, 2006 · Жалоба Ася 66740044, но спрашивал я перед НГ. В общем получается так: Для записи флеша CW в цикле вызывает 1. JLINKARM_WriteDCC() с буфером в 2 слова В первом слове типа кода команды и длина Во втором слове адрес 2. JLINKARM_WriteDCC() с буфером в 0x0A00 слов или 10килобайт собственно данных. Эти 10кБ пишутся несколько сек. Всё это один в один приходит в loader который в RAM ARM-а загружен. Так что на CW я в этой части не грешу. Осталось выяснить где собака порылась в софте ceggera c их сотней вызовов в jlinkarm.dll или в MT-LINK-е. До кучи сейчас ещё один эксперимент провёл. CW со своим лоадером умеет двумя способами общаться 1. Через ARM debug comms channel (По дефолту для большинства процев) 2. Через буфер в RAM. Исходников лоадера под кучу платформ навалом. Вот я и скомпилял лоадер под использование буфера в RAM. Но..., Факир был пьян, фокус не прокатил, скорость ещё меньше оказалась около 3кБ/сек. При этом CW не хорошо поступает. 1. Для загрузки лоадера вызывает JLINKARM_WriteMem с буфером размером с сам лоадер, поэтому лоадер грузится моментально. 2. Сами данные для записи во флэш пихает в RAM через вызов JLINKARM_WriteU32 т.е. по одному слову! :( Гады! Думаю теперь мож во враппере jlinkarm.dll отлавливать JLINKARM_WriteU32 со смежными адресами и группировать их в один вызов JLINKARM_WriteMem, надеюсь прокатит! :) не прокатит. Она (dll) тут же ответа хочет, причем не надуманного. По поводу J-Link и CrossWorks... Я никогда не работал с МТ-Link,а вот с J-Link(производитель -Segger) приходится иногда работать. И скорости загрузки из CrossWorks у меня получались практически такими-же, как и у Alex03... Просто J-Link в CrossWorks работает очень медленно(зато как он работает с родной утилитой J-Flash - very impressive!) а на тему Catch Exception в родном девайсе не просветите ? Не сколько меня, сколько некоторых товарищей Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alex03 0 11 февраля, 2006 Опубликовано 11 февраля, 2006 · Жалоба По поводу J-Link и CrossWorks... Я никогда не работал с МТ-Link,а вот с J-Link(производитель -Segger) приходится иногда работать. И скорости загрузки из CrossWorks у меня получались практически такими-же, как и у Alex03... Просто J-Link в CrossWorks работает очень медленно(зато как он работает с родной утилитой J-Flash - very impressive!) Спасибо за инфу. Теперь к DASM-у в этом вопросе вопросов больше нет. Видимо jlinkarm.dll не оптимально написана, или CW её не очень корректно пользует. Думаю теперь мож во враппере jlinkarm.dll отлавливать JLINKARM_WriteU32 со смежными адресами и группировать их в один вызов JLINKARM_WriteMem, надеюсь прокатит! :) не прокатит. Она (dll) тут же ответа хочет, причем не надуманного. В первом приближении уже прокатило! Около 25кБ/сек получилось! :) Смысл такой: jlinkarm.dll переименовываем в jlinkarm_orig.dll Пишем враппер dll - jlinkarm.dll которая экспортирует все функции оригинальной dll. В этой dll реализуем обёртки вокруг всех функций, вызывая функции оригинальной dll используя LoadLibrary() и GetProcAddress() Далее добавляем свою функциональность. В частности: в JLINKARM_WriteU32() оригинальную функцию не зовём а сохраняем данные в буфере и возвращает управление в CW. Если CW вызывает любую другую функцию, или ту же JLINKARM_WriteU32() но с не смежным по отношению к данным в буфере адресом или если буфер полон то вызываем JLINKARM_WriteMem() и передаём в неё данные из буфера. Т.е. для больших кусков данных записываемых в RAM, тысячи вызовов JLINKARM_WriteU32() заменяем на один JLINKARM_WriteMem(). Результат налицо! Подробности (файлы) для общественности немного попозже. Сейчас мне такие недостатки видятся: - Отложенная реальная запись - не выдерживаются какиенить таймауты и в том числе неверно может считаться скорость записи особенно для последнего куска. - буферезируется не только запись в RAM, но и во всевозможные регистры. Думаю надо буферезировать только запись в RAM. Но RAM в разных чипах в разных местах. Сделаю версию для LPC. P.S. А CW - гады! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
