1. 32-bitni mikrokontroleri i primena - MS1BMP
2017/2018
Nenad Jovičić

2. Low power
Iako je jedino Cortex-M0 dizajniran specifično za low power svi Cortex-i su prilično štedljivi.
Postoje dva low power režima:
SLEEP – procesorski takt je isključen, a periferijski je aktivan
DEEPSLEEP – tipično ni jedan takt ne radi, ali zavisi i od konkretne implementacije. Napajanje za SRAM ili FLASH može biti isključeno, što opet zavisi od implementacije.

3. Low power
Iako je jedino Cortex-M0 dizajniran specifično za low power svi Cortex-i su prilično štedljivi.
Postoje dva low power režima:
SLEEP – procesorski takt je isključen, a periferijski je aktivan
DEEPSLEEP – tipično ni jedan takt ne radi, ali zavisi i od konkretne implementacije. Napajanje za SRAM ili FLASH može biti isključeno, što opet zavisi od implementacije.
U čemu je razlika između WFI i WFE?
Nakon WFI čeka se prekid, i prvo što se izvršava je prekidna rutina.
Nakon WFE jednostavno se nastavlja izvršavanje programa.

4. Izlazak iz low power režima
Sa SLEEP-om je jednostavno. NVIC je aktivan tako da može da procesira svaki prekid.
DEEPSLEEP je problematičan – NVIC je bez takta ili čak i bez napajanja. Kako obezbediti buđenje?
Rešenje: Jednostavna low gate count logika i kontroler buđenja (WIC) koji detektuje stimulus i uključuje napajanje i taktove.

5. Konfiguracija WFE
System Control Register (SCB->SCR) ima set bitova kojima se kontroliše način reagovanja na WFE instrukciju.
Da li se ide u SLEEP ili DEEPSLEEP režim
Send Event on Pending – omogućava da prekidni signali bude procesor i kada je prekid zabranjen
Da li nakon prekida procesor automatski ide u SLEEP?

6. SLEEP ON EXIT funkcija
S obzirom da nikada nema povratka u glavni program, kontekst se ne čuva niti restaurira.

7. STM32Fxx Event je ili prekid ili pravi “EVENT”.
Kod STM32Fxx prave EVENT-e mogu da generišu neki pinovi mikrokontrolera

8. Vežba 3.6 Low-Power Modes Glavni program i dva prekida.
Nema ulaska o režim smanjene potrošnje

9. Modifikacija 1
Nakon svakog prekida izvrši se jedna petlja glavnog programa.
Nailazak na WFI() instrukciju ubacuje procesor u SLEEP mod.

10. Modifikacija 2 Aktivacija SLEEP_ON_EXIT funkcije.
Procesor se nikada ne vraća u glavni program, već izvršava samo prekide.

11. Cortex-M vs. ostali uC-ovi
Cortex-M mikrokontroleri su dominantni na tržištu 32-bitnih mikrokontrolera.
17 Vendora trenutno oproizvodi svoje varijante Cortex-M mikrokontrolera.
Prakitčno nemaju konkurenciju.
Šta održava takvo stanje? Zašto Vendori ne prave svoje miktokontrolere?
Prave ih ako imaju nešto baš specifično. Kao MSP, koji je na primer ultra low power.
Šta je dobro kod Cortex-a? Dobro je to što postoji razvijena podrška, alati, community i slično.
Čime se diferenciraju Vendori? Specijalnim periferijama, prilagođenim realizacijama i slično.

12. Sistemi postaju sve kompleksniji
Nekada su se Cortex-i razlikovali po implementacijama osnovnih periferija, kao što su UART, CAN, SPI itd...
Danas su sev zastupljeniji kompleksni komunikacioni interfejsi, podrška za grafiku, interfejsi preka kamerama, specijalnim kodecima i slično.
Sve je više proizvođača softvera (Third Party) koji nude neka svoja drajverska rešenja u cilju podrške kompleksnim sistemima.
Da bi se proces povezivanja ARM-a, Silicon Vendor-a i Thrid Party proizvođača što više standardizovao uvedem je CMSIS (Cortex Microcontroller Software Interface Standard)

13. CMSIS
CMSIS je kolekcija specifikacija: CMSIS-Core, CMSIS-RTOS, CMSIS-DSP, CMSIS-Driver, CMSIS-Pack, CMSIS-SVD and CMSIS-DAP
CMSIS nije komleksan set HAL (Hardware abstraction layer) drajvera!

14. CMSIS
KEIL po default-u podržava CMSIS

15. CMSIS-Core
CMSIS-Core – Set funkcija i makroa za pristup svim registrima u koje spadaju SysTick, NVIC, System Control Block registers, MPU registers, FPU registers.
Definicije su u core_cmx.h fajlu.
Standardizuje se SystemInit() funkcija koju prilagođava svaki Vendor i u kojoj se vrši osnovno podešavanje takta.
Standardizuje se globalna promenljiva SystemCoreClock

16. CMSIS-RTOS
Set funkcija koje prilagođavaju CMSIS-RTOS API na API specifičnog RTOS-a.
Prvi RTOS koji je izveden na bazi CMSIS-RTOS API-ja je KEIL-ov RTX RTOS, koji je otvoren i besplatan.
Set funkcija je definisan u cmsis_os.h fajlu.
RTX RTOS podleže Berkeley Software Distribution (BSD) licenci i može da se koristi i u komercijalne i nekomercijalne svrhe.

17. CMSIS-DSP
Sadrži preko 60 implementacija najčešće korišćenih matematički zahtevnih funkcija koje se koriste u digitalnoj obradi signala.
Iako su optimizovane za Cortex-M4 i Cortex-M7 mogu se prekompajlirati i za Cortex-M3.
O ovome ćemo više govoriti kansije.

18. CMSIS-Driver
Standardni API za korišćenje najrazličitijih standardnih periferija – od jednostavnjih kao što su UART, SPI, I2C, do kompleksnih kao što su USB, ETHERNET, CAN...
Suština je obezbeđivanje podrške za pisanje drajvera.

19. CMSIS-SVD i DAP
SVD (System Viewer Description) fajl je standardizovana struktura preko koje vendori brzo i jednostavno daju podršku za svoj novi mikrokontroler, i za ono što se u debugger-u zove Peripheral View.
CMSIS-DAP definiše protokol komunikacije sa DEBUG jedinicom. Na ovaj način je omogućeno da svaki programer koji koristi CMSIS DAP protokol može da se koristi za potrebe debagovanja.

20. MISRA-C
Zatvoren standard kreiran od asocijacije “Motor Industry Research Agency”.
Predstavlja set jasnih pravila kodiranja u C-u koja obezbeđuju kvalitetan i pouzdan kod.

21. MISRA-C Standardizovanje tipova podataka:
Kontrola pristupa periferijskim registrima:

22. CMSIS-CORE struktura CMSIS-CORE je dostupan preko tri fajla:
Konfiguracija takta
Startup kode i default vektor tabela.
Opis svih registara i kaskadno uključivanje CMSIS fajlova

23. CMSIS-CORE struktura CMSIS-CORE je dostupan preko tri fajla:
Konfiguracija takta
Startup kode i default vektor tabela.
Opis svih registara i kaskadno uključivanje CMSIS fajlova

24. Startup_ kod
Inicijalizacija steka i tabele vektora prekida

25. Svaki Vendor i svaki mikrokontroler može da ima drugačija podešavanja
System_ kod
Svaki Vendor i svaki mikrokontroler može da ima drugačija podešavanja

26. Promena takta tokom Runtime-a
S obzirom da je promenljiva SystemCoreClock zahtevana po CMSIS standardu obavezno je posle svake izmene registara koji menjaju takt pozvati funkciju SystemCoreClockUpdate() koja vrši update te promenljive.
Korisnički kod koji utiče na izmenu takta preko menjanja sadržaja RCC registara
Na kraju se obavezno poziva SystemCoreClockUpdate()

27. Ovo je suštinski CMSIS Standard
Primer template fajla koji definiše inimum funkcija koje bi trebalo da postoje.
Naravno proizvođači mogu da dodaju i neke svoje specifične funkcije, kao na primer SetSysClockTo72() kod ovog STM-a.
Ovo je suštinski CMSIS Standard

28. <device>.h Device Header File
Definicije svih periferijskih registara

29. <device>.h Device Header File
Definicije nekih dodatnih opcija
U ovom primeru se u slučaju nedefinisanja broja bita za određivanje prioriteta u okviru core_cm3.h fajla za svaki slučaj definiše minimalni broj bita

30. core_cmx.h

31. Non-CMSIS vs CMSIS Projekat 4.1 Projekat 3.4
Projekti 3.4 i 4.1 imaju istu funkcionalnost ali projekat 4.1 je pisan korišćenjem CMSIS funkcija

32. Šta je još definisano u core_cmx.h?
Interesantno je da je implementacija ovih funkcija nevidljiva je su ugrađene su u sam kompajler!