STM32-laitteissa kaikki oheislaitteet ovat oletusarvoisesti pois käytöstä, eivätkä ne saa kellosignaaleja. Tämä säästää joukon voimaa (ja pakottaa sinut ajattelemaan nastojen välistä vuorovaikutusta koodaamisen aikana). Jos haluat käyttää GPIOE: tä, sinun on kerrottava STM32: lle sen kellon ottaminen käyttöön.

1UL << 21 siirtää allekirjoittamaton pitkä -arvon 1 21 bittiä vasemmalle. 1 << 21 siirtää jotakin arvoa, jonka arvo on 1, mutta se on jokin oletustyyppi, joka voi olla tai ei välttämättä ole allekirjoittamaton pitkä , etkä välttämättä tiedä kuinka leveä järjestelmäsi on oletukset ovat. Se vaihtelee alustan ja kääntäjän mukaan. Itse asiassa UL voi vaihdella alustan ja kääntäjän mukaan. On parasta käyttää kirjastotyyppiä, jotka ovat varmoja asioita.

(uint32_t) 1 << 21 ja (uint64_t) 1 << 21 ovat yksiselitteisiä. .

Kaiken kaikkiaan näyttää aika hyvältä. Voisi käyttää vielä joitain kommentteja.

Onko SysTick_Handler keskeytyskäsittelijä? Jos on, sano niin. Olen yllättynyt siitä, ettei ole mitään attribuutteja, jotka ilmoittavat tämän (useimmissa muissa prosessoreissa upotetuissa C: ssä on sana keskeytä jossain i käsittelijän nimen määritelmä). Oletan, että se on määritettävä #DEFINE järjestelmään .h-tiedostoon jonnekin. Harmi, että he piilottavat sen näin.

Kuinka usein SysTick_Handler soitetaan? Tiedän, että se on määritetty SysTick_Config-puhelussa, mutta et sano siitä mitään.

Mitkä ovat Viive-puhelun yksiköt? Millisekuntia? Sano niin.

Mitä taulun LEDiä muokkaat GPIOE-> BSRR = 1 << 8 kanssa?

Onko toiminto TimingDelay_Decrement todella tarpeen? Miksei vain laittaa koodinsa SysTick_Handleriin? Tavallisesti yritetään välttää tarpeettomia puheluita keskeytyskäsittelijässä. Ei ole merkitystä tässä, mutta voi joskus kriittisiä käsittelijöitä.

Luettavuuden vuoksi ja virheiden todennäköisyyden vähentämiseksi käytä makroja maagisten numeroiden sijaan.

stm32f30x.h sisältää makrot (toivottavasti) koko rekisterille arvot. Joten:

  RCC->AHBENR | = ((1UL << 21)); // Ota GPIOE-kello käyttöön GPIOE->MODER | = (1 << 2 * 8); // PIN 9 lähdönä  

voidaan kirjoittaa seuraavasti:

  RCC->AHBENR | = RCC_AHBENR_GPIOEEN; // Ota GPIOE-kello käyttöön. GPIOE->MODER | = GPIO_MODER_MODER8_0; // PIN 8 - ei 9! - tuotoksena.  

(Todellakin - alkuperäinen kommentti oli väärä tässä; makron käyttäminen tekee siitä selvemmän!)

Vastaavasti pin-vaihtokoodi voidaan kirjoittaa kuten:

  GPIOE->BSRR = GPIO_BSRR_BS_8; Viive (50); GPIOE->BRR = GPIO_BRR_BR_8; Viive (50);  

Menee pidemmälle, GPIO_MODER_MODER8_0 ei ole aivan selvää, joten minä saattaa lisätä oman makron:

  #define GPIO_MODER_MODER8_OUT GPIO_MODER_MODER8_0  

Se voi olla hieman väsyttävää, jos määrität paljon nastoja, joten voit tehdä:

  #define GPIO_MODER_OUT (pin) ((((uint32_t) 1) << (2 * (pin)))  

Lisäksi Yläpuolella olevalla rivillä oletetaan, että nämä MODER -bittien bitit olivat jo 0x0 tai 0x1. Jos emme voi olettaa sitä, meidän on ensin tyhjennettävä ne:

  GPIOE->MODER & = ~ GPIO_MODER_MODER8; GPIOE->MODER | = GPIO_MODER_OUT (8);  

Myös:

Jos tiedoston yläosassa ilmoitettuja toimintoja ei käytetä missään muualla, ilmoita ne staattisiksi . Tämä estää niitä käyttämästä vahingossa missään muussa tiedostossa.

Jos kääntäjä sallii, main tulisi ilmoittaa void -tekstinä, ei palauttaa int , koska se ei koskaan palaa.

Tämä on todellinen nitpick: TimingDelay on vain tavallinen numero; sitä ei käytetä, jos heksadesimaalinen esitys on sopiva. Joten kohdassa TimingDelay_Decrement , jossa sitä verrataan nollaan, käytä 0 , ei 0x00 . Tämä tekee siitä myös johdonmukaisen vertailun kanssa Delay.

Jos olen ymmärtänyt oikein, __IO merkitsee muuttujan volatile , ja epäilen, että sitä käytetään merkitsemään luettavia ja kirjoitettavia rekistereitä. TimingDelay : n on todellakin oltava volatile , koska se päivitetään keskeytyksessä - mutta olisin halukas käyttämään volatile -tunnusta sijaan __IO osoittaa, että se ei ole rekisteri.

nTime ei tarvitse olla haihtuva (tai __IO koodi>), koska se on vain normaali toimintoparametri, joka välitetään arvolla, joka luetaan kerran.

Tämän pitäisi teknisesti kuulua koodin tarkistukseen.

Ainoa suositukseni on, että bittimuodostuksen / siirtämisen tulisi olla joko makroja tai toimintoja, jotka kuvaavat mitä tapahtuu. Kommentit ovat hyviä, mutta ne eivät toimi ja viime kädessä mitä kommentit sanovat, ei tarkoita mitään; se on koodi, joka laskee (ja ne eivät synkronoidu). Tee koodista BE kommentit toiminnallisella hajotuksella:

  RCC->AHBENR | = ((1UL << 21)); 

tulee

  enableGpioe () {RCC->AHBENR | = (1UL << 21); }  

ja tämä

  GPIOE->BSRR = 1 << 9; 

tulee

  void setLEDStatus (LED led, Status status) {led = 1 <<-tila; // En tiedä sinun jäseniäsi.}  

kun

Led

ja

Status

ovat enumeja. Voit tehdä niistä vähintään makroja. Tämä helpottaa sinua siitä, että sinun ei tarvitse muistaa oikeaa bitin peittämistä tehtävän suorittamiseksi.