Наистина добре е модератора да раздели темата. Извинявам се и аз на Комбинатор за отклонението от темата.
А сега за Fast GPIO.
Цецо тука се опитва да цака с това че ARM7 всъщност няма инструкция за вдигане/сваляне на пин. И съм съгласен с него. Така е. При ARM7 за да се пише в GPIO трябва да заредиш в регистър адреса на GPIO регистъра, после константа указваща кой бит ще се променя и след това да запишеш в регистъра. Така е, спор няма. Но ще напомня само, че когато търсим бързина, винаги можем да оптимизираме нещата. Да държим константите в регистри например.
Сега остава Цецо да извади следващия коз, че всяка инструкция при ARM7 заема 32 бита в ARM режим и феновете на PIC да запръхтят от удоволствие.
Напомням! Не сравняваме PIC с ARM като цяло. Искам да покажа че "бавните" GPIO операции при ARM7 не правят техните GPIO неизползваеми. Има компромиси с писането на кода, с консумацията, но като времена могат да бъдат не по-зле от PIC16/18. За които съдя само по цифрите, които дава Цецо,защото аз не съм работил с PIC.
Сега за тактовете. Наистина объркал съм ги. Отворих дебелите книги(признавам не го бях направил преди това). Та там пише: за STR инструкция към локал бъса 2 такта, бранч инструкция 3 такта. Тоест горния цикъл без зареждането на константите е 2 + 2 + 3 = 7 такта.
Направих и опитна постановка, която потвърждава това. На една платка с LPC2148(такъв имам под ръка с FastGPIO) опроводих един пин към вход на таймер/брояч вътре в самия LPC2148. Така всяко гавръткане на пина инкрементва брояча. Едновременно с влизането във въпросния цикъл:

Пускам и друг таймер който има за цел да спре броенето след 1 s.
Таймерите и ядрото се клокват на 36 MHz. Програмката върви от FLASH с активиран MAM(Memory Accelerator Module).
След известно време спирам процесора с дебъгера и гледам съдържанието на брояча. Тъй като всичко върви синхронно резултата винаги е един и същ.
При 36 MHz след една секунда брояча е спрял на 5142858(О, 32 битово число! Може ли твоя PIC да направи това?) периода на FastGPIO. Което прави около 194.5 ns за период. Или 7 такта.
Направих тестове и на 12 MHz и на 60 MHz. Както и тест на самия тест, като пуснах пина да се гаврътка от ШИМ.
Прилагам кода, който съм използвал. Който има интерес може да погледне и да повтори теста. Компилатора е arm-elf-gcc, но лесно ще се портне и за друг.
Консумацията няма как да я измеря точно защото на платката има и други компоненти, но по приблизителна оценка я закръглям на 30 mA от 3.3 V.
Така че пишем:
"LPC2148 ще му трябва външен такт 35MHz, при консумация около 30 mA."
Мога да пусна теста и на LPC2103, както и на LPC2378. Ако има интерес.

Не съм съвсем краен като Никола, но споделям неговата позиция. С едно изключение че: "Знанието е лично преживяна истина."

Евала. Аз по принцип имах за идея малко по-универсално решение, затова по моите калкулации отиваше над 40MHz. Но това което ти си доказал влиза точно във входното задание, така че се приема.

Естествено нито ти, нито аз, нито Кольо, ще сме си променили мнението за пикове и армове. Но може пък някой да извлече нещо полезно от спама на тая тема, знам ли.

Но си посипвам главата с пепел и ти дължа бира, защото ти ми доказа, че LPC2148 може да постигне по бърза работа с GPIO от PIC18. Естествено при по - висока консумация. Но е факт, че може Признавам, че отначало не бях съобразил, че можем да спестим 2/3 от инструкциите в задачката за арм, при така поставените от мен условия (на това му се вика автогол)

След всеки байт има acknowledge, т.е. винаги текат 9 бита... Когато господаря говори робите дават потвърждение на всеки байт. Спорен е въпросът само на последния байт - зависи как са си направили протокола. Ако е на пакети с фиксиран размер, може да няма потвърждение на последния байт. Един вид робът напомня на господаря да не праща повече...
Когато роб говори, господарят дава потвържденията. И в двата случая при липса на потвърждение комуникацията спира.
Освен всичко останало един добър снифер би трябвало да показва и старт & стоп.

Тъй като и на мен ми трябва нещо подобно, само че на малко по-висока скорост си направих платчици SAM7S+CPLD, но за съжаление още не съм стигнал до оживяването... Ще го направя някъде до месец надявам се, но ако ти е спешно мога да ти подаря 1-2 платчици да си пишеш сам софта... Платката е 4х5см, с USB конектор за връзка с РС и ако те устройва свиркай.


По повод лиричното отклонение.... Цецо си е прав. ARM не е подходящ за клатене на крака... Не че не става, предполагам може да си "клати краката" не много по-зле от един ПИК. Просто не му е там силата, пък и е грехота само за това да го ползваш. В случая съм сложил CPLD за 1$ мисля беше, колкото да вкарам SSC<->I2C конвертор и от там нататък данните ми влизат и излизат с DMA pri 0% CPU usage. В това е силата на АРМ - да има периферия която да върши черната работа, а той самия да го играе "директор на водопад".

Те това не е бъг бе! Тва е фючър
Сериозно, тва си е много готино ако го ползваш по преднадзначение. Ако ръчно клатиш крака и разчиташ на бързи прекъсвания това те спъва. Обаче за един "директор на водопад" не му трябва голяма бързина и реакция... По-важна е способността да работи с много роби... а като работиш с много е важно да не стават каши. Ако го погледнеш от тая светлина ще видиш че да имаш привилигировани режими, отделни стекове и т.н. е ГОЛЯМО предимство. Същото е с прекъсванията... значи прекъсвания много, ама един вектор само (Handler). Демек RTOS-а ти слага 10-на инструкции на едно място и прехваща всичко. И вече няма проблем лузърски таскове да си бачкат без стек, дадени прекъсвания да обслужват сложни протоколи и да ядат по много стек. И не се омазват взаимно и се бачка лесно.... Е, да... при всяко прекъсване те бави 10-на инструкции, ама ти и на ПИК да сложиш RTOS дето има тия гъдели и той ще ти вкара "излишни" инструкции..

Zdrav, сигурен ли си че тоя код все пак го изпълняваш от flash? Верно са 7 клока на ядрото, но ме учудва тоя MAM дето не вкарва нито един wait state... За да няма, трябва да има кеш на флаша, което ако са го сложили ще ме учудят що ползва 7TDMI а не 720 да речем че на всичко да може да има кеш..

Да от FLASH-а се изпълнява кода. Цикъла който се завърта е много кратък и MAM го кешира в буферите си. Същия код както казах съм го пробвал и на 60 MHz пак директно от FLASH - работи на 7 такта.