1. osa ARM -i kokkupanek TI RSLK robootikaõppe õppekava labor 7 STM32 Nucleo: 16 sammu

2024 Autor: John Day | [email protected]. Viimati modifitseeritud: 2024-01-30 08:47

Selle juhendi keskmes on STM32 Nucleo mikrokontroller. Motivatsioon selleks, et oleks võimalik paljastest luudest koostamisprojekt luua. See aitab meil süveneda ja mõista MSP432 Launchpad projekti (TI-RSLK), millest on juba räägitud mitmetes juhistes.

Internetis ei ole Codep Composer Studio abil ainult montaažiprojekti loomiseks veebis palju abi. Siiani oleme lihtsalt kopeerinud/kleepinud olemasolevast kokkupanekuprojektist. See lähenemine on meid hästi teeninud.

Kuid nüüd, laboris 7, oleme kokku puutunud mõne probleemiga. Või vähemalt ajutine luksumine. Lab 7 tutvustab piiratud olekuga masinaid ja esimene asi, millega kokku puutume, on vajadus luua ja kasutada väärtuste massiivi. Kuna TI kursusel kasutatakse peamiselt C programmeerimist - see pole probleem. Kuid need juhendid on keskendunud kokkupanekule, mitte C.

Lisaks, kuna massiivil on kirjutuskaitstud väärtused, oleks hea panna see välkmällu, mitte RAM-i.

Tundub, et STM32 MCU -d kasutavate kokkupanekuprojektide jaoks on veebis palju rohkem abi, seega alustame sellest juhendist, mille eesmärk on kasutada õpitut, et seejärel taotleda MSP432 ja Code Composer Studio.

Teel selle eesmärgi poole oleme saanud kogemusi veel ühe populaarse mikrokontrolleriga.

Samm: seadme esialgne testimine

Jällegi, miks valida just STM32 Nucleo?

Ausalt? Kuna ma otsisin häid artikleid ARM-kontrollerite palja metalli kokkupanekuprojektide kohta ja sattusin selle sarja juurde. Ja ka seetõttu, et STM32 näib olevat populaarne MCU.

Ma tegin mõningaid uuringuid (valida on palju versioone - vt ülaltoodud pilti), kuid lõpuks sai sellest, mida ma tegelikult saan, kuna kavatsesin kasutada Amazoni (USA -s).

See on lihtsas, kuid professionaalses pakendis, kus on mõned käivitamisjuhised. Natuke naljakas oli näha, et kontrollerisse põletatud demo oli peaaegu täpselt see, mida oleme teinud varasemates Instructablesides - LED vilgub ja muudab kiirust vastavalt nupuvajutusele.

Tundub, et see arendusplaat on MSP432-ga väga sarnane, kuna seal on 2 LED-i ja üks kasutaja nupp. MSP432-l on 2 kasutaja nuppu.

Nagu fotodelt näha, olin ma natuke hämmingus, et plaadil on mini, mitte mikro -USB. Pidin otsa saama, et juhe osta.

Teine hea test on see, et kui ühendate selle arvutiga (kasutan Linuxi kasti), kuvatakse see minu failihalduris failisüsteemina nimega "NODE_F303RE". Avamine, mis avab kaks faili, ühe HTML -i ja ühe teksti.

See on kõik, kuid vähemalt ütleb see ka, et ühenduvus tundub üsna lihtne.

Nüüd oleme valmis alustama.

Püüan mitte korrata IVONOMICON Bare Metal artiklite sarja head teavet, vaid pigem seda täiendada.

2. samm: põhitõed

Esimene asi, mida vajame, on kompilaator.

Ja siis vajame silurit:

devchu@chubox: ~ $ sudo apt-get install gdb-arm-none-eabiPakettide loendite lugemine … Valmis Sõltuvuspuu ehitamine Olekuteabe lugemine … Valmis Installitakse järgmised uued paketid: gdb-arm-none-eabi 0 täiendatud, 1 uus installitud, 0 eemaldamiseks ja 8 uuendamata. Vaja hankida 2,722 kB arhiive. Pärast seda toimingut kasutatakse 7 738 kB täiendavat kettaruumi. Hankige: 1 https://us.archive.ubuntu.com/ubuntu xenial/universum amd64 gdb-arm-none-eabi amd64 7.10-1ubuntu3+9 [2, 722 kB] Leitud 2, 722 kB 1 s (1, 988 kB/s) Varem valimata paketi gdb-arm-none-eabi valimine. (Andmebaasi lugemine … Praegu on installitud 262428 faili ja kataloogi.) Ettevalmistus lahtipakkimiseks…/gdb-arm-none-eabi_7.10-1ubuntu3+9_amd64.deb… gdb-arm-none-eabi (7.10-1ubuntu3+9) lahtipakkimine … Töötlemine käivitab man-db (2.7.5-1) … gdb-arm-none-eabi seadistamine (7.10-1ubuntu3+9)…

Samm: põhialused - Windows

Ülaltoodud samm eeldas, et kasutame Linuxit. Mis siis, kui kasutame Windowsi?

Võite minna arendaja saidile ja saadaval on mitu allalaadimisvalikut. Ma kasutan Windows 8 masinat.

Paigaldamise ajal otsustasin selle installida programmifailide asemel juurdraivile "C: \" lihtsalt sellepärast, et kasutan ka cygwini, ja oli lihtsam luua link kohalikust prügikastist kausta C: kui kõik segadus programmifailide teel (tühikutega jne).

Seega näeb minu cygwini keskkond ja tee jne välja selline:

C: / cygwin64 / home / bin / arm-none-eabi-gcc, kus arm-none-eabi-gcc on link saidile C: / GNUToolsArmEmbedded / 7.2018.q2.update / bin / arm-none-eabi- gcc.

Seejärel lõin cygwini kodu alla kausta "dev" ja sinna paigutasin faili core. S ja käivitasin kompilaatori käsu. (vaadake allpool kompileerija asju).

Ma tegin täpselt sama asja gdb (arm-none-eabi-gdb) puhul.

4. samm: mis on põhiline

Mis siis on "gcc-arm-none-eabi"?

Gnu kompilaator (GCC) kompileerib programmeerimiskeeled (nt C) selle seadme jaoks, milles see töötab, oma algkoodi. Näiteks kui kompileeriksite oma Windowsi masinas GCC abil mõnda C -koodi, oleks see loodud Windowsi masinas töötamiseks. Loodud käivitatav fail ei tööta (tavaliselt) ARM-i mikrokontrolleril.

Niisiis, selleks, et luua programme, mida saab alla laadida ja põletada ARM-i mikrokontrollerisse (praegusel juhul oleks see STM32 Nucelo), peame GCC-le andma midagi muud: võime "ristkompileerida". See tähendab, et võime genereerida käivitatava faili mitte oma natiivsüsteemi (ja protsessori), vaid sihtsüsteemi (ARM-i mikrokontrolleri) jaoks. Seal tuleb mängu "gcc-arm-none-eabi".

Mis siis on "gdb-arm-none-eabi"?

Kui oleme äsja loodud käivitatava faili mikrokontrollerisse alla laadinud ja põletanud (vilgutanud), tahame tõenäoliselt seda siluda-samm-sammult koodi rida. GDB on gnu silur ja ka see vajab oma töö tegemiseks viisi, kuid sihib teist süsteemi.

Seega on gdb-arm-none-eabi GDB-le, mis gcc-arm-none-eabi on GCC-le.

Teine soovitatud paketi install oli "libnewlib-arm-none-eabi". Mis see on?

Newlib on C -raamatukogu ja matemaatikakogu, mis on mõeldud kasutamiseks manussüsteemides. See on mitmete raamatukogu osade kogum, mis kõik on tasuta tarkvaralitsentside alusel ja muudavad need hõlpsasti kasutatavaks manustatud toodetel.

Ja lõpuks pakett "libstdc ++-arm-none-eabi". See on üsna ilmne; see on ristkompilaatori C ++ raamatukogu; sisseehitatud ARM-i mikrokontrollerite jaoks.

Samm: linkerifail

Loome linkeri skripti.

Üks selle faili võtmeosa või plokk oleks käsk MEMORY.

--- from sourceware.org:

Linkeri vaikekonfiguratsioon võimaldab eraldada kogu saadaoleva mälu. Saate selle käsu MEMORY abil tühistada. Käsk MEMORY kirjeldab sihtmärgi mäluplokkide asukohta ja suurust. Selle abil saate kirjeldada, milliseid mälupiirkondi linkija võib kasutada ja milliseid mälupiirkondi ta peab vältima. Seejärel saate sektsioone määrata teatud mälu piirkondadele. Linkija määrab jaotiste aadressid mälupiirkondade alusel ja hoiatab liiga täis olevate piirkondade eest. Linkija ei sega juhuslikult sektsioone, et need sobiksid saadaolevate piirkondadega. Linkeri skript võib sisaldada käsu MEMORY mitmeid kasutusviise, kuid kõiki määratletud mäluplokke käsitletakse nii, nagu oleksid need määratud ühe MEMORY käsu sees. MEMORY süntaks on:

MÄLU

{nimi [(attr)]: PÄRITOLU = päritolu, PIKKUS = len…}

Näide artiklis:

/* Määrake RAM -i lõpp ja virna mälu piir* //* (4KB SRAM liinil STM32F031x6, 4096 = 0x1000)*//* (RAM algab aadressilt 0x20000000) _estack = 0x20001000;

MÄLU

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

Seega peame välja mõtlema, kui palju FLASH -i (meie programmi ja konstantide jaoks jne) ja kui palju RAM -i (programmi jaoks kasutamiseks; hunnik ja virn jne) meie konkreetsele tahvlile. See läheb natuke huvitavaks.

Kena väike kaart, mis Nucleoga kaasas on, ütleb, et sellel on välkmälu 512 ja SRAM 80 kbaiti. USB -ga ühendades paigaldatakse see aga kahe failiga failisüsteemiks ning nii failihaldur kui ka GParted näitavad, et sellel on üle 540+ baiti ruumi. (RAM?).

AGA, üritades failihalduri abil neid kahte faili kustutada, seadme lahtiühendamine ja uuesti ühendamine kuvab need kaks faili. (ja failihaldur tundis midagi ära, sest igal failil on väike "luku" ikoon.

Nii et lähme kaardil olevate arvudega. Nüüd võtame ülaltoodud näite ja teisendame selle meie konkreetseks tahvliks.

Võib -olla soovite kasutada sellist veebimälu muundurit, et minna üldiselt KB -lt kindlale baitide arvule.

Seejärel võiksite kasutada veebipõhist kümnendkoha -heksamuundurit.

/ * Määrake RAM -i lõpp ja virna mälu piirang */

/* (4KB SRAM liinil STM32F031x6, 4096 = 0x1000)* //* näide*/

/ * 1. samm: (80 KB SRAM seadmel STM32F303RE, 81920 = 0x14000) * // * meie plaat */

/* 2. samm, lisage kuuekuuruse suurus kuuendiku algsele aadressile (allpool). */

/ * (RAM algab aadressilt 0x20000000) */

_pasta = 0x20001000; / * näide */

_pasta = 0x20014000; / * meie juhatus */

MÄLU {

Välk (rx): PÄRITOLU = 0x08000000, PIKKUS = 512K

RAM (rxw): PÄRITOLU = 0x20000000, PIKKUS = 80K

}

Nimetagem ülaltoodud faili "linker.script.ld".

6. samm: vektoritabel

Nüüd loome väikese kokkupanekufaili (koos direktiividega), et teha väga lihtne katkestuste käsitlemine. Järgime artikli näidet ja loome faili nimega "core. S".

Jällegi on siin näidisfaili sisu, kuid tegin meie konkreetse tahvli jaoks muudatuse:

// Need juhised määratlevad meie kiibi ja

// koostamiskeel, mida me kasutame:.syntax unified /*Vaadake pärast seda koodiala* //*.cpu cortex-m0* / /*kommenteerige seda näidete rida* /.cpu cortex-m4 /* lisage selle asemel meie juhatuse koor. vaadake ülaltoodud pilti selles etapis * / /*.fpu softvfp * / / *kommenteerige seda näidete rida * /.fpu vfpv4 / *lisage meie plaadi asemele; sellel on FPU */.thumb // Globaalsed mälukohad..global vtable.global reset_handler / * * Tegelik vektoritabel. * Lihtsuse huvides on * kaasas ainult RAM -i suurus ja lähtestuskäitleja. */.type vtable, %object vtable:.word _estack.word reset_handler.size vtable,.-vtable

Hmm.. Ei '.align' direktiivi

See pole siiski kriitiline. Sellest (võib -olla) hiljem.

.süntaks ühendatud

.süntaks [ühtne | jagatud]

See direktiiv seab käsukomplekti süntaksi nii, nagu on kirjeldatud jaotises ARM-instruktsioonikomplekt

9.4.2.1 Käskude komplekti süntaks ARM- ja THUMB -juhiste tugi on kaks veidi erinevat süntaksi. Vaikimisi, jagatud, kasutatakse vana stiili, kus ARM ja THUMB juhistel oli oma eraldi süntaks. Uus ühtne süntaks, mille saab valida.syntax direktiivi kaudu.

.fpu vfpv4

GCC kompilaator suudab toota binaarfaile, millel on ujukomaga mitu võimalust: pehme - sobib töötamiseks protsessoritel ilma FPU -ta - arvutused tehakse tarkvara abil kompilaatori loodud softfp abil - sobib töötamiseks protsessoritel koos FPU -ga või ilma - kasutab FPU -d, kui see on olemas. Meie konkreetse juhtumi puhul (peate ise uurima), vastab selle plaadi FPU standardile vfpv4. Võimalik, et peate sellega mängima. Või jätke see isegi softfp -le.

. thumb (vs. arm)

Nendel ARM -i mikrokontrolleritel on tegelikult käsukomplektide segu. Üks on ARM, teine on pöidla. Üks erinevus on 16-bitised ja 32-bitised juhised. Seega käsib see direktiiv kompilaatoril käsitleda järgnevaid juhiseid kas THUMB või ARM.

Me võtame ülejäänud faili lihtsalt sellisena, nagu see on, kuna need juhised pole veel süvenenud katkestuspõhise koostamise programmeerimisse.

7. samm: programmi „Tere maailm” kokkupaneku versioon

Järgmine võib minna ka varem loodud "core. S" faili. See on jällegi artikli näitest.

/ * * Lähtestaja. Helistati lähtestamisel. */.type reset_handler, %function reset_handler: // Seadista virnaosuti virna lõppu. // Väärtus „_estack” on määratletud meie linkeri skriptis. LDR r0, = _pasta MOV sp, r0

// Määrake mõned näiväärtused. Kui me näeme neid väärtusi

// meie silurist teame, et meie programm // on kiibile laaditud ja töötab. LDR r7, = 0xDEADBEEF MOVS r0, #0 main_loop: // Lisa 1, et registreerida 'r0'. ADDS r0, r0, #1 // Loop tagasi. B main_loop.size reset_handler,.-Reset_handler

Niisiis, ülaltoodud programmi eesmärk on laadida äratuntav muster ühte tuuma MCU registrisse (antud juhul R7) ja kasvav väärtus, mis algab nullist teise MCU tuumregistrisse (antud juhul R0). Kui astume läbi käivituskoodi, peaksime nägema R0 andmete juurdekasvu.

Kui olete MSP432 ja TI-RSLK kursuse/laboratooriumi juhenditega järginud, peaksid peaaegu kõik ülaltoodud programmid teile tuttavad olema.

Üks uus asi, mida ma näen, on "=" kasutamine "DEADBEEF" laadimisel R7 registreerimiseks. Me polnud seda kasutanud.

Siia lisatud fail "core. S" sisaldab nüüd täielikku allikat.

8. samm: koodeksi koostamine

On aeg teha käsurea asju. Midagi tõelist, lõpuks.

Siiski pole me päris seal. Peame jälle artiklis antud käsku kohandama ja seda vastavalt oma olukorrale muutma.

Siin on näite kood:

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

Kui läheme GCC saidile gnu.org (antud juhul versioon 7.3),

x

-X on keele määramine. Vastasel juhul, kui ei -x, proovib kompilaator faililaiendi abil ära arvata. (meie puhul *. S).

Ülaltoodud näide artiklist määratleb assembleri koos cpp-ga, kuid me võiksime lihtsalt teha monteerija.

c

-C ütleb kompileeri, kuid ära linki.

O0

-O on optimeerimistaseme määramine. Kasutades -O0 (oh -null), öeldakse "lühendage kompileerimisaega ja laske silumisel saada oodatud tulemused. See on vaikimisi".

mcpu = ajukoor-m0

-Mcpu määrab sihtprotsessori nime. Meie puhul oleks see cortex-m4.

pöial

-Mthumb määrab ARM- ja THUMB -olekuid käivitava koodi loomise vahel valimise.

Sein

Sein on muidugi väga levinud ja tuntud. See lülitab sisse kõik hoiatuslipud.

Lõpuks on käsu lõpus sisendfail core. S ja väljundfail core.o.

Siin on tulemuseks uus käsurida, mis sobib meie konkreetse juhtumiga.

arm -none -eabi -gcc -x assembly -c -O0 -mcpu = cortex -m4 -mthumb -Wall core. S -o core.o

Ja see koostati.

9. samm: programmi linkimine

Otse artikli näitest näeme järgmist:

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

Enamikku ülaltoodutest olete näinud. Allpool on uudised.

specs = nosys.specs

Seda on natuke keeruline seletada.

See on seotud "semihosting" ja "retargeting" ning sisend / väljund. See on seotud ka süsteemikõnede ja raamatukogudega.

Tavaliselt ei paku manussüsteemid standardseid sisend-/väljundseadmeid. See mõjutaks süsteemi- või raamatukogukõnesid (näide: printf ()).

Semihosting tähendab, et siluril (vt 11. sammu pilt koos silumisosaga, mis on ümbritsetud punasega) on spetsiaalne kanal ja see kasutab poolpaigutusprotokolli ning näete printf () väljundit masinas (siluri kaudu).

Uuesti sihtimine tähendab seevastu, et need sama süsteemi või raamatukogu kõned tähendavad midagi muud. Nad teevad midagi muud, mis on sisseehitatud süsteemi jaoks mõttekas. Mõnes mõttes, näiteks printf () jaoks, on uus rakendus, selle funktsiooni uuesti suunatud rakendus.

Olles seda kõike öelnud, tähendab --specs = nosys.specs, et me ei ole poolhosting. See tähendaks tavaliselt, et me sihime uuesti. See viib meid järgmise lipuni.

nostdlib

Lingivalikut -nostdlib kasutatakse eraldiseisvaks käitamiseks mõeldud programmi linkimiseks. -nostdlib tähendab üksikuid valikuid -nodefaultlibs ja -nostartfiles. Allpool käsitleme kahte võimalust eraldi, kuid kõige tavalisem kasutusviis on ühest kohast ostmiseks lihtsalt nostdlib. Hostitud programmi linkimisel on standardse süsteemi teegid, näiteks libc, vaikimisi lingitud, andes programmile juurdepääsu kõigile standardfunktsioonidele (printf, strlen ja sõbrad). Lingivalik -nodefaultlibs keelab linkimise nende vaiketeekidega; ainsad lingitud teegid on need, mille nimetate linkijale selgesõnaliselt -l lipu abil.

lgcc

libgcc.a on standardne raamatukogu, mis pakub sisemisi alamprogramme teatud masinate puuduste kõrvaldamiseks. Näiteks ARM -protsessor ei sisalda jagamisjuhiseid. Libgcc.a ARM -versioon sisaldab jagamisfunktsiooni ja kompilaator saadab vajadusel sellele funktsioonile kõnesid.

T

See on lihtsalt viis käskida linkijal kasutada seda faili linkeri skriptina. Meie puhul on failinimi linker.script.ld.

o peamine. ise

Lõpuks ütleme linkijale, mis saab olema lõpliku väljundpildifaili nimi, mis meie seadmesse põletatakse/välgutatakse.

Siin on meie versioon täielikust käsureast, mida on meie konkreetse olukorra jaoks muudetud:

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

Veendume, et skriptifail ja core.o-fail on mõlemad samas kataloogis, kus käivitame ülaltoodud käsurea.

Ja see ühendab probleemideta.

Tšekk

Seejärel jookseme:

arm-none-eabi-nm main.elf

ja saame:

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

Näeb hea välja. Käsk arm-none-eabi-nm on viis sümbolite loetlemiseks objektifailides.

10. samm: testimine Ühendus STM32 Nucleo-64-ga

Kui otsustate selle aktsepteerida, on teie esimene ülesanne saada oma süsteem oma arendusnõukogule.

Windowsi kasutamine

Windowsi jaoks otsustasin installida TrueSTUDIO Atollicist (tasuta versioon). See oli valutu install ja see installis draiveri automaatselt, et saaksin ühenduse testimiseks kasutada st-linki. Kui installisin TrueSTUDIO ja seadmehaldur seadet nägi, laadisin alla tekstiili/stlinki tööriistad, mida soovitasime palja metalli artiklis, mida oleme järginud. Panin kausta uuesti otse "C: \" alla ja lõin jälle mõned lingid oma kohalikust cygwini kodukastist käskudele.

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

Esialgse testina, et näha, kas suudame seadmega tõesti suhelda, jooksin:

st-info-sond

Ja tuli tagasi:

Leiti 1 stlink programmeerija

Nüüd teame, et saame oma arendusnõukogust rääkida/päringuid teha.

Linuxi kasutamine

Linuxi jaoks pole draiverit tegelikult vaja. Kuid Debiani jaoks peate st -tööriistad ehitama allikast.

git kloon

Veenduge, et olete installinud libusb-1.0-0-dev.

tabav nimekiri | grep -E "*libusb.*dev*"

Peaksite nägema:

libusb-1.0-0-dev/xenial, nüüd 2: 1.0.20-1 amd64 [installitud]

või midagi sellist.

Selle installimiseks toimige järgmiselt.

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

Pange tähele, et ülaltoodud ei ole sama:

sudo apt-get install libusb-dev

Õige puuduv libusb -arendaja võib põhjustada probleeme cmake'iga.

CMake viga: Selles projektis kasutatakse järgmisi muutujaid, kuid nende väärtuseks on seatud NOTFOUND. Palun määrake need või veenduge, et need oleksid CMake failides õigesti seadistatud ja testitud: LIBUSB_INCLUDE_DIR (ADVANCED)

Muutke projekti juurkataloogi (… blah /blah /stlink). Tehke "vabastage".

Pärast koostamist peaksid tööriistad olema jaotises ".. /build /Release".

Seejärel saate käivitada "st-info --probe". Siin on väljund ühendatud Nucleoga, siis mitte.

devchu@chubox: ~/Development/stlink $./build/Release/st-info --probeLeitud 1 stlink-programmeerija seeria: 303636414646353034393535363537 openocd: "\ x30 / x36 / x36 / x41 / x46 / x46 / x35 / x30 / x34 / x39 / x35 / x35 / x36 / x35 / x37 "välk: 524288 (lehekülje suurus: 2048) sram: 65536 chipid: 0x0446 descr: F303 suure tihedusega seade devchu@chubox: ~/Development/stlink $./build/Release/st- info --probe Leiti 0 stlink programmeerijat devchu@chubox: ~/Development/stlink $

Samm 11: Kasutame Linuxiga GDB -d

Kui olete seda kõike proovinud ja nii kaugele jõudnud - suurepärane! Suurepärane. Lõbutseme nüüd natuke.

Kui ostate need ARM-i arendusplaadid, olenemata sellest, kas need on Texas Instrumentsi MSP432 käivitusplaat või see, millest me praegu räägime, Nucleo-F303 (STM32 Nucleo-64), jõuavad need tavaliselt juba käivitatud programmiga, tavaliselt mõni vilkuv programm, mis sisaldab ka lüliti vajutamist, et muuta LED -ide vilkumise kiirust.

Enne kui me nii kiiresti üle kirjutame, vaatame, mida seal näha ja teha on.

Linuxiga avage terminal, muutke äsja ehitatud stlink git projekti kataloogi ja leidke tööriist st-util.

devchu@chubox: ~/Development/stlink $ find. -nimi st-util

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

Käivitage see tööriist. Kuna oleme juba varem oma ühendust st-info --probega testinud, peaksime saama väljundi järgmiselt:

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: Seadme parameetrite laadimine…. 2018-10-20T18: 33: 23 INFO tavaline. C: ühendatud seade on: F303 suure tihedusega seade, id 0x10036446 2018-10-20T18: 33: 23 INFO tavaline. C: SRAM-i suurus: 0x10000 baiti (64 KiB), välk: 0x80000 baiti (512 KiB) 2048 baiti lehekülgedel 2018-10-20T18: 33: 23 INFO gdb-server.c: kiibi ID on 00000446, põhi-ID on 2ba01477. 2018-10-20T18: 33: 23 INFO gdb-server.c: kuulamine *: 4242…

See on praegu töötav GDB -server ja näeb meie arendusplaati ning mis veelgi olulisem - kuulab pordi 4242 (vaikimisi kasutatav port) kaudu.

Nüüd oleme valmis GDB kliendi käivitama.

Avage Linuxis teine terminal, sisestage see:

arm-none-eabi-gdb -tui

See on täpselt sama, mis gdb rangelt käsurea käitamine, kuid see toodab hoopis tekstipõhist terminali (arvan, et see kasutab needusi).

Meil töötab GDB klient ja GDB server. Klient pole aga serveriga ühendatud. Praegu ei tea see meie Nucleost (või teie valitud plaadist) midagi. Me peame seda ütlema. Terminalis peaks teie viip olema nüüd "(gdb)". Sisenema:

abi sihtmärk

See annab teile nimekirja. Pange tähele, et soovitud sihtmärk on laiendatud kaugjuhtimispult - kasutage jadaühenduse kaudu kaugarvutit.

Kuid me peame andma sellele ka asukoha. Niisiis, sisestage (gdb) viiba:

(gdb) sihtmärk laiendatud kaugjuhtimisega kohalik hosti: 4242

Peaksite vastama sellisele vastusele:

(gdb) sihtmärk laiendatud kaugjuhtimisega kohalik hosti: 4242

Kaugseadistamine kohaliku hosti abil: 4242 0x080028e4 in ?? ()

Vahepeal saime terminalis, kus töötab st-util gdbserver, järgmine:

2018-10-20T18: 42: 30 INFO gdb-server.c: leitud 6 hw katkestusregistrit

2018-10-20T18: 42: 30 INFO gdb-server.c: GDB on ühendatud.

12. samm: kordame Windowsiga ja välgutame oma programmi

St-util gdbserveri ja arm-none-eabi-gdb kliendi käitamise sammud on sisuliselt samad, mis eelmisel etapil. Avad kaks terminali (cygwin, DOS cmd või Windows Powershell), leiad st-utili asukoha, käivitad selle. Käivitage teises terminalis klient-arm-none-eabi-gdb klient. Ainus erinevus on see, et režiimi -tui (terminalipõhine tekstivaade) tõenäoliselt ei toetata.

Kui ülaltoodud toimis Windowsis, peate tõenäoliselt peatama (ainult klient). Siinkohal peate kuidagi käivitama GDB -kliendi, kus on teie ehitusfail ("core.out"), või lisama sellele failile kogu tee GDB -kliendile argumendina.

Ma lihtsustasin oma elu, kasutades cygwini ja luues oma kohalikust kataloogist $ HOME // bin linke mõlema tööriista elukohta.

Ok, oleme kompileerinud ja linkinud nagu varemgi ning meil on fail main.elf valmis vilkuma.

Meil töötab st-util ühes aknas. Käivitame GDB kliendi uuesti, seekord teeme järgmist.

arm-none-eabi-gdb main.elf

Lasime sellel käivituda, ootame (gdb) viipa, teeme sama ühenduse käskluse GDB serveriga (st-util) ja oleme valmis käivitatavat käivitama. See on väga kliimavastane:

(gdb) koormus

Cygwini terminalidega töötades on teadaolev probleem, et mõnikord konsooli käske ei väljastata. Nii et meie puhul oli serverit käivitav aken täiesti vaikne. See, kes töötab klienti, kus me koormust käivitasime, väljastab selle:

Laaditakse sektsioon.text, suurus 0x1c lma 0x8000000Alustaadress 0x8000000, laadimissuurus 28 Edastuskiirus: 1 KB/s, 28 baiti/kirjutamine

13. samm: vilkumine Linuxiga - rohkem tasustamist: D

14. samm: sukeldume veidi sügavamale

Kui siia jõudsite, suurepärane. Liigume edasi.

Miks mitte vaadata faili main.elf, käivitatavat faili? Käivitage järgmine:

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

Peaksite nägema sellist väljundit:

main.elf: failivorming elf32-littlearm

Jaotise.tekst demonteerimine:

08000000:

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

08000008:

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

08000010:

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

Milliseid väikeseid tükke saame ülaltoodud väljundist?

Kui mäletate linker.script.ld -faili arutamisel ja loomisel, väitsime, et nende ARM -seadmete RAM -i väärtus algab 0x20000000 ja FLASH -mälu algab 0x08000000 -st.

Seega näeme, et programm on tõepoolest selline, et see kõik asub FLASH -mälus.

Siis, ülalpool, kuid hilisemas etapis, kui arutasime osa "Tere maailm", oli lause, kus laadime MCU põhiregistrisse ("R7") kohese, konstantse ja sõnasõnalise väärtuse ("0xDEADBEEF").

Avaldus oli järgmine:

LDR R7, = 0xDEADBEEF

Meie koodis on see ainus koht, kus me isegi mainime DEADBEEF -i. Mitte kusagil mujal. Ja siiski, kui vaatate ülaltoodud lahtivõetud/rekonstrueeritud juhiseid jne, on DEADBEEFiga seotud rohkem, kui arvasime.

Niisiis otsustas kompilaator/linkija kuidagi DEADBEEF väärtuse jäädavalt välgutada Flash -aadressiks, asukohas 0x8000018. Ja siis muutis kompilaator meie ülaltoodud LDR juhised järgmiselt:

LDR R7, [PC, #8]

See tekitas meile isegi kommentaari. Kui kena. Ja see käsib meil võtta praeguse programmi loenduri väärtuse (arvuti register), lisada sellele väärtusele 0x8 ja see on koht, kus DEADBEEF on põletatud, ning saada see väärtus ja sisestada see R7 -sse.

See tähendab ka seda, et programmiloendur (PC) osutas aadressile 0x8000010, mis on main_loopi algus, ja et väärtus DEADBEEF asub kahel aadressil pärast main_loopi lõppu.

Samm 15: Lõpuks lühike ülevaade programmi käitamisest

Isegi kui lõpetate GDB, sisestage lihtsalt käsk uuesti. Te ei pea isegi sellele ühtegi faili andma; me ei vilgu enam, vaid käivitame selle.

Kui olete GDB-kliendi GDB-serveriga uuesti ühendanud, klõpsake käsureal (gdb) järgmist.

(gdb) teaberegistrid

Peaksite nägema midagi sellist:

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 42x490000000

Seejärel sisestage (gdb) viipale järgmine käsk:

(gdb) jätkata

Ja vajutage väga kiiresti CTRL-C. See peaks programmi peatama. Sisestage uuesti käsk "inforegistrid".

Seekord näeb see välja teisiti:

(gdb) teaberegistrid

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 0x0x00x000000000000000000000000000000 16777216

Mis juhtus? Täpselt see, mida tahtsime. DEADBEEF laaditi R7 -sse ja R0 on (ülikiirelt) kasvamas. Kui kordate, näete uuesti väärtust R0 teise väärtusega.

16. samm: tahtsime luua Flash-vormingus kirjutuskaitstud massiivi

Üks viis massiivi ekvivalendi loomiseks koostamise ja direktiivide abil on järgmine:

.type myarray, %object // nimi või silt 'myarray' on määratletud objektitüübina.

myarray: // siit algab deklaratsioon „myarray” // (millest see koosneb)..word 0x11111111 // esimene liige või väärtus, mis sisaldub jaotises "myarray"..word 0x22222222 // teine väärtus (külgnevad aadressid)..sõna 0x33333333 // ja nii edasi..size myarray,.-myarray // koostaja/kokkupanija teab nüüd, kus on 'myarray' lõpp või // piir.

Nüüd, kui oleme selle FLASH -mällu seadistanud, saame seda programmis kasutada. Allpool on osa:

LDR R1, myarray // see laadib andmed, mis sisalduvad "myarray" 1. asukohas. " // seda me ei taha.

LDR R1, = myarray // see laadib asukoha väärtuse ise (1. aadress), // mitte andmed.. // seda me tahame.

MOV R2, #0 // R2 peab arvestust, et veenduda, et me ei kõnni minema

// massiivi lõpp. LDR R3, = myarrsize // R3 on samaväärne sõnaga "myarrsize".

// R0 hoiab meie andmeid

main_loop:

LDR R0, [R1] // Laadige R1 ('myarray') osutatud andmed R0 -sse. CMP R2, R3 // Kas oleme massiivi piiril? BEQ main_loop // Kui oleme, siis oleme valmis, nii et me lihtsalt igavesti loopime.

ADD R2, #1 // Vastasel juhul võime jätkata massiivi kaudu kordamist.

ADD R1, #4 // R1 registreerimiseks lisage 4, nii et see osutab õigesti järgmisele

// aadress..

B main_loop // Loop tagasi.

Video läbib selle kõik ja selles on viga. See on hea; see näitab, et see on oluline käivitus- ja silumiskood. See näitab klassikalist juhtumit massiivi otsast eemaldumisel.