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

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

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

Миро, важно е и какво е приложението, и какви са данните.
Методът с DMA и таймаут е удобен, ако всяко съобщение е отделен пакет и от тебе се иска да отговаряш някак си на всяко входно съобщение ( ако ще и един NACK да е ). Така отсрещната страна няма да предаде второ съобщение, докато не получи отговор на първото. Проблем има и ако поради комуникационни проблеми съобщението се прекъсне донякъде и след време > от таймаута продължи. Допълнително усложняване е, ако "от пръв поглед" не е ясно къде почва и къде свършва едно съобщение. Преди години много му сърбахме л****та на това ( ставаше дума за едни терминали ).
В моя случай входните команди може да са непрекъснат поток и е добре да се изпълняват веднага, след като се получат. Данните ми идват с 38400 bps и 7 500 прекъсвания в секунда ( max ) са поносими според мен. Периодично FIFO буферите на полиране се обработват - сглабят се отделни съобщения и се парсват някак си.
Има и реализация само с DMA без прекъсване от таймаут, пак с полиране на буферите. Даже първо го бях направил така, ама Цецо нещо ме уплаши за DMA-то и се отказах. Другата слабост на DMA е, че ми е по-куцо при препълване на буфера. Ако е на прекъсване, при напълване на буфера побутвам напред и указаталя за четене. Така имам последните данни, а не първите ( пак е въпрос на приложение ). При DMA пак може да стане, ама иска повече.
Съвсем друга е песента за DMA при бърза комуникация.

Бате, от как ми умря циганката съм я закъсал с рекламата

Правя опрационна система, та затова понякога имам по-странни капризи. Налага се да правя нещата принципно, а не за конкретно приложение. И е странно, понеже се предполага че контролерчетата също не са проектирани само за едно конкретно приложение.
Стандартният начин на ползване на серийния е с receive timeout. Няма по-добър вариант. Ако това го има всякакво приложение може да се търкаля ефективно.
Ако знаеш колко байта се очакват, просто пускаш четене на толкоз и игнорираш таймоутите. То по принцип ако отсрещната страна не се успива няма даже да има какво да игнорираш. Така или иначе игнорирането е елементарно - просто продължаваш да четеш, докато не ти излезе бройката. Такива приложения обаче са голяма рядкост. В общия случай не знаеш какво ще получиш. Е примерно ако си приказваш с gsm модул винаги може да ти вкара нотификация и да те изненада.
Та затова нормално приложението си пуска заявка за четене около един пакет и обикновено получава сигнал веднага след пакета, защото обикновено между пакетите има пауза. Аки няма пауза, сигналът ще дойде след като се напълни буфера, обикновено това значи пакет и част от следващия. В тоя случай има някакво закъснение, но съгласи се, че ос-а или хардуера няма как да знае къде свършва пакета. Ако толкова е важно за приложението - да чете на малки парчета, ако иска байт по байт да чете и ще има сигналче на всеки получен байт.
Демек приложенията си избират стратегия. Но да се работи байт по байт хич не е желателно. На всеки байт се получават по едно прекъсване (при ST може и повече) плюс два таск суича. И ако както при мен се ползват 3-4 уарта на 115200, може да се стигне до 100К суича в секунда, а това си е голям тормоз за проца. Тъпо е ...
Има и нещо друго, че серийният интерфейс трябва да изглежда абсолютно еднакво както и tcp сокет или usb. Като правиш терминал примерно трябва да може да го пуснеш както по серийна, така и по usb конзола или по сокет. Така че всичко се свежда до функция за четене/писане с поинтер, дължина и опционално таймоут. Това е) дефакто стандарт и не съм го измислил аз
Моят принос е, че го прилагам даже и за gpio-та. Правиш си списък с дефиниции на пинове и с него отваряш стандартен хендъл. Разбира се поне на един от пиновете трябва да си избрал фронт. Съответно четенето може да е блокиращо докато дойде фронт или изтече таймоута. Няма нужда да се пипат интеръпти или нещо из ОС-а. Кой да е таск може да бачка с който си иска пин. Сложил съм примерче как се прави, всеки може да го види... ос-а се казва tmos и е качен на гугъла

Това го знам, ама не посмях да ти го предложа Че като те знам какъв си перфекционист...

А това си е типичен workaround на една дизайнерска глупост. На тоя контролер съм открил няколко такива и ти успешно откри почти всичките. Мисля, че остана само глупостта с CS-а на SPI интерфейса

И то като имаш предвид, че не съм пускал някой от модулите - Ethernet например.

И каква изненадка ме чака с SPI-a?

Споко бе, ножът е дървен.

// ===== Configure SPI controller #1 =====
SPI1->CR1 = SPI_CR1_SSM |
SPI_CR1_SSI |
SPI_CR1_BR_1 | // pclk / 8
SPI_CR1_CPOL | // clk stays "hi" when idle
SPI_CR1_CPHA |
SPI_CR1_MSTR; // master mode
SPI1->CR1 |= SPI_CR1_SPE; // enable the peripheral
SPI1->CR2 = 0;

обърни внимание на SSM и SSI.

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

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

Иначе по принцип аз предпочитам CS да си го джуркам като GPIO, по-универсално е а и винаги имам малко повече SPI устройства. Даже при луминари май не поддържам автоматика, при Атмел си спомням че може, но SPI драйверът така или иначе винаги изпълнява кода за ръчното клатене (с несъщестуващ пин).

И аз си мисля, че на повечето контролери CS се ръчка ръчно.

Ами може аз да съм някакъв мечтател тогава Аз "проблема" го видях, когато прехвърлях един стар проект от STR9-ка на STM32. На SPI имах един сериен LCD, който си рефрешвах на 100ms. И там всичко си ставаше абсолютно автоматично - от прекъсването аз само пускам DMA-то и то си прави всички трансфери през SPI. Четох чаршафа на STM32 уж модула едно към едно със 9-ката (нали са на една фирма да го ...) . Да ама не, CS не ще да се клати. А в първите чаршафи пишеше че се клати сам. После вдигнахме джабала във форума на STM и в следващия чаршаф просто вече не пише че се клати сам. Обявиха ни че сме тъпи и не се разбрали, че това не е bug, a feature Естествено въпроса, що тоя "полезен" фичър го няма на АРМ9 , а цъфва на новия остана без отговор.

Като цяло е полезно ако имаш само едно нещо на тоя интерфейс и нещото му трябва CS да се клати по време на трансфера. На конкретния дисплей беше така, за да прехвърлиш на друг ред, трябва да разклатиш CS-a... Сега имам едни 64 паразитни прекъсвания по време на рефреша за да разклатя глупавия пин софтуерно.

Като цяло не е болка за умиране, процесора не се товари, ама аз си загубих 1 ден докато разбера какво става.

мда... и с spi имам проблем
Няма 9-битов режим, а пък съм вързал графично LCD. Голям майтап ще падне ако трябва да го клатя през пинове. Работата с ST стана като в оня виц "ей момчета, ама как се прецаках"

Съвсем сериозно искам да кажа на всички, които обмислят да ползват STM32 - не се набутвайте. Тия заслужават златен скункс за най-недоклатен чеп...

Обаче spi-я им има 16bit режим!
Да, като черна станция си - не работи това, няма онова.
Що почерняш тези прекрасни микроконтролери? Малко позитивизъм няма ли и за тях?!
За такива нестандарти режими на работа при тях се ползва USART-а в синхронен режим. Е може да се наложи да реверсираш битовете....

Ако знаех, можеше да го ползвам, ама платката отдавна е готова и на тия пинове нямам USART...

Абе издънката си е изцяло моя, трябвало е да внимавам малко повече... А пък аз разчитах, че след като толкова много хора ги ползват, не може да има толкова големи недомислици и в GPIO-та и UART и SPI и DMA и систика и изобщо всичко дето пробвах дотук има проблем. Къде съм спал и аз не знам

Екстра си е чипа. Аз имам вече 7-8 комерсиални проекта с него и се чувствам много комфортно с тая фамилия. Просто не е твоя тип, аз ти го казах отначало.