В тази връзка ако ще оценяваме продукта дай да видим къде не е ок - работи под вин и линукс, поддържа много ядра, интерфейси и чипове, отворен е за ползване през gdb, iar, keil и много други. Друго предимство е че стана доста популярен заради jlink-ob вариантите за ОЕМ и развойни платки - ренесас примерно поддържат флашването на uboot, кърнел, rootfs и отделна потребителска партиция през j-link след компилиране - това цялото плюс дебъга минава през 2-те жици на SWD-то и влиза във външни SPI флашове.
Не знам за peedi, но от по-големите съм бил в досег за кратко с лаутербах - сериозна машина, но ако махнех бързия трейс не видях причина да натискам да харчим 2000 евра (е, похарчихме ги за други по-полезни благинки). Не мога да го оценявам понеже досега ми беше за 2 дни и половина.
То като се замисля никак не ми се връзва ползване на SWD по две жици и трейс през още 32. А SWD за мултидроп не знам как са го направили но си звучи като мъртво родено. За тези цели си има JTAG с глезотиите на return clock - няма как да стане приемливо бързо по 2 жици.
Да, сегера е завършен продукт - комплект от хардуер, софтуер, фирмъуер, документация и прочие. Това имам предвид като казвам жейлинк. Имало и СДК ама не съм я пипал. Да не би някой да го прави без софтуер? Подобието на трейс (RTT) е нещо което не съм срещал в openocd. Конкретното решение ми допада - спомням си че ти преди време говореше за цветове на терминала за трейс, така че не виждам какво не ти харесва сега. Не съм го ползвал понеже не ми е стила - печатането на текстове го ползвам само когато нямам възможност за истински дебъг.
Ако ги разгледаш ще видиш че имаха някъде и концепцията през трейса да минават двоични данни вместо целите текстове, а в пц терминала да се прави разгръщането от двубайтово число до 2 страници ферман. Което за мен е единствения смислен вариант за подобни логове - в реалната система се спестява ресурс да се въртят принтф-ове и разточителни текстове.
А поддръжката на други адаптери - няма как да стане, и те искат шницели да лапат. Ако има нужда от по-бърз или по-евтин адаптер те ще го разработят.

амчи да

Техниките за дебъг и трейс са измислени много преди сегер и даже АРМ. Специално това за софтуерния трейс, техниката общо взето е с брейкпоинт или уатчпоинт. Ако няма хардуерни такива става и брутфорс четене (макар че това е тъпо). Ако е брекпоинт обикновено се дефинира набор от функции като printf/scanf и т.н. Извикването на тези функции става през една служебна, на която с параметърче казваш коя функция точно искаш да се изпълни. Служебната функция е просто куха функция с един NOP примерно върху който се слага автоматично брейкпоинт. Та когато твоя код извика служебната, проца спира, дебъгера вижда че е спряло точно на служебната функция, чете си пареметрите и дърпа или праща данни изобщо изпълява каквото трябва и пуска таргета. Ако е с уатчпоинт е подобно, само че се прихваща писане/четене на определен адрес.
Не знам какво точно са съчинили сегер, но IAR навремето имаха пълен набор от функции, с документации и т.н. и си работеше *независимо* дали си с джейлинк или jtag емулатор през LPT порта... И принципно мястото на подобни софтуерни имплементации е в дебъгера. Казах вече, че при GDB могат да се имплементират безброй подобни щуротии тъй като има скриптиране, има възможност за хуукове почти на всички операции, така че не е никакъв проблем да направиш каквото си искаш... И пак повтарям без НИКАКВО значение какво ти е джелязото, дали си с АРМ, дали с ПИК32 или с джей-линк или без джей-линк....
Добре е да се знае, че ТАКА се прави по принцип, а не да си мислите че само еди кой си е изобретил колелото...

А специално за трейса на АРМ, там нещата са хардуерни. Разликата е като да правиш софтуерна емулация на UART клатейки пинове и истински хардуерен UART. Надявам се няма нужда да обяснявам разликата между софтуерна и хардуерна имплементация. Ще кажа само че идеята на трейс каналите НЕ е да спестват UART. Трейсът е така направен, че изисква ако не се лъжа бяха само два записа в два регистъра да хукне. Демек може да пусне още съвсем началото на ресет вектора, далеч далеч преди да си конфигурирал UART, клокове и т.н. Това е важно тъй като през нормален UART може да трейсваш чак когато вдигнеш всичко, ама вдигането не винаги минава (примерно кварца ти е дефектен) и е добре да може да го видиш това в трейса. Другата разлика спрямо UART са скоростите... хардуерния трейс обикновено почва от 50-100Мбит/с и може да стигне гигабити и даже много гигабайти в секунда. Това има значение ако примерно трейсваш TCP/IP пакети в реално време или USB комуникация и т.н.
Дали трейса си струва 2000 евра... ако си вадиш хляба с програмиране мисля че си ги струва. Още повече че лаутербаха си е с мноого повече екстри и лаутербах са си лаутербах и проблема не е 2к а по-скоро 20к за да се насладиш на пълния им комплект инструменти. И сигурно и 20-те к си струват, само дето аз не мога си ги позволя
Иначе за цветовете... то е елементарно, ей един скриншот от преди малко:

Без цветове трудно се прави да е прегледно кой какво казва и защо го казва... но това няма връзка нито с трейс нито с дебъг. Таргета сам си оцветява приказките...

Иначе да, профи емулаторите могат да флашват сичко дето се доберат някак си. Даже и с мойто пиди мога да пиша по всякакви серийни флашове, NAND/NOR и SDRAM памети и т.н. Но тия глезотии са повече за лайнукс и то ниско ниво, удобно е ако искаш да заредиш сума си мегабайти за отрицателно време... Удобно е също така да можеш да го правиш в standalone режим, т.е. без да има какъвто и да компютър наоколо. Има и други полезни щуротии, за съжаление аз нямам най-полезните като ревърс дебъга... но някой ден като порасна тати ще ми купи и колело

Има ли разлика между edu версията на jlink-а и нормалната такава освен лиценза?
Днес поръчах едно edu да го пробвам, че тоя USBDM дето го ползвам за програмиране става идеално, но за дебъгване ми къса нервите.

Не, еду-то е с всичко което има base-а, както и допълнителните опции.
Edit: цитат от adafruit магазина https://www.adafruit.com/product/1369

Търся фърмуерите на j-link v5, v6, v7 & v8, чета тук, че се налага доста често да се префлашват - какъв е проблема? Заради самият ъпдейт от страна на DLL-a или просто се скапват дивайсите?

Специално за v8 съм установил, че проблема е само от страна на DLL-а. Самият фърмуер не мисля че е физически повреден при детекция на клонинг (с моднат DLL си работи без да се оплаква , дори и преди това да е бил разпознат като клонинг).
Фърмуерите може да си извадиш с инструмента постнат малко по - назад в темата.

Това което се случва често на старите е да си омажат флаша процесорите (атмел). Затова се трият и със самба се презареждат. Друга оправия няма (освен слагането на чип със суфикс A който няма тази болест). Това си е хардуерен бъг на атмел, адаптера може да си отиде докато си работи със стар dll.
Новите са с STM32 и такива изблици на недоволство няма.

И с А се затриват. Доказано

Сега като споменахте версии на чипа се сетих, че този с който съм е от Миро - at91sam7s64au (до колкото помня няма САМБА) и определено не се затрива като бъде изловен че е клонинг.

Какво се има в предвид под моднат DLL? Вътре в него намирам последните фърмуери на всички хардуерни версии. На всеки един в началото има версията - това ли е модването?

Има "черен" списък със серийни номера в dll-а. Моднат в този случай значи - да си намериш серийния номер в DLL-а и да промениш поне 1 байт от него.

А серийният номер не може ли да се намери из фърмуера? А как се вадят фърмуерите не разбрах - могат да се изчетат с програматор или от DLL-a? Има ли вариант да се чете заключен AT91SAM7S64?

Купих от олимекс SAM7-H64 и се опитах да налея един бин файл за v5 на j-link. Качи се успешно (изчете се успешно) но като го включа в УСБ-то - мълчи, и windowsa не го разпознава. Някой борил ли се е с подобно нещо, не искам да губя излишно време - ако може някой, нека помага.

Е то това SAM7-H64 като хадуер съвпада ли изцяло с J-link V5? Щото той си има накачурени разни неща по портовете и си ги проверява вероятно при стартиране. Най - малкото разни ADC входове и ала-бала.

А и каква е целта на подобно мероприятие? Не е ли по-лесно да си вземеш готов J-link, пък бил той и лееееко китайски?

имам един къстъм дивайс на Сегер, който е от 2007 година. Не мога да го намеря за да си го купя а ми трябват още няколко. DLL-a е много подобен на jlink и вътре в него си има фърмуер с последна версия. Когато променя датата на билдване или версията в DLL-то, устройството си се ъпдейтва и работи с "новата" версия, но ако реша да пипна нещо по самият фърмуер (харесъл съм си една команда която връща 100 (в хекс) байта - сменям старт адреса само) ми сваля една версия надолу (явно си смята някакви суми и има бейкъп някъде из флаша) - посе го ъпдейтва до последната от DLLa. Като гледам този фърмуер който вадя от DLLа много се доближава до jllink - v5. Много ми се иска и бутлоудера да е същия ... нямам v6 jlink bin file, може и той да е подобен. Та всякакъв хелп ще ми е от полза - дори някой ако има jllink v5 и не го полза - ще го купя или заменя с по-нов, за да си направя експериментите - че ако взема да лепя елементи по развойния кит на олимекс - ще стане весело.