Добре ще обясня по подробно.

От гледна точка на хрдуера.
- Хардуерния стек е нещо което изкривява доста нещата.
- Банкираната памет свързана с куп ограничения.
- Липсата на читав хардуерен дебъг. Това изработва кофти навик да не ползваш дебъгер пълноценно.
- Бавни и тромави. 10 8 битиви мипса максимум. Изработва навик да губиш куп време да оптимизираш постоянно. В реалния живот се оказва че е важно да пишеш бързо,надежден и четлив код а не оптимален. На всичкото отгоре това което на C e оптимизирано за PIC не е задължително да е оптимизирано за друг процесор. Още се хващам че ползвам разни трикове които съм ползвал при PIC и са безмислени и даже вредни за ARM но по навик ги ползвам понякога.
- Няма единно адресно пространство. Изработва лоши навици за писане на непортируем код. Ако изобщо е възможно да се пише портируем код като работиш с PIC ::)

От гледна точка на компилаторите:

- Най ниско ниво. Единици от най рядко използваните процесори са толкова зле като компилатори и среди като PIC16/18. Оттам ми е останал навика да се изразявам надълго и широко вместо да пиша сбит код. Като напишеш нещо по сложно и компилатора хване гората и прави каквото си иска. Затова трябва да описваш всичко стъпка по стъпка за да няма неясноти . Направо обясняваш като на малоумник

- Изобщо няма читава среда с интегриран дебъгер в нея. Оная недомислица CCS която ползват почти всички пикоборци е пълна ТНТМ измислица. Няма и 10 процента от възможностите които трябва да предоставя една съвременна среда. Да не говорим че компилатора и няма линкер даже,да не говорим за оптимизации на кода. Това да изреже глухи части на кода,да инлайнва където е необходимо ..... Да не говорим за по сложни оптимизации. Един добре оптимизиран компилатор като си направи оптимизацията е изключено да можеш да дебъгваш стъпка по стъпка по C кода. А при CCS-a си дебъгваш точно както си го пише,ред по ред . Още 2 страници мога да изпиша за разликата между CCS и истински компилатор ама нямам време. Занимавка за малки деца си е.

- Дебъгерите включително REAL-ICE са отчайващо бавни. REAL-ICE преценка на око с PIC24 процесор е по бавен от стария дебъгер на ATMEL. По бавен е от BDM-a на Freescale. От дебъгера на Cygnal и MSP 430 също. Като че ли зарежда малко по бързо ама при самото дебъгване се влачи особенно ако имаш някакви данни които се извличат на всяка стъпка.

Има и още ама трябва да се навлиза в подробности пък ми писна

Стига глупости бе хора. Ебати изкарахте пиковата архитектура като вредното влияние на комунизма върху българското съзнание.

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

Кольо е ясен. Имам много високо мнение за тоя човек, в колкото работа ми е помогнал, с една цистерна бира не мога да му се отплатя. Но човека си има пиковофобия в остра форма. Аз затова не му взимам мненията относно пиковете насериозно и се бъзикам. Незнам що тъй, при положение, че и той от там е тръгнал. Бе то средното поколение - 90% от там сме тръгнали. И причината се казва г-н Алипиев. Кво да се лъжем. По старите са с закалка от 6800, тогава имаше само това. А сега "келешите" са глезени - каквото искаш е достъпно. Кеф ти мотороли, пикове, каубойци... всичко има.

@tqi -трябва да ти кажа, че точно пика дресира на асемблерско мислене. Просто защото процесора е толкоз примитивен, че даже и C кода му си страда от асмблерска треска. Рядко ще видиш пиковски C код в който по дефаулт се ползва int. Всичко е unsigned char. Щото няма памет. Всеки бит се пести. Въобще аз поне не познавам сериозен програмист писал за PIC който да не владее и асемблера му. Повечето са доста наясно и с хардуера, по ред причини (вкл. бъгове)

За сметка на това познавам мноооого програмисти на ARM и Cold, който даже не знаят, че съществува супервайзорен режим. Да не говорим, че като чуят за асмблер и бягат с писъци. Регистрите на процесора никога не са ги знаели - маат си под някакъв OС на високо ниво и толкоз. Даже и периферията не ги интересува - ако няма готов драйвер ... сменят платформата и OS-а. Същите тея даже и не знаят в какъв корпус им е процесора А това са сериозни програмисти, класи над мен.

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

Аз ако трябва да отделя процесорите по групи бих сложил PIC и AVR в една група, всички други са много по различни. Тия двата си приличат адски много, просто е въпрос на вкус кой от двата ще ползваш. И двете се истински харвард, без изгъзици и наистина са RISC в буквалния смисъл на думата. Инструкциите им се учат по бързо от листовки за KAT (последните ги назубрих за 2 вечери на бира).

Кольо между другото е много прав, че код писан оптимално за PIC е неприложим върху ARM. Макар че не виждам какво му е странното. Все пак говорим за 8 битов харвардски процесор и 32 битов вой-нюманов процесор (ARM7). Разликата е точно колкото между Z80 и PowerPC. Това е все едно аз да кажа, че трудно пренасям код от Xilinx на ColdFire.

Съвременните 32 битови контролери, по маниер на писане са дости унифицирани. На практика няма значение дали блъска код за ARM, Cold или AVR32, в 90% от случаите не се налага и асемблера да знаеш. Но това са две съвсем различни сегмента бе хора, все едно да кажете че HC логиката създавала вередни навици и пречела на хората да работят качествено с FPGA.

Цецо, проблемът на пикоборския асемблер не е, че е прекалено сложен,
а прекалено ограничаващ възможностите. Човек едва ли би поискал да
прави по-големи неща на него, а подобно желание - и опитите му за изпълнение - е
основен елемент в задържането на интереса на човек. RISC асемблерите за
неизползваеми за нормално програмиране - прекалено отдалечени са
от човешкия начин на мислене. На 6800 асемблер може да се напише
много и бързо (и на 6502 е правено...).
Инак това, че код трудно се местел е т.н. си е по-скоро безпредметно,
колко често човек мести код от една платформа на друга. Ако му се налага
да го прави често, значи е избирал консистентно грешната платформа и има
други, по-сериозни проблеми от местенето за разрешаване. Ако се налага
рядко (веднъж на > 5 години), начин винаги има - на какъвто и да е език
да е писан оригиналът.

От всички неща които изброих по горе се хвана само за портируемоста на кода че не съм прав Ами толкова много и криви кусури що си затваряш очите за тях :):)

Факт е че поради особенностите на IAR компилатора за AVR може да се пише портируем код и за AVR с просто
#define __ICC_AVR си превключваш това онова и си става съвсем Ansi C кода и се компилира където ти трябва.
И компилатора не е малоумен като пикоборските компилатори и можеш да се изразяваш нормално. Оптимизации,C++,Идеален дебъгер. Изобщо в сравнение с работата с CCS-a е мерцедес към трабантче.
Така че твърдението ти че PIC и AVR е едно не е така. Просто не познаваш и 2 те. На това отгоре има и други що годе читави компилатори със среди за AVR.

Ако държите на името PIC PIC24 е спасението. Има IAR с директна поддръжка на Real ICE и всичко си е много човешко. Но като говорим за PIC имаме пред вид PIC16/18. Време им е да потънат в историята като лош кошмар

И друг път съм казвал. IAR спряха преди години поддръжката на PIC16/18. Ако в световен мащаб беше наистина използваема платформа дали нямаше да искат да си гушкат парички.
Просто хората не са малоумници и не инвестират време и усилия в умираща платформа

Tqi.
Ами като правиш един куп изделия е нормално да имаш няколко платформи. Като работиш с няколко платформи и кода който пишеш трябва да е портируем.

Доколкото знам за работата ти работиш върху големи проекти. Но на който му се налага да работи по дребни поръчки? Аз поне засега големите неща ги правя направо за спорта. Не съм успял да изкарам реално заплащане от голям проект. Такова е положението в BG и провинцията особенно.

Стига пък ти тоя CCS. Един път го погледнах и го изхвърлих. И въобще не знам кой реши че на PIC12/16 трябва да пише на C. Това не са процесори за C, а за асемблер, какво искаш за 1-2$?

Всъщност ти можеш ли да ми дадеш пример за контролер за 1$ за единична бройка, с безплатна среда за развой, и който да можеш да си купиш в понеделник от магазина, без да се ровиш по каталози и доставчици и пр.?

Виж за PIC18 може да си се пише съвсем прилично на примитивно C. Но пак не CCS, въобще не знам защо тотва ти се върти в главата, за 18ките повечето хора си пишат на MPLAB-а. Аз също щото съм си го купил.

IAR незнам какво толкоз ти се нрави. Аз лично го харесвам, ама по много по различни причини от теб предполагам. Харесвам го защото е прост и елементарен, без "визуални" среди и прочие шарении. Чувствам го много по близък до Mикрочипската среда (микрочипската, а не CCS). Затова и за ARM го предпочитам пред GNU, кроса и пр. Само дето е прекалено скъп за мен и когато правя нещо различно от хоби глупости - нямам възможност да го ползвам.


PIC си имат достойнството от ниската цена. Абсолютно вярно е че да изтисква човек всеки цент е абсолютна глупост. За съжаление, не ми се случва всекидневно да цъфне някой и да поръча 5 бройки от нещо дето да струва 10000$, та да не ми пука колко струва желязото. Та се налага да се хваща човек и с неща от които се изисква да се цеди цената. Щото и 1000лв. да спести човек от 100 тина бройки нещо дребно - 1000лв. допълнителен доход на месец в БГ са си пари. На кой му се струват малко - евала. Нека не пипа пикове. Като порасна и аз така ще правя.

Прост пример - в момента имам да правя 100 тина устройства. Нищо сложно, просто хамалския софтуер ще ми отнеме около 3 плътни седмици с тестването. Спокойно мога да го пусна на PIC на 3-4$ на бройка за това време. Аналогичната платформа на Cortex ще ми се върже около 10$ на бройка. И ще загубя една седмица повече (може би 2 заради GNU-то). Те ти ги 1000лв. за един месец, които мога да "изкарам" или "спестя", без да си давам зор. Разбираш ли сега как мисля. Всъщност едва ли разбираш - ще го направя с Cortex-а щото съм мазохист ентусиаст, даже мисля да ползва кортексите дето бях приготвил за теб (и да купя Cross) Имам нужда от нещо ново Жената си я обичам, така че ще трябва да сменя платформата.

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

Цецо
CCS-a е най приятната среда за всички PIC-ове. Даже PIC24 поддържат. На това основно работят пикоборците
А да се пише код в MPlab-a е мъка отвсякъде.
Да сравняваш IAR с Микрочипските компилатори е просто несериозно. По скоро означава че не си навлизал в детайли да разучаваш всевъзможните екстри на IAR. Това само ако ги сравняваме като компилатори. Ako сравняваме като интегрирана среда пак става като разлика между мерцедес и трабантче.

За пример за нещо правено на IAR. Имам база за AVR в която имам около 400 C и H файла. Това цялото чудо съдържа куп готов код,драйвери за разните периферии,купища макроси,2 Операционни системи uCos и FreeRtos. Fat и още всевъзможни неща. Поддържа 7-8 процесора с които съм работил. Като цяло бързо добавям и нови.
Като си правя нов проект си копирам директорията на базата в директорията на проекта инклудвам в проекта един C файл един асемблерски фаил и един h файл. Има един голям конфиг файл в който настройвам това онова повечето от библиотеките си имат собствени конфиг фаилове и за тези библиотеки които ползвам настройсвам в тях.
В общи линии един проект с Freertos и повечето периферия се оформя за час. Оттам нататък си пиша кода който ми е специфичен за приложението. Всичко останало е напасвано и си работи.
Отделно обикновенно имам няколко варианта на компилация за различни процесори и различни версии на платката които в Иар се превключват с едно падащо меню само.

И това работи от най дребните ATtiny13 и ATtiny2313 до АТмега128. И продължавам да си я развивам и да набъбва като код и възможности. Като напиша интересна библиотека за някаква друга платформа си я добавям и в тази база.
И това не се компилира един час. Първоначално се компилира за минута 2 а после съвсем бързо,само файловете които си пипал.
Досега не ми се е отдало да направя такова нещо с друго освен IAR.

Имаш ли вариант с някакви средства за PIC да го направиш? Мисля че ги познавам всичките и съм сигурен че няма да стане.

Разбира се тази организация на работа не ми дава особенно предимство ако става дума за дребна програмка за 300-400 реда код. Но за малко по сериозна програмка нещата съвсем сериозно се обръщат.

Дадох примера за да прецениш какво може IAR-a.

За ниски цени и малки процесори. И двете на повече бройки идват на доста под долар . Безлатна среда. Истински BDM дебъгер на USB за 100тина лева. По бърз от пикльовците и с по малка консумация. Единно адресно пространство. Повече ресурс като ram от съответните на мокрочип. Асемблера им ако толкова държиш е лесен като микрочипския. Пак отиваме на трабант и мерцедес. Само дето трябва да си заръчаш 160 броя ама ако това ти е проблем ... . Дават си и семпли хората. През Future се доставят.
MC9RS08KA2CSC
MC9S08QD4
Ако те бъркат 10-20 цента разлика разбира се ще избереш трабанта. Ама какво да се прави,мизерията ражда мизерия

АТtiny13
ATtiny25/V
ATtiny45/V
ATtiny85/V
Като цена на повече бройки тези са по добре от съответните им от Мокрочип. Като възможности също. Безплатна среда има. Дебъгер по една жичка

Кво излиза че дори и в най малкия клас са пак зле мокрочипците.

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

Ами за пик и аз не се сещам за кой зане какви алтернативи на CCS, MPLAB ми е неприятен, а IAR ми е такъв от ървия момент в който пробвах да го позлвам Hitech имат сравнително не лош компилатор за Пик. Относно възможностите на компилатора, ами те са съизмерими с възможностите и приложението на процесора. Да процесора е прост, с прост асемблер, и е много добър за прости задачи, а пълно с такива. Да пуснеш TCP/IP на пик .. е това не го пожелавам на никого, едно кода сигурно ще е огромен, а ако вземеш да пишеш на асм ще е голямо наказание. CCS сам по себе си е почти асемблер, прав е Киров че няма оптимизации, да няма, аз и не искам обаче да иам като ползвам пик, на тоя процесор само това му трябва, компилатор който да почне да оптимизира. Иситнат е че от него имам навика да пиша С код като асемблерски, истина е и че в повечето ми неща правени на С за пик има поне 20% чист асм, иначе няма начин, най-вече проблеми с компилатора. Но както казах, просто компилатор, за просто процесорче за прости птиложения.
Дебъг възможностите не са много, но пак казвам ... просто процесорче, опредлено не е за сложни задачи с тромав код.
Относно преносимоста на софтуера ...може би при някои професори е възможно ... аз лично не съм голям фен на това, та дори между проекти за едно ядро, някои специфични неща да но като цяло съм против, но разбира се това че С му е далеч от ANSI е минус.
Сега за бавни и тромави ... много е относително, при работа с портове и битове са доста по ефективни от много други. Хардеурният стек .. ами колкото лошо толкова и добро, просто е плитък, но човек свиква да се съобразява с това. Естествено точно тук маниер на писане х86 може много да прецака нещата, забравяш да се оливаш с викането на функция от функция ... виждал съм кодове където се викат една от друга до безумие ... е при пик не става. Може да приемем за минус малкия стек.
И другото за което донякъде съм съгласен с Киров е банкирането, но то това не е само при пик все пак, има и други подобни недоразумения.

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

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

п.с. Киров, като говорим за цени на едро, говоримза 100 или 200 хил, имаш ли цена за 100 хил броя на пик и атмел? После ако мислиш че припроцесор от 1$ $0.2 са малко аз не съм съгласен, ако ралзиката е таква въобще не може да се говори, при 100 хил бройки това са $20 хил, няма копания която да ги прежали. А при продукти в сериа от по 1 млн .. там се цеди до цент, до част от цента ... примерно миксери, фритюрници и всякаква домашна електорника която има нужд аот някакъв контолер. Много от тях ползват пикове, и се произвеждат в милиони. При много от тях ядрото дори не е опаковано а се лепи на платката за да икономиста от корпус и платка, и сам си виждал как са изпълнени. истина е че и много от тях ползват разни специализирани неопаковани чипове, според производителя. Това е еиднот сериозните им пазари.

Ето и ти стигна до това просто процесорче с произтичащите от това проблеми. При положение че има по читави неща на съизмерима цена защо да се ползва изобщо PIC. Просто е въпрос на навици в 90 процента от случаите да се опре до PIC.

За IAR не става ей така в движение да започнеш и да му ползваш екстрите. Трябва да отделиш време за обучение. После си го връща стократно. А и ти си пробвал IAR за PIC16 вероятно който е най смотания IAR. Както казах по горе вече прекратиха от години поддръжката му.

Базата която описах по горе работи и на най малките процесорчета даже. При IAR за AVR например има допълнения към езика с които просто отпада изобщо необходимоста да се пише на асемблер. Има неща неописани в документацията също които се виждат като се поровиш в include директорията. Поне аз с AVR-a съм стигнал дотам че нямам вече никаква необходимост да пипам асемблера. За всичко почти си има начин да стане на C.

За MSP430 е по подобен начин положението с IAR.

А колко често в нашата мила родина боравим с такива тиражи? 100 или 200 хил са изключение обикновенно по мои наблюдения.
Домашната електроника отдавна се прави от жълтурите. Те държат големите тиражи.

Киров - ти с един "прост" пик неможа да се сбориш - чудя се как бориш другите платформи...

А и как така един "философ", който не се занимава с ПИК критикува същите

Хубавото е че сравнява 16/18 с АРМ

:lol:

След като смяташ че с един пик не мога да се сборя нека е така :):)

Що ли се мъча да ви отварям очите. Ей го на Wizard. Вместо да прочете какво пиша се опитва да ме подиграва.

Факт е че Wizard вече също предпочита PIC24-33 :)

Wizard имам ICD II, Тия дни ми донесоха ICD Lite. Поработих един ден и с Real ICE и PIC24 и имам няблюдения от него.
Така като гледам това са им всичките дебъгери.
Имам поне 10 тина развойни платки и китчета с PIC. Имам и няколко проектчета на практика с PIC. И някакви устройства за мен съм си правил. Имам и няколко хиляди реда C сорсове за PIC.
Пробвал съм за разлика от повечето пикоборци всичко по известно правено за PIC като среди и компилатори. И то защото съм недоволен и съм търсил нещо по добро. Мислиш ли че нямам опит. Така като гледам имам по добър поглед към пиковете отколкото ти си си изработил за години работа
Мисля че имам право да сравнявам PIC с другите платформи. Не мислиш ли?

И накрая ми доде акъла и пробвах с нещо различно от PIC :). Ама твоя дали ще дойде Кефиш се на Infinion ама работиш с умрели пикове.

И последно прочел си последните 2-3 съобщения и даваш мнение. Ами що не прочете малко по нататък. Дал съм и основанията си кога може да се сравнява. Заради теб да пиша пак ли? Темата се завъртя в що годе сериозна дискусия. Ако искаш дай си аргументи срешу нещо казано до тук и ще продължим конструктивно. :)

сори ама те нарекох философ щото се месиш там където си зле...
Разбирам те какво искаш да кажеш ама не е правилно да плюеш една платформа и използващите я за да изтъкнеш друга

Да факт е че от доста време не се занимавам с 16/18 и се кефя на 30/33/24 - за 32 нямам поглед, но все още не ме удоволетворявя периферията му
Кефя се и на Infinion, но ще се занимавам с него когато достигнe достъпност колкото PIC/AVR

А за IAR и CCS - пенкелерите, кучета ги яли - може някъде да са добри ама някъде са много много зле



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

Кво излезе,и поредния защитник на PIC16/18 излезе че ги е захвърлил вече :)

Пък дали съм зле с пиковете това е друг въпрос. Ела на гости в Зарата и ще ти покажа разни неща правени с PIC. :)
И сега ако дойде клиент дето иска да плаща дебело за нещо направено с PIC няма да го върна. Ама ще умножа по 3-4

В темата се изписаха и интересни неща. Който му е интересно разбрал :):) Нищо и няма.