Такая "Официальная" точка зрения излагалась не раз,
однако кроме официальной есть еще точки зрения рядовых потребителей......

Что то с такими настроениями придется копить деньги на J-link, я чувствую. Как частник не купиш, официальной поддержки нет, в наличии нет (обешали в начале февраля (я конечно понимаю, что до 15 числа еще только начало )).
Посоветуйте пожалуйста, что лучше: дожтаться MT-link или поднатужиться и взять
J-link(как я уже говорил, я частное лицо, для меня это почти хобби и не хочется пустить деньги на ветер).

Я J-Link в руках не держал :-(( Но собираюсь, как только подвернется. MT-Link в подавляющем большинстве случаев вполне работоспособен. Явно отсутствуют полько несколько фич второго плана.
По утверждению DASM родной J-Link периодически ему доступен (правда какого-то старого варианта исполнения по железу) и ведет у него так-же.
Полагаю, что во многих случаеях это так и есть, но в некоторыех случаях (например
поведение MT-Link+Драйвер при железном сбросе отлаживаемого устройсва или запуск при
отсутствии питания на устройстве) в это уже верится с трудом - уж больно ситуация лежит на поверхности.

Не очень понимаю, какую ценность для отладки имеют описанные Вами ситуации?

Это вызывает НЕУДОБСТВА, например при перезапусках системы и отладки процесса
инициализации, калибровки и прочего, который зачастую составляет ЛЬВИНУЮ долю кода.
Нажал кнопочку сброс и .... получил выпадение с воплем о потере MT-Link -
"удобно" до невозможности. При этом установках J-Link имеется возможности настойки перехватов
reset и еще массы других которые НЕ РАБОТАЮТ с MT-Link. Что их туда напмхали для тго, чтобы пользователи могли наезжать на поддержку J-Link с вопросами о неработосбособности?
Сомневаюсь. Аналогичная ситуация и с запуском MT-Link при случайно отключеном питании - получаем честное сообщение об отсутствии оного, но на этом все и кончается - далее на любую попытку продолжить MT-Link+Драйвер падают. Это смертельно? - нет конечно! Но присходят такие эффекты с родным J-Link - Сомневаюсь, ибо уж больно они заметны невооруженным глазом. Меня, больше беспокоят другие проблемы о которых я писал на этом форуме, которые повторились у Автора и.... остались :-( они гораздо более неоднозначны :-(.

Похоже всетаки МТ-Линк ждать буду. J-Link доступен только с TMS-FET470R1A256 который стоит у нас 17000руб. Для меня будет очень накладно.

Есть ещё непонятный момент - это скорость в 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.

Насколько я знаю, поддержки канала DCC в MT-Link нет вообще. Что там получается в результате
вызова - неизвестно. А если попрробовать поддержку DCC отключить? Или этой возможности нет в
CW?

Лично у меня (IAR) реальная скорость закачки может ОЧЕНЬ прыгать - тоже бывае шьется буквально
несколько байт в секунду, потом устаканивается. Проявляется чаще на более слабых машинах.
Шьется в том числе и LPC2294. Обычная реальная скорость порядка десятков килобайт.

поясняю. DCC канал поддерживается ровно настолько, насколько он он поддерживается драйверами джлинка. Никаких специальных запросов к джлинку не делается - все идет как обычно. Просто в ОЗУ необходимо загрузить код, который будет работать через DCC канал. Все это хорошо видно на примере JFlash, при установке галочки Use DCC скорость программирования возрастает в 1.7 раза. По поводу Catch Exception - пожалуйста, сообщите номера страниц в описании джлинк как именно и в каких условиях они должны работать

А какой номер аси ? Вроде всем всегда отвечаю, если на месте

Ася 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, надеюсь прокатит!

ну что я могу сказать. "Нет, я не плачу и не рыдаю,
На все вопросы я открыто отвечаю,
Что наша жизнь игра, и кто ж тому виной,
Что я увлекся этою игрой?

И перед кем же мне извиняться?
Мне уступают, я не в силах отказаться.
И разве мой талант и мой душевный жар
Не заслужили скромный гонорар?" :-)))
Update для 300-ых версий дров от сеггера будет в понедельник - они пошустрее кстати. Но CW это вряд ли поможет

По поводу J-Link и CrossWorks...

Я никогда не работал с МТ-Link,а вот с J-Link(производитель -Segger)
приходится иногда работать. И скорости загрузки из CrossWorks у
меня получались практически такими-же, как и у Alex03...
Просто J-Link в CrossWorks работает очень медленно(зато как он
работает с родной утилитой J-Flash - very impressive!)

не прокатит. Она (dll) тут же ответа хочет, причем не надуманного.


а на тему Catch Exception в родном девайсе не просветите ? Не сколько меня, сколько некоторых товарищей

Спасибо за инфу.
Теперь к DASM-у в этом вопросе вопросов больше нет.
Видимо jlinkarm.dll не оптимально написана, или CW её
не очень корректно пользует.



В первом приближении уже прокатило! Около 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 - гады!