Tämän sisäisen riippumattomuusviiveen konteksti puuttuu täältä.Mutta oletan, että tarvitset lyhyen viiveen alustuksen aikana tai muussa koodin osassa, jossa sen sallitaan estää.

Kysymyksesi ei saisi olla fool GCC.Sinun tulisi tell GCC mitä haluat.

  #pragma GCC push_options
#pragma GCC-optimointi ("O0")

(uint i = 0; i<T; i ++) {__ NOP ()}

#pragma GCC: n pop_options
 

Pään päältäni tämä silmukka on noin 5 * T-kelloa.

( lähde)

Colin kertoi oikeudenmukaisesti toisen vastauksen.NOP: n ei voida taata ottavan jaksoja M4: llä.Jos haluat hidastaa asioita, ehkä parempi vaihtoehto on ISB (huuhteluputki).Katso yleinen käyttöopas.

Käytä ajastinta, jos sinulla on sellainen käytettävissä.SysTick on erittäin helppo konfiguroida, ja sen ohjeet ovat Cortex M4 -käyttöoppaassa (tai M0, jos olet M0-osassa).Lisää numeroa sen keskeytyksessä ja viivetoiminnossa voit estää, kunnes numero on lisännyt tiettyä määrää vaiheita.

Sinun osassasi on paljon ajastimia, jos systick on jo käytössä, ja periaate pysyy samana.Jos käytät eri ajastinta, voit määrittää sen laskuriksi ja katsoa vain sen lukurekisteriä välttääksesi keskeytyksiä.

Jos todella haluat tehdä sen ohjelmistolla, voit laittaa silmukan sisään asm ("nop"); . nop ei tarvitse viedä aikaa, prosessori voi poistaa ne putkistosta suorittamatta sitä, mutta kääntäjän tulisi silti luoda silmukka.

Älä vähennä muita vastauksia täällä, mutta tarkalleen kuinka pitkää viivettä tarvitset? Joissakin taulukoissa mainitaan nanosekunnit; muut mikrosekunnit; ja vielä muut millisekunnit.

• Nanosekunnin viivästykset palvelevat yleensä parhaiten lisäämällä "aikaa tuhlaavia" ohjeita. Tosiaankin mikro-ohjaimen nopea nopeus tarkoittaa, että viive on tyydytetty osoittamiesi ohjeiden "aseta tappi korkealle, aseta tappi matalalle" välillä. Muussa tapauksessa yksi tai useampi NOP , JMP -to-next-command tai muu aikaa vievä ohje riittää.
• Lyhyet mikrosekunnin viiveet voi tehdä for -silmukalla (suorittimen nopeudesta riippuen), mutta pidemmät voivat edellyttää odottamista varsinaisella ajastimella;
• Millisekunnin viivästykset palvelevat yleensä parhaiten tekemällä jotain muuta täysin odottaen prosessin päättymistä ja palaten sitten takaisin varmistaaksesi, että se on todella suoritettu ennen jatkamista.

Lyhyesti sanottuna kaikki riippuu oheislaitteesta.

Paras tapa on käyttää sirun ajastimia. Systick-, RTC- tai oheislaitteiden ajastimet. Näillä on se etu, että ajoitus on tarkka, deterministinen ja se voidaan helposti mukauttaa, jos prosessorin kellotaajuutta muutetaan. Vaihtoehtoisesti voit jopa antaa CPU: n nukkua ja käyttää herätyskeskeytystä.

Likaiset "varattu-viive" -silmukat ovat toisaalta harvoin tarkkoja ja niissä on erilaisia ​​ongelmia, kuten "tiukka kytkentä" tiettyyn suorittimen käskyjoukkoon ja kelloon.

Joitakin huomioitavia asioita:

• GPIO-nastan vaihtaminen toistuvasti on huono idea, koska se vetää virtaa tarpeettomasti ja aiheuttaa myös EMC-ongelmia, jos tappi on kytketty jälkiin.
• NOP-ohjeiden käyttäminen ei välttämättä toimi. Monet arkkitehtuurit (kuten Cortex M, iirc) voivat vapaasti ohittaa NOP: n suorittimen tasolla eivätkä itse suorita niitä.

Jos haluat vaatia likainen kiireisen silmukan luomista, riittää, että vain volatile hyväksytään silmukka-iteraattori. Esimerkiksi:

  void dirty_delay (mitätöity)
{
  for (haihtuva uint32_t i = 0; i<50000u; i ++)
    ;
}
 

Tämän avulla voidaan taata erilaisia ​​roskakoodeja. Esimerkiksi ARM gcc -O3 -vapaasti seisova antaa:

  likainen_viive:
        mov r3, # 0
        sub sp, sp, # 8
        str r3, [sp, # 4]
        ldr r3, [sp, # 4]
        ldr r2,. L7
        cmp r3, r2
        bhi. L1
.L3:
        ldr r3, [sp, # 4]
        lisää r3, r3, # 1
        str r3, [sp, # 4]
        ldr r3, [sp, # 4]
        cmp r3, r2
        bls. L3
.L1:
        lisää sp, sp, # 8
        bx lr
.L7:
        .sana 49999
 

Siitä lähtien voit teoriassa laskea, kuinka monta punkkia kukin käsky vie, ja muuttaa taikuuslukua 50000 vastaavasti. Putkilinja, haaraennuste jne. Tarkoittaa, että koodi saattaa kuitenkin suorittaa nopeammin kuin vain kellojaksojen summa. Koska kääntäjä päätti ottaa pinon mukaan, myös tietojen välimuistilla voi olla merkitystä.

Koko ajatukseni on, että on vaikeaa laskea tarkasti kuinka paljon aikaa tämä koodi todella vie.Kokeiluversioiden vertailuanalyysi &ista on todennäköisesti järkevämpi idea kuin teoreettisten laskelmien yrittäminen.