Какво значи надежден, няма как да е по надежден тъй като С компилира до ASM. А относно CCS, няма разлика общо взето, компилатора не прави нищо което не си му казал, дали е CSS, XC или IAR, е все тая. Всеки компилатор си има разни специфики, CSS най-големия му проблем е че не е съвсем ANSI, но и XC според мен не е. Ако говориш за изпозлване на готови библиотеки, аз не изпозлвам никакви от самият компилатор освен тези които са си ANSI, стрингове, math и др. от сорта. Всичко друго си го пиша сам. Имат проблемни библиотеки, но всички според мен имат, това е така защото масово тия библиотеки са за начинаещи и са правени с много уговорки и компромиси. Например масово в билиотеки на CCS и не само се използва while и то по сравнително идиотски начин. Също и някои функции не му работят както трябва, но отново това се случва при много компилатори.

Проблемът се състои в това, че програмирането, на какъвто и да било език крие рискове - от това да направиш проста грешка при писане и компилаторът да възприеме командата като вярна(пример '='<->"=="), до това да използваш не напълно дефинирана последователност от команди. За това препоръката е да се използват само части от C, които обаче са напълно дефинирани, и по-този начин се получава много по-висока надеждност или качество на кода(както искаш го наречи). Препоръката е да не се използва ASM за критични(важни) системи!
ПП: Ами на мен ми се е налагало да използвам на няколко пъти библиотеките на CCS(говоря за Ethernet, CAN, USB) и обикновено това са библиотеки за C18... или XC, който са леко модифицирани, за да се компилират. Тази лека модификация превръща кода, който трябва да добавиш(все пак трябва да прави нещо контролерът), в мазаляк... Чудо е! Та за това си използвам оригиналните библиотеки с оригиналния компилатор!

Какво ще рече критични/важни? За медицинско приложение дали ще е на C или на ASM докато не мине 100к теста пак няма да влезе в употреба.

Правя разни прости машини за фармацията (във фирмата в която работя правим - аз се занимавам с автоматиката) - та аз и да съм убеден 100% че машината е ок, после като отиде в на мястото си 6 месеца и правят евал. И това говорим за елементарни машини.

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

Ами добре! Аз пък се чувствам най-спокоен, когато някой е направил паралелна хардуерна защита!
ПП:Тези неща дето съм ги написал по-горе са ги измислили Ора бая по-умни от нас двамата!

Да но точно на С е по-лесно да допуснеш случайна грешка, просто защото на асемблера няма как да объркаш = с == и др. от сорта. Много изместихме темата, както казах аз не се имам за програмист, пиша код от няма и къде, за мен дали е на асм или на С няма особенна разлика, просто С-то предлага удобства и по-висока производителност на писане. Грешките които аз допускам, а и предполагам при всички е така, са грешки които бих допуснал и на С и на АСМ, т.е. това са логически грешки, аз почти не допускам грешки от рода вместо = да пиша ==, или ако го направя се открива много бързо, повечето грешки са логически от които нищпо не може да те спаси освен тест и QA. Лятото изгубих сума и време да си търся грешка, то грешка нямаше, просто една променлива беше с грешните индианци а аз упорито си мислех че е с праивлните, не знам защо ... скоро пак имаше нещо подобно. С не напълно дефинирана последователнст от команди, не знам какво имаш в предвид.
Проблемите в библиотеките са сипроблеми на библиотектие, не на компилаторите, и отново казвам, тия библиотеки с компилаторите са екстри за хора които ги мързи да пишат да търсят или да си платят за нещо, т.е. зарибявка, като безплатните минути при операторите, имаш ги ама не са ти много полезни щото да речем са само в твойта група, или само с тоя оператор ... примерно кейла, не знам какви библиотеки има освен стандартните анси, не ме и интересува, usb си идва от силабс да речем, и е написано работещо, не ми е и хрумвалод а търся таква библиотека в кейла, може и да имат не знам.
Навремето опитвах да изпозлвам на CCS библиотеката за паралелни дисплеи, много тъпо написана, така че да може да увисва, ами пренаписах си я и от тогава не съм изпозлвал тяхната, същото беше с тази за 1Wire.
Проблема със софтуера обикновенно не е нито в езика, нито в самото писане, а в концепцията и подхода, а в много случаи такива няма, особенно изпозлвайки среди от сорта на ардуино, имаш там нещо което върти колелцата, слагаш едно твое колелце и то да се върти, ама какво става при рестарт, има ли WDT, как се обработва, следиш ли си BOT, следиш ли източника на ресет, и купища други такива, никой не знае, а и не го е и грижа, а това са важни неща.
И във връзка с темата, точно за това според мен подхващайки нещо голямо, и разчитайки на това че ще му качиш ардуино, или ще изпозлваш някакъв фреймуорк, или готов код и ти само ще добавиш някакъв "апп" според мен не е начина да се развиеш като девелопър, да може да се научиш как да си конфигурираш портовете, как да си пуснеш ацп-то, как да приемеш нещо но серийния порт, и в същото време ще си далеч от нещо което може да се нарече продукт. По-добре да се хванеш с нещо по-малко, обозримо, което може да го разучиш за да схванеш основните принципи, и като вземеш голямото, без начение дали си го изпизсал сам или изпозлваш среда, да занеш че има и А и Б и да ги търсиш, и да ги изпозлваш ... другото е като да караш самолет с авто пилот, може да мениш курса, височината, дори може да го насочиш и приземиш, т.е. той сам да се приземи, но ти си само един интерфейс между някой който ще ти каже направи 1,2,3 и автопилота, реално ти сам никога не би могъл да пилотираш или да го преземиш.

То кацането май не може на автопилот, поне като съм гледам по National Geografic, това само за протокола ...
А иначе Ардуино-то си е чиста учебна платка за мен. Имаше една Launch Pad развойна платка на TI, ами тя самата, а и средата и за програмиране (Energia) визуално са еднакви. Също и стила на писането вътре е ардуински. Та значи и ардуиното е развойно.

А, за тексасците не така - енергията си е модифицирана среда ардуино (Processing), само че нещата не спират дотам. Имат едно друго животно - Code composer studio, то между другото може да отваря скечове от енергията. Ама това е 1 промил от функционалността. За разлика от ардуинотата лаунчпадите имат пълнофункционален дебъгер вграден, и като го закачиш такъв към code composer-a получаваш една от най-добрите Еклипс базирани среди за ембедед. И не само - същото чудо може да прави качествен дебъг на линукс през jtag (за техните процесори).
Да не говорим за тексасците са един от големите писачи (committer-и) е Еклипс фондацията, и доста от нещата дето и ние ползваме са там заради тях.

От много време насам няма друга тема, дето да е вдигнала толкова шум. Само чака някой да (му)й го измери.

Поне покрай темата намерих, че освен FFT има и FHT. Да ги пробвам, че да видя разликата и има ли я?
В общият случай в началото разработчика гледа да намери нещо готово, че да вървят нещата (Ардуино тип). После гледа колкото може повече да си ги настройва- оптимизира - до АСМ евентуално. После му е се тая и гледа да върви и не се занимава повече (Ардуино тип)
Бях на интервю в наша водеща фирма за авто електроника. Водещият програмист ми се скара че не може прекъсване да прекъсне прекъсване? (Нестед интеръпт)

Е, оня ден правих прекъсвания на две нива на 18F26K22 ... е това не е рекурсия де, ако това е имал в предвид.

Да- може това да е имал в пред вид. Аз- че ако се изпълнява бавно и дълго прекъсване да не пречи на Реал тайма. То съм се чудел дали- как може от прекъсване да се излезе с прехвърляне в някаква обикновена процедура и продължи, все едно го е нямало? Сега го правя с флаг в прекъсването и излизам. После от обработката на събитията проверявам за вдигнати флагове и им викам процедурите.

Ами тя така си беше зададена, широко скроена

Това нестед не го знам какво значи. А иначе на асемблер на пиковете като излизаш от прекъсване се пише retfie. То може да не го пишеш, ами да изчистиш флаговете и с goto да отидеш някъде. После при ново прекъсване пак отиваш на org 0х04... То по принцип не ми е ясно по какво точно се различава retfie от return. А иначе определено не възстановява W регистъра, наложи ми се да си го възстановявам ръчно, защото го използвах и в прекъсването...

Много обобщено го каза така за "пиковете" и точно пък W се възстановява на всички (които имат въобще прексъване) с retfie, като на 18ките има retfie 1 което възстановява W, Status и BSR и като ползваш приоритет, за ниския приоритет трябва да се грижиш да си ги запазиш тия регистри и после да си ги възстановиш.

Тая тъпня с гото да отидеш някъде след прекъсване за сефте я чувам. Разликата между retfie и return е че ти възстановява регистри и ти вдига GIE/GIEH в момента в който се изпълнява връщането. Помисли малко - ако преди return разрешиш прекъсванията и имаш вдигнат флаг ще те запрати пак в прекъсване, без да си извадил от TOS точката за връщане - потенциална предпоставка за омазване - особено ако си на границата на return stack-а, а той не е кой знае колко дълбок. А я ми кажи как ще възстановиш GIE в точката на връщане като тя може да е навсякъде в останалата част от програмата? Ще пишеш през ред GIE = true ?...

Не само може, ами и трябва Това се вика deffered procedure call. Идеята е довършване на обработката в друг контекст (не в този на прекъсването), т.е. с друг приоритет. Например в линукс им викат ISR (interrupt service routine - първата част дето тича в самото прекъсване) и IST (interrupt service thread). Това реално и вид шедюлър. Най-близкият до хардуера начин е с викане на софтуерно прекъсване, стига да има свободни такива и ядрото да има акъла да го поддържа.
Такива разклонения често са нужни, но не бива да се слагат произволно, т.е. без мислене - ползването му вкарва все пак забавяне (resheduling) и може да се избегне в определени случаи.
Тактиката при която от прекъсването слагаш флаг (и копираш заявката в споделени променливи, например получения символ по уарта) се вика "superloop с прекъсвания". Удобна е за прости неща но води до скапване на времето за реакция - в смисъл това е от най-бавните варианти заявката да стигне от прекъсването до главния loop. Ползва се понякога - например ако в прекъсването за приемане на уарта вкарваш в буфер а главния loop получава по-големи парчета когато може. Имам предвид че ако прекъсването само слага флага и копира само един символ, то няма никаква разлика с това да няма прекъсване и главната програма да си следи флага без прекъсване.