juzisound, поздравления за продукта, който си създал. Браво.





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

Какво блокирват прекъсванията - процесора или ДМА-та?
juzisound май иска да каже ,че тъй като за обработката му трябва цялото процесорно време няма значение дали ще е в прекъсване, така или иначе той за други нишки не ще да дава ресурс. Просто прекъсването му гарантира ,че никой няма да му яде време от критичната обработка. Но може би грешката му е ,че си мисли ,че му трябва цялото процесорно време ,а то може и да му е в излишък, но "неуплътнено".

Уж да не продължавам дискусията - ама ме сърби да кажа...

Ясно че прекъсванията са блокиращи. Този им недостатък, обаче може да се ползва и като предимство. На мене точно такива ми трябват!

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

Сега: Изхождайки от тук - аз имам нужда от 3 вида - да ги наречем "нишки".

1. Една - абсолютно НЕ ВАЖНА - която да се изпълнява - само докато няма какво друго да се прави. Това ми е главната програма - екран, индикации и т.н.

2. Няколко нишки - които ТРЯБВА да се изпълняват БЛОКИРАЩО една спрямо друга - и когато те имат работа, трябва НАПЪЛНО да блокират нишката по точка 1. Това са ми няколкото прекъсвания с еднакъв приоритет - за четене от картата. Пак да кажа - те ТРЯБВА да се изпълняват една след друга И ДА БЛОКИРАТ основната нишка ако имат някаква работа. Не трябва да могат да вървят паралелно. Една след друга - това е!

3. Нишка с най-голям приоритет - която се изпълнява на определено време - и като и дойде времето тя трябва да БЛОКИРА ВСИЧКО ОСТАНАЛО по точка 1 и 2, и да си върши нейната работа.

Чудейки се това как да стане - то направо си реве за реализация с прекъсвания - щото те като им нагласиш приоритета, вече сами и най-хубавото - ХАРДУЕРНО - се сечат едно спрямо друго - без никакъв софтуер. Все едно имам хардуерно менажиране на тасковете и то точно от типа който ми трябва. Хардуерен ОС!

За пояснение само - работата на нишките по точка 2 е - да дадат заявка за четене от картата. Това е малко парче код. От там нататък - самото четене става НАПЪЛНО хардуерно - като SDIO модула се разправя с картата - а DMA-то се разправя с прехвърлянето на данните от SDIO модула в SDRAM-а. Всичкото това става НАПЪЛНО ХАРДУЕРНО и ЕДНОВРЕМЕННО с изпълнението на оная най-важната нишка от точка 3. Тя уж по някое време ще е блокирала нишките по точка 2 - ама те реално не могат да бъдат блокирани - защото не са софтуер а хардуер. Сладка работа...

Отделно от това - четене от картата се налага - само ако оная главната нишка иска данни. - тоест свири се в момента. Ако тя иска данни - само вдига флага на някое от прекъсванията по точка 2 което отговаря за пълненето на съответния буфер - и това прекъсване се случва ВЕДНАГА и САМО!!! щом най-важната нишка си свърши работата. Ключовата дума е САМО. Аз не проверявам има ли нужда от данни - трябва ли да пълня буфери и т.н. Те сами си се оправят...

Ясно е, че всичко това може да се реализира по различни начини - въпроса е дали ще е е по-ефективно от това...

Значи алгоритъмът му е:

1) Разрешава 8 прекъсвания, които са с равен приоритет
2) Прекъсванията започват да се викат едно по едно.
3) Във всяко прекъсване пуска и чака по 1 трансфер.

Дотук не е ясно с колко буфера на канал бачка. В смисъл ако е по един е ясно - задейства всичките канали като всеки прави трансфер и спира (самозабранява си прекъсването)
Ако са по два и повече буфера на канал не е ясен редът. В смисъл влиза първото прекъсване, пълни един буфер и после кво? Продължава със следващите буферчета, докато се напълни всичко за тоя канал? Или като направи един трансфер се изключва, за да даде възможност на всички останали канали да напълнят по един буфер - това е по-логичното...


На фона на това през фиксарано време (таймер?) се задейства по-високо прекъсване, което обработва данните и след като освободи буферче разрешава съответния канал.

Сега проблемите:
1) В даден момент тече само 1 трансфер. Това не е проблем, просто го отбелязвам
2) Между трансферите ще има паузи предполагам, защото след като свърши 1 трансфер, той трябва да излезе от прекъсване, да влезе в друго, там да зареди ДМА и т.н. Не знам ST дали имат двойно буфериране, но ако имат би трябвало да се използва, така че да няма "дупки".
3)След като се стартира обработката, докато тя не приключи не може да се пусне нов трансфер. Ако има пуснат той ще завърши, но нов няма да почне.
Сега ако обработката натовари с 50% ЦПУ-то, то през 50% от времето няма да може да пусне трансфер. Много тъпо.. Идеята на ДМА е да не изискват ЦПУ и да работят паралелно с него. Демек да може през 99% от времето да си правиш сметките и в същото време трансфера да върви на 100%.
В случая алгоритъмът е такъв, че ако сметките натоварят на 99%, то трансфера ще падне на 1% (ще умре тотално).


Правилният алгоритъм е:

1) Обработката става с най-нисък приоритет!! Тогава може да си остане в прекъсване (таймера).
2) Трансферите трябва да с по-висок приоритет и да не блокират. В случая не знам как го правиш с 8 прекъсвания като периферията е една... Едно прекъсване за трансфери е напълно достатъчно

Нормалната практика е за трансфера да се ползва прекъсване, което се задейства при "idle" на периферията. Когато се освободи някой буфер, прекъсването се разрешава, без да се интересуваш дали вече не е разрешено.
Като влезеш в прекъсването проверяваш дали току-що има приключен трансфер, ако да - маркираш буфера. При всички случаи накрая проверяваш дали може да се пусне, ако можеш пускаш, ако не може се самозабраняваш като прекъсване. Но в никакъв случай не блокираш в това прекъсване

@juzisound, на колко клокваш SD картата?
Предполагам че е на 36, 24 или 18 MHz?

което ще рече съответно 4, 3 или ~2MB/s теоретичен трансфер, a ти умираш на около 1MB/s.

Така че, ако клокваш на 36MHz значи сметките ти са на 75% CPU usage и може да подобриш с около 25%.
Ако клокваш с 24 значи имаш 66% usage. При 18МHz си на 50% usage и ще можеш да го вдигнеш двойно...

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

В частния OS-less случай на juzisound, високо приоритетното прекъсване идва на точно определени интервали(20.83(3) us -> 48kHz). Т.е timeslice за тази задача е точно определен и фиксиран още при проектирането на системата и не се променя динамично. На всеки 20.83(3) us прекъсването за трансфер към ЦАП-а идва изяжда си своята порция време и каквото остане до следващото му появяване е за останалите задачи. На следващото по приоритет ниво, където са 8-те "потока", трансферите се движат след високоприоритетната задача, така го разбрах аз ето от тук:

Т.е. 8-те потока се движат в синхрон с "главната" високоприоритетна задача за зареждането на ЦАП-а.
Задачите на juzisound не са асинхронни и timeslice-овете им са определими още при проектиране на системата.
Ако имаше възможност обработката да става в най-ниско приоритетната нишка, като данните от 8-те потока се смилат и се пълнят в буфер от който по прекъсването с най-висок приоритет само се взимат данни и се пращат към ЦАП-а тогава може да се направи реорганизацията, която предлагаш Миро. Но по-нагоре, всъщност ето тук:

човека си казва че не може да буферира. Може би няма памет достатъчно ли незнам.

Не ме кефите нещо. Juzisound направил джаджа, свири... а го засипвате с "не се прави така", "грешно е така"... Със сигурност има бели петна по познаването на апаратната част. Например това дето FLASH-а нямал директна адресация ме изкърти. Но оставете една нишичка моля и за нас, хората с OS-less мислене.

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

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

Та хубаво, малко, просто, ефективно и универсално решение няма. Всичко зависи според случая.

В нашите сензорчета само на батерии, с процесори с по 32кб флаш и 4кб рам - няма място за РТОС - нито от към памет, нито от към консумация на батерията. Та най-доброто решение е "къстъм" решение, подобно на дискутираното тука. Когато говорим за много бройки - струва си човек да си губи времето с "къстъм" изпълнения. За единични и бутикови бройки без особоенни изисквания - ползваш най-познатото ти универсално решение ...

Мисля, че работи с по един буфер на канал, така го разбирам. Използва DMA каналите за автоматично мултиплексиране на SDIO модула. Например, нека на нишката от т.3 й трябват данни за буфер N, тогава вдига бита за DMA канала N, който си е вече настроен с адреса на източника и приемника на данни, колко байта ще прочете, подредба някаква ( младши-старши ) и канала започва на следващия наличен цикъл да чете данни през SDIO модула. Същевременно, докато все още не е приключил DMA канал N, нишката от т.3 има нужда от данни за буфер M, тогава от прекъсването на нишката от т.3 разрешава трансфера на данни от DMA канал M, но тъй като SDIO модула е вече "заптисан" от DMA канал N, DMA канал М, ще чака да свърши 1-во трансфера по N, и едва тогава ще се стартира автоматично неговия трансфер. Понеже не се знае и няма подредба някаква кога какви буфери да са пълни, няма как да се кешира нещо, всичко се прави на момента. Предполагам, че DMA каналите са в режим с автоматично презареждане, така че не му се налага да зарежда адреси, броячи, подредби и т.н. Когато дойде прекъсването от т.3 се проверява дали е приключил трансфера от дадения DMA канал и ако е се прави обработката. Какво става обаче, ако не е приключил не е ясно.

Постановката му ми се вижда доста читаво направено. Все пак ако иска да изтиска всичко от хардуера ОС не би помогнал особено, по-скоро ще забави нещата. Може да ги направи ( ОС-то ) по читаеми и разбираеми за поддръжка, но надали ще забърза трансферите.

Не знам дали за SD картите важи дефрагментацията, както е при дисковете.

Възможно е... но при 1 буфер не може да четеше и пишеш едновременно. Докато не свърши четене не пускаш писане, защото ако ДМА е бързо (а то е) ще настигне и ще напише нови данни преди да си обработил старите.

А цялата тая разправия започна с твърдението, че човека чете и пише едновременно и ДМА-то му блокирало процесора и BUS matrix и дрън-дрън

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

Примерно правил съм следното ( на PIC32 ): пускам DMA-то да пълни, когато напълни половината от буфера ми вдига флаг, който може да дойде на прекъсване или просто да се полира в главнатата програма, тогава без никакви притеснения си обработвам първата половина, докато я обработвам DMA-то вече пълни втората, при напълване на втората пак ми вдига флаг и минавам на обработка на втората, DMA-то през това време само си превключва и започва да ми пълни първата половина на буфера. Така не го чакам да ми трансферира целия буфер и се получава едно препокриване като непрекъснато се гоним.

Другата възможност при PIC32 е да следиш чрез полиране на DMA канала брояча на трансферирани байтове, така преценяваш дали може CPU-то да започне работа. Но това са все други варианти, които може и да не се приложими при Куртексa. Ако няма може да се реализира с 2 DMA канала.

Абе Пирев, кого се опитваш да излъжеш

Един буфер разделен на две са си два буфера!

А туй с полирането на брояча може да излъжеш ПИК, ама по принцип на другите процесори не става.... Щото докато "гониш" ДМА указателя си ОК, ама като стигнеш края на буфера и преместиш ДМА-то да те гони теб става весело

Малко да разсея неяснотите.

Първо - буферите са по 2 за всеки от осемте канала. От единия чета - в другия очаквам ДМА-то да пълни.
Не може да се полват повече буфери - по следната причина:
Един буфер ми е 512 байта - или 256 семпъла - 16 битови. Тоест един буфер ми стига да свиря от него малко над 5 милисекунди. А иначе го зареждам за около 350 микросекунди. Сега - защо не може повече буфери - ами не може - защото това е музикален инструмент. Какво ще ми трябва като данни - зависи от оня дето свири. А той за 5 милисекунди може да изсвири 5 различни тона. Това според спецификацията на МИДИ-то. За какво ми е да зареждам бъдещи данни - като незнам дали оня дето свири няма да натисне друг клавиш - и всичките тия данни дето съм заредил да ми станат изведнъж излишни. Е това е причината - за да не се зареждат ненужни данни - винаги се пълни само по един буфер. Не може да се направи и някакво кеширане свястно - щото пък данните имат голямо текучество. Тоест няма как да помня част от някакъв тон - дето може да ми потрябва - ама може и да не ми потрябва - щото данните вървят много бързо и прочетените много бързо остаряват.

Картата - тоест SDIO модула работи на 24.5 МХз, щото процесора е на 73.728 МХз.

SDIO модула не може да прави повече от един трансфер по едно и също време.

ФАТ таблица няма. На картата има спецялно наредена информация - и си я търся по сектори - поради скоростта разбира се. Това е най-бързия начин.

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

Тясното място и на мене ми е ясно вече.
Процесора е МНОГО натоварен от към сметки - особено когато се свирят всичките 8 тона. Има 8 линейни интерполации с усложнения разни. Отделно какво ли още не - и му става зор. Тогава седи много в нишка 3 - и наистина не може да се стартират адекватно процесите по пълненето на буферите.

miro_atc го е казал много точно: "След като се стартира обработката, докато тя не приключи не може да се пусне нов трансфер. Ако има пуснат той ще завърши, но нов няма да почне. "

В моемента мисля над начин да оптимизирам това място.

Колко пъти - то много неясноти станаха ?

А той juzisound го е написал:

Има двойно буфериране

EDIT: А, докато съм писал е имало пояснение