А бе на 400 kHz ще е зор за всеки неголям контролер - 2 uS IRQ латентност
си е (все още) недотам тривиална работа. Ако ще прави само това в цикъл
и няма да обработва прекъсвания от никъде е по-лесно, ама за какво ще служи
това нещо тогава ако няма да може да комуникира едновременно по още един
канал, по-бърз от I2C-то.
Може би през два серийни (кодек чешит) портове непрекъснато да чете
SDA и SCL по веднъж на микросекунда и да буферира, а буферираното да
го анализира без да гони ниска латентност - но с достатъчна скорост.
Със сигурност ще се побере в един 400 MHz MPC5200 ... Всъщност
биха се побрали два и биха работили едновременно комуникирайки резултатите
нанякъде без да отиде много от ресурса... . Ако $25 за процесор и още
толкова за DDRAM и FLASH не са много, всъщност решението не е и чак толкова
изхвърлено и дори би могло да се окаже практично...

Цецо в няколко теми вече не миряса с тези GPIO. Дай някакви цифри за един PIC18 да видим за какво става въпрос.
Например нещо от рода:

и

Като става въпрос за сравнение, как ще ги сравняваме, във времена при максималната честота на процесора, в тактове на ядрото, в брой инструкции за горните две постановки? А когато трябва да се клатят или четат едновременно 32 пина?
И едно уточнение "новите" LPC-та са на пазара вече трета година.

Майтапя се бе човек, кво се връзвате. Просто ми се пие бира и си търся повод.

Иначе на простите сметалки горните два примера биха изглеждали тъй -

while(1)
{
GPIO = HIGH; сетни бит еди кой си - 1 цикъл
GPIO = LOW; клирни бит еди кой си - 1 цикъл
} върни се пак горе - 2 цикъла

и

while(HIGH == GPIO) тестни бит и продължи ако е 0 - 1 (ако продължи) или 2-3 (ако лупва) цикъла

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

Това всичко с уточнението, че един тактов цикъл варира - 4 (за по дъртите) и 2 (за по новите) клока на кварца. Т.е. дърт пик бягащ на 40Mhz кристал, ще сетне пин за 100ns, и ще го провери за 100 или 200ns. По нов търкалящ се на 80 MHz, може да гаврътка пин на .....25ns. Добро постижение нали, а?

Аз лично като сравнявам бързина на GPIO го правя тъй - колко клока на кварца ми трябват за да вдигна/сваля един пин. При пик това са 2 (при новите) или 4(при старите).

За сравнение:

Cortex-а на при сетване на пин постига впечатляващите 80ns..... но на 72Mhz. LPC то мисля, че също може да докара 100 ns на 60Mhz. При .... 2 до 3 пъти по висока консумация Или ако сравняваме през кварца - 6 клока.

Всъщност целия фокус при пикльовците е че те нямат RAM в характерния смисъл на думата. Те всъщност имат масив от регистри За туй дъртия пик може да копира от RAM в RAM на два цикъла. Или да направи четене от паметта, обработка и връщане обратно за един цикъл. Или пък да се пъхне в прекъсване за 500ns. Ама това е за друга бира.

Не ме разбирай погрешно. Не казвам че LPC е по калпав контролер. Той си има други достойнства, но точно GPIO то му.... всъщност то това не е проблем на дизайнерите на NXP, а на ARM Просто някой не се е сетил, че като правиш контролер, а не процесор, ще ти се налага доста често да манипулираш битове.

Иначе аз съм пристрастен. Не толкоз към пикльовската архитектура, колкото до това, че с ARM7TDMI ми е много куцо да работя. Например винаги съм се чудил, що за болен мозък може да напъха подобна тромава концепция за прекъсвания и привилигировани режими, в един прост контролер. . Cortex-a показва че и а ARM са осъзнали че да правиш процесори и контролери, са малко по различни неща. Жалко само че 7ТДМИ стана прекалено модерен, и сега Кортекса трудно се налага.

Заслужих ли си бирата? Или по скоро оспамих темата....

И какво излиза, че като скорост нещата май са изравнени. Онези въшки LPC2101-3 работят до 72 MHz, при 6 такта -> 80 ns т.е. по-бързо от повечето PIC-ове ако гоним бързина. А като ни трябва бързина винаги правим компромис с консумацията.
До тук си заслужи бирата.
А сега ми кажи за чий са ти тези бързи операции с GPIO. Дай някакъв пример, приложение в което това е незаменимо преимущество на PIC.
Ако искаш да си гавръткаш просто един пин не можеш ли да го правиш с изход от таймер модула или ШИМ-а.
Нека да сме наясно. Не сравняваме PIC с ARM. Не си мерим п****те. Не казваме на никой с какъв контролер да работи. Това не е тема - "PIC срещу останалия свят".
Раздела е "Академия" чете се от начинаещи.
Лято е. Бирата се пие за удоволствие.

Е ако тръгнем да увеличаваме кварца, само за да клатим един пин.... То накрая ще сложим 3GHz пентиум, на който ще му трябват около 100 цикъла през 16-17 бриджа за да разклати пина, но сигурно ще го свърши за 79ns

Иначе да сравняваме PIC с АРМ е като да сравняваш Поло с Пасат. Аз лично предпочитам да имам в гаража и двете

Бирата винаги се пие за удоволствие и с удоволствие И лете и зиме. Ама лете е по кеф

Първото ти изречение звучи като че ли не четеш какво пиша или си изпил вече бирата авансово
Не става въпрос за 3GHz Пентиум, а за 32 битов процесор с ядро работещо на 1.8 V, произведен по друга технология. Как ще сравняваме сега консумацията?:?
Сравнение между PIC и ARM не съм имал намерение да правя. Исках обаче да се уточнят нещата. Да не предъвкваме все едни и същи неща. Човека, който пусна темата не знам дали има твоята стройна система за избор на MCU, но звучи като да е докопал някоя играчка(Пасат) и ти сега... да го разочароваш. Нека да я разчовърка няма лошо. Скоро ще го хвърляме този ARM7 нека му се нарадваме. Сега му е времето.

Уф. Добре. Сравнение по клок и консумация. Правим елементарна постановка за да се сравни по лесно:

Изходни данни: искаме да разклатим един пин на 100ns (100ns горе, 100ns долу, нищо друго).

PIC18J ще му трябва външен такт 40MHz, при консумация около 11mA.
PIC24F ще му трябва външен такт 20MHz, при консумация около 15mA.
LPC213X ще му трябва външен такт 60MHz, при консумация около 40mA.
STM32F103 ще му трябва външен такт 60MHz, при консумация около 30mА.

Всичките железа ги храним на 3.3V. Консумацията е приблизителна. Външния такт е след PLL-a, това което се подава на ядрото. За ARM-ските процесори съм взел (аматьор съм в областта) две зареждания на регистър + запис в паметта, т.е. по мои сметки 6 клока. С по малко не знам как може да стане.

Само не ми казвай че това може да се направи с PWM. Щото може и с 1 транзистор

Иначе човека нека си кара пасата. Не е лоша колата. Може и да стане задачката с LPC, не казвам че не може.

Ей не ти увира главата че тия неща се правят с периферията при всички читави процесори. Това че често ти се е налагало да клатиш IO та директо и бързо е от многото занимания с PIC. Като на повечето малки конролери периферията им не е особенно функционална.

А само пин ли ще клатиш :):) то страшно приложение ще да е :) Ами сети се че между клатенето на пиновете ще имаш още доста операции. А PIC-a не е особенно бързо ядро. Малкото му и орязани инструкции раздуват кода. И с тия умрели 10 мипса къде си тръгнал да говориш за 100ns цикли. Я влез в реалния живот.
Дори да вземем нещо просто и безмислено да се прави по този начин,един програмен SPI да кажем. Така като посмятам при една честота на ядрото при AT91SAM7 и пик18 ще изкараш долу горе един и същ клок. С малко преимущество на PIC18. При 10Mhz около 13-14mA за SAM7. Само дето SAM7 има 5.5 пъти повече мипсове.
Дори в едно такова хипотетично приложение можеш да си свършиш работата с ARM7.

Той и Zdrav те попита "А сега ми кажи за чий са ти тези бързи операции с GPIO. Дай някакъв пример, приложение в което това е незаменимо преимущество на PIC. " ама не отговаряш :):):)

Знам че ще се опиташ да дадеш за пример DC-DC на електрошоковите стимулатори с които се бориш. Ама да го направиш с директно клатене на пиновете си е леко програмистка идея. Доста транзистори вероятно си утрепал.
Но от друга страна като знам какво чудо са PWM на PIC16 с какъвто вероятно си го правил е обяснимо що си закопал в тази посока. :)
Като разработваш следващия си модел се консултирай с някой типичен хардуерист да даде съвет как се прави елегантно с PWM и една външна CMOS-ка.

Цецо ще коригирам цифрите, които даваш за LPC ARM-овете.
Както вече беше казано при ARM7, регистрите за управление на GPIO са вързани на периферната шина(APB). Това означава че следния код:
се изпълнява за 16 такта. Което означава минимален период за вдигане сваляне на пин при 60 MHz -> 266ns
Тоест задачката така поставена(100ns:HIGH-100ns:LOW) е непостижима за един ARM7. От едно време насам PHILIPS, после NXP, слагат в своите ARM7 т.нар. FastGPIO. Регистрите за управление на GPIO са закачени на Local bus-a на ядрото при което скороста се вдига около 3.5 пъти за горния код. Тези FastGPIO вече се слагат на всички от LPC2000 серията, като по-старите чипове имат нова версия 01, в която са отстранени всички известни бъгове, добавени са FastGPIO и някои други подобрения на периферията.
Та какво означават тези FastGPIO. Горният код в цикъл се изпълнява за 5 такта. Ако клока е 60 MHz това прави 83 ns период. За да гавръткаме на 200 ns период това означава, че трябва да свалим клока на ядрото на 25 MHz. Тогава консумацията също ще падне. Така че можеш да напишеш:
"LPC213X/01 ще му трябва външен такт 25MHz, при консумация около 20 mA."
Мисля че и аз заслужавам една бира. Ей сега отивам да я извадя от хладилника.
Наздраве!

С хардуерния не знам Бус адресите как ще чета.
А имам хубав сниф под DOS. през LPT-то ама вече ми е бавен.
Ще се опитам да направя преход от бърз към бавен от 400 към 100
Мисля на първо време да чакам старт да записвам всичко в паралелна ram до стоп ......без да ме интересуват повторни ASC или 7 или 10 bit бус адресация.
След това когато остане време да прехвърлям към LPT.
Софтуера сам си познава адресите на устройствата и дали се чете или пише.
Не съм сигурен ако направя фалшиво задържане на SDA при ACK....... може и да ми не трябва RAM (балженни са вярващите).
Не знам нямам много опит.

Като го правиш с хардуерния няма такова положение като bus адреси . Работиш с байтове. Декодирането на самия протокол е софтуерно.
Такъв трик с акнолиджа не можеш да правиш. Когато мастъра дава акнолидж обикновенно не се инрересува какво става на шината. Ако евентуално се инрересува обикновенно ще се генерира грешка.

Чакай сега. Може и аз да бъркам, но ми се струва че бъркаш с две по. При FASTGPIO ти трябват 5 такта да вдигнеш пина и 5 такта да го свалиш. Е май можеш да спестиш едната инструкция в последствие, но другите две (вкл. бавната писане в памет) остават. Което значи 9 цикъла за един период. Т.е. на 25MHZ системен няма как да стане. Трябват ти 40-50MHZ системен клок. Ако аз не пропускам нещо де, но цикъла трябва да е нещо от сорта:

1. Константа в регистър
2. Адрес в регистър
3. Регистър (константа) в памет

дотук го вдигнахме, трудно но му стана за 5 клока

4. Адрес в регистър
5. Регистър (константа) в памет

Вече му става по лесно - 4 клока

и т.н.

Айде да сме съвсем коректни... може би и 4 може да се спести... в последващите итерации. Така че изключае първото завъртане, натататък може да се сведе до 3 клока на "вдигане" респективно "сваляне". Но стана прекалено частен случай

А на пик ще имаме просто :

1. bsf PORTA,1
2. bcf PORTA,1

Просто до съвършенство. :):)

Кольо с теб за пикове не споря. Ти си предубеден до степен на религиозност

Пуснах за проба подобно цикълче.Според осцилоскопа и сметките ми излиза 14 цикъла. Не че е съществено де. Пак си е бавно.

Цецо нищо не каза за съвсем разумните аргументи които дадох,така като гледам нищо религиозно нямаше там

Останал съм с впечатлението че при задния фронт на 8-SCL подчиненото устройство трябва да свали SDA
в нулево състояние за да рзбере master-a че всичко е наред и да предава следващия байт, иначе ще има повторение.
Също така мислех че състоянието на задържане на ACK от подчиненото не се счита за грешка а след като главното
дочака вдигането на SDA ще продължи.Не знаех че някой мастер устроиствата не се интересуват дали подчинените са приели данните
Да забравил съм че подчинените чакат старт и стоп условита за да проверяват за своите бус адреси с бита за четене или запис.
Това ставаше само софтуерно след всеки старт.

Нищо няма да кажа за аргументите ти, защото обекта на спора не е за или против ПИК. Просто с Здравия се опитваме да изясним колко цикъла му трябват на арм7тдми (в частност имплементацията на LPC) за да го вдигне (пина) Пика просто го давам като база за сравнение. Ако толкоз ви дразни ще го сменя с AVR.

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

Рекоструктор, скъсай темата на две, че Комбинатора го оспамихме. А приннципно въпроса за бързите GPIO на АРМ процесорите е интересен предполагам за доста хора.