Оптимизацията е ясна - смяна на приоритетите. Математиката винаги е с по-нисък приоритет от хардуера. Като игнорираш прекъсванията почти нищо не пестиш ,защото те се обработват много бързо (поне така трябва да е).
Колко са ти тия таблични данни, не може ли да си сложиш по-бърза памет? Записал си данните за да не губиш време да ги смяташ, но губиш време да ги зареждаш - къде е ползата от файдата?.

ех, много - много, колко да е много? Не е повече от 66% вЕрвай ми

Като си оправиш алгоритъма ще може да изстискаш още около 30% usage, което реално си е към 50% повече спрямо сегашното (към 12 потока)...
Другото е да оптимизираш кода за математиката.... ако може, но предполагам че ще може

Пак не си съвсем прав, един буфер е разделен на две и фактически са си 2 буфера, както казваш, но харчиш само един DMA канал при такава организация ! Погледнато от страна на DMA канала той си няма представа, че ти логически разделяш буфера на две.



DMA-то няма как да ме гони, защото за да почне CPU-то някаква обработка, то трябва да има данни от DMA-то. А като стигне CPU-то края на буфера съм го описал много ясно какво става: DMA-то само се прехвърля ( без намеса от рода на прекъсване, вдигане на флаг и т.н. ) след като достигне края на буфера в началото му, т.е. то непрекъснато върти в този буфер без да спира. Така че докато CPU-то достигне началото на втората половина на буфера, DMA-то е вече в първата. Естествено тази логика работи ако обработката на CPU-то на половин буфер е много по-бърза отколкото трансфера на DMA-то на половин буфер, което при мен е спазено. Аз също чета от SD карта, през FAT32, изходния sample rate e 78кHz,
това е за mono, за stereo имам заделен още един DMA канал, който върши същото. Така с два DMA канала реализирам това, което на други процесори, като Куртекс например , ще стане с 4-ри DMA канала. Практически от налични 8 DMA канала използвам 2 и имам налични още 6 DMA, които за момента няма за какво да ги използвам.

Както и да е, това не касае темата, нито проблема на juzisound Сега на всички ни е ясно какво точно прави, използва процесора на макс, и никакви ОС-та няма да помогнат да го разтовари, напротив ще загрузят още повече пейзажа

хехе, ти уби всичко детско в мен




Абе ПИК са голяма работа, някой ден като ти остане време ще вземеш да ми ги обясниш по-подробно, че да минавам на тях направо

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

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

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

Пи, похватът се нарича "двойно буфериране" (double buffering) и се ползва широко от десетилетия.

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

От описанието дето си дал на това как го правиш не става ясно как процесорът ти разбира
кога DMA-то напълва първия буфер (първата половина) та да може да се захване с нея
(втората айде ясно, заедно със зациклянето ще цъкне и нещо и т.н.). Или просто гледаш
адресния регистър на DMA-то? При тия ниски скорости това май си е съвсем практичен
вариант всъщност.

Първо за ST-тата - ми процесори като всички други. Имат си бъгове (горе долу прилично документирани), имат си и "бъгове" които по неизвестни причини пройзводителя смята за "особенности" Като например това че SPI мастер не ще автоматично да драйви -CS пина. И трябва да го кандилкаш на ръка и цялата ти DMA автоматика отива по дяволите в някои случаи. Или пък да правиш чудеса от геройство с таймери и прочие дивотии. Но според пройзводителя, това си било нормално, чудно що сме очаквали нещо друго. Това, че при STR9 си се кандилка самичко не е от значение, явно там е нормално да е така, а тук е нормално да е онака....Друга подобна "особенност", е че UART-а няма сигнализация при определено време без данни, нещо което почти всички други процесори от класа имат. Може да се заобиколи, не е да не може - ама що бе джанъм?

Относно ADC - то аз не съм имал проблеми. Като цяло това е контролер мислен наистина от добри инженери. И то наиситна инженери. Аз не съм виждал толкова мощна ADC система в процесор от такъв клас. Таймерите му също са навързани в адски гъвкава система. Въобще мислено си е от хора които са имали конретни проблеми и задачи и са търсили решение за тях. Изпълнението след това е друга тема....

Не могат на 100Мхз.... На мен не са ми потрябвали засега ама върти, сучи, това си е 25% пройзводителност повече при конкуренцията.

Аз NXP съм ползвал само от старите ARM7 и не ме кефят много. Периферията им е що годе добра (ама що годе), обаче пиновете са наистина много неграмотно намятани. ATMEL съм се отказал да ги чакам, а от краварските ... де да си бяха краварски изначало. И си бачкам с ST. Хубави-лоши.... то хубав процесор на пазара НЯМА от времето когато процесорите се означаваха с 4 цифри и думичката "ерата" не ми беше позната!

Относно проблема на juzisound.... Бе аз едно не мога да разбера - като имаш проблеми с недостиг на ресурс, има доста начини човек да провери, къде аджеба му се губи ресурса. Щото и да му предлагате OS, без OS, то нещата са си свеждат до прости числа. Има едни трансфери и едни обработки. Ако се окаже, че обработките са му прекалено тегави, каквото и да дроби, каквито и нишки и прекъсвания да плете - все тая. Като оставим настрана факта, че човека работи с АРМ без дебъгер, нещо само по себе си много странно за мен, да разклати там няколко пина и да види, кой аджеба му яде ресурса.

То той проблем няма Устройството му работи. Спора май е само академичен




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


Обаче, бях пропуснал това.


Къде това ? Ревизия B1 имат в ерратата описани няколко ситуации, при което могат да влезнат в latch-up. Ако Vusb се подаде преди захранването и други подобни. Изчистено е в С ревизия. За това ли става дума ?

Не е това... USB няма нищо общо... на кита им с големия дисплей, закачаш дебъг кабел с ресет бутонче, цъкаш няколко пъти и е готово Видимо процесора работи, даже той си тръгва с някакъв тетрис и може да си играеш, ама процесорът пари ще ти изгори пръстите
За щастие на наши платки не можахме да го възпроизведем, тъй че не съм се ровил повече. Но и без това консумацията е меко казана висока, на старите ревизии тръгваше с 60-70мА и колкото да го мъчиш не пада много. В ревизия C1 малко я оправиха (10-15 мА) но пък с тоя патч във флаша направо избиха рибата. Но С1 се оказа по-капризна на тема захранване, ние имаме повечко кондензатори на входа но с Bx си бачкаше. Като минахме на С1 и почна да се държи супер нестабилно, тръгва когато си иска... Изправихме фронта и се оправиха нещата.
Сега преди няколко дена пробвахме С3 и "изненада" още по-нестабилно.... Само че захранването няма накъде повече да го оправяме, може и друго нещо да му е проблема, но е факт че на платки дето старите ревизии бачкат новите не щат.
Просто едно оправят друго развалят Сякаш сега се учат А за дизайна да не говорим, разхвърляни периферии, регистри... каша! В тая тема досега коментирахме ДМА, тия сложили супер сложни ДМА-та със scatter-gather и какви ли не чудеса, обаче само за управлението и таблици искат 1KB, абсолютно разхищение. На всичкото отгоре не поддържат трансфер от флаша. А това са ДМА прикачени към периферии. Аз правя драйвери и кво да правя в драйвера? Да проверявам дали адреса ми е от флаша и да решавам дали да ползвам ДМА или? И прекъсванията на ДМА-та са една оза...

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

То имаше 3-4 такива ситуации, дето могат да прадизвикат lach, това с усб-то беше само едно от нещата. Платката с големия телевизор я имам, но тоя ефект не съм го налюдавал. DK-LM3S9B96 имам по-точно.

В С3 разкарали ли са пача от флаша? Между другото, не го знам какво точно прави това чудо, на няколко процесора съм го изтрил и не забелязвам странични ефекти..

А, щях да питам още - в прекъсването за DMA error какво трябва да се направи ? И доколко е вероятно то да се случи? При мен досега не се е получавало нито веднъж, при всичките ми експерименти.

П.С. Ти пък казваш, че продължава да работи, само дето грее. Значи не е описания latch-up, ами нешо друго

Разкаран е...

А ДМА-тата аз ги разкарах, защото не ми се занимава с глупости

Миро, а външен чип за ресет имаш ли в твоя хардуер?



При мен има, и тръгва стабилно всеки път. Дори не бях забелязъл тоя пункт от ерратата досега А уж гледам да я чета подробно :-S Със сигурност е по-важна от data-shit-a

Тъй, за всички дето ще минават на Ц3 да не се шашкат ако чипът изобщо не тръгва

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

Значи, всеки чип с дебъг интерфейс (JTAG/SWD/BDM) си има 2 ресета, един за дебъга, друг за ядрото... И всеки емулатор като усети захранване първо си ресетва дебъг интерфейса и после ресетва кура (освен ако не прави attach to runnung target). При JTAG ресета се казва TRST, a системния ресет e SRST. На дебъг конектора може да е изведен единия, другия, двата или нито един. Това няма значение, защото винаги има начин дебъг емулатора да прави и двата ресета при това да ги прави *независимо* един от друг.

При Ц3-ката обаче са решили че нама нужда да са независими... И вързали TSRT към SRST. Просто гениална идея Всеки път когато направиш ресет на ядрото, се ресетва дебъг интерфейса и емулатора се отсвирва... Айде в JTAG режим отсвирването само води до единична грешка, ама в SWD се губи сесията и отсвирването е фатално...

Та чипът не бачкаше, щото моят емулатор се конектва след това бичи ресет на ядрото, уж за да почне на чисто... но това ресетва и дебъга и отсвирва емулатора. Всеки опит да се направи софтуерен ресет чрез SySCtlReset (VECTRST), watchdog и т.н. задължително бие шута на емулатора.

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

Е да де, но в JTAG-lock-pick хората са отчели тази работа и са разделили двата ресета!
Сега друг е въпроса дали и как се използва?!