1. daļa ARM asambleja TI RSLK Robotikas apguves mācību programma 7. STM32 kodols: 16 soļi

2024 Autors: John Day | [email protected]. Pēdējoreiz modificēts: 2024-01-30 10:53

Šīs pamācības uzmanības centrā ir STM32 Nucleo mikrokontrolleris. Motivācija tam, lai varētu izveidot montāžas projektu no kailiem kauliem. Tas palīdzēs mums iedziļināties un izprast projektu MSP432 Launchpad (TI-RSLK), kas jau ir bijis vairāku Instructables tēma.

Tiešsaistē nav daudz palīdzības, lai izveidotu MSP432 tikai montāžas projektu, izmantojot Code Composer Studio. Līdz šim mēs tikai kopējām/ielīmējām no jau esoša montāžas projekta. Šī pieeja mums ir labi kalpojusi.

Tomēr tagad 7. laboratorijā mēs esam saskārušies ar nelielu problēmu. Vai vismaz pagaidu žagas. Lab 7 ievieš ierobežota stāvokļa mašīnas, un pirmā lieta, ar ko saskaramies, ir nepieciešamība izveidot un izmantot vērtību masīvu. Tā kā TI kursā galvenokārt tiek izmantota C programmēšana - tā nav problēma. Bet šie norādījumi ir koncentrējušies uz montāžu, nevis C.

Turklāt, tā kā masīvam ir tikai lasāmas vērtības, būtu labi to ievietot zibatmiņā, nevis RAM.

Šķiet, ka tiešsaistē ir daudz vairāk palīdzības montāžas projektiem, izmantojot STM32 MCU, tāpēc mēs sākam ar šo pamācību, kuras mērķis ir izmantot apgūto, lai pēc tam pieteiktos MSP432 un Code Composer Studio.

Ceļā uz šo mērķi mēs arī esam ieguvuši pieredzi ar vēl vienu populāru mikrokontrolleri.

1. darbība. Ierīces sākotnējā pārbaude

Atkal kāpēc izvēlēties īpaši STM32 Nucleo?

Godīgi? Tā kā es meklēju labus rakstus par neapbruņotu metālu montāžas projektiem ARM kontrolieriem, un es saskāros ar šo sēriju. Un arī tāpēc, ka STM32, šķiet, ir populārs MCU.

Es veicu dažus pētījumus (ir daudz versiju, no kurām izvēlēties - skatiet attēlu iepriekš), bet galu galā tas kļuva par to, ko es varu iegūt, jo es gatavojos izmantot Amazon (ASV).

Tas ir iekļauts vienkāršā, bet profesionālā iepakojumā ar dažiem darbības uzsākšanas norādījumiem. Bija mazliet smieklīgi redzēt, ka kontrolierī ierakstītā demonstrācija bija gandrīz tieši tāda, kādu esam darījuši iepriekšējos Instructables - LED mirgo un maina ātrumu atbilstoši pogas nospiešanai.

Šķiet, ka šī izstrādes plate ir ļoti līdzīga MSP432, jo tajā ir 2 gaismas diodes un viena lietotāja spiedpoga. MSP432 ir 2 lietotāja pogas.

Kā redzat fotoattēlos, es biju mazliet pārsteigts, ka plāksnei ir mini, nevis mikro USB. Nācās skriet, lai nopirktu vadu.

Vēl viens labs tests ir tas, ka, savienojot to ar datoru (es izmantoju Linux kastīti), tas tiek parādīts manā failu pārvaldniekā kā failu sistēma ar nosaukumu "NODE_F303RE". Atverot, tiek atklāti divi faili, viens HTML un viens teksts.

Tas tā, bet vismaz tas arī saka, ka savienojamība šķiet diezgan vienkārša.

Tagad mēs esam gatavi sākt.

Es centīšos neatkārtot nevienu labo informāciju no IVONOMICON Bare Metal rakstu sērijas, bet drīzāk to papildināt.

2. darbība

Pirmā lieta, kas mums nepieciešama, ir kompilators.

Un tad mums ir nepieciešams atkļūdotājs:

devchu@chubox: ~ $ sudo apt-get install gdb-arm-none-eabiPakotņu sarakstu lasīšana … Gatavs Atkarības koka veidošana Statusa informācijas lasīšana … Gatavs Tiks instalētas šādas JAUNAS pakotnes: gdb-arm-none-eabi 0 jaunināts, 1 jauns instalēts, 0 noņemams un 8 nav jaunināts. Nepieciešams iegūt 2 722 kB arhīvu. Pēc šīs darbības tiks izmantoti 7 738 kB papildu diska vietas. Iegūstiet: 1 https://us.archive.ubuntu.com/ubuntu xenial/Universums amd64 gdb-arm-none-eabi amd64 7.10-1ubuntu3+9 [2, 722 kB] Ielādēts 2, 722 kB 1 s (1, 988 kB/s) Atlasot iepriekš neizvēlēto pakotni gdb-arm-none-eabi. (Tiek lasīta datu bāze … Pašlaik ir instalēti 262428 faili un direktoriji.) Gatavošanās izpakošanai…/gdb-arm-none-eabi_7.10-1ubuntu3+9_amd64.deb… gdb-arm-none-eabi (7.10-1ubuntu3+9) izpakošana… trigeri man-db (2.7.5-1)… Gdb-arm-none-eabi iestatīšana (7.10-1ubuntu3+9)…

3. darbība: pamati - Windows

Iepriekš minētajā solī tika pieņemts, ka mēs izmantojam Linux. Ko darīt, ja mēs izmantojam Windows?

Jūs varat doties uz izstrādātāja vietni, un ir pieejamas vairākas lejupielādes iespējas. Es izmantoju Windows 8 mašīnu.

Instalēšanas laikā es izvēlējos instalēt to saknes "C: \" diskā, nevis Program Files tikai tāpēc, ka es arī izmantoju cygwin, un bija vieglāk izveidot saiti no vietējās tvertnes uz saknes C: mapi nekā visas juceklis ceļā uz programmu failiem (ar atstarpēm utt.).

Tādējādi mana Cygwin vide un ceļš utt. Izskatās šādi:

C: / cygwin64 / home / bin / arm-none-eabi-gcc, kur arm-none-eabi-gcc ir saite uz C: / GNUToolsArmEmbedded / 7.2018.q2.update / bin / arm-none-eabi- gcc.

Tad es izveidoju "dev" mapi zem cygwin mājas, un tur es ievietoju core. S failu un palaidu kompilatora komandu. (lasiet tālāk zemāk, lai uzzinātu par kompilatoru).

Es darīju tieši to pašu ar gdb (arm-none-eabi-gdb).

4. solis: kas ir būtisks

Tātad, kas ir "gcc-arm-none-eabi"?

Gnu kompilators (GCC) apkopos programmēšanas valodas (piemēram, C) mašīnas, kurā tā darbojas, vietējā kodā. Piemēram, ja jūs savā Windows datorā apkopotu kādu C kodu, izmantojot GCC, tas tiktu veidots tā, lai darbotos Windows mašīnā. Izveidotais izpildāmā fails (parasti) nedarbosies ar ARM mikrokontrolleri.

Tātad, lai izveidotu programmas, kuras lejupielādēt un ierakstīt ARM mikrokontrollerī (šajā gadījumā tas būtu STM32 Nucelo), mums ir jāpiešķir GCC kaut kas cits: iespēja "savstarpēji apkopot". Tas ir, spēja ģenerēt izpildāmo failu nevis tās vietējai sistēmai (un procesoram), bet gan mērķa sistēmai (ARM mikrokontrollerim). Tieši šeit parādās "gcc-arm-none-eabi".

Kas tad ir "gdb-arm-none-eabi"?

Kad būsim lejupielādējuši un ierakstījuši (mirgo) jaunizveidoto izpildāmo failu mikrokontrollerī, mēs, iespējams, vēlēsimies to atkļūdot-soli pa solim pa kodu. GDB ir gnu atkļūdotājs, un arī tam ir nepieciešams veids, kā veikt savu darbu, taču tam jābūt mērķētam uz citu sistēmu.

Tādējādi gdb-arm-none-eabi ir GDB, kas gcc-arm-none-eabi ir GCC.

Vēl viena ieteicamā pakotnes instalēšana bija "libnewlib-arm-none-eabi". Kas tas tāds?

Newlib ir C bibliotēka un matemātikas bibliotēka, kas paredzēta izmantošanai iegultās sistēmās. Tas ir vairāku bibliotēkas daļu konglomerāts, kurām visām ir bezmaksas programmatūras licences, kas padara tās viegli lietojamas iegultos produktos.

Un visbeidzot, pakete "libstdc ++-arm-none-eabi". Tas ir diezgan acīmredzams; tā ir C ++ bibliotēka savstarpējam kompilatoram; iegultiem ARM mikrokontrolleriem.

5. darbība: saistītāja fails

Izveidosim linkeru skriptu.

Viena galvenā daļa vai bloks šajā failā būtu komanda MEMORY.

--- no sourceware.org:

Linker noklusējuma konfigurācija ļauj piešķirt visu pieejamo atmiņu. To var ignorēt, izmantojot komandu MEMORY. Komanda MEMORY apraksta mērķa atmiņas bloku atrašanās vietu un lielumu. Varat to izmantot, lai aprakstītu, kurus atmiņas apgabalus var izmantot saistītājs, un no kuriem atmiņas apgabaliem jāizvairās. Pēc tam varat piešķirt sadaļas konkrētiem atmiņas reģioniem. Saistītājs iestatīs sadaļu adreses, pamatojoties uz atmiņas reģioniem, un brīdinās par reģioniem, kas kļūst pārāk pilni. Saistītājs nejauc sadaļas, lai tās ietilptu pieejamajos reģionos. Saistītāja skripts var saturēt daudzus komandas MEMORY lietojumus, tomēr visi definētie atmiņas bloki tiek uzskatīti par tādiem, kas norādīti vienā komandā MEMORY. Atmiņas sintakse ir:

ATMIŅA

{vārds [(attr)]: ORIGIN = izcelsme, GARUMS = len…}

Piemērs rakstā:

/* Definējiet RAM beigas un kaudzes atmiņas ierobežojumu* //* (4KB SRAM uz līnijas STM32F031x6, 4096 = 0x1000)*//* (RAM sākas ar adresi 0x20000000) _estack = 0x20001000;

ATMIŅA

{FLASH (rx): ORIGIN = 0x08000000, LENGTH = 32K RAM (rxw): ORIGIN = 0x20000000, GARUMS = 4K}

Tāpēc mums ir jāizdomā, cik daudz FLASH (mūsu programmai un konstantēm utt.) Un cik daudz RAM (programmai lietošanai; kaudze un kaudze utt.) Mūsu konkrētajai padomei. Tas kļūst mazliet interesanti.

Jaukajā mazajā kartītē, kas tiek piegādāta kopā ar Nucleo, teikts, ka tās zibatmiņa ir 512 KB, bet SRAM - 80 KB. Tomēr, savienojot to ar USB, tas tiek montēts kā failu sistēma ar diviem failiem, un gan failu pārvaldnieks, gan GParted norāda, ka tajā ir vairāk nekā 540+ baitu vietas. (RAM?).

BET, mēģinot izdzēst divus failus, izmantojot failu pārvaldnieku, atvienojot ierīci un pēc tam atkal pievienojot to, abi faili joprojām tiek parādīti. (un failu pārvaldnieks kaut ko atpazina, jo uz katra faila ir maza "bloķēšanas" ikona.

Tātad, iesim ar skaitļiem uz kartes. Tāpēc tagad mēs ņemam iepriekš minēto piemēru un pārvēršam to mūsu īpašajā padomē.

Iespējams, vēlēsities izmantot kaut ko līdzīgu šim tiešsaistes atmiņas pārveidotājam, lai no vispārējā KB pārietu uz noteiktu baitu skaitu.

Tad, iespējams, vēlēsities izmantot tiešsaistes decimāldaļu un heksadecimālo pārveidotāju.

/ * Definējiet RAM beigas un kaudzes atmiņas ierobežojumu */

/* (4KB SRAM uz līnijas STM32F031x6, 4096 = 0x1000)* //* piemērs*/

/ * 1. darbība: (80 KB SRAM uz STM32F303RE, 81920 = 0x14000) * // * mūsu dēlis */

/* 2. solis, pievienojiet sešstūra izmēru sešstūra sākuma adresei (zemāk). */

/ * (RAM sākas ar adresi 0x20000000) */

_stack = 0x20001000; / * piemērs */

_stāvs = 0x20014000; / * mūsu valde */

ATMINA {

Zibspuldze (rx): IZCELSME = 0x08000000, GARUMS = 512K

RAM (rxw): IZCELSME = 0x20000000, GARUMS = 80K

}

Sauksim iepriekš minēto failu "linker.script.ld".

6. solis: vektoru tabula

Tagad mēs izveidosim nelielu montāžas failu (ar direktīvām), lai veiktu dažas pamata pārtraukumu apstrādes darbības. Mēs sekosim raksta piemēram un izveidosim failu ar nosaukumu "core. S".

Atkal šeit ir faila satura piemērs, bet es veicu izmaiņas mūsu konkrētajā padomē:

// Šie norādījumi nosaka mūsu mikroshēmas un

// montāžas valoda, kuru mēs izmantosim:.syntax unified /*Skatiet tālāk pēc šī koda apgabala* //*.cpu cortex-m0* / /*komentējiet šo piemēra rindiņu* /.cpu cortex-m4 /* vietā pievienojiet mūsu dēļa garozu. šajā solī skatiet iepriekš redzamo attēlu * / /*.fpu softvfp * / / *komentējiet šo piemēra rindiņu * /.fpu vfpv4 / *tā vietā pievienojiet mūsu valdes; tam ir FPU */.thumb // Globālās atmiņas vietas..global vtable.global reset_handler / * * Faktiskā vektoru tabula. * Vienkāršības labad * ir iekļauts tikai RAM apjoms un “atiestatīšanas” apstrādātājs. */.type vtable, %object vtable:.word _estack.word reset_handler.size vtable,.-vtable

Hmm.. Nē '.align' direktīva

Tomēr tas nav kritiski. Vairāk par to (varbūt) vēlāk.

.sintakse vienota

.sintakse [vienota | sadalīts]

Šī direktīva nosaka instrukciju kopas sintaksi, kā aprakstīts sadaļā ARM-instrukciju kopa

9.4.2.1 Instrukciju kopas sintakse Divas nedaudz atšķirīgas sintakses atbalsta ARM un THUMB instrukcijas. Noklusējuma, sadalīts, izmanto veco stilu, kurā ARM un THUMB instrukcijām bija sava, atsevišķa sintakse. Jaunā, vienotā sintakse, kuru var izvēlēties, izmantojot.syntax direktīvu.

.fpu vfpv4

GCC kompilators var radīt binārus failus ar vairākām iespējām attiecībā uz peldošo komatu: mīksts - piemērots darbināšanai ar CPU bez FPU - aprēķinus veic programmatūrā kompilatora ģenerēts softfp - piemērots darbināšanai CPU ar FPU vai bez tā - izmantos FPU, ja tāds būs. Mūsu konkrētajā gadījumā (jums būs jāveic pašam sava izpēte), šīs konkrētās plates FPU atbilst vfpv4. Jums, iespējams, būs jāspēlē ar šo. Vai pat atstājiet to softfp.

. īkšķis (pret ieroci)

Šiem ARM mikrokontrolleriem faktiski ir instrukciju kopumu kombinācija. Viens ir ARM, otrs ir THUMB. Viena atšķirība ir 16 bitu un 32 bitu instrukcijas. Tādējādi šī direktīva nosaka kompilatoram turpmākos norādījumus uzskatīt par THUMB vai ARM.

Mēs vienkārši pieņemsim atlikušo faila daļu, jo šīs instrukcijas vēl nav iedziļinājušās pārtraukuma vadītajā montāžas programmēšanā.

7. solis: programmas “Sveika pasaule” montāžas versija

Iepriekš izveidotajā "core. S" failā var iekļaut arī tālāk norādīto. Tas atkal ir no raksta piemēra.

/ * * Atiestatīšanas apstrādātājs. Zvanīja pēc atiestatīšanas. */.type reset_handler, %function reset_handler: // Iestatiet kaudzes rādītāju uz kaudzes beigām. // Vērtība “_stack” ir definēta mūsu saistītāja skriptā. LDR r0, = _kraušana MOV sp, r0

// Iestatiet dažas fiktīvas vērtības. Kad mēs redzam šīs vērtības

// mūsu atkļūdotājā mēs zināsim, ka mūsu programma // ir ielādēta mikroshēmā un darbojas. LDR r7, = 0xDEADBEEF MOVS r0, #0 main_loop: // Pievienojiet 1, lai reģistrētu 'r0'. ADDS r0, r0, #1 // Atkārtota cilpa. B main_loop.size reset_handler,.-Reset_handler

Tātad iepriekš minētās programmas mērķis ir ielādēt atpazīstamu modeli vienā pamata MCU reģistrā (šajā gadījumā R7) un pieaugošu vērtību, kas sākas ar nulli, citā MCU pamatreģistrā (šajā gadījumā R0). Ja mēs ejam cauri izpildes kodam, mums vajadzētu redzēt R0 datu pieaugumu.

Ja esat sekojis instrukcijām saistībā ar MSP432 un TI-RSLK kursu/laboratorijām, tad gandrīz visai iepriekšminētajai programmai jums vajadzētu būt pazīstamai.

Viena jauna lieta, ko es varu redzēt, ir "=" izmantošana, ielādējot "DEADBEEF", lai reģistrētu R7. Mēs to nebijām izmantojuši.

Šeit pievienotajā failā "core. S" tagad ir viss avots.

8. darbība: koda apkopošana

Ir pienācis laiks veikt dažas komandrindas darbības. Beidzot kaut kas īsts.

Tomēr mēs neesam gluži tur. Mums atkal ir jāpielāgo rakstā sniegtā komanda un jāpārveido tā atbilstoši mūsu situācijai.

Šeit ir koda piemērs:

arm -none -eabi -gcc -x assembler -with -cpp -c -O0 -mcpu = cortex -m0 -mthumb -Wall core. S -o core.o

Ja mēs ejam uz GCC vietni gnu.org (šajā gadījumā 7.3. Versija),

x

-X ir valodas norādīšana. Pretējā gadījumā, ja nav -x, kompilators mēģinās uzminēt, izmantojot faila paplašinājumu. (mūsu gadījumā *. S).

Iepriekš minētajā piemērā no raksta ir norādīts montētājs-ar-cpp, bet mēs varētu vienkārši veikt montētāju.

c

-C saka: apkopot, bet nesaistīt.

O0

-O ir iestatīt optimizācijas līmeni. Izmantojot -0 (oh -nulle), tiek teikts: "saīsiniet apkopošanas laiku un veiciet atkļūdošanu, lai iegūtu gaidītos rezultātus. Tas ir noklusējums".

mcpu = garoza-m0

-Mcpu norāda mērķa procesora nosaukumu. Mūsu gadījumā tas būtu garozs-m4.

īkšķis

-Mthumb nosaka izvēli starp ģenerējošu kodu, kas izpilda ARM un THUMB stāvokļus.

Siena

Siena, protams, ir ļoti izplatīta un plaši pazīstama. Tas ieslēdz visus brīdinājuma karodziņus.

Visbeidzot, komandas beigās mums ir ievades faila kodols. S un izvades fails core.o.

Šeit ir jaunā komandrinda, kas atbilst mūsu konkrētajam gadījumam.

arm -none -eabi -gcc -x montētājs -c -O0 -mcpu = cortex -m4 -mthumb -Wall core. S -o core.o

Un tas apkopots.

9. darbība. Programmas saistīšana

Tieši no raksta piemēra mums ir šāds:

arm -none -eabi -gcc core.o -mcpu = cortex -m0 -mthumb -Wall --specs = nosys.specs -nostdlib -lgcc -T./STM32F031K6T6.ld -o main.elf

Lielākā daļa no iepriekš redzētajiem. Zemāk ir jaunumi.

specs = nosys.specs

Šo ir mazliet sarežģīti izskaidrot.

Tas ir saistīts ar "semihosting" un "retargeting", un tas ir saistīts ar ievadi / izvadi. Tas ir saistīts arī ar sistēmas zvaniem un bibliotēkām.

Parasti iegultās sistēmas nenodrošina standarta ievades/izvades ierīces. Tas ietekmētu sistēmas vai bibliotēkas zvanus (piemērs: printf ()).

Semihosting nozīmē, ka atkļūdotājam (skatiet 11. soļa attēlu ar atkļūdotāja daļu, kas apvilkts sarkanā krāsā) ir īpašs kanāls, un tas izmanto pusizvietošanas protokolu, un jūs varat redzēt printf () izvadi saimniekdatorā (izmantojot atkļūdotāju).

No otras puses, atkārtota mērķauditorijas atlase nozīmē, ka tie paši sistēmas vai bibliotēkas zvani nozīmē kaut ko citu. Viņi dara kaut ko citu, kas ir jēga iegultajai sistēmai. Savā ziņā, teiksim, printf (), ir jauna ieviešana, atkārtota šīs funkcijas ieviešana.

To visu sakot, --specs = nosys.specs nozīmē, ka mēs nepiedalīsimies puspiegādē. Parasti tas nozīmētu, ka mēs mērķējam vēlreiz. Tas noved mūs pie nākamā karoga.

nostdlib

Linker opcija -nostdlib tiek izmantota, lai saistītu programmu, kas paredzēta atsevišķai darbībai. -nostdlib nozīmē atsevišķas opcijas -nodefaultlibs un -nostartfiles. Tālāk mēs abas iespējas apspriežam atsevišķi, taču visizplatītākais lietojums ir tikai vienas pieturas iepirkšanās. Saistot mitinātu programmu, standarta sistēmas bibliotēkas, piemēram, libc, ir saistītas pēc noklusējuma, nodrošinot programmai piekļuvi visām standarta funkcijām (printf, strlen un draugi). Saistītāja opcija -nodefaultlibs atspējo saistīšanu ar šīm noklusējuma bibliotēkām; vienīgās saistītās bibliotēkas ir tieši tās, kuras jūs skaidri nosaucat saistītājam, izmantojot karodziņu -l.

lgcc

libgcc.a ir standarta bibliotēka, kas nodrošina iekšējās apakšprogrammas, lai novērstu konkrētu mašīnu trūkumus. Piemēram, ARM procesors neietver dalīšanas instrukciju. Libgcc.a ARM versijā ir dalīšanas funkcija, un kompilators vajadzības gadījumā izsauc zvanus uz šo funkciju.

T

Tas ir tikai veids, kā norādīt saistītājam izmantot šo failu kā saistītāja skriptu. Mūsu gadījumā faila nosaukums ir linker.script.ld.

o galvenais.pašam

Visbeidzot, mēs sakām saistītājam, kāds būs galīgā izvades attēla faila nosaukums, kas tiks ierakstīts/parādīts mūsu ierīcē.

Šeit ir mūsu pilnas komandrindas versija, kas pielāgota mūsu konkrētajai situācijai:

arm -none -eabi -gcc core.o -mcpu = cortex -m4 -mthumb -Wall --specs = nosys.specs -nostdlib -lgcc -T./linker.script.ld -o main.elf

Mēs pārliecināmies, ka skripta fails un core.o fails atrodas vienā direktorijā, kur mēs izpildīsim iepriekš minēto komandrindu.

Un tas ir saistīts bez problēmām.

Parbaude

Tad mēs skrienam:

arm-none-eabi-nm main.elf

un mēs iegūstam:

devchu@chubox: ~/Development/Atollic/TrueSTUDIO/STM32_workspace_9.1 $ arm-none-eabi-nm main.elf 20014000 A _estack 08000010 t main_loop 08000008 T reset_handler 08000000 T vtable

Izskatās labi. Komanda arm-none-eabi-nm ir veids, kā uzskaitīt simbolus objektu failos.

10. darbība. Testēšana Savienojums ar STM32 Nucleo-64

Ja izvēlaties to pieņemt, jūsu pirmā misija ir panākt, lai jūsu sistēma redzētu jūsu attīstības padomi.

Izmantojot Windows

Operētājsistēmai Windows es nolēmu instalēt TrueSTUDIO no Atollic (bezmaksas versija). Tā bija nesāpīga instalēšana, un tā automātiski instalēja draiveri, lai es varētu izmantot savienojumu, lai pārbaudītu savienojumu. Kad es instalēju TrueSTUDIO un ierīces pārvaldnieks ieraudzīja ierīci, es lejupielādēju texan/stlink rīkus, ko ieteica raksts Bare Metal. Es atkal ievietoju mapi tieši zem "C: \" un atkal izveidoju dažas saites no vietējās cygwin mājas tvertnes uz komandām.

ln -s /c/STM32. MCU/stlink-1.3.0-win64/bin/st-info.exe ~/bin/st-info

Sākotnēji pārbaudīju, vai mēs tiešām varam sazināties ar ierīci, es skrēju:

st-info-zonde

Un atgriezās:

Atrasti 1 stlink programmētāji

Tātad, tagad mēs zinām, ka varam runāt/vaicāt mūsu attīstības padomei.

Izmantojot Linux

Linux gadījumā jums nav īsti nepieciešams draiveris. Bet attiecībā uz Debian jums būs jāizveido st rīki no avota.

git klons

Pārliecinieties, vai esat instalējis libusb-1.0-0-dev.

trāpīgs saraksts | grep -E "*libusb.*dev*"

Jums vajadzētu redzēt:

libusb-1.0-0-dev/xenial, tagad 2: 1.0.20-1 amd64 [instalēts]

vai kaut kas tāds.

Lai to instalētu:

sudo apt-get install libusb-1.0-0-dev

Ņemiet vērā, ka iepriekš minētais nav tas pats, kas:

sudo apt-get install libusb-dev

Pareizi trūkstošais libusb izstrādātājs var radīt problēmas cmake.

CMake kļūda: šajā projektā tiek izmantoti šādi mainīgie, taču tie ir iestatīti uz NOTFOUND. Lūdzu, iestatiet tos vai pārliecinieties, vai tie ir pareizi iestatīti un pārbaudīti CMake failos: LIBUSB_INCLUDE_DIR (ADVANCED)

Pārslēdzieties uz projekta saknes direktoriju (… blah /blah /stlink). Veiciet "atbrīvošanu".

Pēc šīs būvēšanas rīkiem jābūt zem ".. /build /Release".

Pēc tam varat palaist "st-info --probe". Šeit ir izeja ar pievienotu Nucleo, tad ne.

devchu@chubox: ~/Development/stlink $./build/Release/st-info --probeAtrasts 1 stlink programmētāju sērija: 303636414646353034393535363537 openocd: "\ x30 / x36 / x36 / x41 / x46 / x46 / x35 / x30 / x34 / x39 / x35 / x35 / x36 / x35 / x37 "zibspuldze: 524288 (lapas izmērs: 2048) sram: 65536 chipid: 0x0446 descr: F303 augsta blīvuma ierīce devchu@chubox: ~/Development/stlink $./build/Release/st- info --probe Atrasti 0 stlink programmētāji devchu@chubox: ~/Development/stlink $

11. darbība: izmantosim GDB kopā ar Linux

Ja jūs visu to izmēģinājāt un esat nonācis tik tālu - lieliski! Lieliski. Tagad mazliet izklaidēsimies.

Pērkot šīs ARM izstrādes plates, neatkarīgi no tā, vai tās ir MSP432 palaišanas bloks no Texas Instruments vai šī, par kuru mēs tagad diskutējam, Nucleo-F303 (STM32 Nucleo-64), tās parasti ierodas jau mirgojot ar darbināmu programmu, parasti kāda mirgojoša programma, kas ietver arī slēdža nospiešanu, lai mainītu gaismas diodes (-ņu) mirgošanas ātrumu.

Pirms mēs tik ātri pārrakstām, paskatīsimies, kas tur ir jāredz un jādara.

Izmantojot Linux, atveriet termināli, nomainiet tikko izveidotā stlink git projekta direktoriju un atrodiet rīku st-util.

devchu@chubox: ~/Development/stlink $ find. -vārds st-util

./build/Release/src/gdbserver/st-util

Palaidiet šo rīku. Tā kā mēs jau iepriekš esam pārbaudījuši savu savienojumu ar st-info-probe, mums vajadzētu iegūt šādu rezultātu:

devchu@chubox: ~/Development/stlink $./build/Release/src/gdbserver/st-util

st-util 1.4.0-50-g7fafee2 2018-10-20T18: 33: 23 INFO common.c: Ierīces parametru ielāde…. 2018-10-20T18: 33: 23 INFO common.c: Pievienotā ierīce ir: F303 augsta blīvuma ierīce, id 0x10036446 2018-10-20T18: 33: 23 INFO common.c: SRAM izmērs: 0x10000 baiti (64 KiB), zibspuldze: 0x80000 baiti (512 KiB) 2048 baitu lapās 2018-10-20T18: 33: 23 INFO gdb-server.c: mikroshēmas ID ir 00000446, pamata ID ir 2ba01477. 2018-10-20T18: 33: 23 INFO gdb-server.c: Klausīšanās *: 4242…

Tas ir GDB serveris, kas pašlaik darbojas, un tas redz mūsu attīstības paneli, un vēl svarīgāk ir tas, ka tas klausās portā 4242 (noklusējuma ports).

Tagad mēs esam gatavi aktivizēt GDB klientu.

Sistēmā Linux atveriet citu termināli, ievadiet šo:

arm-none-eabi-gdb -tui

Tas ir tāds pats kā stingri komandrindas palaišana gdb, taču tā vietā tiek radīts uz tekstu balstīts terminālis (manuprāt, tas izmanto lāstus).

Mums darbojas GDB klients un GDB serveris. Tomēr klients nav savienots ar serveri. Pašlaik tā neko nezina par mūsu Nucleo (vai jūsu izvēlēto dēli). Mums tas ir jāpasaka. Terminālī jūsu uzvednei tagad vajadzētu būt "(gdb)". Ievadiet:

palīdzēt mērķim

Tas sniegs jums sarakstu. Ņemiet vērā, ka vēlamais ir paplašinātā tālvadības pults - izmantojiet attālo datoru, izmantojot seriālo līniju.

Bet mums ir arī jānorāda tā atrašanās vieta. Tātad, (gdb) uzvednē ievadiet:

(gdb) mērķa paplašināts attālais lokālais saimnieks: 4242

Jums vajadzētu saņemt šādu atbildi:

(gdb) mērķa paplašināts attālais lokālais saimnieks: 4242

Attālā atkļūdošana, izmantojot vietējo saimnieku: 4242 0x080028e4 in ?? ()

Tikmēr terminālī, kurā darbojas st-util gdbserver, mēs saņēmām šo:

2018-10-20T18: 42: 30 INFO gdb-server.c: atrasti 6 hw pārtraukumpunktu reģistri

2018-10-20T18: 42: 30 INFO gdb-server.c: savienots GDB.

12. solis: Atkārtosim, izmantojot Windows un Flash mūsu programmu

St-util gdbserver un arm-none-eabi-gdb klienta darbības ir būtībā tādas pašas kā iepriekšējā solī. Jūs atverat divus termināļus (cygwin, DOS cmd vai Windows Powershell), atrodat st-util atrašanās vietu, palaidiet to. Otrā terminālī palaidiet klientu-arm-none-eabi-gdb. Vienīgā atšķirība ir tāda, ka režīms -tui (uz termināļiem balstīts teksta skats), visticamāk, netiek atbalstīts.

Ja iepriekš minētais darbojās operētājsistēmā Windows, jums, iespējams, būs jāpārtrauc (tikai klients). Šajā brīdī jums kaut kā būs jāpalaiž GDB klients, kur atrodas jūsu būvēšanas fails ("core.out"), vai jāpievieno viss šī faila ceļš kā arguments GDB klientam.

Es vienkāršoju savu dzīvi, izmantojot cygwin un izveidojot saites no vietējā $ HOME // bin direktorija uz abiem šiem rīkiem.

Labi, mēs esam apkopojuši un saistījuši tāpat kā iepriekš, un mums ir fails main.elf, kas ir gatavs mirgošanai.

Mums vienā logā darbojas st-util. Mēs no jauna palaižam GDB klientu, šoreiz:

arm-none-eabi-gdb main.elf

Mēs ļaujam tam startēt, gaidām (gdb) uzvedni, izpildām to pašu savienojuma komandu ar GDB serveri (st-util), un esam gatavi izpildāmā faila mirgošanai. Tas ir ļoti pretklimatisks:

(gdb) slodze

Darbojoties ar Cygwin termināliem, ir zināma problēma, ka dažkārt konsoles komandas netiek izvadītas. Tātad mūsu gadījumā logs, kurā darbojas serveris, bija pilnīgi kluss. Tas, kurš vada klientu, kur mēs veicām slodzi, izvada šo:

Ielādē sadaļu.teksts, izmērs 0x1c lma 0x8000000Sākuma adrese 0x8000000, ielādes lielums 28 Pārsūtīšanas ātrums: 1 KB/sek, 28 baiti/rakstīt.

13. solis: mirgošana ar Linux - vairāk atlīdzības: D

14. solis: ienirsim mazliet dziļāk

Ja nokļuvāt šeit, lieliski. Ejam tālāk.

Kāpēc nepaskatīties izpildāmā faila main.elf iekšpusē? Izpildiet tālāk norādītās darbības.

arm-none-eabi-objdump -d main.elf

Jums vajadzētu redzēt šādu izvadi:

main.elf: faila formāts elf32-littlearm

Sadaļas.teksts demontāža:

08000000:

8000000: 00 40 01 20 09 00 00 08.@. ….

08000008:

8000008: 4802 ldr r0, [pc, #8]; (8000014) 800000a: 4685 mov sp, r0 800000c: 4f02 ldr r7, [pc, #8]; (8000018) 800000e: 2000 kustību r0, #0

08000010:

8000010: 3001 pievieno r0, #1 8000012: e7fd b.n 8000010 8000014: 20014000.word 0x20014000 8000018: deadbeef.word 0xdeadbeef

Kādus mazus gabaliņus mēs varam iegūt no iepriekš minētā rezultāta?

Ja atceraties, kad apspriedām un izveidojām failu linker.script.ld, mēs norādījām, ka šīm ARM ierīcēm ir RAM, sākot ar 0x20000000 un ka FLASH atmiņa sākas ar 0x08000000.

Tādējādi mēs redzam, ka programma patiešām ir tāda, ka tā visa atrodas FLASH atmiņā.

Tad, augstāk, bet vēlāk, kad mēs apspriedām daļu “Sveika pasaule”, bija paziņojums, kurā mēs ielādējam tūlītēju, nemainīgu burtisku vērtību ("0xDEADBEEF") MCU pamatreģistrā ("R7").

Paziņojums bija šāds:

LDR R7, = 0x DEADBEEF

Mūsu kodā tā ir vienīgā vieta, kur mēs pat pieminam DEADBEEF. Nē kur citur. Un tomēr, ja paskatās uz iepriekš minētajām izjauktajām/rekonstruētajām instrukcijām utt., Ar DEADBEEF ir vairāk, nekā mēs domājām.

Tātad, kompilators/saistītājs kaut kādā veidā nolēma pastāvīgi mirgot DEADBEEF vērtību FLASH adresē, vietā 0x8000018. Un tad kompilators mainīja mūsu iepriekš minēto LDR instrukciju, lai tā būtu šāda:

LDR R7, [PC, #8]

Tas mums pat radīja komentāru. Cik jauki. Un tas liek mums ņemt pašreizējo programmas skaitītāja vērtību (datora reģistru), pievienot šai vērtībai 0x8, un tieši tur DEADBEEF ir sadedzināts, un iegūt šo vērtību un ievietot to R7.

Tas nozīmē arī to, ka programmu skaitītājs (PC) norādīja uz adresi 0x8000010, kas ir main_loop sākums, un ka vērtība DEADBEEF atrodas divās adresēs pēc main_loop beigām.

15. solis: Visbeidzot, īss ieskats programmas darbībā

Pat ja jūs aizverat GDB, vienkārši vēlreiz ievadiet komandu. Jums pat nav jāpiešķir tam neviens fails; mēs vairs nemirgojam, tikai darbināmies.

Kad esat atkārtoti pievienojis GDB klientu GDB serverim, komandu uzvednē (gdb):

(gdb) informācijas reģistri

Jums vajadzētu redzēt kaut ko līdzīgu šim:

r0 0x0 0

r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 sp 0x20014000 0x20014000 lr 0xffffffff 42949600000

Bet pēc tam (gdb) uzvednē ievadiet:

(gdb) turpināt

Un ļoti ātri nospiediet CTRL-C. Tam vajadzētu apturēt programmas darbību. Vēlreiz ievadiet komandu "informācijas reģistri".

Šoreiz izskatās citādi:

(gdb) informācijas reģistri

r0 0x350ffa 3477498 r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0xdeadbeef 3735928559 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0x0x00x000000000000 16777216

Kas notika? Tieši tas, ko mēs gribējām. DEADBEEF tika ielādēts R7, un R0 (ārkārtīgi ātri) palielinās. Ja atkārtojat, atkal redzēsit R0 ar citu vērtību.

16. darbība. Mēs vēlējāmies Flash režīmā izveidot tikai lasāmu masīvu

Viens veids, kā izveidot masīva ekvivalentu, izmantojot montāžu un direktīvas, ir šāds:

.type myarray, %object // nosaukums vai iezīme 'myarray' ir definēts kā objekta tips.

myarray: // tas ir sākums deklarācijai “myarray” // (no kā tā sastāvēs)..word 0x11111111 // pirmais dalībnieks vai vērtība, kas ietverta 'myarray'..word 0x22222222 // otrā vērtība (blakus esošās adreses)..word 0x33333333 // un tā tālāk..size myarray,.-myarray // kompilators/montētājs tagad zina, kur beidzas vai // robeža 'myarray'.

Tagad, kad esam to iestatījuši FLASH atmiņā, mēs varam to izmantot programmā. Zemāk ir daļa:

LDR R1, myarray // tas ielādē datus, kas atrodas 'myarray' 1. vietā. ' // tas nav tas, ko mēs vēlamies.

LDR R1, = myarray // tas ielādē pašu atrašanās vietas vērtību (pirmā adrese), // ne dati.. // tas ir tas, ko mēs vēlamies.

MOV R2, #0 // R2 uzskaitīs, lai pārliecinātos, ka mēs neaiziesim

// masīva beigas. LDR R3, = myarrsize // R3 būs ekvivalents vārdam “myarrsize”.

// R0 glabās mūsu datus

main_loop:

LDR R0, [R1] // Ielādējiet R1 ('myarray') norādītos datus R0. CMP R2, R3 // Vai mēs esam masīva robežās? BEQ main_loop // Ja mēs esam, mēs esam pabeiguši, tāpēc mēs vienkārši uz visiem laikiem.

ADD R2, #1 // Pretējā gadījumā mēs varam turpināt atkārtot, izmantojot masīvu.

PIEVIENOT R1, #4 // Pievienot 4, lai reģistrētu R1, lai tas pareizi norādītu uz nākamo

// adrese..

B main_loop // Atkārtota cilpa.

Video iet cauri tam visam, un tajā ir kļūda. Ir labi; tas parāda, ka ir svarīgi palaist un atkļūdot kodu. Tas parāda klasisku gadījumu, kad aiziet no masīva beigām.