Е те за този етап от разработката ме интересува всичко това. Ако всичко (или повечето) не се тества и дебъгне на този етап, на следващия или ще е много трудно или невъзможно...

По темата - със сигурност е полезно да има такъв инструмент. Но приложимостта (колко ще съм навит да платя, казано директно), е много силно свързана със приложения софтуер.
Мисля си нещо - каква честота гониш да се анализира? Питам понеже има доста евтин начин да вкараш 24Мбайта/с, което за еднобитов стрийм лесно (шифт регистър/CPLD?) може да стане 192Мбит/с. Имам предвид cypress-кия чип дето е в клонингите на usbee/saleae. Може и някой FTDI, защо пък не. Те май MPSE-е то им (ако така се пишеше) стигаше 30МHz, може то да ги прави анализите?
Оттам насетне анализа може да е софтуерно в PC-то, което значи възможност за безкраен запис. Мисля че натоварването на ПЦ-то няма да е проблем, пък и винаги може да се смени ПЦ-то. Остава екстрата да си работи като логически анализатор, което пак е бонус за клиента.
Има вариант и за usb3.0 но цената ще е тежка.
Като цяло генерално това е един от начините да се намали цената на инструмент - да се прехвърли задачата на PC-то.

Няма софтуер, то това е една от причините да съм учуден защо няма подобни продукти. Ако имаше софтуер е ясно... подръжка ала-бала, много по-сложно е.



По принцип няма таван... или по-точно колкото и да е ще има ситуации в които е малко

При малките куртексчета с SWO без TARCE клок, сигналът може да е с максимална честота на CPU клока, което в масовия случай е 100-120MHz, но има и куртексчета дето са над 200MHz. При тия скорости обаче проблемът е доколко е як драйвера на пина, щото повечето нямат запас и физически изобщо не излиза читав сигнал от чипа. Да не говорим как след това е опроводен по платка и след това кабел... В интерес на истината има и такива дето изкарват и до към 200MHz, примерно STM32F1 (въпреки че тоя фамилия изобщо не е за такива честоти). При всички случаи над 150-160MHz сигналът е много капризен. Да не забравяме, че това е сигнал без клок към него!
Така че за мен това е тавана, което като данни е 1/2 т.е. пиково до към 80Mbit/s или 10MB/s.
Другия вариант е с TRACE port, при малките обикновено е до 4 бита + клок, което обаче като данни може да е много. Не съм гледал новите М7-ци с какви портове са, но няма да се учудя ако изкарват 1200Mbit/s (4*300МHz). A пък вече големите куртексчета там нещата съвсем загрубяват...

Това с шифт регистри и други подобни измишльотини според мен няма смисъл... Нито свалят цената, нито дават кой знае какви предимства. Ако се гони цена, то най-простият вариант се определя от fpga-то щото без фпга няма как да стане номера. Но евтините фпга-та както писах са доста ограничени откъм клоци и крайния резултат е че с такова решение трудно ще се семплират над 50-60MHz, демек под 30Mbit/s което мога ти го вкарам и в проц за под 5$ с вградено high speed USB. Така че с проц излиза хем по-евтино, хем по-гъвкаво.
А пък вече нагоре, като сложиш хубаво фпга съвсем не върви да го спъваш с кофти интерфейси...
Ако има дилема тя е къде да спре, щото истината е в zynq-a... само че се почва от 100$ а и отива в една друга категория...

Идеята е максимално бързо да се "маркира" преминаването през контролна точка, както и да може да се логва преминаването през много контролни точки за единица време БЕЗ да забавяме хода на програмата с изчакания за предаване на маркер след като е завършило предишното такова. Та колкото по-висока е честотата - толкова по-добре.
В конкретния проц максималния възможен клок е 48MHz. В следващия дето някога ще боря може да е и доста повече... Кой знае ...
Но да кажем все пак - честота поне 25MHz за манчестер клока.
По-тънкия момент е с автоматичното определяне на баудрейта БЕЗ пропускане на байт.
Мисля, че е допустимо да се зададат няколко възможни баудрейта (2 до 4), които ще са възможни в системата в различните low-power режими в зависимост от моментния клок на проца, като манчестер декодера ще трябва да разпознае кой от тях е използвания във всеки един момент. Това мисля, че опростява задачата.

Не знам как ги мислиш тия работи

Вземи лист хартия и молив и се пробвай да начертаеш как изглежда сигнала, като имаш предвид че
1) клока на таргета може да е всякакъв
2) клока може да е нестабилен поради спред спектрума на pll-а или просто да си е калпав. Отделно при честоти над 30MHz и фронтовете става значима част от периода и не е ясно къде точно е окото на прозореца...
Демек, ако трябва да го начертаеш като хората имаш "око" - това е част от периода на сигнала в която той е валиден и друга част от периода в която може да го виждаш и като "1" и като "0" и като нещо по средата, но дали това което виждаш е истина няма кой да ти каже
Помисли и над въпроса, че след като си го начертал това нещо като сигнал, ти няма как да го видиш целия, а само определени точки съвпадащи с клока на фпга-то. Демек не всичко, което ще виждаш е истина. Отделно клока на фпга-то по никакъв начин не е синхронизиран с клока на таргета, т.е. на сигнала ти. Така че каквото и да правиш ВИНАГИ ще имаш биене между двата клока. А това означава, че след като си семплирал първия бит, следващия няма как да го семплираш на същата позиция спрямо окото. Семплираш с някаква грешка, колкото ти е биенето... При следващия бит грешката се натрупва, при следващия пак се натрупва и натрупва и само след няколко бита си в киреча

Идеята на манчестера е да НЕ семплираш по клок и да НЕ трупаш грешки. Най-много до два бита, но това е нищо защото без манчестер нямаш никакъв шанс
Задължително се прави стейт машинка и с нея преценяваш дали това дето виждаш има шанс да е манчестер или не. Ако е манчестер то ще е поредици от Х или 2*Х твои клока и трябва да допускаш +/- 1 твои клок (и повече ако разликата е голяма). И ако направиш това ще видиш, че няма никакво значение КОЛКО точно е твоя клок или другия клок, стига твоя да е поне 3 пъти по-висок

TRACE порта си е друго нещо.
Защо да не може да стане без FPGA? Представи си 20Мбайта в секунда стрийм, който идва на ПЦ софтуера и той прави манчестър или NRZ или каквото искаш декодиране, не виждам какъв да е проблема, стига честотата на стрийма да е достатъчно по-голяма от сигнала.
С директен достъп и с ползването на хардуера на Logic-клонингите имаш 24Мсемпъла/с, т.е. става за по-бавни битрейтове на SWO-то, но говорим за готов и разпространен хардуер за 8 долара, който и без това работи като анализатор. Към това допълнително ти остават още 7 (или дори 15) бита за тестови сигнали - защото през SWO-то няма да можеш да маркираш точни с 10-20нс резолюция, а така ще имаш 1 трейс + 7/15 логически маркера.
Има си и Open source софтуери, има и SDK за логик-а дето може да се добави обработката.
То и сегашния им софтуер има манчестър декодер, но вие искате такъв със смяна (детектване) на бод рейта, а и по-бързо. Ако сте виждали как излизат там дешифрираните сигнали от бъсове (uart, i2c, spi,...) изглежда подходящо:



Всъщност това би било доста яко - ако нещо примерно върти регулатор на 1мс, ще е интересно да може да се отпечатат примерно 20-30 байта който да дават стойностите на няколко 32 битови променливи.

Идеята ми беше че има лесен начин да се обърне последователния стрийм към 8-битов паралелен за да влезе 8х по-бърз сигнал. Със 192Мбит/с би трябвало да се постигнат желаните 48МХз на манчестера. Някой трябва да клоква един шифт регистър на 192МХз и да вади клок веднъж на 8.

Това си е направо 100Mbps Ethernet само трябва да се направи пакет с преамбъл, мак адреси и CRC накрая. Трябва да се прекарат данните през 4B5B енкодер и накрая MLT-3 физически енкодер и това го ръгаш направо в суича, дето в вързан дебъг компютъра.

Не съм схванал идеята ти, но тя е още по-откачена отколкото си мислех
Не знам, може би трябва да опиша подробно що е то трейс и как се ползва, може би клипче ще е по-нагледно. Обикновено това е текстова конзола и целта е текста да е сведен до минимум, за да може да се наблюдава в реално време. Само в редки случаи се пуска як трейс, примерно като се дебъгва tcp/ip стек и ако се трейсват всички пакети няма как да ги гледаш в реално време. Но без значение колко се трейсва е желателно да се работи на много висок клок, за да не бави проца.
Аз по-горе казах, че минимално семплирането трябва да е поне три пъти манчестер клока. Но това е минимум, т.е. ще работи ако платката е рутирана добре, кабелите не са дълги и т.н. Ако нещо не е перфектно и се работи на високи честоти, то може да се наложе много по-голямо съотношение. Примерно ако окото падне на 10% (съвсем нормално за високи честоти) то ти трябва поне 10 пъти по-висок клок, иначе просто ще изпускаш битове. Но дори и "само" 4-5 пъти по-висок клок ще ти дава минимум 8-10 пъти повече трафик. Казвам минимум, защото с твоето решение не знаеш кога има данни и кога не и ще пращаш постоянно. А както казах в началото обикновено трафика като текст трябва да може да се чете в реално време, демек ти ще натовариш 480 мбит-вата шина на usb до дупка а полезните данни ще са смешни...
Не знам каква е идеята, да спестиш 2$? за сметка на 10 пъти по-кофти продукт? А той ще е поне 10 пъти по-кофти, повярвай ми... То ако е въпроса за евтино и просто имаше решение с D-версията на FTDi, единия канал се ползва за дебъг, другия за трейс и май стигаше до 1 мбит.

хммм... странни неща се получават.

първо потърсих ибис модел на F4 - йок
намерих за F2. SWO пина го дават PB3.
за този пин има 4 драйверни модела. първия не можах да го разклатя, за другите 3 не виждам разликата.
озадачаващо е, че и трите са за 3.3V, което ми се вижда множко за големи честоти.
както и да е.

вързах го с подходяща серийна терминация и жица 15см на стандартен 50 ома стекъп към IOB на XCS05XL.

ето картинките

100MHz прост клок.
изглежда що-годе нормално. червеното е драйвера, зеленото е приемника.
вероятно може да се подобри малко

око

нямам патерн за манчестер, избрах нещо приблизително.
пак 100MHz, 100 цикъла по 8 бита с гаусов джитер 5% (от UI). нямам идея колко би бил джитера на вътрешния клок. може и в ns да ми го кажете.
врмевия запас е по 10% от двете страни, което може би е малко.

ако искате други стойности за симулация - давайте

Да де, текстова конзола ще излиза както надписите от протоколните анализатори горе на картинката, виж там на канал 9 "SCIO" как пише "Address:....", това може да е твоят текст.
Разбира се, текст не ми звучи никак ефективно, не помня кои, май Atollic има някакво решение, или Segger, което заместваше "label"-те в кода с числови идентификатори, които се търкаляха по дебъг-а, и после от другата страна дебъгера ги замества с текстовете от ELF-а или както там е направено.
Съгласи се, едно е да пратиш "Packet received, crc=0x2234", друго е да "AA23 2234". Въпрос на инструментариум.
Имам предвид че raw текст може да е ок по сериен порт и да го гледаш с терминал по избор, и да жертваш ефективността заради по-малко инструменти. Или да не ти пука че ще напълниш 2 мбайта лог за 10 секунди понеже имаш 128Мб РАМ. Но това е далеко то ембеддед. То ако чистите текстове са във флаша на процесорчете няма да остане място за истински код - трябва си текстови таблици и секции в елф-а. Да не говорим за типичния overhead на string функциите.

Явно не съм схванал идеята - мислех си, че това е трейс на всички инструкции които се изпълняват в реално време, писане в паметта и т.н. така, че да мога после да анализирам кой е омазал нещата. За още един сериен изход не бих дал повече отколкото струва един FTDI USB <-> RS232, това което Гичо казва, че може да се праща само 4 байта с адреса съм го правил на живо, дори лога се записва във флаш и се праща по гпрс до центарлния сървър, така че после мога да анализирам какво се е омазало от другия край на света. Т.е. скороста въобще не ми е била фактор в този случай ...

Дедо, доста реално изглежда симулацийката ти... не знам какво станно намираш. Аз повече съм си играл с jtag (там аз определям клока) и с истинско джелязо съм се опитвал да завържа приказка с чепа. Казах вече, че рекорда ми е около 200MHz с F1. Естествено говоря си само с TAP контролера, успявам да чета ID-то, bypass тестове и т.н.
С F2 не можах да докарам 200MHz, но то може да е било и от платка и от рутиране... То проблемът с тия истории е, че няма стандарт изобщо и на нищо не може да разчиташ. Нито знаеш драйвера, нито как трябва да е опроводено, нито как да е терминирано, нищо... Някой просто ти е изкарал някакъв конектор и закачил някакъв кабел и очаква да постигаш високи честоти. Помня едно оплакване от клиент на PEEDI, бяха си направили тестова установка на която се закачат не знам по колко изделия, то нали JTAG-а е верига и може да ги навързваш. Та тая цялата работа беше с размери метър на метър, отделно кабела към пидито не знам колко метра беше и не работело...
Относно клока на F2 - не става, има джитер и без да е включен spread-а. Аз го ядох с етернета, бях го направил аз да генерирам 50MHz за ref_clk от 25МHz кристал. Не става, после прочетох че и те си признават че не може от проца да се изкара 50MHz читав клок по никакъв начин. Но за трейса това може и да не е проблем, там регулярно се калибрира честотата и ако не се мандахерца твърде бързо нагоре-надолу няма да е проблем.



Съгласен съм, но SWO-то си има "пакетизатор", който разделя различните съобщения в различни по тип пакети. Така че имаш до 32 канала за трейс, отделно може да изкарваш семпли на РС counter, отделно watchpoints, отделно cyclecounter. Изобщо може да изкарваш много неща и самите неща да изкарваш по един или друг начин.
Практиката е трейс каналите да се стрипват до текст. А дали ти ще пращаш ASCII текст вече е твоя работа, но текста е по-удобен с оглед на това че не ти трябва никакъв специализиран софтуер. Обикновено самия емулатор разпакетирва и може да изкарва само чистия текст на някакъв сокет/порт, а ти от другата страна се закачаш с някаква телнет конзола или терминалче и зяпаш.
За другите типове данни вече трябва софтуер, защото за да се онаглядят като хората вече трябва да имаш и връзка със сорсове и т.н. Това беше голям проблем със софтуера, но както писах в началото на тая тема вече гледам че има решения. Примерно не е много сложно РС семплите да се експортират в един gprof.out файл и от там в gprof да се правят статистики и анализи, даже има и визуални плъгини за еклипс. Така че на тема статистики вече има няколко решения.
Остана единствено тайм дебъга или reverse debug, това засега май го има само в най-скъпите интрументи като GreenHills и Lautherbah. Но не знам доколко ще работи с обикновено SWO, защото за да има смисъл трябва да се запъше пълна история на изпълнените инструкции и променените данни. После тия данни се зареждат в дебъгер и може да дебъгваш напред-назад, в която посока искаш. Страшно полезно нещо е. Примерно ако някъде мажеш по паметта, самото мазане е много трудно да го хванеш, обикновено гърми много по-късно. Примерно мазал си по стека на спяща нишка, тя се събужда, бачка известно време и като почне да си празни стека гърми. Тогава вече се хваща, но като не знаеш кой ти е омазал стека файда няма. Та ако имаш ревърс, просто слагаш watchpoint и пускаш времето да тече в обратна посока и директно ще ти спре на мазалото...

SWO работи с клок кратен на CPU клока, като в най-добрия случай е равен и изкарваш 1 бит за един клок. Тоя режим почти не се използва, защото без пакетиране е трудно да се ориентираш, а пакетирането вкарва овърхед. Отделно за да семплираш сигнала ти трябва оригиналния клок, а ти обикновено го нямаш, затова се ползва манчестер, което намаля двойно полезните данни. С една дума през SWO излизат под половин бит на клок. Как ще кодираш "всички инструкции" в реално време? Не става!
Сега има трейс портове с 4/8/16 т.н. пина и с реф. клок и някои имат DDR, но пак не може да се изкара всичко на 100%. А то не и нужно, ITM-a на АРМ e достатъчно умен и вместо да изкарваш всички инструкции може да изкарваш само при преход, да знаеш накъде се е разклонила програмата. Изкарват се и данни от определени памети, които те интересуват.



Мда, сериен... само че едно е сериен 115200 друго е сериен на 50 или 100Mbit. Едно е сериен на който да трябва да му баеш на баудрейта постоянно, друго е сериен който работи независимо от клоците на проца ти. Просто трябва да поработиш малко и с едното и с другото и ще разбереш разликата

Това не решава проблема със смяната на процесорния клок - от там и клока на серийния swo изход в uart режим.
Допълнително искам (с много лек компромис) да имам и инфо на лог. анализатор за момента на преминаване през "контролната" точка спрямо активността на другите интерфйси и пинове. Целта е да се направи нещо повече от клатване на пин при преминаване през контролна точка. А да не забравяме, че обикновено нямям свободни пинове... Така следейки началото на предавания байт(байтове) на swo-то ще имам инфо и за времевия момент и за номета на тестпойнта.
И не на последно место - всичко това с минимално забавяне на програмата...

Освен тест пойнт номера може допълнително да се изведат и даннови байтове- например стойност на променлива(и). Разбира се не трябва да се прекалявя с това.

П.п. Миро ме е изпреварил.

Миро, преди да се заровя в документациите можеш ли с няколко думи да обясниш функционалността на swo канала и възможностите му? До колкото схванах всичко това е "сдандартизирано" в някаква степен...

Ами аз по-горе обяснявах, че може да изкарваш различни неща, може да изкарваш директно или да се пакетерат преди това. Може uart, може манчестер...

Да, всичко е стандартно, но някои неща са опционални и може съответния производител да не ги е имплементирал, макар че май не съм среща такива скръндзи.

Относно формати и кое как да се изкарва, най-добрият вариант SWO-то да е комбинирано с SWD интерфейса. То така или иначе конектора обикновено е един, но мисълта ми е, че настройките на SWO е по-добре да си се правят от дебъг интерфейса, а не от твоя софтуер в таргета. За трейса примерно ти само проверяваш дали е разрешен трейс модула и ако да - трейсваш. Не се интересуваш какъв формат и т.н. А вече съответния jtag/swd емулатор като се закачи има грижата да си разреши и настрои каквото му трябва и в какъвто режим му трябва.