И аз имах едни такива очаквания, ама след като не намерих подобна точка поне в документацията на Ф1 реших да питам (just in case)...

Общо взето процедурите започват с писане на регистри на периферията, което е станно. Обикновено първа точка е вдигане на шалтера, пускане на клока и чак тогава може да се адресират регистри на периферията. Може би нейде из дребния шрифт са го наврели, примерно гледам че SPI има разни забележки от тип "преди да направите това трябва да се вдигне SPE", ама къде е тоя бит не става ясно.

Както и да е, поорентирах се за gpio-тата и каквото ми трябваше. Ще понадраскам малко код, пък после ще видим

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

Не помня къде бе описано, но за да пишеш по регистрите на дадена периферия , първо трябва да пуснеш клока към съответната периферия !

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

Ми не съм се замислял. За мен периферията е спряна, като няма клок. В такива режими, консумацията се покрива горе долу с това от дейташита.


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

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

С това темпо до напролет ще цъфна дано другите периферии на ST са малко по-читави...

Стига бе, точно от тебе не го очаквах! Иначе и аз си имам едно хоби проектче с Discovery STM32F4 и не ползвам "библиотеките" на ST. Само че при мен не се налага динамично да се променят настройките на пиновете.

има много какво да се желае от "библиотеките" им

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

едит: има елементарни правила, примерно не може един регистър в дейташийта да се казва по един начин, а в хедърите по друг. А за такива неща като че примерно една функция за конфигуриране на пин трябва да е thread safe, изобщо не мога и да си мечтая...
Но не са само ST така де, при всички има бози. На ST големият проблем е недомислиците в дизайна, особено с F1, айде другите серии са една идея по-добре.

Нали ти казах, щом на мен ми допада... на теб едва ли

Библиотеките им са .... абе по добре от нищо, ама до там.

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

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

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

почнах да разучавам UART-a... и вече няколко пъти препочитам и не мога да разбера тоя idle при приемане.

Тва на всеки 9-10 бита единици прави интеръпт или е еднократно? Щото както са го дефинирали, че idle е фреймът преди първия старт бит е малко грозно...

На мен всъщност ми трябва receive time out. Това е като не знаеш колко байта ще дойдат, да пуснеш един голям буфер, а пък то като засече пауза да ти сигнализира.
Друг проблем, е че не ме интересуват айдъли докато не дойде поне 1 байт. Демек ако приемем, че айдъла е многократен (надявам се) в началото трябва да го пусна без айдъл интеръпт и като дойде нещо да разреша айдъла и да продължа да приемам докато идва нещо или дойде айдъл... Малко грозно, обаче с ДМА май ще стане много грозно. Не знам дали ДМА няма да ми изяде интеръптите за получаване? А и тая простотия с отделните вектори за ДМА и за периферия направо ще ме довърши...

Няма.

С Idle не става, аз поне не мога да го ползвам за целта. Маам го с DMA-то и това е

супер....

то в такъв случай и от ДМА файдата е почти никаква.

това не е ли разумно да се прави с таймер (в ОС-а примерно)? иначе скоро ще почнеш да се сърдиш, че ДМА-то не разпознава <CR><LF>
не че няма и такива (ко)процесори, де

и на мен ми е чудна нуждата от ДМА, може би при много високи скорости.
признавам си, че съм чел главата за UARTA сутрин и с очила.

Aз DMA ползвам само за СД картата. За UART със скорости около 10К знака за секунда не виждам смисъл. Приемане / предаване ми е само на прекъсване. Ей така някак си изглежда:
void USART2_IRQHandler(void)
{
char ch;

// find out what is the source of the interrupt
if (USART2->SR & USART_SR_RXNE) // is there a new data received ?
{
// new data is available
ch = (char)(USART2->DR);
RxRS232PutChar(ch); // put rcv char into a FIFO buffer
rs232_rx_timer = GetSystemTime();
}
if (USART2->CR1 & USART_CR1_TXEIE) // are Tx interrupts enabled e.g are we transmitting ?
{
if (USART2->SR & USART_SR_TXE)
{
if (TxRS232GetChar(&ch) == 0) // get the char in buffer
{
// put a char in Tx register
USART2->DR = (unsigned short)(ch);
rs232_tx_timer = GetSystemTime();
}
else
{
// no more chars to be transmitted, stop Tx interrupts
USART2->CR1 &= ~USART_CR1_TXEIE;
}
}
}
}