Спамим на човека темата.. ама...

Сетих се и за другото общо нещо между двете - прекъсванията. Възможно е и там да е проблема.
Да обясня малко...

Имам едно главно прекъсване - което е с най висок приоритет. То се случва с честота 48кХз. То минава и обира данни от всички 8 буфера, Прави сътветно и нужните обработки. Ако някои от буферите се изчерпва - минава към четене от другата му част, и съответно вдига заявка че имаме празен буфер за пълнене. Заявката представлява софтуерно активиране на друго - по-ниско приоритетно прекъсване, което би трябвало да се случи веднага след като завърши текущото - дето му викам "главно". Така след като главното прекъсване си свърши работата - демек обрало е данните от всичките потоци и ги е обработило - то освен това и е навдигало заявките на буферите които трябва да се пълнат. Всички заявки са реално отделни прекъсвания - които обаче са с еднакъв приоритет - и не могат да се прекъсват едно - друго. От там - всяко прекъсване инициира трансфер с картата - и чака докато DMA-до каже че трансфера е готов. През времето през което чака - то не може да бъде прекъснато от друго такова прекъсване - същото като него. Тоест заявките за пълнене се изпълняват една след друга и не могат да се прекъсват. Те могат да се прекъсват единствено и само от главното прекъсване, което обира данните. В общи линии - това е постановката.

Търсим и слаби места

Какви слаби места бе човек? В прекъсвания гледаш да не правиш нищо, влизаш, сигнализираш и излизаш... А той милият "минава и обира данни от всички 8 буфера, Прави сътветно и нужните обработки."

Ясно е за прекъсванията - обаче тука става въпрос за малко по-различна концепция.

В главната програма няма нищо важно - само екран и все неща които може да чакат и да се правят когато има време за тях.
Даже и да спре напълно - главната програма - това по никакъв начин не се отразява на работата на устройството.

Няма НИЩО ПО-ВАЖНО от обирането на данни и предоставянето им на изхода на ДАКА. Все пак това е аудио - не може да чака.
След като няма нищо по-важно от това - тоест то по НИКАКВА причина не трябва да се прекъсва от нещо друго - защо цялото това нещо да не е в прекъсване с най-висок приоритет. Има разбира се някакво буфериране - ама то не се отразява на концепцията.

Така - след това обиране на данни - което е най важно?
Ами следващото по важност е осигуряването на данните. Няма по ефективен начин според мене - това да става в по-нископриоритетни прекъсвания, защото те не могат да прекъснат ГЛАВНОТО - а и не трябва да се прекъсват едно друго. Тоест - 8 прекъсвания с еднакъв приоритет. Така не се налага да вдигам някакви флагове че трябва да чета от някъде - след това да ги проверявам и т.н. Главното прекъсване вдига флага на някое от тези - и щом главното свърш - процесора сам отива да изпълнява някое от тези - и ги оправя всичките едно по едно. Няма флагове - няма проверки и т.н. Аз не се занимавам с това.

Има разбира се и други - още по високо приоритетни прекъсвания /по главни от главното / - които са за разни асинхронни процеси - независещи от софтуера - примерно четене от сериен порт и т.н. Към тях вече се отнасям по обичайния начин.

Уф нямам време в момента нито да вникна какво правиш, нито да ти обяснявам подробно как се прави...

Накратко, АРМ и другите процесорни системи не се ползват така. Приоритетите на прекъсванията в една многозадачна система не се определят по това колко са ти важни на теб, а според честотата на тяхното появяване. Иначе многозадачността ти отива по дяволите...

Ти слагаш най-рядкото прекъсване с най-висок приоритет и правиш един куп неща в него. Всичко ти е наопъки...

Хммм... Не се прави така. В прекъсването - никакви сложни обработки и/или i/o. Какво ти пречи да прекъсваш математиката ? Вдигане на DMA заявка към периферията ще е не повече от мяколко микросекунди, после математиката си продължава оттам, докъдето е стигнала.

Не схващате концепцията явно.

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

Един вид - прекъсванията - и приоритетите им взти заедно се разглеждат като отделни нишки - с различен приоритет. Тези които са с еднакъв - са нарочно с еднакъв - за да не могат да се прекъсват една друга - и да се налага да им се прави синхронизация.

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

Основната полза е, че четенето от картата трябва да става заявка по заявка. Трябва да чакам текущата да завърши - за да дам следващата. Затова много прекъсвания с еднакъв приоритет. Активирам ги всичките - а те се изпълняват едно след друго сами - без аз да им бера грижата. Доста е удобно, а и изглежда най-бързия вариант. Иначе докато чакам в прекъсване /какво светотатство а / трансфера от картата да завърши - или казано друго яче - ДМА-то да каже че трансфера е завършил - аз реално нищо не спирам освен главната програма, ама както казах тя изобщо не ме интересува. Това което реално съм спрял е - да може да се извърши друга заявка към картата - която така и така не трябва да се извършва докато текущата не е завършила. Всичко останало си въреи. Ако имам нужда да обера пак данни - обирам си ги. Ако имам прекъсванета от сериен порт или там нещо друго - правя си ги. Просто нишки с различен приоритет и това е.

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

Ето го и устройството - за което говорим: http://vbox7.com/play:f4da76a3
Малко е етно - ама какво да се прави - клиенти.

В подробности аз не се и опитвам... но като цяло концепцията е много.. как да го кажа по-меко... Абе ще е добре да видиш и другият начин, за да си прецениш ти сам

Лошото е, че наистина има коренна и принципна разлика между твоят начин и другият начин. Тук и 100 човека да ти кажем че не се прави така и си има много причини да не се прави така, докато не пробваш и другия вариант няма да стане...

Ако решиш някога да правиш редизайн, пиши - ще коментираме

Ами отворен съм за другия начин. Аз по добър от тоя не можах да измисля.

А и все още не съм разбрал какво му е лошото на този. Може би това ще ме накара да премина на "другия".

А иначе - по темата - щот начина ми е толкова лош - а тоя процесор все пак се оправя - значи - "Това е Процесора!"

Абе нишки, пи*ки вече ти казах, че коцепцията ти на писане и разбиране е явно като на PC!
Хубаво би било да се поогледаш и да проумее за какво иде реч.
Иначе бъди сигурен, че ще те подкрепяме!

Нещо не мога да разбера къде точно бъркам.

Смята ли това нещо поразлично когато е в прекъсване и когато е извън каквото и да е прекъсване? Предполагам, че смята еднакво...

Да опростим нещата за проба.
хронометръ - който увеличава променлива на 1 секунда.

1. Имаме си код - който се точи в главния цикъл някакъв.
2. Имаме си едно прекъсване - което става на всяка секунда - и трае много кратко - щото е по принцип е лошо да сме в прекъсване дълго време.
Това е ПРАВИЛНА постановка - нали?

Сега - усложняваме малко нещата...

1. Имаме код - който се изпълнява в главния цикъл - кода е само един безкраен цикъл - без нищо вътре.
2. Имаме едно нископриоритетно прекъсване, което се активира от таймер примерно - и в него кода е същия като един цикъл от предния пример.
3. Имаме едно високоприоритетно прекъсване - което става на всяка секунда - и трае много кратко - щото е по принцип е лошо да сме в прекъсване дълго време.

Това каква постановка е - правилна или неправилна?
Реално е като предната - ама отместена с едно ниво на горе - поне според мене.

Абе ти тези прекъсвания ги нямаш за нищо!
Не ти трябва прекъсване за текуща задачка. Вземи научи и ползвай FreeRTOS примерно!
Изобщо си за чат, защото доста постове ще отнесе една евентуално нова тема с този въпрос!
То и трябва да се отдели и време за това!

P.S. А ти случайно да се сдоби с дебъгер?

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

А и за какво ми е дебъгер? В моя код бъгове няма!!!

Относно операционните системи - мисля, че проекта не е чак толкова сложен, че да се налага да прибягвам до такова нещо, а и малко ми е неловко да ползвам код, който не съм писъл аз. Така знам винаги кой е виновен - ако нещата не стават...

Освен това - не мисля че ОС ще ми донесе по-голяма производителност - най-вероятно повече проблеми...

Край на спама по темата!

Ей, много си самонадеян! Като гледам снимката на сайта ти не ми изглеждаш 20 годишен! Вече трябва повече мъдрост да вкарваш(така си мисля де)!

Кефиш пич
И не се връзвай да те набутат с някакъв ОС и концепции Карай си bare metal нищо че си етно настроен

Много неща, но така казано сигурно нищо не ти говори...

По принцип твоят стил е тип OS-less. Не защото не ползваш OS, а защото начинът ти на мислене е "правя това, после правя това..".

Другият начин е да използваш многозадачност. Едната задача се грижи за това, друга за онова... Не мислиш коя задача след коя ще се изпълнява, защото в съзнанието ти те трябва да се изпълняват паралелно. А на практика ще се изпълняват почти паралелно, стига да не циклиш някъде в очакване на Годо, особено пък в прекъсвания

Проблемът освен концептуален е и чисто практически, понеже архитектурата на проца е предвидена за многозадачност. Затова хората слагат ДМА-та, бъс матрици и чудеса, че да стават по няколко неща едновременно. Перифериите са така направени, че да не се налага да ги "дебнеш". В случая не знам как е при ST, но при другите или има достатъчно fifo или ДМА-то е с двойно буфериране. Така всяка периферия може да си бачка на 100% натоварване, без да спира и без да се налага процесорът да й робува. Достатъчно е просто в някакво време да получи само малко внимание
То по друг начин просто няма как да подкараш 10-15 периферии, колкото има един чип от тоя клас.
Още веднъж забележи разликата - не ти с процесора да чакаш някаква периферия, а периферията да може да те чака теб да й обърнеш внимание като й обслужиш прекъсването. Не забравяй, че имаш много периферии и прекъсванията трябва да могат да валят постоянно. Не бива да ги блокираш допълнително, щото те не могат да чакат много. Те достатъчно се блокират взаимно и всичко е разчетено за разумно забавяне. Никой няма да ти сложи излишни буфери

Изобщо всичко е предвидено за RMA (Rate-Monotonic Algorithm), който е добре да прегледаш. Няма как иначе да разбереш защо приоритет е = честота, а не "важност".

Сега конкретно за твойта постановка... Имаш аудио, доколкото разбрах клатиш DAC през I2S - туй ти е една задача, която ще се грижи да държи I2S-а сит като го храни от някакъв буфер.
Тоя буфер ще се пълни от друга задача, която да кажем ти е смесител. Задачата от смесителя на входа си трябва да има 8 буфера или колкото там канала имаш. Сега каналите може да са 8 отделни задачи или една обща. Предполагам заради обработката по лесно ще стане една задачка за канал, която си чете от SDIO драйвера и си обратва данните.

Тук въпросът е в терминологията - под "задачка" имам предвид таск/нишка. В прекъсване не можеш да направиш задачка, защото то е блокиращо. Още веднъж - задачките трябва да се изпълняват паралелно... Не е задължително да ползваш ОС, но по-добре е да не се мъчиш Дори и да вземеш калпав ОС, пак най-вероятно ще постигнеш по-добри резултати