При LPC с ARM7 базирано cpu ядро 3-степенен конвеир на зареждане командата при относителна адресация
защо зарежда PC 8 байта напред .
А и вътрешния флаш с каква организация е 8,16 или 32 битова.

заради конвейера става така; всъщност не са 8 байта, а дължината на 2 инструкции (8 байта в ARM режим, 4 байта в THUMB режим); получава се така, защото заради конвейера, когато дадена инструкция се изпълнява (3-то ниво на конвейера), следващата я физически в паметта инструкция(вече извлечена) се декодира (2-ро ниво на конвейера), а още по-следващата я физически в паметта - подлежи на извличане от паметта (1-во ниво на конвейера); инструкцията, която се извлича, е на адрес:
'програмен брояч на текущо изпълняваната инструкция + 1 инструкция (която в момента се декодира) + 1 инструкция (която се извлича)', т.е. PC + 2 * INSN_LEN

изобщо, така се и спестява отделен регистър и/или малко логика за сумиране в ядрото за формиране на адреса на инструкцията, която да бъде извлечена, аз поне така го разбирам

Нещо не връзвам

Тогава LDR PC, [PC,#8]
PC=0x4000+0x0008
PC=0x4008+(запълване на конвейра 1 избор(PC=0x4008) + 2 декодиране на 0x4008(PC=0x4009) +3 изпълнение 0x4008(PC=0x400А) )
И след тези три клока вече се изпълнява командата на адрес 0x4008 , а се е заредила командата на 0x400A.

А ако е заради дължината тогава прескачането на 8 инструкций(PC) не трябва ли да е 8*4 или *2
Има ли някъде обяснение за малоумни.

хм, аз нищо не разбрах от това, което питаш, но някои неща не ми изглеждат съвсем наред
първо - програмният брояч (PC) в ARM режим може да е само кратен на дължината на една ARM инструкция - т.е. на 4; това горе PC=0x4009, PC=0x400a просто е невъзможно; аналогично - в THUMB режим програмният брояч може да е само кратен на дължината на една THUMB инструкция - т.е. на 2

документът, който ти трябва, е: http://infocenter.arm.com/help/index.jsp , във фрейма вляво ARM Architecture, Reference Manuals, ARMv5 Architecture Reference Manual (известен като ARM ARM DDI 0100I) - за да се изтегли е нужна безплатна регистрация

от цитирания документ:
When an instruction reads the PC, the value read depends on which instruction set it comes from:
• For an ARM instruction, the value read is the address of the instruction plus 8 bytes. Bits [1:0] of this
value are always zero, because ARM instructions are always word-aligned.
• For a Thumb instruction, the value read is the address of the instruction plus 4 bytes. Bit [0] of this
value is always zero, because Thumb instructions are always halfword-aligned.

за инструкцията, която си написал:
LDR PC, [PC,#8]

от раздела адресен режим 2 в цитирания документ:
[<Rn>, #+/-<offset_12>]
where:
<Rn> Specifies the register containing the base address.
<offset_12> Specifies the immediate offset used with the value of Rn to form the address.
Use of R15 If R15 is specified as register Rn, the value used is the address of the instruction plus eight.

PC е синоним на R15

така, инструкцията LDR PC, [PC,#8] ще зареди програмния брояч с 32 битовата дума, на адрес PC + 8, но тъй като се ползва програмния брояч (т.е. R15), то стойността му е равна на "Адреса на инструкция LDR PC,[PC,#8]"; пример:

0x4000 LDR PC,[PC, #8] // адресът на инструкцията е 0x4000; в момента, когато тази инструкция се изпълнява (т.е. е в трето ниво на конвейера), стойността на PC е равна на 0x4000 + 2 * ARM_INSN_LEN = 0x4000 + 8 = 0x4008; така, инструкцията зарежда програмния брояч с думата, записана на адрес [PC, #8] = PC + 8 = 0x4008 + 8 = 0x4010, т.е. извършваш преход към адрес, чиято стойност е записана на адрес 0x4010

наистина не разбрах какво точно питаш, но горния документ е този, който ти трябва; това е документацията на ядрото, какъв точно чип ползваш (LPC, SAM или за какъвто друг АРМ се сетиш) няма абсолютно никакво значение

Инструкцията:
LDR PC, [PC, #8]
е всъщност "branch" инструкция. При "branch" това което е извлечено в конвейра се игнорира. След което извличането започва от новия адрес.
При LPC ARM7 има така наречения Memory Accelerator Module(MAM), който също се намесва в играта(ако е разрешен). Предвижда пренасочванията(branch-овете) и извлича от FLASH-а в буферите си съответните инструкции. Ядрото извлича инструкции от буферите на MAM.
Така че сценария, който описваш няма как да се случи.
При тези процесори на NXP организацията на FLASH-a e 32-битова. Но реално шината от FLASH към MAM е 128 битова и се извличат наведнъж 16 байта. Това наведнъж е ограничено от времето за достъп до FLASH-a, което за тези процесори е 50ns. При първите чипове от LPC2000 серията, освен всичко това FLASH-a е разделен на две банки с които се работи паралелно. За потребителя обаче FLASH-a винаги изглежда така все едно е с 32 битова организация.
Това е при четене, при запис грижата за всичко има вградения bootloader.

Май и аз не съм разбрал какво точно те мъчи. Но документа който ти е посочил шопов е това което ти трябва. Има и няколко други книжки. Eдната мисля че може да свалиш свободно от сайта на HITEX.

Искам да си направя снуфер на I2C 400kHz. И ще ми трябва накой бързак.

В thumb режим бачкаш само с R0-R7 при load, така че РС няма как да е destination...

Иначе имаш конвейр - първата степен извлича инструкция, втората я декодира, трета - изпълнява. Номерът е че степените на конвейрите както обикновено работят в паралел. Това ще рече, че докато се извлича една инструкция, втора се декодира, а трета изпълнява...
Много хора често се бъркат понеже РС сочи инструкцията която се извлича, а не тази която се изпълнява. Затова ако на адрес 0х4000 се намира твоята инструкция "LDR PC, [PC,#8]" то като дойде ред тя да се "изпълни", РС вече ще сочи 0х4008 и като добавиш отместване #0х8 се получава 0х4010 откъдето ще се извлеча адреса за преход...
Броят на клоковете в случая не е важен. Но все пак при LDR конвейра леко се задръства и са 3, но когато се зарежда РС задръстването е по-големичко и стават 5 клока. Всъщност за разлика от други контролери, инструкциите при АРМ се мерят не в "клокове" а в бъс операции. Като операциите могат да бъдат последователни и непоследователни (случаен достъп). Броят на клоковете общо взето съвпада с броя на операциите, но стига да няма wait states.
Размерността на флаша също е без значение - става дума за АРМ ядро, което е еднакво без значение дали говорим за ЛПЦ или не. Това че ЛПЦ използват 128-бит флаш е само за ускоряване на последователните достъпи, които при бавен флаш иначе биха изисквали wait states.

В крайна сметка нищо от това не ти трябва да го знаеш. Нормално ако пишеш асемблер се ползва



компилатора сам се грижи да замени "=new_address" с нещо от сорта на "[pc, #...] включително и да осигури място за константата/
макар че цялата тая работя няма никакъв смисъл тъй като по-правилно би било:



Зареждане на РС има логика само когато прави jump по таблица...

Мерси много, намерих си хубава и изчерпателна книга на руски.

ами определено LPC - то не е подходящия контролер за това. Колкото и да ме плюят колегите това си плаче за PIC. Или CPLD + LPC (Макар че за чии ти е LPC-то тогава)...

Но само LPC... аз лично по тромаво GPIO от това на LPC не съм пипал последните 10 години. Наистина ти трябва бързак, ама не сметало, а щракало.

Снифер за I2C се прави най добре с хардуерен I2C. Ако е читав разбира се.
И колкото и да ти е странно Цецо съм го правил и с друг процесор различен от PIC на GPIO-та само. :):):):)
А новите LPC имат и много бързи портове.

Хъм. Не съм попадал досега на достатъчно раздвижен хардуерен I2C който да може да се ползва за снифер. При повечето в слейв, адресацията е хардуерна и напрактика става глух за всичко дето не е насочено към него (то това му е идеята де ). Ама може и аз да не съм в час нещо.



Еми незнам, не съм чел за новите, но мога да се хвана на бас, ей тъй на сляпо за спорта, че няма LPC (или който и да е 7TDMI) дето да бие елементарна 18ка в клатене/четене на портове при една и съща тактова честота

С ATmega имам правен с хардуерното. Мисля че и с PIC18 става,така и не го завърших,първо с такъв се пробвах навремето. При AVR-a се хваща и SCL-а с прекъсване в което четеш SDA по заден фронт. две три ситуации се обработваха така. Ако ще сканираш готово устройство което не бърка протокола може и само с хардуерното. Но аз си го правих да си настройвам моите устройства.

Иначе за LPC-то са закачили управление на портовете на шината на процесора. И е станало много бързо. Не четох задълбочено щото не съм работил с такива но вероятно клатенето на пин е един или 2 клока на ядрото. И така става наистина доста бързо.

При кортексите на ST мисля че 2 клока е също писането/четенето на I/O. Което отива да е x4 сравнено с PIC18. като се пуснат и 2та на максимална честота.

Изобщо новите ARM вече са ги докарват да са достатъчно добри за подобни приложения.

На 7TDMI най-доброто постижение е ако има директен регистър който да избегне Read-Modify-Write хардуерно. И този регистър трябва да е закачен директно на процесора. Тогава може да стане с три инструкции, от които едната е STR, т.е 6 клока общо. Мисля че нещо такова има в "бързите портове" на LPC. 6 клока е и най-доброто постижение на кортекса, при него псевдо атомичното човъркане на регистър е заложено в ядрото. Пак е нещо де, сега поне можеш да промениш бит, като си сигурен, че прекъсване няма как да те захапе по средата.

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

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

При кортекса регистрите са в адресното пространство което е дублирано да може да се чете/пише побитово. Оттам оставам с впечатление че става за един два клока. Няма R-M-W цикъл. Но не съм задълбавал. Може да има някъде цикли на изчакване.

Комбинатор ако ще бориш с LPC и хардуерен I2C и закъсаш може да постнеш какво си измислил и да бутна едно рамо.