Цецо всичко което казваш би било валидно ако аз съм на 10 години.
И идентифицирането с някакъв микроконтролер и меренето на пишки(на което се позоваваш с нужда и без нужда) са характерни лапешки номера.
Друго характерно за тези години е че според малчуганите всеки истински майстор прави само върховни неща, неща които са винаги нещо повече от другите и използва винаги най-новите технологии, най-добрите инструменти и прочие...
Едва ли НЕ знаеш, че на всеки инженер, на всеки конструктор, проектант му се налага да прави И компромиси. Било то заради цената, било то за да държи нещата максимално опростени, било то защото целите на задачата понякога са противоречиви. Или както обичаме да перефразираме в такива случаи Дядо поп "Не може хем душата в рая хем х*я в п*****а"
Помисли за какви приложения е предназначен ARM7TDMI и какви цели са били поставени при проектирането му. Какви са били компромисите които са били направени(същото можеш да приложиш и за корейските "тенекии").
И мисля че тогава няма да се налага да казваме неща, които всички знаят, но прекарани през призмата на антагонистични противоречия от типа на "ARM срещу PIC в моите приложения" успяват да изпълнят две-три страници с постове.

Ето така започва ARM Architecture Reference Manual:

"The ARM architecture has been designed to allow very small, yet high-performance implementations. The architectural simplicity of ARM processors leads to very small implemetations, and small implementations allow devices with very low power consumption."

Аз се опитах да замажа положението, то стана по зле. Взимам си бележка и отивам наказан в ъгъла. ))))

Екстра си е засега АРМ-а. Поне не е по различно от това което очаквах от него. То не че съм задълбал кой знае колко дълбоко де, ама от първи впечатления - работи нормално.

Остава и Филипс да са го направили достатъчно шумоустойчив за мойте нужди. Но това ще се знае следващата седмица. Най много да си търся нова работа. ))

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

386 в защитен режим на 20 MHz му трябват 138uS за да влезе в обработка на прекъсване със запазване на контекста.
затова при бързи обмени и малка латентност хората са измислили хардуер - DMA. има доста ARM-ове с добри DМА контролери в тях.
асинхронния интерфейст, когато е замислен е ограничен до 19200. не случайно. пускането на 115К е възможно, но си има кусури.
асинхронен обмен на 500К си е безумие, да ме прощавате.
за тези скорости си има синхронни порти/контролери, някой даже работят в HDLC режим, и са тясно свързани с DMA и блоков трансфер.

не че няма екзотики като етернет или USB правен само с AVR/PIC. ама това е малко като манекенка - изглежда страхотно, има убийствено излучване и поведение на сцената, но не може едни яйца в къщи да изпържи. да не говорим за пълнено прасе

Аз също си взимам бележка. Позволих си да се отплесна само защото знам че отсреща има човек, който разбира.


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

съгласен съм
обаче сигурно и ти си съгласен, че е безумие...

Безумие е относително понятие. В момента умувам как да разделя оптронно UART работещ на 2Мбода. Невиждам защо 500кбода асинхронно по жица да са безумие.
Всъщност асинхронно и синхронно също са относителни понятия. Дали говорим за физическия интерфейс или по горните логически нива. Защото върху един UART може да се изгради съвсем синхронен протокол, което е и стандартната практика. Но какъв е проблема от един UART работещ на 1мбд например.

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

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

при асинхронния, предавателя и приемника работят със собствени клокове, които са асинхронни. те трябва да са с еднакви честоти (с някакви малки допустими отклонния), което се постига относително лесно при ниски битови скорости на предаване. сихронизацията става по спецично състояние на медията. в случая с UART, това е стартовия бит. поради асинхронността на двата клока, естествената разлика в честотите и много вероятната им флуктуация, синхронизацията се налага да е на ниво символ, вместо на ниво фрейм. прозореца за данни е мнопо по-тесен примерно 3/8 или 5/16. освен това данновата плътност е допълнително намалена от стартови, стопови и контролни битове. битовата грешка е много по-вероятна и затова се контролира на ниво символ. фреймова синхронизация е невъзможна на хардуерно ниво.

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

не претендирам за изчерпателност, дано сте разбрали каква е разликата

Така е Дедо, нещата дето си казал са верни.

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

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

А и пустия UART се е наложил като стандарт за комуникация с PC. Как иначе човек да вкара галванично развързани данни в компютъра по максимално евтин и универсален начин?

ма хич не си праф... точно обратното е!

E1 (2мбита) интерфейса само с фреймер е 1км, а с модем е до 7км по стандарт. ако са дебели жиците (зависи и от модема де) дига до 10км и то в "зашумен" кабел.
ISDN/S (160кбита) е до 1.5км само с трафче. U интерфейса (192кбита) също само с трафче е 7км също

това са брадади интерфейси, поне на 20 години. и се правят с елементарни чипове. сименс произвежда от поне 15 години чипсет, който има и HDLC, върши всичко сам до L2, че новите имат и L3 функции, реализирани хардуерно.

има още много - Е3 (34мбита), STM1 (155мбита), които се ползват много отдавна в телекомуникациите, но не за типично потребителски
това са скорости, когато модемите бяха на 2400, а тези на 9600 бяха бели лястовици

опто развръзването не подходящо на големи скорости.
промяната в стръмността е съизмерима с времето на семплиране на UART-а
моето мнение

в това, че UART се е наложил, няма нищо хубаво. сигурно имаш предвид 82х50? този чип е много куц, прото е жалко, че в оригиналното РС IBM са сложили точно него. ако бяха сложили 8530 на zilog, света днес щеше да е друг

....не че няма екзотики като етернет или USB правен само с AVR/PIC....
бих казал че е "изкуство"... Бързи Процесори,Бавни Опен Сорсове, Големи екипи, много пари за разработки... ехеее те и китайците станаха "програмисти"

изкуство?
може би си прав...
на мен по-скоро ми прилича на течение: нещо като импресионизъм. сигурно ти харесва пикасо?

едва ли е "Течение"... повече ми прилича на професионализъм, но както и да е - пак разводнихте темата, вече си мисля за някакъв вид БГ синдром...

Е и ти помогна накрая.

И какво да си разплетем чорапите ли? Като изчерпахме темата (свършихме работата), може да си полафим.

Четох, четох... (то това го правя вече трети ден), обаче нещо не мога да се ориентирам за abort handler-a.
Та затова да си попитам - когато се обработва ексепшън от типа дата аборт (т.е. по AXI-то на BRESP има DECERR), сладкото Куртексче (R4) влиза в дата аборт. Съответно Fault регистрите се сетват.
Та въпроса ми е, когато се обработва аборта кой се грижи за тез регистри? Аз ли трябва да мина и да ги забърша или процесора сам ги ъпдейтва на излизане от хендлъра?