Ми това с безплатното също си е трик. Как иначе след време щяха да станат толкова богати!

Повече ме впечатли репликата на шефовете на IBM. "За какво са им на обикновените хора компютри"
Може би след 100 години ще звучи смешно и реплика от сорта: "за какво му е на обикновения човек ядрена централа или пък космически кораб"
В днешно време е много по-лесно да направиш нещо, отколкото да го продадеш успешно. Ако човек се замисли, защо ми е на флашка 2ГБ доживотна гаранция, като след 2 години ще я изхвърли както си е читава. Но колко ли фирми са продали своя по-некотируем спрямо други фирми продукт благодарение само на тези 2 думи.

Наистина безмислен спор...

Смятам че повечето които работят с ПИК са почнали щото доскоро нямаше голям избор. Платформи като PPC, ARM и т.н. са много хубави обаче не и за начаинаещи. Напоследък мисля че АРМ се поизчисти и стана сравнително достъпна. Има опен сорс (GNU GCC,GDB) поддръжка, която е напълно безплатна и неотстъпва кой знае колко на професиолните среди. А пък за тези които предпочитат лъскавите среди - има хапчета Има голям избор на чипове, има готови платки, има емулатори, абе всичко си има вече... Само мераклии да има!
И операционни системи има, то по принцип ARM без многозадачност си е като таратор без краставици и кисело мляко (демек гола вода).

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

Стига простотии де , с топ да стреляме по врабчета, да мятаме използвани прашки с кафяво отзад по щрауси, или да разсъждаваме като американците: караме големи коли щото оная баба с едното око и с тритонния буик като ни блъсне да оцелеем . Ми що не карате танкове тогаз, след като онзи дядо с двете очи ( и с натопорчено трето ) кара Хамър ? Та и вашата работа намирисва на таквоз чудо. Използваме АРМ щото като ни излезне на среща един ПИК, да не ни намачка ламарините . Да Ви имам логичните разсъждения. Що не изполвате тогава ПК вместо АРМ-ове ? Ако не сте дорасли за тях, обадете си, ще Ви светна в това онова, няма срамно нещо да попитате батковците, стига с тези хобикитчета с АРМ-чета , ние откога използваме 64-битови професори и 128-килограмови академици. Професора не прави проектанта. Ама искам, на всяка цена искам, дори да и се Удрискам, да си отговоря на въпроса защо точно PIC е по-разпространен в България, а ми не Renesas. И това какво ще помогне на човека, който зададе простичкия въпрос може ли с PIC да се направи многозадачна система ? Добрия специалист ще отговори простичко на въпроса на лаика, а не с глупости от рода що не минеш на Пентиум, а бе най-добре КуРеДуоНаГъзару 6, но първо подзяпай филма умиргай сладко АВеР32 Е батий, карате ме да пиша и аз като Вас тюрлю-гювече на търкалета.

Пирев ти там си на заплата. Цял ден да си чешеш оная работа все толкова ще земеш. Пък за шефовете там какво да ти пука,тъпи хамериканци
Но там където трябва да се върши реална работа е престъпление да се ползва ТНТМ-to Microchip. Всичко върви мудно и криво.
Ако няма алтернатива да кажеш майната му ще се борим и ще побеждаваме Ама има.
С други платформи се работи в пъти по бързо и удобно.

А за глупостите че с топ трепем мухи мога да кажа че всичко зависи от цената. Има си малки арм,че с цена под тази на пиковете. Да не говорим че са с доста по сериозен ресурс.

Freescale също изкараха малки ColdFirе. Coldfire1,32 битово процесорче с единно адресно пространство. Дребни евтини и бързи. Засега не съм ги човъркал лично но отзивите от колеги са много добри.

Единното адресно пространство е много сериозен плюс при писането на C. Няма спецификатори на достъп и други допълнения на езика свързани с това. В общи линии код писан за един процесор е напълно съвместим с код писан за друг процесор с такава организация на паметта. Пък ако става дума за код писан за 32 битови платформи съвместимоста е пълна.
Наличието на повече ресурс в процесора ти позволява да си ползваш спокойно библиотеки без да ти пука особенно за колко памет в повече ще изядеш така. Кода може да се направи прегледен и да се работи доста бързо.
На по сериозен процесор си пускаш и OS и работата ти става още по ефективна. Много неща ти идват готови направени и тествани с OS-a.
Че такива работи
Пикоборец просто няма място там където трябва да се върши работа. Просто е неефективен дори да е добър програмист и да си върши съвестно работата.

Ми намери си такава работа дето и ти да си го чешеш по цял ден, кво са ти виновни процесорите

Какво те бърка единното адресно п-во, когато използваш език от високо ниво ? Нима в Freescale Ц няма спецификатори ? Или в Ц-то за останалите проци ? Кои спецификатори в Ц-то те притесняват ? И кои са тези програми на Ц дето ще ги прехвърлиш с много малко работа от един процесора на друг ? Може би тези от 2 реда:


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

Но не ми се спори за глупости. Важното е какви пари правиш с изделията си, отколкото кой 32-битов процесор си използвал да запалиш две ламБи. И не на последно място, PIC-овете са като Windowsa, можем да ги мразим, но всеки ден ги използваме

дори 8 битовите им процесори на freescale са с единно адресно пространство. Спецификаторите за достъп са голям проблем за преносимоста на кода при работа с указатели. А указателите се използват повсеместно в C.

Единствено IAR имат някакво облегчение за работата с различните адресни пространства и май само за AVR.
За пример
void funct(const char __generic * str);

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

При различно адресно пространство няма начин да изпълняваш код от Ram-a също. Това е много криво при правенето на специфични бутлоадери и други трикове.

А за преносимоста на кода относно периферията си има трикове. Работиш си с периферията чрез драйвери. За новия процесор си пишеш само нови драйвери в повечето случаи. Но такива неща не е удачно да се правят на дребни процесори.

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

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

Това, че на C се замазват мръсотиите на дадена архитектура прави нещата
по-замазани, не по-добри.
Линейното адресно пространство е задължително за всеки процесор,
който може да бъде вземан насериозно в днешно време. Преди 20-ина
години хората са почнали да го разбират (не че линейното адресно пространство
е добро нещо, а че е задължително ако ще вършиш реална работа и ще
се конкурираш на базата на продукта си). Неотдавна Питър Алфке (основен
фактор в техническо отношение в Xilinx) разказа следната история в
comp.arch.fpga :работел за Zilog, когато пуснали Z8000. Отишъл да агитира
Стив Джобс с него за следващия (след 2) вариант Apple, и загубил
от 68000 просто защото последният бил с линейно адресно пространство,
а Z8000-не.
Та в днешно време да се опитва някой да ме накара доброволно да взема
процесор със сегментирано адресно пространство, да замажа цялата
работа на C, та да не я виждам, и да си загубя куп време докато цялото
това зловоние някак заработи, трябва мнооого здраво да ме притисне,
например с насочен пистолет в ъгъла.
Има толкова свестни алтернативи, с които мога да бъда пъти по-бърз
от вякаква конкуренция, че доброволно не бих си загубил времето с
размазаности.
Това има и друг ефект, не очевиден за страничния наблюдател.
Когато правиш всичко *свястно*, така че да няма заметени под килима
мръсотии, с годините се натрупват неща, които можеш да използваш пак.
За последните 14 години съм натрупал над 30 мегабайта сорсове (доста
над 1 милион реда), и не се е налагало да пренаписвам напълно нищо
досега, актуални са си ( http://tgi-sci.com/dsv/scnt3.gif ).
И 32-та бита линейно адресно пространство, в което живеят, е съществена
част от това. От известно време пиша с мисълта за минаване към 64-бита
такова пространство, но как ще е ще видя, като стигна дотам - засега не
съм.

Никола, защо имам чувството, че се опитваш да сравняваш ябълки с круши ? Сравняваш 32-битови процесори с "дребни" процесори. 32-битовите ги сравни с 32-битови, 8-битови с 8-битови. Никога не ме е бъркало адресното пространство на PIC, пък и не е сегментирано ако трябва да използваме точните термини ( сегментирано е например това на 80x86, където имаш сегментен регистър, офсет и т.н. ), а страницирано на банки, но ако използваш компилатор това вече не те интересува, компилатора си превключва сам банките. В този ред мисли остава единствената разлика, че RAM и ProgMemory са разделени и че трябва да го имаш в предвид, което пък е елементарно да се разбере. Иначе проблем с указателите нямаш кой знай колко голям, може да си направиш подходящи макроси, а може и компилатора да ги поддържа тези неща.

Bootloader-ите са изключително специфични неща. Аз имам bootloader за PIC16, който си написах на C, след време си го прехвърлих на PIC18, обаче компилатора MCC18 избълзва много голям код и затова си го пренаписах на асемблер за 18-ките. Ако обаче трябва да прехвърля кода от PIC16 към някой друг процесор извън PIC-овете, ще имам точно толкова проблеми, колкото и ако е бил писан за 32-битов процесор с линейно адресно пространство. При мен функциите на bootloader-а съм ги разделил на такива за комуникация, такива за разбор на hex файла и на такива за актуалния запис. Достатъчно ще е да сменя функциите за запис ( ако използвам драйвери за останалите неща, както предлагаш ) и евентуално някои неща в разбора на hex файла, защото hex файловете за 16-битово адресно п-во и 32-битово са различни. Това е.

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

И тъй като съм консервативен на тема смяна на платформи, заради броя на битовете, ще премина на 32-битов АРМ, когато Никола Киров се похвали, че е минал на 64-битов АРМ, тогава ще съм сигурен, че 32-битовите АРМ нямат вече неоткрити бъгове

Сравнявам процесори с процесори. След като 2 процесора са ми с един и същ брой изводи приблизително и на приблизително еднаква цена значи че мога да ги сравнявам и да си избера този с който ще си свърша работата по бързо и без много нерви. И от ARM и от някои от другите 32 биитови процесори има варианти с малко I/O та и с по малко периферия и ресурси съответно на цена сравнима с 8 битовите.

Пък ти не се олежавай там. Ще вземеш да решиш да се върнеш и пак тук и ще се налага да работиш наистина

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

leotron, ако следването ти е пряко свързано с компютрите да знаеш ,че с пика ти е много ниска летвата - това е за техници. Ако знаеш елементарна двоична аритметика и що е това тригер , значи знаеш да програмираш и пик. И много внимавай когато наричаш ПРОЦЕСОР, нещо което не може да работи директно с външна памет!

А по-темата хвърли едно око тука:
http://www.piclist.com/techref/microchi ... asking.htm

@ji4ka, Какво разбираш под директна работа с външна памет ? Без адресен дешифратор ли ?


- това показва че явно може да работи и с външна памет

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

Ами значи е процесор (но си е ПИК-екзотика). Те и хората са си го написали - с външна памет - микроПРОЦЕСОР, без външна - микроКОНТРОЛЕР(програмна памет имам предвид).
Абе казвах ви аз ,че Микрочипите ще почнат да пробутват контролери като процесори... Ама така е - другите фирми почнаха да им ядат от баницата, те пък почват да им ръфат от кюфтетата.

Нещо си в грешка - процесора няма вградена периферия- АЦП,ЦАП,.....

Пример за процесор :

High-Performance Floating-Point Digital
Signal Processor (DSP)
– TMS320C30-50 (5 V)
40-ns Instruction Cycle Time
275 MOPS, 50 MFLOPS, 25 MIPS
– TMS320C30-40 (5 V)
50-ns Instruction Cycle Time
220 MOPS, 40 MFLOPS, 20 MIPS
– TMS320C30-33 (5 V)
60-ns Instruction Cycle Time
183.3 MOPS, 33.3 MFLOPS, 16.7 MIPS
– TMS320C30-27 (5 V)
74-ns Instruction Cycle Time
148.5 MOPS, 27 MFLOPS, 13.5 MIPS
32-Bit High-Performance CPU
16-/32-Bit Integer and 32-/40-Bit
Floating-Point Operations
32-Bit Instruction Word, 24-Bit Addresses
Two 1K × 32-Bit Single-Cycle Dual-Access
Оn-Chip RAM Blocks
One 4K × 32-Bit Single-Cycle Dual-Access
On-Chip ROM Block On-Chip Memory-Mapped

Опресни си понятията за процесор и контролер

Разделянето е от мен. Честно казано ми беше малко трудно да определя кое е за тук и кое не, за това ако има нещо изпуснато - ще извинявате.