Ами ограничен е, ама аз никога не го надминавам (в работата от Фрискейл ползвам само HC08 и S08 контролери) . А иначе платена версия може да се вземи и за под 1000$. Не вярвам 1000$ да ви е проблем .

Ми не е много наистина. Аз мислех че е повече.

В интерес на истината, просто фрискалите не ми лежат на душата. Както краварите и атмелите. Просто докато мога да се глезя с каквото ми е приятно, ще го правя. Утре ако каже боса минаваш на фрискал и кодвариор.... ми слушам и изпълнявам, за това ми плаща

Като те гледам как се глезиш - голяма веселба настава .

Абе мазохизма го има, определено В случая както казах се опитах да стана по католик от папата. Имам си работеща среда, ама реших да сглобя по-нова. Да ме пита човек - нервите ли са ми в излишък, времето ли.....

Даже новия Code warrior за Kinetis Cortex M4 контролерите е на базата на Eclipse та няма да ти е кой знае колко по-различно .

На човек главата му чупи, хатъра му не дей!

Абе нямате ли усещане че новите сглобки работят по бавно? На мен така ми се струва. Незнам на Helios-a ли се дължи на gcc-то ли....

Ползвам си външен make файл и съм по склонен да обвиня gcc-то....

Еклипса няма нищо общо... От GCC 4.х(нещо си) се забави компилирането осезаемо, особено при мен щото ползвам по-стара и бавна машина...
Аз даже си направих специално за случая скрипт, който засича времето за компилация и винаги сравнявам преди и след ъпдейт на тулчейна. Но забавянето е само след една определена версия, след това всички по-нови са еднакво бавни

Е явно съм баш на "определената" версия та го усещам. Много ме дразни. Почвам да се чудя, дали да не върна стария 4.2 нещо си. И без това като гледам историята, нещо дето да ме касае не виждам.

Правилно си се ориентирал! Пускай си старата! Наистина по-новите имат трески за дялане!

Някой знае ли от къде да се дръпне Insight инсталационен за Win ?

Една фирма го поддържаше ама забравих я коя беше


Иначе ситуацията е следната - от доста време не пускал release и си бачках само с дебъг версии и всичко си е ОК. Сега компилирам релийз с максимални оптимизации, кодът е ОК, бачка ама не може да се дебъгва изобщо... При всякакъв опит за спиране, примерно брейкпоинт таргета спира, а GDB-то влиза в безкрайно четене на паметта. Вероятно не може да си undwind-не стека... А на Eclipse плъгина не може да се изключи ънвиндването та затова търся Insight или друг дебъгер...

Лошото е, че не знам как го постигнах това омазване... нещо GCC опциите ли или при ъпдейти на туловете или друго. То по принцип рядко ми се налага да дебъгвам релийз версия, ама ей на...

Малко ъпдейт за "изпитания" тулчейн....


Преинсталирах всичко и за пръв път всичко работи с последни версии под бозата. Изключая 64-бит версията на Еклипс. То по принцип май ще се окаже, че всичкия 64-бит софтурер на бозата е дърво. Досега нищо не ми е тръгнало като хората, но с Еклипс загубих повече от ден за глупости. Първо искаше 64-бит джаба, а тя май не е много официална. Както и да е с джабата се разбрахме, но Zylin-а твърдо отказа да си комуникира с GDB. Още на target remote и гърми с ""unknown host" и дотам. И CDT плъгините пробвах и кво ле не, ама не та не...

Та така не си губете времето с 64-бит. 32-битовия Еклипс (helios) тръгва, няма проблем...
Последното Yagarto (28.03.2011) също тръгва и поне засега работи. То е с последните GCC (4.6) и GDB (7.02) и те даже работят

Казват че са вдигнали скоростта на компилиране (аз не мога да преценя щото съм на нова машина дето е N-пъти по-бърза). Добавили са нови оптимизации и разбира се... още по-агресивни нови warnings. То с всяка нова версия на GCC е така, все повече забележки дава...

Важното е че всичко работи, минавайте смело на последно yagarto+eclipse



[edit]
Докато се мъчих да подкарам дебъга с 64-битовия еклипс както казах пробвах и последната версия на CDT плъгина... Та в него вече са вкарали директно съпорт за OpenOCD, BDI200, Macroigor... Може да е интересно за хората дето ги ползват. Но иначе все още им куца GDB конзолата, та затова аз си оставам на Zylin...

Би ли конкретизирал какви са тия агресивни warning-и?

Ми стават все по-агресивни, че чак досадни... и не можеш лесно да ги излъжеш

Примерно аз на различни места имам структури в които да кажем имат 4 поредни байтови полета. Нормалното при инициализация е да ги сетна едно по едно, ама така стават поне 4-5 инструкции.
По-ефективния начин е да взема адреса на първото, да го кастна до int и наведнъж да присвоя стойност и на 4-те полета. Естествено като каствам байтов адрес до int да дава предупреждения.

Досега обаче можех да го излъжа като адреса на полето първо го кастна до void* и след това до int* то забравяше за всякакви предупреждения. Сега обаче номерът вече не минава

Освен това са добавили и warnings за GCC опциите, така че даже и в makefile-а ми намери забележки

miro_atc, като цяло такива акробатики (макар, че това е доста дребно) не ги прилагам, като има 4 инструкции да се изпълнят - по-добре да се изпълнят, поне знам, че gcc-тата няма да ме псуват в някой версии.
Де да знам, замислям се дали да не го пробвам тоя еклипс най-после, свикнал съм си с rowley-то и хич ми ние дреме, ама като гледам що е мания да се ползва - сигурно има защо?