Подскажите, пожалуйста, подходит ли MT-Link для плат на ядре ARM920T фирмы Atmel?

К сожалению, этот вопрос до сих пор без ответа.
Похоже сам разработчик пока к нему не подключал свой прибор.

подходит. Поверяли.

Спасибо. А есть ли возможность работы через MT-Link со средой ADS? Если да, то каким способом?

Тем-же способом, что и J-Link -> через RDI
Почитайте на сайте Segger.

одна тонкость. Новых мтлинков больше не будет. Closed. Если можно - без объяснения причин. Поддержку будет вести Xelen (приведу на этот форум)

Честно говоря было уже заметно :-(
Жаль.

Дык может тогда в паблик? Когда запасы кончаться. И глюки быстрее выявим на множестве камней, И с поддержкой непрерывно изменяющегося протокола будет проще.

Насколько я понимаю, продавать их под флагом MT-System будут, просто официальная поддержка так и не появится, а неофициальной поддержки и развития более не будет.
В даных условиях паблик невозможен.

всетаки хотелосьбы понять, стоитли брать пока еще есть мтлинки или они того уже нестоят?
только собрался брать как все разом и закончилось.....
из доступного только оные и все (wiggler не считаю)

почему же не стоит, строго отрицательного я про них не видела. А их самих я переведу на другой процессор, так что выше голову. Заказывать можно и сейчас (старых еще есть немного, новые на подходе)

Так а где заказывать то? Очень хочется, но не знаю где купить.
MT-Systems на сообшения не отвечает.
Они их продают? И больше никто?

продают только они, не отвечают, видимо, из-за перехода на другой чип

2 Xylene

Я наверное выражу мнение многих пользователей, надо бы сделать страницу поддержки MT-LINK, где можно было бы обновлять прошивки.
Пока версии прошивок прикреплялись в 2-х темах:
http://electronix.ru/forum/index.php?showtopic=9640
http://electronix.ru/forum/index.php?act=ST&f=43&t=9296

И, кстати, что слышно о заявленой поддержке MSP430?

А стоит ли покупать со старым или все же подождать?
Тогда возникает логичный вопрос. Сколько ждать появления версии с другим чипом и что изменится по сравнению с тем что есть сейчас?

появится гальвоноразвязанный вариант, улучшим питание. В прямом виде это будет некий "кит", софт записывает в него пользователь (так же просто, как и update). Почему так - думаю понимаете.
VAI - я заберу исходники, но обещать не могу. Если Вам так это важно, верните приборы назад, Вам не откажут. DASM явно поторопился.

Возвращать не собираюсь, у нас паралельные проекты на АРМ и МСП.

Как я поняла соотношение заказов по MSP к ARM 1-100. Вот декларировать не надо было поддержку, согласна

Хотелосьбы поподробнее узнать про кит что из себя будет представлять, и как это отразится на его цене.
Побольшому счету интересен отладчик в коробке, с подержкой (update прошивки) и работоспособностью в новых версиях IDE .

Ну а все таки, хоть примерная ожидаемая дата появления в продвже новой версии есть?
Просто вопрос стоит, добиваться ли сейчас у МТ-СИСТЕМС программатора, или ждать. Если ждать, то хочется знать хоть порядок количества дней :-)

Ну какая такая поддержка и какие такие обновления прошивок :-(
Помер проект. Коммерческя выгода будет излекаться и не более того.
Я не припомню, в конце-концов здесь пробегала прошивка 1.5
(которая "11111114' ) - если нет, то могу выложить.

У меня ее нету. Если не трудно, выложите.

Я что-то где-то проморгал??? - Что случилось с MT-LINK и самим DASM? Если это топ-сикрет, то в привейт сообщите плиз!

А то я то-же обладатель MT-LINK и перспектива похорон этой примочки как-то не очень!

Пишпилена...

Похоже на секрет. Все, что посчитал нужным сообщить DASM находится в его
очень кратком, но абсолютно доходчивом "послании", в этой ветке.

Почему похорон, сломалась разве?

Вкратце. Девайс будет, поддержка старых тоже (но что под ней понимать, работает ведь), но для повышения скорости нужен переход на другой процессор. Новые будут через месяц примерно, и я сильно постараюсь, чтобы приобрести их можно было без проблем

На будущие,
хотелосьбы както распозновать версии отладчикой а то он все время mt-link (и все)
а потом народ пытается выяснять у кого сколько лампочек на передней панели и определить версию и соотвенно подходит обновление прошивки...

P.S. С нетерпением жду выхода новой версии.

у него серийник - это номер версии. Но новые версии будут продаваться как кит - без софта. Софт будет лежать в интернете и заливаться поьзователем через USB - 5 секундная операция.

Как цена ожидается ?

Уже хочу такой, именно в виде КИТа.

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

Что то с такими настроениями придется копить деньги на 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 - гады!

Гм. Крут :-) Поздравляю.

Подробности тут: http://www.caxapa.ru/echo/arm.html?id=51086