Здравейте.
До сега съм се занимавал само с PIC-ове и реших да премина към LPC. Те се програмират и дебъгват през JTAG и тук нещата не са ми много ясни. За дебъгваща и програмираща среда ще ползвам Eclipse, тъй като е безплатен. Проблема е хардуерната връзка. Нямам паралелен порт и вероятно ще трябва да използвам FT245. Мога ли да дебъгвам микроконтролера, ако е закачен директно към FT245? Каква ще бъде горе-долу скоростта на лоудване на програмата? Какво е по-специалното при заводските дебъгери? Май някой JTAG команди се изпълняват по-бързо... има ли значителна разлика в скоростта на запис? Ако не е удачен вариант само използването на FT245, можете ли да ми покажете някоя добра схема.

Благодаря.

1. ARM7 няма да се развива повече, защото се заменя с Cortex M3. Вторият е за препоръчване ако тепърва започваш.

2. Еклипс е само среда. Към него трябва да интегрираш компилатор+линкер+дебъгер. Този комплект се нарича тулчейн. Предполагам ще използваш някакъв GNU тулчейн. Аз ти препоръчвам ягарто (www.yagarto.de). Има една тема за "изпитан тулчен" в тоя форум, може да я прочетеш...

3. Към дебъгера ти трябва и някакво "желязо" за джейтага, което се нарича "Jtag емулатор". Има много "заводски" и незаводски... Ако търсиш решение с FTDI чип виж OpenOCD - има схеми в нета, всичко е опън сорс. Към о-це-де-то върви и софтуер който трябва да свалиш/компилираш/инсталираш/конфигурираш...
След това ако ще ползваш Еклипс като потребителски интерфейс може да му инсталираш и един плъгин (zylin) за връзка с дебъгера и с емулатора. Оригиналният плъгин на Еклипса не е много добър.

4. Скоростта на download не я мисли. Ограничава се първо от USB-то (няма как да е по-висока) и второ от jtag клока, който пък няма как да е по-висок от клока с който работи проца ти в момента. А като пишеш по флаша се ограничава от скоростта на писане и т.н. Но в общия случай се постига 30-40kB/s т.е. в най-лошия случай за няколко секунди ще "лоадваш"...

ОЦД-то има проблем със скоростта на трейсване.. При ARM7 има DCC канал, а при Куртекс ако искаш трейс по-добре си предвиди двоен FTDI чип за да хванеш SWO-трейса, пък ще дебъгваш по SWD (вместо jtag).

5. За повече информация виж тук

Благодаря за отговорите.
"Emulation trace module supports real-time trace."
Това е от документацията на процесора. Не означава ли, че не ми е необходим допълнителен хардуерен емулатор?

"трейс" е общо понятие... означава проследяване и има много неща за проследяване.

Най-просто (това което имах предвид) в възможността в софтуера да си оставяш "следички" от типа:


При АРМ7 за това може да се ползва DCC (debug communication chanel) и не изисква нищо повече от JTAG. При Cortex се ползва SWO пин и изисква хардуер (поне UART). Разбира се ти винаги може да ползваш UART, USB или нещо друго за трейсване, но наличието на "безплатен" и стандартен начин е голямо улеснение.

Друг, много по-сложен трейс е възможността процесора да трейсва какви инструкции изпълнява, от какви адреси и т.н. Тоя тип трейсове обикновено се записват и ако успееш да запишеш всичко след това може да се възпроизведе всичко каквото е правил процесора. Но дори и да не е всичко пак е полезно, щото може да направиш статистика каква част от кода се изпълнява най-често и т.н.
За тоя тип трейсове при АРМ7 ти трябва да имаш изведен ЕТМ порт, което е голяма рядкост. Трябва и специализиран (скъп) хардуер и софтуер.
При кортексите трейса може да се изкарва през SWО-то, т.е. на теория може да ползваш и решението с двоен FTDI чип. На практика обаче ще хванеш много малко данни. Изобщо за тоя тип трейсове си трябва специализиран хардуер (трейс емулатор).

"За тоя тип трейсове при АРМ7 ти трябва да имаш изведен ЕТМ порт, което е голяма рядкост. Трябва и специализиран (скъп) хардуер и софтуер. "
На мен ми е нужно да мога да наблюдавам променливите и да мога да изпълнявам на места програмата стъпка по стъпка.
"Emulation trace module supports real-time trace."
Както се има предвид emulation

нямаш грижи...

ETM - Embedded Trace Macrocell, това е различно от EmbeddedICE към който се закача JTAG. (Сега виждам че в документацията на по-новите LPC2000 е въведен и термина "embedded trace module" и "emulation trace module".)
Миро ти е посочил един от вариантите - YAGARTO + OpenOCD. Ще трябва и доста четене от твоя страна.
Като удариш на камък питай тук

Миро ти го е казал - не се занимавай с ARM7 ако не ти го налага нещо отвън - задание, шеф и т.н. Ако можеш да избираш вземи ядро с Кортекс М3 - по нови са, по евтини, по-по-.... и т.н. АРМ7 е пътник, т.е. на доизживяване.

Убдеихте ме ще ползвам кортекс.
Но поне в началото смятам да ползвам Keil uVision.
http://elk.informatik.fh-augsburg.de/hh ... bjtag.html
Тези FTDI чипове могат ли да се подкарат с опция "Cortex-M/R J-LINK/J-TRACE" или няма да се получат нещата?

Странна логика... Все едно от София да тръгнеш към Видин, но в "началото" да минеш през Бургас.
Отдели малко повече време за проучване и реши накъде точно искаш да тръгнеш...


С FTDI се прави OpenOCD, това е различно от JLink, камо ли от JTRACE

Ако искаш JLink има клонинги, даже май беше изтекла и схемата и фърмуера тъй че ако много държиш може да си го направиш сам. За Jtrace не съм чувал да има схеми, но мисля че братята китайци продават клонинги. Но аз не ползвам продуктите на segger и не съм в час с последните слухове

harleybg, вземи си нещо подобно на това:
http://www.st.com/internet/evalboard/product/250863.jsp
http://www.emcu.it/STM32Discovery/STM32 ... overy.html
Сега има толкова достъпни развойни платки. Ще загубиш време в лепене на FTDI JTAG сонди.

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

Основно се ползва GCC+Eclipsе или IAR.

Като дебъгер OpenOCD+FTDI (най-евтиния и достъпен вариант) или J-link. Това е което ние ползваме и можем да окажем подкрепа. За другото си сам.

Имам разработка на орязан (липсва само допълнителния сериен порт) "flyswatter" - OpenOCD+FTDI, проектирана платка за изпълнение в домашни условия (2 странна).
Ако някой проявява интерес - да пише.

Сега погледнах какво използвам , нарича се Ride7 + GCC 4.3.xxx + RLink. Средата e шарения като Eclipse, като за без пари е добре. Не съм видял да има поддръжка на Version Control ( използвам SVN в MPLAB и ме дразни липсата ). Не може да генерира или да използва makefile, само с неговия си формат. Поддържа всички STM32/STM7/STM9 + LPC17/21/24xxx. Не поддържа друго желязо освен RLink. Гледам, че в OpenOCD е вкарана поддръжка на RLink, тия дни ще го видя работи ли. RLink е ограничен до 32kB Debug, отключването струва 70 евро. Горе-долу стабилна среда, средно гърми веднъж на ден...

Като цяло дебъгването/програмирането е мнооого бавно, то първо се свързва с GDB, после изскача нещо с надпис Jungo-Мунго драйвер, после докато изтрие паметта, докато програмира и брада се хваща. Към 50 секунди трае процедурата от натискането на Debug до реалното стартиране на програмата ( размера на програмата в Flash е около 150kB ). Не знам дали и при останалите ARM среди и дебъгери е така ( просто това ми направи впечатление, щото примерно при MPLAB с RealICE & PICKit2/3 при сходен размер на програмата всичко става за няколко секунди ). А може би е доста бавно щото в вързано по SWD. Веднъж обаче като захапе дебъгването е с прилична скорост, да речем нещо като PICKit2.

Това вече е интересно. Нека споделят хората