Новия Proteus вече предлага ARM7, не съм ги пробвал, но очаквам, че ще работи. За Eclipse и GCC съм казвал вече, много добра комбинация, на Eclipse му свикнах доста, ползвам го и за писане под Linux, като IDE предлага всичко, което ми трябва - autocomplete функцията например, нещо което доста сериозно съкращава времето за девелоп. Към няколкото проблема, които видях споменати по-горе, ще добавя и доста различния синтаксис на асемблера, почти няма прилика с този в IAR или KEIL...засега ползвам готови стартъп файлове, от време на време правя малки корекции, що годе се справям. Друг недостатък - в момента, в който реша да ползвам sprintf, 10K от флаша си заминават, в 32K процесор това е недопустимо. С IAR обаче няма такива проблеми, дебъга е добър, има почти всичко което се иска. Покрай него обаче имам други проблеми - чакам SAM7S32 цяла минута да се запише FLASH-а, S64-ката почти два пъти повече...проблема го заобиколих временно с HJTAG като RDI дебъгер и флашер.

що се смеете на един начинаещ за printf() - ако имате малко виждане върху GSM-ите(като не мисля, че са слаби платформи) - по-голяма част от дебугера е на базата на printf(), а JTAG-a го ползват само за дебъг на ниско ниво и програмиране....

Това е един от проблемите на конкретните компилатори - трябва да се привържеш към тях и за следващия проект не е ясно дали можеш да ползваш нещо. Навремето сравнявах ADS (на ARM компилатора, сега може да се казва по друг начин) и GCC. ADS беше доста по-напред в оптимизациите, но имаше такъв уникален синтаксис за асемблера, че директно не се класира. Винаги съм карал на GCC и извън не чак толкова перфектния код, нямам оплаквания.

Ако имаш нужда от малък ре-ентрантен (няма такава дума в езика ни) sprintf() който можеш да си конфигурираш кои формати да поддържа, оттам и размера на кода - обади се. Няма единствено floating point.

Естествено може и без jtag, може и без осцилоскоп, може и без аналайзер, може даже и без светодиод - може даже и без уред - лапаш една топлийка и "замерваш" с език...

Не искам да обиждам никого ама всичко това е аматьорска работа, за хора които не си ценят времето...
Специално JTAG пести (добре - може да пести...) много време. Не случайно цената на един читав емулатор е много дебела (хиляди).
В най-лошия случай човек може да си спретне един за 5лв. или да си купи от Олимекс за 50 (usb-ocd). Малко по-грозно е но може и да се копира... JLINK-а се прави с един SAM7.

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


Хищник, за sprintf/sscanf проблемът е никакъв
Стандартните имплементации наистина са кофти - не само заемат флаш ами са ужасно тромави и ядат много стек - тръгнах да дебъгвам sprintf и още в началото гледам заделят 1700 байта и веднага спрях дебъгера и директно й бих шута на библиотеката

Миро, да си пробвал да дебъгваш с JTAG под uClinux или CE например?

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

JTAG, както отбелязах, е нещо много добро. Не само заради debug-a, това е повече страничен ефект.

Само че, както и при автомобилите, проблемът обикновено е в задкормилното устройство.

Мислене трябва, мислене ... особено като няма JTAG или не помага по никакъв начин.

Линукс досега не съм пускал... но доколкото познавам всички юникс/линукс системи - те се базират на концепции от времето когато jtag не е същестувал. При тях jtag-а седи като кръпка лепната върху текстовия протокол на GDB. Та затова и се изпада до абсурдните ситуации в които GDB показва едно, а реално в таргета нещата са други...
Долу-горе същото е дереджето и с М$ (да не кажем и по-плачевно) - не че не може да си напишеш собствен дебъг драйвер, но това в общия случай е само теоретична възможност...

Въпреки всичко, точно в такива системи използването на jtag е най-често Защото повечето нов хардуер е на BGA и ти идва гол като пушка - имаш само един начин да оживиш системата и това е JTAG. Веднъж като подкараш някакъв буутстрап, може всякак да дебъгваш, но до тогава май нямаш алтернативи?
И дори след това в много случаи JTAG-а си остава незаменим - особено ако изпълняваш код от флаш...

Верно много хора с калпави емулатори предпочитат да заобиколят jtag-a, защото ако имаш >10МБ имидж трябва на всяко префлашване да си вземаш почивка. Но това съвсем не означава че проблемът е в jtag-a и че хардуерното дебъгване няма почва...

Тук си говорим само за елементарно дебъгване... Да не забравяме че повечето нови процесори си имат и TRACE - я се замисли кой губи почва?
Възможностите които получаваш тогава са просто несравними... И дума не може да става за алтернативи!
И не хардуера губи почва - ами ние тук губим почва, защото цените са 6 и 7 циферени и подобни инструменти още дълго време ще ги гледаме през крив макарон...

Намират ли се такива схеми ?
Аз това,което успях да "намеря" е USB-JTAG подобен като на olimex ( даже съм склонен да вярвам,че олимекса са копирали схемата ) с FT2232L,че дори и проект USB+RS232->JTAG. Въпроса с направата,подкарването и софтуера остава,но имайки предвид какви "индивиди" са в олимекс съм по-склонен да се мъча сам,отколкото да им давам пари.

Аз съм.


Какво точно общо има JTAG с концепции в OS???


Че откъде-накъде пък GDB го свързваш с Un*x ???


Ако идеята ти е че не ти харесва GDB - не си единствен. А за разликата м/у това което виждаш на PC и това което е реално в системата има два варианта:
1) не е четено откъдето трябва или както трябва
2) вече се е променило


Много uC си вървят с малък bootloader в ROM. При липса на такъв, JTAG (ако и него го има в чипа) е манна-небесна.

Всяка опреационна система от висок клас предвижда начини за дебъгване. Дали ще е някакъв монитор или терминал/порт или специален драйвер - няма значение. Въпросът е че каквито и инструменти изполваш след това, те трябва да са съобразени с това което вече е заложено и трудно могат да предложат много повече от предвиденото.
Конкретно за JTAG, или по-скоро ICE - имаш малко повече възможности от страна на хардуера - не само брекпоинти, но да следи изрази, използване на определени адреси или данни.
На практика се получават две коренно различни неща и проблемът не е хардуерна несъвместимост, а софтуерна недомислица и някои неща могат да се дебъгват само с JTAG други само през монитор/порт/драйвер или каквото там е направено.
На теория, би трябвало jtag-a да стане пълна медия и през него да си излиза цялата дебъг информация, включително и трейсовете. То хардуерно е предвидено - има DCC, ама аз не съм го виждал работещо на емулатор от нисък клас. Или пък както са решили идиотите от Segger - да се ползва за някаква тяхна измишльотина... Така ако използваш само JTAG, нямаш достъп до трейсове или до конзоли.
Ако тръгнеш да дебъгваш през монитор - виждаш трейсовете, ама нямаш jtag-възможностите...
Естествено, повечето хора ползват и двата начина - едни неща гледаш на едно място, други на друго.. А не трябва да е така!






"Люниксите" доколкото знам се разработват основно с помоща на GNU. Греша ли? Или ти след като М$ пуснаха фрее компилатор си минал на VisualStudio??? Би било интересно
Както и да е... едва ли бачкаш с комерсиален дебъгер - не че няма такива които да могат да използват дебъг информацията от GCC. Та ако не си с комерисиален и ако изобщо някога си дебъгвал тоя линукс дето си ползвал - то си ползвал нещо GDB-базирано (Insight примерно). То просто няма друго - или поне аз не съм чувал да има...
Та, така според мен (лаикът) не само че има връзка между линукс & GDB - те просто са дупе и гащи
А пък това което исках да кажа в предния пост е, че GDB и грам идея си няма за jtag... И вместо Мохамед да отиде при планината става обратното и jtag емулаторите експортират gdb интерфейс. От там идват и купищата проблеми - gdb изобщо не знае че може да прочете - забележи РЕАЛНИТЕ стойности на регистрите. Просто той като е правен не е имало начин да видиш стойността на регистрите освен чрез софтуер - т.е. като ги омажеш. Та затова и GDB си пази негови копия на регистрите - такива каквито той си мисли че са...

Едит: Друга слабост на GDB - вместо да изчете кода, който реално се дебъгва, GDB "предполага"... Така ако си забравил да програмираш таргета или нещо се е омазало се стига до абсурдната ситуация - GDB показва един сорс, а пък реално се изпълнява нещо друго. Подобна простотия не съм забеляз в нито един комерсиален дебъгер.

На ядрото си, на драйверите, на user-ските програми, или на embedded системите на бюрото ти?
Кои OS-ове тогава са "висок" клас и кои "нисък"?


Хвърляш ме в джаза, честно. OS-а си има други работи да върши, твоето дебъгване се прави от <u>обикновена</u> userland програма. Единственото задължение на OS-а е да осигури на тази твоя програма достъп до хардуера, било то през паралелен порт, сериен порт, USB, ISA/PCI платка (системна шина), TCP/IP и какво ли още не, както и достатъчно процесорно време и памет по възможност.


JTAG се занимава с други неща. Наличието на дебъг примитиви (в контекста на процесор) подкачени към TAP контролера и тяхната функционалност е екстра според чипа/производителя и не е задължителна.


Binutils, GCC, Make и други. GDB въобще не е необходимо.
GNU e огромен набор от програми с отворен код.


Това не го разбрах. Не ползвам M$ бози.


Почти не ползвам дебъгери, printf() ми е достатъчен за повечето случаи.
GCC слага съвсем стандартна DWARF дебъг информация в съвсем стандартен ELF, която е четима от всеки желаещ.
Не знам какви дебъгери ползват хората по света - всеки си има личната свобода.
А изводът ти ... ще оставя без коментар.

За оплакванията ти от GDB не мога да кажа нищо - не съм запознат. За случая на ARM7 можеш да гледаш регистри, памет и т.н. само когато си спрял процесора, ръчно или от предварително зададен breakpoint.

woody, woody... нашта работа ще стане като вица с мравките:
- колко?
- пет
- какво пет?
- какво колко?

Виждам че не си много наясно с "дебъгването" Не се засягай, аз също не съм кой знае какъв експерт, но ще се пробвам да ти обесня някои неща - може други по-навътре да ме допълнят/поправят...

Значи, първо висок клас - ясно е че не става дума за малки ртос-ки, а за истински операционни системи, които поддържат кърнел моде и юзер моде и най-вече в контекста за който говорим имат концеция за "дебъг".

Дебъгът е в две направления - първо нещо от сорта на т.н. "ром-монитор", при М$ е драйвер - няма значение, става дума за нещо което експортва някакъв интерфейс за remote debugger и позволява постъпково изпълнение, брейкпоинт и т.н. Естествено това е част от системата и не става дума за дебъгване само на едно приложенийце...
Ако работиш с някакъв ембедед линукс това което ти трябва се нарича "stub" за GDB remote и ще ти позволи да си дебъгваш като бял човек Специално за АРМ мисля заемаше само 4KB код и да ти се чуди човек що не го ползваш. Може би си си мислел че само с jtag може да дебъгваш

А другото направление е извеждането на софтуерните трейсове, демек това което ти ползваш с printf. Под М$ обикновено се ползва TRACE() макрос, за линукс съм виждал и макроси и директно разни функции имаше - KDebug() ли беше - не помня. Под Windows тия трейсове се виждат или ако си пуснал студиото или ако си пуснеш DbgView() на sysinternals. Ако си сложиш стъбчето за GBD пък може да си изкарваш трейсовете в gdb-конзолата.

Моят съвет като цяло е - пробвай да дебъгваш, не боли...
И няма нужда да се гордееш че не ползваш дебъгери - това е все едно да се гордееш че си мазохист

Драги miro_atc,

Дано от тая дискусия излезе нещо полезно накрая.

Аз все още не мога да разбера ти от какво се оплакваше - от host OS-a или от target OS-а. Ако е от host (както бях разбрал аз), там дебъгера ти е user програма и прави каквото иска и може. Ако говориш за target OS дебъгване, не виждам как може да имат унифициран интерфейс за дебъгване - всяка би трябвало да си решава кое и е удобно и възможно. Не всички процесори имат дори хардуерен компаратор с маски за адреси и данни. Дори не бих ги делил на ниски и високи класове.

В случая на дебъг на target OS и наличието in-circuit debug (през JTAG или специализиран порт) не ти трябва специална структура в OS-a, можеш да си видиш каквото искаш. Понякога спирането на процесора е задължително за да може да се вземат данни (регистри, памет), но това пък може да убие периферията в зависимост от това на какви клокове работят.

В Linux има KGDB stub за някои архитектури, който ти позволява дебъгване на ядрото. Не съм ползвал.


Не съм мазохист, но успявам да си върша работата с наличните средства и без много мрънкане.
От десетките архитектури които са ми минали съм имал щастието само за 3-4 да имам хардуерен дебъг. За всички съм си писал собствен bootstrap и за почти всички собствен runtime.
Доволен съм на компилатор и възможност за printf() (имам си и собствен) .... както имаше една стара история за перфокартите и бира.

Поздрави!

абре woody, човека ти говори за in-circuit debug... в случая не те вълнува дали имаш ОС или мигаш свето-диоди и естествено ще е мазохис оня дето ще дебъгва(хардуерно) Линукс, Виндолс и всякакви там ала-бала ОС
И как така се занимаваш с Ембедед системи като не са ти ясни хардуерните начини и принципи за дебъг на самия процесор или системата като 99% от ембедед системите са обвързани със ICD-JTAG...

//OFFTOPIC
Колеги, моля ви - пийте по една биричка и после продължете спора.
Няма лошо, но в неделя, следобед, трябва да е по - позитивно някак!
//Wise