@juzisound, не само че бързаш ами май нещо ни пързаляш

Освен ако ST не са омазали нещо ситуацията дето описваш граничи с абсурдното... Поне при атмел най-бързата периферия е hi speed multimedia controler-а... Бърз, бърз ама колко да е бърз? По памет бачкаше до 50-60MHz и хвърля 4 бита/на клок демек около 200Mbit/s. Само че ти трябват 8 такива периферии че натовариш паметта на 100%, т.е. 8 парчета по 4 бит = 32 бит трансфер на клок...

Само дето няма 8 мултимедии... а другите 20 периферии дето имат ДМА-та взето заедно трудно ще докарат колкото една мултимедия... Или в най-добрия случай всички периферии пуснати на шест, ще натоварят с 10-20% трафика към паметта.

А 10-20% винаги има свободни, щото ядрото си има отделни шини и освен ако не циклиш load/store няма как да стане. Всъщност може, ако си тръгнал да изпълянваш код от паметта, ама това си е също безумие

Ами ако ВИ пързалям - значи и аз се пързалям... - което е напълно възможно де.

За какво става въпрос:
Аз ползвам SDIO модула - който го има само в този модел процесор. Той работи на 24мХз и чете сектори от картата - по 512 байта.
Четенето става в няколко различни двойни буфера - примерно 8. Двойни - защото от едната част на буфера процесора вади данни - байт по байт, а в другата - ДМА контролера слага данните които пристигат от SDIO модула.

При честота 48кХз - каквато ползвам - успявам да ползвам до 8 такива процеса едновременно. Това ще рече че чета от картата 8 потока от по 96000 байта в секунда всеки и ги пиша в рама. Отделно от това чета от рама други 8 потока - пак със същата скорост, миксирам ги и ги пращам по I2S навън. Естествено правя и други неща - ама това е основното. До 8 процеса - добре. От там нататък - вече не става. Проблема е, според мене де - че броя на обръщенията към рама става огромен. Обръщенията са по принцип 2 вида - на процесора - за четене - кратки и чести, и на ДМА-то - за писане в рама - по-редки, но по-дълги. Та при голямо натоварване става така, че се налага да се изчакват.

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

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



Нищо не пречи да бъркам някъде де - ама за сега така мисля.

Виж сега... сметката е проста. В най-добрия случай твоите 8 потока са ти 1MB/s, това към паметта е нищо и половина. На колко ти бачка проца? На 24 или 48 МHz? В единия случай имаш 100 в другия 200MB/s. Как точно с 1-2% натоварване успяваш да задръстиш системата ?

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

На теория има и друг вариант, ама не вярвам ST чак такава простотия да са направили.... Куртекс ядрото е с 3 шини от тях две са важните - едната за код, другата за данни. Ако са ги обединили двете смятай че са спънали коня отвсякъде, защото няма кеш и само извличането на код натоварва до към 100%. Ако и арбитрацията им е кофти с тия трансфери байт по байт наистина и от малко камъче ще обърнеш каруцата. Но пак казвам, *не вярвам* да са направили такава простотия...
Обикновено се прави друго - две AHB шини, едната за флаша другата за RAM и ядрото няма грижи. Обаче всякакви външни мастери остават леко хвърчащи.... Става супер сложно един мастер да се арбитрира към две шини. При Луминари е така и те за по-просто са направили ДМА да бачкат само с едната шина, демек не може да пуснеш ДМА от флаш.

Тъй като са замисля може би не е чудно ако ST наистина са обединили двете шини, като ми остане време ще ги прегледам... Иначе аз затова казвам че само Атмел знаят кво правят. Куртекса им е една шина ама 4 layers, демек 4 мастера могат едновременно да бачкат с различни слейвове. Такава шина няма задръстване, въпреки че са 20+ ДМА-та...

Процесора работи на 73.728 MHz - щото само така мога да получа точно 48000 и да остана на честота най близка до 72 MHz.

Ето я организацията на STM32

От схемата се вижда, че:
1. за да стигнат данни от SDIO до SRAM трябва да се мине през BUS MATRIX, като инициатор и мастер на трансфера е DMA2.
2. за да може ядрото да извлече данни от SRAM, данните пак трябва да минат през BUS MATRIX, като мастер на шината тогава е ядрото.

До колкото аз го разбирам - BUS MATRIX не може ЕДНОВРЕМЕННО да работи с 2 мастера. Да!!! Има 4 възможни мастера - обаче винаги работи само единия от тях - като има арбитриране по Round Robin схема, която гарантира, че никой от мастерите няма да заеме цялата шина и да запецне напълно останалите.

Отделно от това - ядрото по същото време основно чете и от време на време пише данни в куп други променливи - като явно достъпа до тях пак става през тоя BUS MATRIX, което няма как да се пренебрегне. Никъде не успях да намеря точно колко е пропускателната способност на BUS MATRIX ама не виждам що да не може да се задръсти от описания трансфер. Надявам се да не съм прав де - щото така ще има много път за оптимизации.

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

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

Какви данни вървят по ICODE? Вземи малко поразсъждавай, и прочети за AHB и APB шините! В случая AHB шината е Lite и е Single master. Там вървят паралелно адрес и данни и е на честотата на ядрото. Навързани към нея през Bus Matrix са флаша рама и DMA. Докато APB1 и APB2 са с последователно предаване на адрес и данни, съответно на половината и на честотата на ядрото. Към тях са навързани перифериите. Изхождайки:) от това, вече може да се правят съответните изводи.

Знаех си аз - че има разбирачи тука.
Да разбирам, че по ICode вървят само инструкции, а ако чета данни от флаша - ще се върнат в ядрото по DCode? Така ли?
Ако може малко по-подробно, че вече почвам да се заплитам - ама яко.
Чопли ме и един друг въпрос - защо SDIO е вързано там дето е вързано - направо на AHB? То не е ли и то периферия?

Картинката е много подвеждаща и трябва да се провери. По принцип "bus matrix" е матрица позволяваща повече от един канал едновременно (естествено различен мастер и различен слейв). Но ако беше истинска матрица ICode и флаша няма логика да са отделно.. Тъй че най-вероятно си е прост мултиплексор и както казваш

Така стигаме до варианта с двете шини - ICode <> флаш и матричката с DCode/System/DMA<> RAM/AHB... Подобно е и при Луминари.
Но това не обяснява твоите проблеми, защото ядрото не натоварва RAM повече от 50-60%, а ти повече от 1%




Шините винаги са синхронни спрямо ядрото
Честотата на която бачкат е кратна на системната и не по-висока от най-бързите мастер и слейв. Демек виж колко бърза е RAM, ако тя може да бачка без wait states значи бъс матричката трябва да е на 72MHz. Ако не, значи си на 36MHz.






Не го мисли това... Иначе буферите на флаша са заради бавния достъп, но и ядрото е предвидено за това и то също си има prefetch buffer.
Буферите на флаша служат са по-бърз prefetch, но за данните нямат ефект (освен ако не четеш с load multiple).
Проблемът в случая не е в конфликта, а в забавянето на данните, щото като се вкарат wait states се блокира конвейра, съответно той не иска prefetch (прекалено къс е).
С други думи ако сложиш два флаша - един за данни и един за код - скоростта няма да се вдигне изобщо, въпреки че няма да имаш конфликт.

Проблемът с конфликтите се появява при бързите памети. Тогава статистически една шина би се натоварила някъде 120-130%. Само кодът ако е поредица от 32-бит инструкции ще ти е 100%.
Просто ядрото затова е с отделни шини, защото има възможност да обработва по една инструкция и по един даннов трансфер на клок. Разбира се двете не винаги се случват едновременно. Голяма част от инструкциите са 16 бит, т.е. един prefetch на два клока и голяма част от инструкциите не са load/store...

По принцип да... но не забравяй, че в самото ядро има бъс мултиплексор
Иначе да, ICode е за инструкции, но както забелязваш тя не е вързана към RAM и ако го нямаше мултиплексора в ядрото нямаше да можеш да изпълняваш код от RAM на това ST



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

А за SDIO явно са преценили че е бързо, ама пак ти казвам - бързо, бързо - колко да е бързо

juzisound, пич от къде изрови тази картинка, че и я коментираш?!
Ето ти за твоя случай картинки:

Е как от де?

RM0008 Reference manual - страница 41.

Изтегли си RM за "Medium-density performance line" и зяпай там ! Контролера ти трябва да е STM32F103RB
Medium-density performance line:
http://www.st.com/stonline/products/lit ... /13587.pdf

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

Аааа - не е тоя!

Процесора е STM32F103RET6 - ама то все тая. И това дето даваш линк са спецификациите - а не документацията. Тя е един друг доста по-обемист файл.

Относно софтуерните проблеми - ами преди това правех същата постановка с един dsPIC 30Fxxxx който го дават около 30MIPS.
С него същата горе долу постановка работеше с максимум 2 потока от тия дето описах преди малко.

Тоя STM32 е с производителност 90 MIPS - и ми изглежда нормално да може да се справи с 8 потока. Не трябва сякаш да очаквам много повече от него.

Ми, сори! Ама ти ме вкара в заблуждение, защото в пост от предната страница си дал линк на кит с STM32F103RB струва ми се!?

@juzisound,

Стига, тия "потоци" са ти 1 MB/s и ако наистина ги прехвърляш на сектори от 512 байта с DMA са точно едно нищо...

Търси къде бъркаш в софтуера Сигурно нещо като превключваш задачките не е както трябва...

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

Сложна е тя мойта - а как добре си беше с пиковете