Влизам в графата "ентусиасти", не "нуждаещи се" (за сега си имам нужното, макар и чуждо), та насочи ме - кое е това дето е читавото (явно нещо имаш на предвид) да му се замисля?

Обаждам се

Потвърждавам - мichev e човека!

Ако има зор с NET-a и аз ще ударя едно рамо .

E нямам предвид нищо конкретно като схема и/или софтуер... Трябва някой да седне да ги направи. Примерно едно прочесорче като SAM3U спокойно може да емулира както OpenOCD така и JLINK. Но може да е в пъти по-бързо и да има SWO trace...

Което както се сещаш е за хора с много време, а мен ме няма в тая графа точно сега Е, ако все пак ако ти попадне - сподели.

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

Иначе ако има хора дето си ценят времето и могат да си позволят нещо по-професионално с удоволствие ще им споделя готово решение

Понеже не съм дебъгвал с GDB ми е доста неясно последователността на действия. Всъщност дебъгвал съм, но от Qt средата, която мисля в крайна сметка изпраща команди към GDB, но от команден ред не съм се борил. Та имам такъв един въпрос: производители на програматори/дебъгери, които работят с GDB бол, обаче именно тук е загадката за мен, след като всички среди използват GDB ( а може и да не използват де, но аз съм останал с такова впечатление ), тогава защо има несъвместимост и дадена среда не поддържа програматор/хардуер на друг производител за същата серия професори ? Или да речем IAR си праска собствен интерфейс към програматор, Keil друг и т.н. ? Мисълта ми е, ако да речем си разработя собствено желязо за програматор/дебъгер, който да поддържа JTAG за MIPS/ARM/TI, на AVR интерфейса, на Microchip, BDM на Motorola, и с това желязо се комуникира през GDB, това ще означава ли, че ще се поддържа от различните системи автоматично ( тези които използват GDB ) ? Желязото спокойно мога да го направя с някой PIC32 с USB/Ethernet, така че да може и като отдалечен дебъгер да се използва, отделно имат достатъчно RAM/Flash да събера кода за всичките горни професори. Само питам, не съм тръгнал да го правя, ако ще го правя то има смисъл само ако се прави с търговски цели, иначе за спорта само, мерси, нямам време за такива неща

Значи в момента имам вече няколко MIPS C/C++ работещи компилатори, ако мога да ги внедря в MPLAB, ще ми е най-лесно да си осигуря поддръжка на C++ за PIC32, щото ще могат да използват готовите периферни библиотеки на Microchip, newlib примерно също я има, имам ICD1/ICD2/PICKit2/PICKit3/RealICE, т.е. абсолютно всичко. Може би ще ми е по-лесно да се поразровя да видя дали Microchip са публикували как се прави plugin за MPLAB-a.

Има един Plugin за Eclipse, който поддържа dsPIC30/33/PIC32 , качил съм го, работи, но кое желязо да използвам ? Като най-лесно решение е Macraigor Wiggler на паралелен порт.

А вие как се оправяте с тия паралелни портове - за тая цел още си къткам иначе болния Делл Д600, ама той ще отиде в гробището по някое време. Тогава от де паралелн порт?! Знам, че другите Латитуди подъжат пралелен порт през репликатора, но ... не съм виждал Пък и само те ли да останаха с тоя интерфейс? А иначе по евтино и универсално решение от Macraigor Wiggler няма. Само пустия паралелн порт да не беше изчезнал...

Паралелен порт имам и на 3-те настолни машини в къщи, на лаптопите нямам, нямам дори и репликатор, понеже не съм фен да използвам лаптоп за разработка

[quote="¶"Та имам такъв един въпрос: производители на програматори/дебъгери, които работят с GDB бол, обаче именно тук е загадката за мен, след като всички среди използват GDB ( а може и да не използват де, но аз съм останал с такова впечатление ),[/quote]

С грешно впечатление си останал... Има много фирми, които предлагат собствен компилатор, собствено IDE и собствен дебъгер. Примено IAR, GreenHills, това дето го купиха АРМ (забравих им името).
Има и такива като Rowley (CrossStudio) или CodeRed дето ползват GCC като компилатор и/или GDB като дебъгер. Има и трети дето правят само дебъгер, или само емулатор. Изобщо всякакви ги има...



Ами няма задължителен стандарт за комуникация между дебъгер и емулатор. Кой каквото си направи. Segger са си направили JLINK, разбрали са се с IAR и продават "готово решение". Включваш и бачка.... Но ако искаш да ползваш JLink с друга среда вече имаш проблем. Примерно за да го ползваш с GDB ти трябва освен хардуера да си купиш от Segger и JServer, който навремето струваше към 600$, отделно и JFlash, който също струваше майка си и баща си.. Верно сега вече върви "безплатно" към jserver, щото баламите да плащат по 1000$ за софтуер намаляха.
Отделно, че софтуера го има и нелегално...
Както и да е - много причини има, включително и умишлена политика на фирми...




Значи ако имплементираш GDB Remote Protocol (оня текстовия дето си гледал) e ясно че няма да имаш ядове с GDB. Сега за комерсиалните дебъгери е трудно да се каже. Имай предвид, че те за всяко работно място, за всеки таргет гледат да те одерат за отделен лиценз. Дори и таргетите да са от един тип, пак трябва да плащаш. И в общия случай IAR за арм е един софтуер, IAR за 8051 друг и т.н.
И отделно за всеки тип имаш различни версии, така че много трудно е да направиш нещо и да кажеш, че то се поддържа от IAR или друга фирма.
Докато с GDB го няма тоя проблем - дебъгерът е един, няма значение колко или какви ядра...

Мда, сега ми стана ясно каква е какафонията Може би има смисъл от една такава собствена разработка, що пикаджии ще се налапат

Между другото, днес си комуникирам цял ден с Microchip, за да получа тяхната спецификация Microchip Language Toolsuite, която всъщност е документа, в който се описва как да си направиш plugin за MPLAB. Още го нямам документа де, питат за глупости, ще мисля събота и неделя с какво да ги залъжа

Желязото е най-малкия проблем, в пъти по трудното е "мекото" дето ще върти желязото - демек софта. Класическия (и май единствен) вариант за дебъгване на ембеддед цпу-та с gdb/insight/ddd/eclipse e gdbserver към който да се свърже gdb-то. От своя страна "сървъра" по JTAG/SWD/BDM командори ЦПУто. Сървъра може да е вграден в желязото - това са по скъпите емулатори от над 1000евро или да е на ПЦто и да говори с желязото по УСБ/паралелен - това са всичките вигглер и ж-линк подобни.

На този принцип работи OpenOCD, така че на който му се иска да си направи нещо къстъм най-добре да почне от него, те вече са портнали няколко ЦПУ фамилии. Та ако искаш да си добавиш нов ЦПУ съпорт - правиш го и автоматично може да използваш вече всичките железа които ОЦДто поддържа... ако искаш пък правиш си само драйвер за твоето желязо и така вече с твоето можеш да дебъгваш всички поддържани ЦПУта...

До колкото си спомням МИПС съпорта на ОЦДто е правен точно за ПИК32 та даже и флаша му може да програмира...

tito като каза ПИК пуснах едно търсене и първите 5 резултата направо ме изумиха


Иначе желязото е най-малкия и най-големия проблем... Най-малкия щото се прави лесно, а най-големия щото никой не го е направил като хората. Желязото на OpenOCD е направо отврат. Един тъп FTDI, който не само че не е подходящ, ами направо са осрали пейзажа с техните фирмени библиотеки дето не можели да се ползват. За да го подкараш трябва да конфигурираш, да компилираш сорсове, да инсталираш, ебахти мизерията...


Трябва да се направи нещо много просто - да се сложи един читав хардуер, примерно нещо с hi speed USB и да се пипне софта на ОЦД-то така че да стане едно читаво съвърче. Аз съм сигурен че все някой ще го направи...

От програмирането на флаша до читаво дебъгване има доста хляб да изядат. Един от програмистите на OpenOCD беше писал
във форум на Microchip, че използвал OpenOCD и RealICE за програмиране, което е невъзможната комбинация За какъв
ми е да инсталирам OpenOCD като RealICE си е пушка под MPLAB. Все още чакам с нетърпение да видя крайния вариант
на MPLAB X с NetBeans, надявам се там да са оставили някаква документация как се правят плъгини.

Според моето скромно мнение, вместо да се опитват да използват FTDI подобен хардуер, специално за PIC32 е много по-лесно
да се използва PICKit2, понеже сорса е отворен, желязото се държи много добре, трябва да се прегледа кода от
страната на ПК, и да се вкара в OpenOCD сървъра.

miro, какво те втрещило от търсенето не разбрах, PIC32 не поддържа BDM, а ти си търсил за PIC32 + BDM.



Microchip средите в момента изглеждат като неразораната целина, няма външна среда от типа на Eclipse, която да поддържа
цялата им гама, а процесорите им се развиват, ноември 2010 Microchip са лицензирали най-новото MIPS ядро M14K, очаква
се през тази година да пуснат на пазара първите процесори с новото ядро. Така че, който пръв пусне читаво решение,
дори да е с нов тип хардуер за дебъгера ще напечели мисля доста добре