1. rész ARM összeszerelés TI RSLK Robotika tanulási tanterv 7 STM32 Nucleo: 16 lépés

2024 Szerző: John Day | [email protected]. Utoljára módosítva: 2024-01-30 09:40

Ennek az utasításnak a középpontjában az STM32 Nucleo mikrovezérlő áll. Ennek motivációja, hogy csupasz csontokból összerakási projektet lehessen létrehozni. Ez segít mélyebbre ásni és megérteni az MSP432 Launchpad projektet (a TI-RSLK), amely már több Instructables témája volt.

Az interneten nincs sok segítség a Code Composer Studio segítségével csak összeszerelési projekt létrehozásához az MSP432 számára. Eddig csak másoltunk/illesztettünk egy már meglévő összeszerelési projektből. Ez a megközelítés jól szolgált nekünk.

Most azonban a 7. labor esetében egy kis problémába ütköztünk. Vagy legalább egy átmeneti csuklás. A Lab 7 véges állapotú gépeket mutat be, és az első dolog, amivel találkozunk, az az, hogy létre kell hozni és használni kell egy értékrendet. Mivel a TI tanfolyam elsősorban C programozást használ - ez nem jelent problémát. De ezek az utasítások az összeszerelésre összpontosítottak, nem a C.

Továbbá, mivel a tömb csak olvasható értékű, jó lenne flash memóriába tenni, nem RAM-ba.

Úgy tűnik, hogy az STM32 MCU -t használó összeszerelési projektekhez sokkal több segítség áll rendelkezésre az interneten, ezért először ezzel az utasítással kezdjük, amelynek célja a tanultak felhasználása, majd az MSP432 -hez és a Code Composer Stúdióhoz való jelentkezés.

A cél felé vezető úton egy újabb, népszerű mikrovezérlővel is tapasztalatokat szereztünk.

1. lépés: Az eszköz kezdeti tesztelése

Ismét miért érdemes különösen az STM32 Nucleo -t választani?

Őszintén? Mivel jó cikkeket kerestem az ARM vezérlők csupasz fém összeszerelési projektjeiről, és rábukkantam erre a sorozatra. És azért is, mert az STM32 népszerű MCU -nak tűnik.

Végeztem némi kutatást (sok verzió közül lehet választani - lásd a fenti képet), de végül az lett, amit valójában megszerezhetek, mivel az Amazon -ot fogom használni (az Egyesült Államokban).

Egyszerű, de professzionális csomagban érkezik, néhány indítási utasítással. Kicsit vicces volt látni, hogy a vezérlőbe égetett demó majdnem pontosan az volt, amit a korábbi Instructables -ben tettünk - egy LED villog, és egy gombnyomásra változtatja a sebességet.

Úgy tűnik, hogy ez a fejlesztőpanel nagyon hasonlít az MSP432-hez, mivel 2 LED-et és egy felhasználói nyomógombot tartalmaz. Az MSP432 2 felhasználói gombbal rendelkezik.

Amint a fotókon is látszik, kicsit megdöbbentem, hogy a táblán mini és nem mikro USB van. El kellett fogynia, hogy vesz egy zsinórt.

Egy másik jó teszt az, hogy amikor csatlakoztatja a számítógéphez (Linux -fiókot használok), akkor megjelenik a fájlkezelőben, fájlrendszerként, "NODE_F303RE" néven. Nyitás, amely két fájlt tár fel, egy HTML -t és egy szöveget.

Ennyi, de legalább azt is mondja, hogy a csatlakozás meglehetősen egyszerűnek tűnik.

Most készen állunk a kezdésre.

Megpróbálom nem megismételni az IVONOMICON Bare Metal cikksorozat jó információit, inkább bővíteni.

2. lépés: Az alapvető

Az első dolog, amire szükségünk van, egy fordító.

És akkor szükségünk van egy hibakeresőre:

devchu@chubox: ~ $ sudo apt-get install gdb-arm-none-eabiCsomaglisták olvasása … Kész telepítve, 0 eltávolításra és 8 nincs frissítve. 2,722 kB archívumot kell beszereznie. A művelet után 7 738 kB további lemezterület kerül felhasználásra. Letöltés: 1 https://us.archive.ubuntu.com/ubuntu xenial/Universum amd64 gdb-arm-none-eabi amd64 7.10-1ubuntu3+9 [2, 722 kB] Letöltve 2, 722 kB 1 másodperc alatt (1, 988 kB/s) A korábban nem kiválasztott gdb-arm-none-eabi csomag kiválasztása. (Az adatbázis olvasása… 262428 fájl és könyvtár van telepítve.) A kicsomagolás előkészítése…/gdb-arm-none-eabi_7.10-1ubuntu3+9_amd64.deb… A gdb-arm-none-eabi kicsomagolása (7.10-1ubuntu3+9)… Feldolgozás trigger-man-db (2.7.5-1)… A gdb-arm-none-eabi beállítása (7.10-1ubuntu3+9)…

3. lépés: Az alapvető tudnivalók - Windows

A fenti lépés feltételezte, hogy Linuxot használunk. Mi van, ha Windows -ot használunk?

Lépjen az Arm Developer webhelyre, és számos letöltési lehetőség áll rendelkezésre. Windows 8 gépet használok.

A telepítés során úgy döntöttem, hogy a programfájlok helyett a gyökér "C: \" meghajtóra telepítem, csak mert én is cygwint használok, és könnyebb volt linket létrehozni a helyi tárolóból egy gyökér C: mappába, mint az összes rendetlenség a programfájlok elérési útján (szóközökkel stb.).

Így a cygwin környezetem és utam stb. Így néz ki:

C: / cygwin64 / home / bin / arm-none-eabi-gcc, ahol az arm-none-eabi-gcc egy link a C: / GNUToolsArmEmbedded / 7.2018.q2.update / bin / arm-none-eabi- gcc.

Ezután létrehoztam egy "dev" mappát a cygwin home alatt, és oda helyeztem a core. S fájlt, és futtattam a fordító parancsot. (a fordítóval kapcsolatban lásd alább).

Pontosan ugyanezt tettem a gdb-vel (arm-none-eabi-gdb).

4. lépés: Mi az alapvető

Tehát mi az a "gcc-arm-none-eabi"?

A gnu fordító (GCC) a programozási nyelveket (például a C -t) lefordítja annak a gépnek a natív kódjába, amelyen fut. Például, ha egy C kódot fordítana a GCC használatával a Windows gépén, akkor az a Windows gépen való futtatásra épülne. A generált végrehajtható fájl (általában) nem fut az ARM mikrovezérlőn.

Tehát ahhoz, hogy letölthető és az ARM mikrovezérlőbe írható programokat (jelen esetben ez az STM32 Nucelo legyen) felépítsünk, mást kell adnunk a GCC-nek: a "keresztfordítás" lehetőségét. Vagyis egy végrehajtható fájl létrehozásának képessége, nem a natív rendszeréhez (és a processzorához), hanem a célrendszerhez (az ARM mikrovezérlő). Itt jön szóba a "gcc-arm-none-eabi".

Akkor mi is az a "gdb-arm-none-eabi"?

Miután letöltöttük és elégettük (felvillantottuk) az újonnan létrehozott végrehajtható fájlt a mikrovezérlőbe, valószínűleg hibakeresést szeretnénk végrehajtani-lépésről sorra a kódon. A GDB a gnu hibakereső, és neki is szüksége van egy módra, hogy elvégezze a munkáját, de más rendszert kell megcéloznia.

Így a gdb-arm-none-eabi a GDB-nek, a gcc-arm-none-eabi a GCC-nek.

Egy másik javasolt csomagtelepítés a "libnewlib-arm-none-eabi" volt. Mi ez?

A Newlib egy C könyvtár és matematikai könyvtár, amelyet beágyazott rendszereken való használatra terveztek. Ez több könyvtári rész konglomerációja, amelyek mindegyike ingyenes szoftverlicencek alapján teszi könnyen használhatóvá a beágyazott termékeken.

És végül a "libstdc ++-arm-none-eabi" csomag. Ez elég nyilvánvaló; ez a keresztfordító C ++ könyvtára; beágyazott ARM mikrovezérlőkhöz.

5. lépés: A linkerfájl

Hozzunk létre linker szkriptet.

Ebben a fájlban az egyik kulcsrész vagy blokk a MEMORY parancs lenne.

--- from sourceware.org:

A linker alapértelmezett konfigurációja lehetővé teszi az összes rendelkezésre álló memória kiosztását. Ezt felülbírálhatja a MEMORY paranccsal. A MEMORY parancs a cél memóriablokkjainak helyét és méretét írja le. Segítségével leírhatja, hogy mely memóriarégiókat használhatja a linker, és mely memóriaterületeket kell kerülnie. Ezután szakaszokat rendelhet bizonyos memóriaterületekhez. A linker a memóriarégiók alapján állítja be a szakaszcímeket, és figyelmeztet a túlságosan megtelt régiókra. A linker nem keveri a szakaszokat, hogy illeszkedjen a rendelkezésre álló régiókba. A linker szkript a MEMORY parancs számos felhasználását tartalmazhatja, azonban az összes megadott memóriablokkot úgy kezelik, mintha egyetlen MEMORY parancsban adták volna meg. A MEMORY szintaxisa:

MEMÓRIA

{név [(attr)]: EREDET = eredet, HOSSZ = len…}

Példa a cikkben:

/* Határozza meg a RAM végét és a verem memória korlátját* //* (4KB SRAM az STM32F031x6 vonalon, 4096 = 0x1000)*//* (RAM a 0x20000000 címen kezdődik) _estack = 0x20001000;

MEMÓRIA

{VAKU (rx): EREDETI = 0x08000000, HOSSZ = 32K RAM (rxw): EREDETI = 0x20000000, HOSSZ = 4K}

Tehát ki kell találnunk, hogy mennyi FLASH (a programunkhoz és az állandókhoz stb.) És mennyi RAM (a program használatához; halom és verem stb.) Az adott táblához. Ez egy kicsit érdekessé válik.

A Nucleo -hoz mellékelt szép kis kártya azt mondja, hogy flash memóriája 512 Kbyte, az SRAM pedig 80 Kbyte. Az USB -hez csatlakoztatva azonban két fájlból álló fájlrendszerként kerül telepítésre, és mind a fájlkezelő, mind a GParted azt jelzi, hogy több mint 540 KB tárhelyet tartalmaz. (RAM?).

DE, ha megpróbálja törölni a két fájlt a fájlkezelővel, szétkapcsolja, majd újra csatlakoztatja az eszközt, akkor is megjelenik a két fájl. (és a fájlkezelő felismert valamit, mert minden fájlon van egy kis "zár" ikon.

Tehát menjünk a kártyán szereplő számokkal. Tehát most vegyük a fenti példát, és alakítsuk át a saját táblánkra.

Érdemes valami ilyesmit használni, mint ez az online memóriakonverter, hogy az általános KB -ról bizonyos bájtokra lépjen.

Akkor érdemes online decimális -hexadecimális konvertert használni.

/ * Határozza meg a RAM végét és a verem memória korlátját */

/* (4KB SRAM az STM32F031x6 vonalon, 4096 = 0x1000)* //* a példa*/

/ * 1. lépés: (80 KB SRAM az STM32F303RE -n, 81920 = 0x14000) * // * táblánk */

/* 2. lépés, adja hozzá a hexadecimális méretet a hexadecimális kezdőcímhez (alább). */

/ * (A RAM a 0x20000000 címről indul) */

_eszköz = 0x20001000; /* a példa */

_eszköz = 0x20014000; / * a testületünk */

MEMÓRIA {

VAKU (rx): EREDETI = 0x08000000, HOSSZ = 512K

RAM (rxw): EREDETI = 0x20000000, HOSSZ = 80K

}

Nevezzük a fenti fájlt "linker.script.ld" -nek.

6. lépés: A vektoros táblázat

Most létrehozunk egy kis szerelési fájlt (direktívákkal), hogy elvégezzünk néhány alapvető megszakítási kezelést. Követjük a cikk példáját, és létrehozunk egy "core. S" nevű fájlt.

Ismét itt van a példa fájl tartalma, de módosítottam a saját táblánkon:

// Ezek az utasítások meghatározzák chipünk és

// az összeszerelési nyelv, amelyet használni fogunk:.syntax unified /*Lásd alább ezt a kódterületet követően add hozzá a táblánk kéregét. lásd a fenti képet ebben a lépésben. van egy FPU */.thumb // Globális memóriahelyek..global vtable.global reset_handler / * * A tényleges vektoros táblázat. * Az egyszerűség kedvéért csak a RAM mérete és a „reset” kezelő * szerepel. */.type vtable, %object vtable:.word _estack.word reset_handler.size vtable,.-vtable

Hmm.. Nem „.align” irányelv

Ez azonban nem kritikus. Erről (talán) később.

.szintaxis egységes

. szintaxis [egységes | megosztott]

Ez az irányelv az utasításkészlet szintaxisát az ARM-utasításkészlet részben leírtak szerint állítja be

9.4.2.1 Utasításkészlet szintaxisa Két kissé eltérő szintaxis támogatja az ARM és a THUMB utasításokat. Az alapértelmezett felosztás a régi stílust használja, ahol az ARM és a THUMB utasításoknak saját, külön szintaxisa volt. Az új, egységes szintaxis, amely a.syntax direktíván keresztül választható ki.

.fpu vfpv4

A GCC fordító többféle lebegőpontos bináris fájlt tud készíteni: lágy - alkalmas CPU -n való futtatásra FPU nélkül - a számításokat szoftveren a fordító által generált softfp végzi - alkalmas CPU -n való futtatásra FPU -val vagy anélkül - ha van, akkor FPU -t fog használni. A mi esetünkben (saját kutatást kell végeznie), ennek a táblának az FPU -ja megfelel a vfpv4 -nek. Lehet, hogy ezzel kell játszani. Vagy akár hagyja a softfp -nél.

. hüvelykujj (vs. kar)

Ezek az ARM mikrokontrollerek valójában utasításkészletek keverékét tartalmazzák. Az egyik az ARM, a másik a THUMB. Az egyik különbség a 16 bites utasítások és a 32 bites utasítások között van. Így ez az irányelv arra utasítja a fordítót, hogy a későbbi utasításokat THUMB vagy ARM néven kezelje.

A fájl fennmaradó részét csak úgy vesszük, ahogy van, mivel ezek az utasítások még nem mélyültek el a megszakítás-vezérelt összeszerelés programozásában.

7. lépés: A „Hello World” program összeszerelő változata

A következők is mehetnek a korábban létrehozott "core. S" fájlba. Ez ismét a cikk példájából származik.

/ * * A Reset kezelő. Visszaállításkor hívták. */.type reset_handler, %function reset_handler: // Állítsa a veremmutatót a verem végére. // A "_estack" értéket a linker szkriptünk határozza meg. LDR r0, = _halmozás MOV sp, r0

// Állítson be néhány értéket. Amikor ezeket az értékeket látjuk

// hibakeresőnkben tudni fogjuk, hogy a programunk // be van töltve a chipre és működik. LDR r7, = 0xDEADBEEF MOVS r0, #0 main_loop: // Adjon hozzá 1 -et az 'r0' regisztrálásához. ADDS r0, r0, #1 // Hurok vissza. B main_loop.size reset_handler,.-Reset_handler

Tehát a fenti program célja, hogy egy felismerhető mintát töltsön be az egyik mag MCU regiszterbe (ebben az esetben R7), és egy nulláról induló értéket egy másik mag MCU regiszterbe (ebben az esetben R0). Ha átlépünk a végrehajtó kódon, látnunk kell az R0 adatnövekedését.

Ha követte az utasításokat az MSP432 és a TI-RSLK tanfolyam/laboratóriumok tekintetében, akkor a fenti programnak nagyjából ismerősnek kell lennie.

Az egyetlen új dolog, amit látok, a "=" használata a "DEADBEEF" betöltésekor az R7 regisztrálásához. Ezt nem használtuk.

Az itt csatolt "core. S" fájl a teljes forrást tartalmazza.

8. lépés: A kód összeállítása

Ideje néhány parancssori dolgot végrehajtani. Végre valami igazi.

Azonban nem egészen tartunk ott. Ismét módosítanunk kell a cikkben megadott parancsot, és a saját helyzetünkhöz kell igazítanunk.

Íme a példakód:

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

Ha felkeressük a GNU gnu.org webhelyét (ebben az esetben a 7.3 -as verziót),

x

A -x a nyelv megadása. Ellenkező esetben, ha nincs -x, akkor a fordító megpróbálja kitalálni a fájlkiterjesztést. (a mi esetünkben *. S).

A fenti példa a cikkben az assembler-with-cpp-t határozza meg, de csak összeállíthatjuk.

c

A -c azt mondja: fordíts, de ne linkelj.

O0

Az -O az optimalizálási szint beállítása. Az -O0 (oh -nulla) használata azt jelenti, hogy "csökkentse a fordítási időt, és a hibakeresés eredményezze a várt eredményeket. Ez az alapértelmezett".

mcpu = kéreg-m0

Az -mcpu adja meg a célprocesszor nevét. Esetünkben cortex-m4 lenne.

hüvelykujj

A -mthumb megadja az ARM és a THUMB állapotokat végrehajtó generáló kód közötti választást.

Fal

A -Fal természetesen nagyon gyakori és jól ismert. Minden figyelmeztető zászlót bekapcsol.

Végül a parancs végén megvan a core. S bemeneti fájl és a core.o kimeneti fájl.

Itt található az új parancssor, amely illeszkedik a konkrét esetünkhöz.

kar -nincs -eabi -gcc -x összeszerelő -c -O0 -mcpu = kéreg -m4 -hüvelykujj -falmag. S -o mag.o

És ez összeállítva.

9. lépés: A program összekapcsolása

Közvetlenül a cikk példájából ezt kapjuk:

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

A fentiek nagy részét láttad. Az alábbiakban az újdonságok olvashatók.

specs = nosys.specs

Ezt kicsit bonyolult megmagyarázni.

Ennek köze van a "félhosztáláshoz" és az "újracélzáshoz", valamint a bemenethez / kimenethez. Ez a rendszerhívásokhoz és a könyvtárakhoz is kapcsolódik.

A beágyazott rendszerek általában nem biztosítanak szabványos bemeneti/kimeneti eszközöket. Ez hatással lenne a rendszer- vagy könyvtári hívásokra (példa: printf ()).

A félhosztolás azt jelenti, hogy a hibakeresőnek (lásd a 11. lépés képét, amelynek a hibakereső része pirossal van körbevéve) van egy speciális csatornája, és a félhoszting protokollt használja, és láthatja a printf () kimenetét a gazdagépen (a hibakeresőn keresztül).

Az újracélzás viszont azt jelenti, hogy ugyanazok a rendszer- vagy könyvtári hívások mást jelentenek. Mást csinálnak, ami értelmes a beágyazott rendszer számára. Bizonyos értelemben, mondjuk a printf () esetében, van egy új implementáció, egy újrafelcélzott megvalósítása ennek a függvénynek.

Mindezek után a --specs = nosys.specs azt jelenti, hogy nem leszünk félhosztingok. Ez általában azt jelentené, hogy újra célzunk. Ez elvezet minket a következő zászlóhoz.

nostdlib

A -nostdlib linker opciót arra használjuk, hogy összekapcsoljunk egy önállóan futó programot. -nostdlib magában foglalja az egyes beállításokat -nodefaultlibs és -nostartfiles. Az alábbiakban külön tárgyaljuk a két opciót, de a legjellemzőbb felhasználási mód az egyablakos vásárlás. A tárolt programok összekapcsolásakor a szabványos rendszerkönyvtárak, mint például a libc, alapértelmezés szerint össze vannak kapcsolva, így a program hozzáférhet az összes alapfunkcióhoz (printf, strlen és barátai). A linker -nodefaultlibs beállítás letiltja az alapértelmezett könyvtárakkal való összekapcsolást; csak az összekapcsolt könyvtárak azok, amelyeket kifejezetten az -l jelzővel a linkernek nevez.

lgcc

A libgcc.a egy szabványos könyvtár, amely belső alprogramokat biztosít az egyes gépek hiányosságainak kiküszöbölésére. Például az ARM processzor nem tartalmaz osztási utasítást. A libgcc.a ARM verziója felosztási függvényt tartalmaz, és a fordító szükség esetén hívásokat bocsát ki erre a funkcióra.

T

Ez csak egy módja annak, hogy megmondja a linkelőnek, hogy használja ezt a fájlt linker szkriptként. Esetünkben a fájl neve linker.script.ld.

o fő.magam

Végül közöljük a linkelővel, hogy mi lesz a végső kimeneti képfájl neve, amelyet a készülékünkbe írnak/villognak.

Itt található a teljes parancssor verziója, amelyet az adott helyzethez módosítottunk:

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

Győződjünk meg arról, hogy a szkriptfájl és a core.o fájl ugyanabban a könyvtárban található, ahol a fenti parancssort futtatjuk.

És problémamentesen kapcsolódik.

Ellenőrzés

Ezután futunk:

kar-nincs-eabi-nm fő.maga

és kapjuk:

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

Jól néz ki. Az arm-none-eabi-nm parancs lehetővé teszi a szimbólumok listázását az objektumfájlokban.

10. lépés: Tesztelés Csatlakozás az STM32 Nucleo-64-hez

Az első küldetés, ha úgy dönt, hogy elfogadja azt, az, hogy a rendszer láthassa a fejlesztői fórumot.

A Windows használata

Windows esetén úgy döntöttem, hogy telepítem a TrueSTUDIO -t az Atollic -ból (ingyenes verzió). Fájdalommentes telepítés volt, és automatikusan telepítette az illesztőprogramot, hogy az st-link segítségével tesztelhessem a kapcsolatot. Miután telepítettem a TrueSTUDIO -t, és az eszközkezelő meglátta az eszközt, letöltöttem az általunk követett Bare Metal cikk által javasolt texan/stlink eszközöket. A mappát ismét közvetlenül a "C: \" alá helyeztem, és ismét létrehoztam néhány hivatkozást a helyi cygwin otthoni tárolóból a parancsokhoz.

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

Első tesztként annak megállapítására, hogy valóban tudunk -e kommunikálni az eszközzel, a következőket futtattam:

st-info-szonda

És visszajött:

Talált 1 stlink programozót

Tehát most már tudjuk, hogy beszélhetünk/lekérdezhetjük a fejlesztési táblánkat.

Linux használata

Linux esetén nem kell illesztőprogram. Debian esetén a st eszközöket a forrásból kell elkészítenie.

git klón

Győződjön meg róla, hogy a libusb-1.0-0-dev telepítve van.

találó lista | grep -E "*libusb.*dev*"

Látnod kéne:

libusb-1.0-0-dev/xenial, most 2: 1.0.20-1 amd64 [telepítve]

vagy valami ilyesmi.

Telepítése:

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

Vegye figyelembe, hogy a fentiek nem ugyanazok, mint:

sudo apt-get install libusb-dev

A helyes hiányzó libusb fejlesztő problémákat okozhat a cmake -ben.

CMake hiba: Ebben a projektben a következő változókat használják, de NOTFOUND értékre vannak állítva. Kérjük, állítsa be őket, vagy ellenőrizze, hogy helyesen vannak -e beállítva és tesztelve a CMake fájlokban: LIBUSB_INCLUDE_DIR (ADVANCED)

Váltson a projekt gyökérkönyvtárába (… blah /blah /stlink). Végezzen "kiadást".

A buildek után az eszközöknek a ".. /build /Release" alatt kell lenniük.

Ezután futtathatja az "st-info --probe" parancsot. Itt a kimenet, amikor a Nucleo csatlakoztatva van, akkor nem.

devchu@chubox: ~/Development/stlink $./build/Release/st-info --probeElső 1 stlink programozó sorozat: 303636414646353034393535363537 openocd: "\ x30 / x36 / x36 / x41 / x46 / x46 / x35 / x30 / x34 / x39 / x35 / x35 / x36 / x35 / x37 "flash: 524288 (oldalméret: 2048) sram: 65536 chipid: 0x0446 descr: F303 nagy sűrűségű eszköz devchu@chubox: ~/Development/stlink $./build/Release/st- info --probe Talált 0 stlink programozót devchu@chubox: ~/Development/stlink $

11. lépés: Használjuk a GDB -t Linux alatt

Ha mindezt kipróbálta, és idáig eljutott - nagyszerű! Kiváló. Most szórakozzunk egy kicsit.

Amikor megvásárolja ezeket az ARM fejlesztőlapokat, legyen szó akár a Texas Instruments MSP432 Launchpadről, akár erről, amelyről most beszélünk, a Nucleo-F303-ról (STM32 Nucleo-64), általában már futó programmal villogva érkeznek néhány villogó program, amely magában foglalja a kapcsoló megnyomását is a LED (ek) villogásának sebességének megváltoztatásához.

Mielőtt ilyen gyorsan túlírnánk, nézzük meg, mit kell látni és csinálni.

Linux alatt nyisson meg egy terminált, változtassa meg az éppen létrehozott stlink git projekt könyvtárát, és keresse meg az st-util eszközt.

devchu@chubox: ~/Development/stlink $ find. -név st-util

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

Futtassa az eszközt. Mivel korábban már teszteltük az összeköttetést az st-info --probe-val, valamilyen kimenetet kell kapnunk, mint például:

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: Eszközparaméterek betöltése…. 2018-10-20T18: 33: 23 INFO common.c: A csatlakoztatott eszköz: F303 nagy sűrűségű eszköz, azonosító: 0x10036446 2018-10-20T18: 33: 23 INFO common.c: SRAM-méret: 0x10000 bájt (64 KiB), Flash: 0x80000 bájt (512 KiB) 2048 bájtos oldalakon 2018-10-20T18: 33: 23 INFO gdb-server.c: A chip-azonosító 00000446, a Core-azonosító 2ba01477. 2018-10-20T18: 33: 23 INFO gdb-server.c: Hallgatás: *: 4242…

Ez a GDB szerver fut most, és látja a fejlesztőlapunkat, és ami még fontosabb, a 4242 -es porton (alapértelmezett porton) hallgat.

Most készen állunk a GDB kliens elindítására.

Linux alatt nyisson meg egy másik terminált, írja be ezt:

arm-none-eabi-gdb -tui

Ez ugyanaz, mint a gdb szigorúan parancssori futtatása, de ehelyett szövegalapú terminált hoz létre (feltételezem, hogy átkokat használ).

A GDB kliens és a GDB szerver fut. Az ügyfél azonban nem csatlakozik a szerverhez. Jelenleg semmit sem tud a Nucleo -ról (vagy az Ön által választott tábláról). El kell mondanunk. A terminálban a parancssornak a "(gdb)" -nek kell lennie. Belép:

segítség célpontja

Ez ad egy listát. Figyeljük meg, hogy az általunk kívánt kiterjesztett távoli cél - Használjon távoli számítógépet soros vonalon keresztül.

De meg kell adnunk a helyét is. Tehát a (gdb) parancssorba írja be:

(gdb) cél kiterjesztett távoli localhost: 4242

Valami ilyesmi választ kell kapnia:

(gdb) cél kiterjesztett távoli localhost: 4242

Távoli hibakeresés a localhost használatával: 4242 0x080028e4 in ?? ()

Eközben az st-util gdbservert futtató terminálon ezt kaptuk:

2018-10-20T18: 42: 30 INFO gdb-server.c: Talált 6 hw töréspont regisztert

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

12. lépés: Ismételjük meg, Windows -szal és Flash -el programunkat

Az st-util gdbserver és az arm-none-eabi-gdb kliens futtatásának lépései lényegében ugyanazok, mint az előző lépés során. Megnyit két terminált (cygwin, DOS cmd vagy Windows Powershell), megtalálja az st-util helyét, futtatja. A másik terminálon futtassa az arm-none-eabi-gdb ügyfelet. Az egyetlen különbség az, hogy a -tui (terminál -alapú szövegnézet) mód valószínűleg nem támogatott.

Ha a fentiek működtek a Windows rendszerben, akkor valószínűleg le kell állítania (csak az ügyfelet). Ezen a ponton valahogy futtatnia kell azt a GDB -ügyfelet, ahol a buildfájl található ("core.out"), vagy hozzá kell adnia a fájl teljes elérési útját argumentumként a GDB -ügyfélhez.

Leegyszerűsítettem az életemet a cygwin használatával, és linkeket hoztam létre a helyi $ HOME // bin könyvtárból arra a két eszközre.

Oké, ugyanúgy fordítottunk és linkeltünk, mint korábban, és a main.elf fájl készen áll a villogásra.

St-util fut egy ablakban. Újraindítjuk a GDB klienst, ezúttal:

arm-none-eabi-gdb main.elf

Hagyjuk, hogy elinduljon, várjuk a (gdb) parancssort, végezzük el ugyanazt a csatlakozási parancsot a GDB szerverrel (st-util), és készen állunk a végrehajtható fájl villogására. Nagyon klimatikus:

(gdb) terhelés

A cygwin terminálokkal futva ismert probléma, hogy a konzolparancsok néha nem jelennek meg. Tehát esetünkben a szervert futtató ablak teljesen néma volt. A kliens futtatója, ahol a terhelést futtattuk, ezt adja ki:

Szakasz betöltése.text, méret 0x1c lma 0x8000000Kezdési cím 0x8000000, betöltési méret 28 Átviteli sebesség: 1 KB/sec, 28 bájt/írás.

13. lépés: Villogás Linux alatt - több jutalom: D

14. lépés: Merüljünk egy kicsit mélyebben

Ha ideér, kiváló. Menjünk tovább.

Miért nem nézi meg a main.elf fájlt, a végrehajtható fájlt? Futtassa a következőt:

kar-nincs-eabi-objdump -d fő.maga

Valami ilyesmit kell látnia:

main.elf: fájlformátum elf32-littlearm

A.text szakasz szétszerelése:

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 mov r0, #0

08000010:

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

Milyen kis rögöket kaphatunk a fenti eredményből?

Ha visszaemlékszik a linker.script.ld fájl tárgyalásakor és létrehozásakor, kijelentettük, hogy ezeknek az ARM -eszközöknek a RAM -ja 0x20000000, a FLASH memória pedig 0x08000000 -tól kezdődik.

Láthatjuk tehát, hogy a program valóban olyan, hogy minden a FLASH memóriában van.

Aztán, fent, de egy későbbi lépésben, amikor a "Hello World" részről beszélgettünk, volt egy olyan kijelentés, amelyben azonnali, állandó, szó szerinti értéket ("0xDEADBEEF") töltünk be az MCU magregiszterébe ("R7").

A nyilatkozat a következő volt:

LDR R7, = 0x DEADBEEF

A kódunkban ez az egyetlen hely, ahol még a DEADBEEF -et is megemlítjük. Sehol máshol. És mégis, ha megnézi a fenti szétszerelt/rekonstruált utasításokat, stb., Több dolog van a DEADBEEF -rel kapcsolatban, mint gondoltuk.

Tehát a fordító/linkelő valahogy úgy döntött, hogy véglegesen felvillantja a DEADBEEF értékét egy FLASH -címbe, a 0x8000018 helyen. Ezután a fordító megváltoztatta a fenti LDR utasításunkat:

LDR R7, [PC, #8]

Még hozzászólást is generált számunkra. De kedves. És azt mondja, hogy vegyük az aktuális programszámláló értékét (a PC regisztert), adjunk hozzá 0x8 -at ehhez az értékhez, és ott égettük el a DEADBEEF -et, és vegyük le ezt az értéket, és töltsük be az R7 -be.

Ez azt is jelenti, hogy a programszámláló (PC) a 0x8000010 címre mutatott, ami a main_loop kezdete, és hogy a DEADBEEF érték a main_loop vége után két címen található.

15. lépés: Végül egy rövid áttekintés a program futásáról

Még akkor is, ha kilép a GDB-ből, írja be újra a parancsot. Még csak fájlokat sem kell megadnia; már nem villogunk, csak futunk.

Miután újra csatlakoztatta a GDB klienst a GDB szerverhez, a (gdb) parancssorban:

(gdb) információnyilvántartások

Valami ilyesmit kellene látnia:

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

De akkor a (gdb) parancssorba írja be:

(gdb) folytatás

És nagyon gyorsan nyomja meg a CTRL-C billentyűt. Ennek szüneteltetnie kell a programot. Írja be ismét az "info regiszterek" parancsot.

Ezúttal máshogy néz ki:

(gdb) információnyilvántartások

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

Mi történt? Pontosan amit akartunk. A DEADBEEF betöltődött az R7 -be, és az R0 (rendkívül gyorsan) növekszik. Ha megismétli, akkor ismét R0 jelenik meg egy másik értékkel.

16. lépés: Csak olvasható tömböt akartunk létrehozni vakuban

Az összeállítás és az irányelvek segítségével a tömb megfelelőjének létrehozásának egyik módja a következő:

.type myarray, %object // a "myarray" név vagy címke objektumtípusként van definiálva.

myarray: // ez a "myarray" deklarációjának kezdete // (miből fog állni)..word 0x11111111 // a "myarray" első tagja vagy értéke..word 0x22222222 // a második érték (szomszédos címek)..word 0x33333333 // és így tovább..size myarray,.-myarray // A fordító/assembler most már tudja, hol van a „myarray” vége vagy // határa.

Most, hogy beállítottuk a FLASH memóriába, használhatjuk a programban. Alább egy részlet:

LDR R1, myarray // ez betölti a "myarray" első helyén található adatokat. ' // ezt nem akarjuk.

LDR R1, = myarray // ez magát a helyértéket tölti be (az első cím), // nem az adatok.. // ezt akarjuk.

A MOV R2, #0 // R2 folyamatosan számol, hogy megbizonyosodjon arról, hogy nem megyünk el

// tömb vége. LDR R3, = myarrsize // R3 a "myarrsize" megfelelője lesz.

// R0 tárolja adatainkat

main_loop:

LDR R0, [R1] // Töltse be az R1 ('myarray') által mutatott adatokat az R0 -ba. CMP R2, R3 // A tömb határán vagyunk? BEQ main_loop // Ha igen, akkor végeztünk, így örökké csak hurkolni fogunk.

ADD R2, #1 // Ellenkező esetben továbbra is iterálhatunk tömbön keresztül.

ADD R1, #4 // 4 hozzáadása az R1 regisztrálásához, így helyesen mutat a következőre

// cím..

B main_loop // Hurok vissza.

A videó mindezt végigjárja, és van benne hiba. Ez jó; azt mutatja, hogy fontos a futtatás és hibakeresés kódja. Ez egy klasszikus esetet mutat, amikor egy tömb végéről sétálunk le.