Нещо си в грешка пак - никога не съм защитавал 16/18

Както и другите казват тук в класа си може и да са най-добрите и най-удобните
Е поне за сега все още...

Makefile + произволни конзолни развойни средства.
GCC има възможност да ти прави auto-dependencies, така че makefile-овете са смешно малки.

IDE-тата просто ти организират аналог на makefile + dependencies, някои дори в явен вид.

"Досега не ми се е отдало да направя такова нещо с друго освен IAR."
Това имах пред вид за цялата база която описах. Иначе при повечето среди /компилатори последното си е така направено.

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

Никола, tgi, стига се палихте бе хора! Аз не защитава пиковете, даже са ми по-скоро неприятни въпреки че се е налагало и с тях да се занимавам. Обаче благодарение на многообразието на пазара има пикоборци, армъри, моторолци, каубойци и т.н. За всеки влак си има пътници както казват хората. Горе-долу така е и с програмните среди - няма лоша програмна среда, има лоши програмисти. В това отношение персонално подкрепям ToHu - IAR е възможно най-неприятната среда от тези разпространените. И все пак когато продуктът ти е завършен, хардуера бачка както си му е редът, програмите вървят мазно, крайния потребител не се интересува дали е пик или интел вътре и на какво и писан софтуера. Важното е качеството да е на ниво - нещо което много хора забравят в името на "модерния" избор

И цената е важен момет което също го пропускат някой, ако цената е многократно по висока от желязото за единица бройка, тогава желязото действително няма значение ако искаш сложи и PC на 4000MHz.
Ако ще правиш няколко хил бройки защо да не спестиш от процесор "желязо", ако за същото нещо може да го върши и по евтиния му събрат , ако това са също няколко хиляди че и повече и имаш шеф икономист ще те уволни ако не го направиш. Всичко друго е програма и програмист , ако програмата не е добре значи програмиста не му е мястото там , да си сменя професията
Спора малко прилича като за яйцето и кокошката кое е първо
Не е нужно с топ по врабче да се целиш или със самолет до село да си ходиш!

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

И поради това че полза няма аз приключвам с тази тема.
Пикобореца е особенно животно. Явно си е родено да се мъчи :):)
Ама скоро освен да се мъчи ще седи и гладно,щото ерата на устройства тип мигащ светодиод отминава :):)
Клиента вече иска функционалност :)

Ники, това което написах беше в отговор на чуденето защо са толкова разпространени, със сигурност нашата мила родина няма никакъв принос в това.
Никога не съм определял пик-а като най-добрия контролер, но и не мисля че е най-лошия, изобщо според мен най-добър и най-лош не могат да се изпозлват като определение за контролер. А относно различните модели аз лично съм привърженик на 10/12/16/18 серии, защо да се санимавам с новите им 24/33 които сигурно са и фрашкани с недокументирани бъгове когато там има доста удачни алтернативи. Както вече исах, процесорите им са простички за прости приложения. 24-ката не ме впечетли от това което разгледах, даже сме направили платка на едно у-во с нея но ще го правим с ренесас. За 33-ка изобсхто пък не съм гледал нищо.

С интерес следя темата от самото начало. Да зададеш такъв въпрос е като да омешаш агитиките на Левски и ЦСКА в един сектор на стадиона. Леле, какво меле настава .
И аз съм от отбора на "пикофобите", но не намирам нищо лошо в това, че някои харесват PIC и програмират на него. Все пак се борим за демокрация. Лошото е, ако за един професионалист светът на процесорите започва и завършва с PIC. Човек без да се усети започва да прави все по-странни неща само и само да се вмести в рамките на ограниченията, които сам си е поставил.
На времето ни учеха по диалектически материализъм (какъв термин само), че "количествените натрупвания водят до качествени изменения". Това важи в пълна сила и за процесорите. Използвайки достатъчно мощен процесор като ARM, ColdFire, MIPS и т.н. дизайнерът спира да брои цикли и байтове и започва да отделя повече време за усъвършенстване на алгоритъма, за структуриране и изчистване на програмата от грешки.
А цените на тези чипове не са това, което бяха. Малките ARM-ове вече се продават под 2$ (говорим за масови количества), чипове с комфортен размер на Flash и RAM струват 5-6$, а 200MHz ARM9 - под 10$.
Развойните средства също ги има на цени "за всеки джоб". Без да броим безплатните среди, компилаторът на CrossWorks се продава под 1000$, а IAR е в средата на ценовия клас - около 5000$. Тези цени може и да изглеждат високи за България, но все пак компилатор не се купува само за един проект, а се ползва с години.
Все още никой не е правил статистика за България, но американски фирми изчисляват, че един програмен ред, написан, тестван и документиран от опитен програмист им излиза между 100$ и 200$. Това не са само пари за заплати, но на този фон цените на компилаторите изглеждат като незначителен разход.
Накратко, светът се променя. Ако искаме да бъдем конкурентноспособни трябва да следим непрекъснато тенденциите и да се адаптираме бързо.

> На времето ни учеха по диалектически материализъм (какъв термин само), че
> "количествените натрупвания водят до качествени изменения".

Всъщност цитатът е от Хегел, "Quantitaet ergibt Qualitaet", количеството резултира
в качество. Класически пример за невярно твърдение с висока популярност според
мене - вярно би било "количеството понякога (често?) резултира в качество".
В контекста в който го ползваш като пример си е напълно приложимо и съм
съгласен с тебе, де.

> Използвайки достатъчно мощен процесор като ARM, ColdFire, MIPS и т.н. дизайнерът
> спира да брои цикли и байтове и започва да отделя повече време за усъвършенстване
> на алгоритъма, за структуриране и изчистване на програмата от грешки.

А бе наистина мноого по-малко цикли броим в днешно време, но то е признак просто
на това, че хардуерът се е развил доста по-напред от софтуера. В момента типичният
C-написан софтуер подлежи на 10 до към 1000 кратно (според случая) ускоряване, ако
бъде пренаписан "както трябва". Засега тая скорост не е потрябвала никому, но
с доближаването на границата за експанзия на хардуера нагоре по GHz/ватове и т.н.
и това ще стане, разбира се (колко неусвоен ресурс оставя двуногото ни племе, само
да може да се докопа до него... ).

Ала-бала ... Процесорът не прави дизайнера. А на калпав дизайнер процесора не му е виновен.

Относно цитатът според мен си е бил верен, за онова време и онея разбирания. Тогава хората споредмен са вършели по съвестно работата си , ама това са само мои теории ...

Да ама не. В университета имахме един професор Пантев, лека му пръст на човека,та той и други хора преподаващи автоматика казваха и казват,че за нуждите на автоматичното управление 8 бита са достатъчни.При това за управление в реално време на сериозни процеси,като синтез на антибиотицинапример.Ние не вярвахме,но един от професорите ни показа кореспонденция между него и едни французи които се занимават се прогнозиране на сигурност и живот на ядрени системи.Та те невярваха,че с методи и математика които нашите тук в БГ разработват могат да се прогнозират неща като техните и хвърлили ръкавицата.Та въпросния професор беше обработил данните и им ги прати обратно с прогнозите направени с неговите алгоритми.И французите си признаха,че данните му съвпадат с техните до няколко знака след десетичната точка. Друг е въпроса колко от нас разбират математиката до такава степен-аз лично си признавам че не я разбирам.
Защо пиша всичко това - защото спорим за глупости.Един човек който знае какво иска да направи,как да постави задачата и как да я реши не го бърка каква е платформата.Тя е някакво средство за постигане на целта и на нея не трябва а се робува.

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