Да бе и на мен ми стана интресно, какъв е тоя конфликт на DMA и прекъсвания?

Принципно има две концепции за ДМА:
1)като самостоятелен и независим периферен модул, съответно отделен вектор за прекъсвания, регистри и т.н. Това е най-разпростространената концепция.
2)Всяка периферия да си има ДМА, съответно ДМА-регистрите са част от регистрите на периферията, ДМА-прекъсванията са част от прекъсванията на периферията


Луминари обаче са направили някакъв миш-маш. Уж самостоятелна периферия, ама каналите са обвързани с конкретна периферия. Има общ вектор за прекъсване при грешка, но за нормалната работа се ползва вектора за периферията към която е свързан конкретния канал.

И то така е свързано прекъсването, че изключва прекъсванията на периферията. Демек като включиш ДМА-то вектора на прекъсване се ползва от ДМА-то, поне докато свърши трансфера. Междувременно не се генерират прекъсвания от периферията. В повечето случаи това не е проблем, ти като заредиш ДМА трансфер чакаш само да свърши.
Обаче с UART-a примерно не е така - зареждаш да получиш 100 байта, но идват само 2 и толкоз. ДМА-та няма да ти направи прекъсване, щото трансфера не е свършил. UART-a има receive таймоут, обаче той не може да прави прекъсване докато ДМА-то бачка.

Така на практика при получаване аз не мога да ползвам DMA. Всъщност мога ама трябва сам да си организирам таймоутите... но тогава цялата UART комуникация ще се забави яко.
При изпращане пък не мога да пращам от флаш-а с ДМА. Тъй че и в двете посоки проблеми с ДМА-то.

В крайна сметка решихме НИКОГА да не ползваме ДМА За щастие перифериите си имат и FIFO-та, така че загубата не е голяма...

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

Иначе както казва Пирев, всичко си работи "както е описано в чаршафите"...

И ако човек не е претенциозен като мен контролерите стават С други думи ако пишеш код, който праща конкретни неща от UART2, ползва SPI0 и т.н. няма проблем. Аз обаче правя ОС и когато пиша UART драйвер, той е универсален, демек няма значение дали ще се инсталира на UART0 или UART5. Когато пиша драйвера не знам дали ще се праща от флаш или от RAM, не знам какви пинове ще са вързани към драйвера и т.н.
И проблемът с Луминари е, че подобни "универсални" неща стават твърде сложно и с голям овърхед. Не е като при Атмел, където периферията си има базов адрес на който са разположени всички регистри, включая ДМА. Така драйверските функции получават указател към базовия адрес и не се интересуват от това към кой UART?? е указателя.
И при Луминари има базов адрес, но той не включва всички регистри. Примерно за да бачкаш с периферията трябва първо да я разрешиш, което става в някакъв регистър от системния контрол, който няма нищо общо нито с базовия адрес, нито с номера на периферията. Ако ползваш ДМА пак е някакъв канал, който също не е обвързан нито с базовия адрес, нито с номера на периферията.

Така от базовия адрес, който получавам като параметър трябва с таблица или case да видя кой ще е системния регистър, или ДМА регистър, бит и т.н.
1) Това е овърхед.
2) Това не е универсално, защото ако сега има case с 3 UART-а, а утре пуснат 4-ти аз ще трябва да си преправям драйверите. Тъпо!
3) Това е източник и на много други синхронизационни проблеми. Примерно DMA-то е една периферия, всеки pin port е една периферия и тя трябва най-малкото да бъде разрешена, преди да може да се ползва. Обаче кой да я разреши? Демек като пиша UART дравер и ползвам DMA трябва да видя дали uDMA генерално е разрешен, ако не да го разреша. Ако да - да увелича броя на клиентите. Щото и други драйвери може да ползват ДМА-канали или пинове и накрая като спрат да ги ползват последния трябва да изгаси осветлението. Та тия проверки и глупости трябва да ги правя и във всички останали драйвери (SPIx, UARTx, USB...)

Резултата от цялата тая работа е, че за да пусна едно DMA се викат 6-7 функции, те смятат, броят, хабят памет и т.н. Докато при атмел същото става само с 2-3 писания по регистри, на стандартно отместване спрямо базовия адрес и нито памет се хаби, нито се интересувам от други драйвери, нищо... Да не говорим, че специално ДМА-то се стартира веднуж и после само зареждаш нов буфер. Като свърши трансфера ДМА-то спира и чака следващ буфер(и). Докато при Луминари спира и се изключва и наново трябва да го пускаш и конфигурираш. Малоумна работа!

Тъй де, според мен Луминари яко са се изложили... и е странно, защото явно не са си направили труда да огледат конкуренцията. Все пак Атмел са мноооого по-стари. Както и да е, всеки сам си решава. Мен лично това не ме бърка много-много. Затова съм се спрял на АРМ, защото имам избор - вчера Атмел, днес Луминари утре нещо друго.... Това че ОС-а и драйверите ми за едната платформа щели да бъдат 5% по-бързи или по-неефективни ми е все тая. Така или иначе в повечето случаи ползвам под 10% от производителността на контролера. Зорът е само докато направя драйвери за съответния производител. После кеф ти Атмел, кеф ти Луминари

Благодарско за обстойния отговор!

Интересно, няма ли abort механизъм на DMA контролера при КУРтекса ? Примерно тъй и тъй имаш ОС, задължително имаш и системен таймер, пускаш си канала и задаваш кое прекъсване да ти генерира abort, връзваш го това към системния ти таймер, получаваш си квото си получаваш по UART канала, като се спекат байтовете, по някое време системния таймер ще ти генерира прекъсване, което ще задейства автоматично abort механизма и след излизането от прекъсването на таймера, автоматично ще влезнеш в abort прекъсване на съответния DMA канал.

При PIC32 максималния брой DMA канали е 32, поне така изглежда по запазените битове, но до момента има реализирани само 8 канала. Максималния брой байтове на един трансфер е ограничен на 64kB, има обаче автоматичен режим на презареждане, при което нищо не преинициализираш/пускаш/спираш. Каналите могат да се организират във верига и когато свърши трансфера на единия, автоматично се стартира следващия. Трансфера може да бъде на 8 бита, 16 бита или 32 бита. Може да се зададе пренареждане на байтовете при трансфер, примерно ще се трансферира към външна периферия, която има различна подредба на байтовете в дума/голяма дума, тогава се задава какво подреждане има приемника на трансфера. Източника и приемника може да имат различна дължина на трансфера, могат да имат и различна дължина на единичния трансфер ( примерно 1 байт източник 4 байтов приемник ). Транфера приключва при достигане на края на източника или края на приемника, по прекъсване от кой да е източник на прекъсване, по съвпадение на байт/дума в потока данни. Прекъсванията на DMA контролера са напълно независими от системата на прекъсвания на процесора. Като цяло DMA контролера е гъвкаво организиран.

Между другото, шефа на отделите за разработка на перифериите на dsPIC30/dsPIC33/PIC32 и на dsPIC30/dsPIC33 ядрата е бивш главен конструктор на Motorola, привлякън през 2003г. в Microchip. Той от своя страна довежда цяла група конструктори със себе си.
Прави впечатление, че има последователност и в корпусите ( dsPIC30/dsPIC33 могат 1:1 да се заместят от PIC32 ), и в организацията на периферия и прекъсвания, така че ако примерно си усвоил dsPIC30, не се налага голяма промяна при портване към dsPIC33, или PIC32. В последната версия на C компилатора за PIC32 са заменили макросите, с които се бъзика периферията с функции, което е стъпка в грешна посока, добрата новина е, че са оставили и макросите. Просто функциите харчат излишно много памет, обръщения и т.н. Ако обаче компилатора е настроен на пълна оптимизация някак си "усеща" тези функции и ги отпмизира много добре, почти като макроси. Но ако ще се ползва студентската версия е по-добре да се използват макросите за достъп до периферията.

Погледнах го тоя dsPIC32, ми архитектурата на процесора му много напомня 54xx архитектурата.
Те на Майкрочип разработките ако ги правят в Остин, ще е все същият тиквеник правил неща и за
TI и Motorola.
Съвсем святна архитектура ми се видя впрочем - и това не е PIC .

Ми, като гледам, как от ден на ден започваш да си променяш мнението за микрочип, май май скоро ще ги заобичаш пиковете!

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

Най-добре си е receive timeout timer, защото го програмираш в бит-времена като той сам се стартира при първия получен байт и ако след еди колко си бит времена не дойде старт бит ти прави прекъсване.
Примерно когато по UART си говориш с GSM, зареждаш ДМА-то с един голям буфер и чакаш GSM-а да каже нещо. Той като говори праща байтовете залепени един след друг и пауза се получава едва на края на приказките му. Тогава се задейства таймоута и получаваш прекъсване и обработваш това дето е казал телефона....

Ако трябва да ползваш външен таймер, първо трябва да го стартираш след първия получен байт и да го ресетваш.... А в случая с Луминари ти нямаш никакви прекъсвания и не знаеш кога е получен някакъв байт. Но дори и да имаше прекъсвания трябва да смяташ времена, което не е лесно. Поне при мен целта ми не е да търкалям процесора на 80MHz а на толкова, колкото е нужно. Ако нямам много работа свалям честотата до няколко MHz или още по-ниско. Самият UART също може да си сменя baudrate-a. Тъй че ако е външен таймер най-вероятно ще бачка на променливия системен клок и ще мери променливите бит времена на UART-а. Това са сметки и ядове...
Естествено много по-добре си е самият UART да засича таймоутите, които да задаваш в бит-времена и да не го мислиш когато сменяш системния клок или baudrate...

Иначе ДМА-то на Луминари също има размери. Самите канали по принцип не са свързани, нито помежду си, нито с нещо друго. Но може да си правиш в паметта контролни структури и чрез scatter-gather може да правиш списъци от трансфери, без значение откъде и накъде. Така може да си програмираш някаква последователност, примерно правиш един трансфер от периферията, след това трансфер от паметта към някакви регистри, после други и така докато свърши списъка. Включително може да пишеш и върху структури от списъка, т.е. да си самомодифицираш трансферите, да ги зацикляш и прочие глупости.
Абе има всичко като "мощните" ДМА контролери. Единствено няма възможност за променлива логика. Аз съм ползвал разни чипове на каубойците дето имат и логика, т.е. контролната структура става нещо като "инструкция" и може да правиш събиране/изваждане, може да правиш проверки, може и да правиш условен преход към една от две възможни следващи структури.
На практика това си е цял"език за програмиране" и се нарича PCL (packet control list). Даже ние си бяхме направили и нещо като "компилатор". Но тая работа е удобна само за компютрите, защото една инструкция си беше 128 байта, а за един трансфер се попълваха/изпълняваха десетки инструкции...
Ние го ползвахме при мрежова комуникация, където ДМА-то първо дърпа хедъра на пакета, проверява получателя, дестинацията и ако всичко е наред го мята в паметта на компа. При изпращане пък праща една част, чака потвърждение, ако трябва повтаря същия пакет, ако е наред минава на следващия и т.н. Демек ДМА-то пере, чисти и готви само

При компютрите всичко това е много готино, щото има памет и не е добре да прекъсваш процесора по 10000 пъти в секунда. Хем мрежата става много по-бърза и надеждна, хем компютъра не се товари.

При контролерчета, обаче, тая концепция не е подходяща. Нито има излишна памет, нито пък е разумно за няколкото байта дето чакаш от UART да попълваш няколко килобайта структури... Много по-чиста е концепцията на Атмел - всяка перифиерия със собствено простичко ДМА. Няма контролни структури, няма никакви гимнастики и настройки. Имаш два регистъра - адрес и дължина. Първо задаваш адреса, после дължина. В момента в който регистъра с дължината стане различен от 0, дма-то тръгва - прави трансфери и инкрементира адреса. Като свърши ако искаш подменяш адреса или само пишеш нова дължина и то си продължава. Просто като гъбено семе
Единственото "усложнение" е че е двойно буферирано, демек може предварително да зададеш и следващ буфер (адрес/дължина) и той ще зареди автоматично когато трябва...

Бах мааму, да вземеш да напишеш книга по въпроса?!

Едва ли ще ги ползвам скоро. Тия dsPIC-ове, дето ги правят днес, ако и да напомнят 54xx
като архитектура са 1/4 от това, което съм имал от 54xx преди 10 години.
Просто реших, че си струва да се отбележи, че не са пълен боклук като това недоразумение
дето имаше някакви страници, стекът му не е в паметта и инструкциите му бяха не ми говори.
Разгледах го веднъж - когато почнаха да ги предлагат Комет - и повече време не съм си губил с тях.
По-новите им архитектури видимо са по-свестни, MIPS и тя е добра, ама са много много
далече от това, което имам в момента - камо ли да се състезават за ново нещо.
(В момента ползвам 400 MHz power - което с 64-те си бита данни е почти 800 MIPS - и се
оглеждам за следващото стъпало.).

Колко му е... дай 20 бона, ще ти я напиша, ще ти я отпечатам в 1000бр тираж, а пък ти си я продавай

tgi, ми давай тогава за да мигнем два-три светодиода да ползваме quad core на 4 GHz с 6GB рам. Все пак ние не се опитваме да летим в космоса, а просто да решим някаква елементарна задачка.

Ей човеко, да имам възможност с радост бих ти дал.
И все пак за мен е голямо удоволствие да ти чета обширните постовете
по подобни теми - страхотни са!
Чест и почитания!

Айде сега, нищо такова не предлагам. Ама и когато задачата е проста няма нужда човек да я
решава с ръцете вързани зад гърба, като може и по-лесно, де. Разните 08, coldfire и т.н. серии
са къде-къде по-разумно скроени.
А с тия пикове - дето са баш пикове де - си е излишна мъка. Или ако не е мъка значи
няма задача за решаване (настрана от преопаковане на готови неща).

Аз се шегувам разбира се... макар, че наистина бих могъл да напиша една книга, ще намеря мат'риал за толкоз. Пък и имам опит и с книгите и издателствата.. ех, не като автор де;-)

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