имах две съображения, като пуснах темата:

1. да получа представа за практическата страна на въпроса и то най-вече за LPC-тата. дали някой има достатъчно направени железа за да е статистически достоверна информацията. най-вече надеждност, устойчивост и т.н.

2. идеята за уеднаквена елементна база

във всяко по-сложно изделие (или изделия) неминиемо се налага функционално разделяне. в повечето случай функционалното разделяне води и до хардуерно разделяне и всяка функция се реализира от отделен процесор (или микроконтролер).

представете си какво би станало, ако се ползва PIC, AVR, 430, Z80, 8051 и ARM! ако трябва да си купиш развойните средства ще ти трябват няколко десетки хиляди гущера. това от една страна - другата е програматори за всички, документация и, най-сложното, хора! обикновено даден специалист работи добре с до две архитектури, което води до събиране на достатъчно голям екип, чието управление само по себе си вече е тежка задача.

от тази гледна точка, идеята да се ползва само една архитектура е много съблазнителна. купуваш си най-добрия компилатор, който поддържа всички чипове, имаш единна обща среда за разработка и дебъгване, хората говорят на един език помежду си. в този аспект, няма значение, че мухобойката щяла да струва $2-3 повече от MCU-8. прдимството на голямата мухобойка е, че поне решава кардинално въпроса с мухите :-"

цената има значение само при големи количества. ако разликата в цената на чипа е $3, при 500бр. разликата е $1500. то един читав компилатор стува повече, да не говорим за часовете чесане по главата, необходими да му свикнеш.

по друг начин седи въпроса, ако се проектира изделие за 50К бройки...

Дедо Боре,
Мен ме е учил едно време Трайко Петков! Той казваше, че няма по- и най- оптимално!!
Оптималното е единствено по зададен критерий - може да е цена или бързодействие или......
каквото си помислиш....
Но няма НАЙ:)))
Та в тази връзка -няма идеален контролер, и определено PIC-овете са мноооооооооого
далеч от него:))
Никога (за себе си) няма да залагам на тях. (това е субективно)
и се дискутира на халба бира...)

По въпроса за устоичивоста на смущения сега успях да поговоря с един колега които се занимава с ARM откак са излезли и работи апаратура която работи по нефтените сондажи из Русия.
Ползват ARM7 ot ТI - TMS470. Казва че са пробвали почти всичко от ARM7 и не ставало за техните условия,а тексаските били супер устоичиви,само при много ниски температури често зависвали но като се ресетнат от кучето продължавали смело. Ама това ставало по далечния им север така че ясно за какви температури става дума
Така че има и ARM7 които са достатъчно устоичиви,само не знам по BG дали могат да се намират.

Тексасците са железни - аз поне каквото тяхно съм ползвал, съм нямал грижи. Може и да имат някъде косури, ама аз несъм попадал още на тях .

Едно от неудобствата при ARM7 като микроконтролер е липсата на директна адресация.
Архитектура му го прави ефективен за 32бит операнди но не и за байтови операции
директно с RAM и портове.

Един пример - увеличаване на байт с 1 и прехвърляне в друга клетка :

unsigned char cc,bb;

Next label is a Thumb label
cc++;
0x00008114 480B LDR R0, [PC,#0x02C] ; [0x8144] =cc (0x10002D)
0x00008116 490B LDR R1, [PC,#0x02C] ; [0x8144] =cc (0x10002D)
0x00008118 7809 LDRB R1, [R1, #0]
0x0000811A 1C49 ADD R1, R1, #1
0x0000811C 7001 STRB R1, [R0, #0]

bb=cc;
0x0000811E 480A LDR R0, [PC,#0x028] ; [0x8148] =bb (0x10002C)
0x00008120 4908 LDR R1, [PC,#0x020] ; [0x8144] =cc (0x10002D)
0x00008122 7809 LDRB R1, [R1, #0]
0x00008124 7001 STRB R1, [R0, #0]



Срещу PIC18:

.................... cc++;
0016: INCF 06,F
.................... bb=cc;
0018: MOVFF 06,05



Все пак в повече от приложенията това може да не е от значение.

@Lino пусни го този компилатор за ARM с оптимизация че то така и мене ме заболя главата.

Трябва да стане нещо такова:

ldr r0, [pc, 0x2c]
ldrb r1, [r0]
add r1, r1, #1
strb r1, [r0]
strb r1, [r0, #+4]

Стана почти два пъти по-малко. Но ... Ей тука PIC печели.

@ZDRAV в конкретния пример може да се направи оптимизация, но ако между
c++; bb=cc; има други операции които променят съдържанието на
регистрите R0,R1... оптимизация няма да е възможна(освен ако самия програмист не се грижи за
оптималната последователност на операциите.


Още един пример за CLR/SET на PORT бит:
IOCLR = 1;
0x00008126 480D LDR R0, [PC,#0x034] ; [0x815C] =0xE002800C
0x00008128 2101 MOV R1, #1
0x0000812A 6001 STR R1, [R0, #0]
.
.
IOSET = 1;
0x0000812C 480C LDR R0, [PC,#0x030] ; [0x8160] =0xE0028004
0x0000812E 2101 MOV R1, #1
0x00008130 6001 STR R1, [R0, #0]


При PIC (и AVR аналогично CBI,SBI)

BSF PORTA,0
BCF PORTA,0

Сега като сравним PIC работещ на макс. 48MHz значи има 12MHz такт, ще го изпълни това за 2 инструкции време - 160ns (ако въобще го изпълни, да не наводнявам ама имаше една Errata дето ревеше, че можело и да не стане с BSF/BCF при нам си кви условия)...ARM работещ на 48MHz.... 20ns за инструкция, едва ли има смисъл да се сравнява Ама що ме карате да се напъвам, и без това трудно си преглъщам кафето тая сутрин

Тъй, тъй .... принципно едно иде а ? ... това как да е, ама онова с преъсването е по смущаващо, но пък AVR -а .... той по бързичък иде .... но както и да е, но пък ако имаме

int32 a,b

a++;

b=a;

тук вече нещата май стават други ......

С примерите обръщам внимание на липсата на директна адресаци при ARM и до каво води
това: по-вече инструкции за конкретни цели. Честотите на процесорите и за колко цикъла се изпълнява една инструкции е съвсем отделен въпрос.
Трябваше да дам примери с други процесори за да не засягам болната тема PIC.

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

Когато говорите за максимална скорост на PIC говорете и за максимална скорост на чип с ARM7. Представителите на най-ниския клас LPC2101-3 работят до 70MHz. И ако ARM се забави на cc++; bb=cc; то по-нататък със сигурност ще навакса.
Въпросът със прекъсването е сериозен ако гледаш максимално неблагоприятната ситуация. Ще повторя това което беше казано до тук. Ако ARM7 бъде заварен в началото на изпълнението на най-дългата си инструкция, а именно LDM или STM (съответно LoadMultiply и StoreMultiply), която прехвърля няколко регистъра на/от последователни адреси тогава имаме максимална латентност на влизането в прекъсване. Времето за изпълнение на тази инструкция зависи от броят регистри които се прехвърлят. Та максимално неблагоприятният случай е когато се прехвърлят всичките 16 регистъра за дадения режим.
Тази инструкция не се ползва винаги да не говорим дали я има въобще при другите процесори с които сравняваме ARM.
С тази инструкция се пести програмна памет и може да бъде заменена(ако паметта не е проблем, а се гони бърза реакция) с няколко по-кратки които прехвърлят по един или два регистъра.
Ако се изисква бърза реакция на дадено събитие се използва FIQ(Fast IRQ) той има по-висок приоритет от нормалните IRQ и може да прекъсва процедура, която обработва нормален IRQ. При подаване на FIQ към ARM7 ядрото, процесорът, след интервала на латентност(който в най-добрия случай е 5 такта на процесора) отива на адрес 0x1C, където се намира векторът на FIQ и автоматично превключва в FIQ режим. Превключването в FIQ режим означава автоматично запомняне на сатус регистъра и превключване на банкираните регистри r8-r14, които не са видими за другите режими на процесора. Ако процедурата за обработка на FIQ използва само тези регистри не се налага запомняне на контекста при влизане и възстановяването му при излизане. Излизането става с инструкция
subs pc, lr, #4
Която автоматично възстановява запомненият статус регистър, превключвайки в режима в който се е намирало ядрото преди FIQ и се връща там от кадето е бил пренасочен.

В най добрия случай латентността е 5 такта(при 70 MHz това са 72 ns), като вътре в процедурата за обработка на прекъсването не е необходим код за запомняне и възстановяване на контекста.

Моля да ме простите за това дълго словоизлияние. Всичко което казвам може да се намери в документацията на www.arm.com
Нека да не четем документите само за да открием нещо в което PIC или AVR са по-добри и да отминаваме предимствата на ARM7. Като че ли някой ви кара да се откажете от добре утъпканите пътища и да навлезете в тъмни и непознати дебри. Ако не виждате смисъл в използването на ARM7 то значи това ядро не е подходящо за вашите задачи.

Ако някой се интересува от Wigglera ей това може да му помогне:
http://www.mcu-bg.com/mcu_site/viewtopic.php?t=257

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

Работите обектно-ориентирано* на 8,че дори и 32бит микроконтролер на 70Мхз.
имам чувстото , че Nikola говори за C

* - по-скоро аз не го виждам как ще стане реализацията на C++ за микроконтролер, при положение, че как да го кажа примерно ще трябва страшно бърза да обработва прекъсваня ...

За Атмегата се пише много приятно на C++. За Арм ли да не може
Какво те бъркат прекъсванията,тях си ги правиш кратки и оптимизирани а в main нишката си правиш каквото си искаш.