Binutils, gcc, newlib, gdb

Dankzij de inspanningen van vrijwilligers en bedrijven heeft de Gnu compiler collectie degelijke support voor ARM cores. Bij het configureren van de build van de cross compiler moet expliciet worden opgegeven dat ondersteuning voor thumb modus, software floating point math, interworking (switchen tussen ARM en THUMB instructieset) en een niet standaard libc gewenst is.

Dit wordt bekomen door de ./configure commando's de argumenten --enable-interwork --enable-multilib --with-float=soft mee te geven. Merk op dat alvorens deze argumenten herkend worden, het bestand gcc/config/arm/t-arm-elf uit de gcc source tree gepatcht dient te worden, een gepatcht t-arm-elf bestand is te vinden op de http://www.gnuarm.com website.

Het bouwen van binutils gcc, de newlib C-library en gdb heb ik geautomatiseerd met een script dat te vinden is in de bijlage.

PATH=/opt/gnuarm-4.1.1/bin
ROOTPATH=/opt/gnuarm-4.1.1/bin
LDPATH=/opt/gnuarm-4.1.1/lib

lpc2isp

Lpc2isp bestaat uit een enkel bronbestand, lpc2isp.c, en kan door de host compiler eenvoudig worden gecompileerd

#versie 1.32 van embedded artists uitpakken
#compileren met host-gcc
gcc lpc2isp -o /usr/bin/lpc2isp
#uitvoerbaar maken
chmod +x /usr/bin/lpc2isp

Het gebruik is heel simpel:

lpc21isp test.hex /dev/ttyUSB0 115200 14746

OpenOCD

Ik heb de OpenOCD versie uit de cvs gebruikt

#unmasken van libftdi in gentoo
echo dev-embedded/libftdi >>/etc/portage/package.keywords
#libftdi installeren
emerge libftdi
#bron afhalen
svn checkout svn://svn.berlios.de/openocd/trunk
#make met ondersteuning voor de chip in de arm-usb-ocd
./configure --enable-ft2232_libftdi
make
make install

Makefile

Bij software waar meer dan enkele bronbestanden aan te pas komen, gebruikt men Makefiles om het compilatieproces te automatiseren. Als deze Makefiles flexibel opgebouwd zijn, laat dit toe, door het wijzigen van enkele variabelen of declaraties, heel het compilatieproces te beïnvloeden. Zo zullen er variabelen zijn die het formaat van de resulterende binary gaan bepalen (elf/intel hex/binair), of er THUMB of ARM instructies gaan gegenereerd worden (compiler flags), welke optimalisatie flags gebruikt gaan worden en welk link script gebruikt gaat worden. Kortom alle instellingen die je bij een (commerciële) IDE in het project properties dialoogvenster zou terugvinden.

Start-up code

Tussen het moment dat de klokfrequentie gestabiliseerd is (en de programmateller begint te lopen), en de uitvoering van main(), dienen nog wat formaliteiten te gebeuren. Zo dienen andere de PLL klok vermenigvuldiger en de MAM geconfigureerd te worden, de stack voor de verschillende operating modes ingesteld te worden. Dit neemt de startup code (die in assembler geschreven is) voor zijn rekening, ook worden hier de interrupt vectors gedefinieerd.

De complexiteit van de startup code van de bluetooth-board-demo grenst ongeveer aan het onmenselijke. Er wordt namelijk gebruik gemaakt van de C preprocessor. Dit heeft tot gevolg dat op basis van de instellingen in het bestand config.h, de PLL en MAM juist geconfigureerd worden. Enkel oppervlakkige dingen, zoals gewenste kristal- en klokfrequentie, dienen opgegeven te worden.

Linkerscript

Het linkerscript wordt door de Linker (het programma dat de objectbestanden van de compiler en de gebruikte libraries combineert tot een solide executable) gezien als zijn opdracht. Met dit bestand kunnen we bepalen welke geheugengebieden gebruikt gaan worden (zowel flash als ram), en waar uiteindelijk de code uitgevoerd gaat worden (soms is het wenselijk de code vanuit ram uit te voeren, omwille van de lage toegangstijd). Hier volgt een chronologische bespreking van het linkerscript, aangezien dit script zeer cruciaal is.

De executable vangt aan bij de _startup: label

ENTRY(_startup)

De declaratie van de memory map is als volgt voor de LPC2104 controller (128k flash en 16k ram):

MEMORY
{
  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00020000
  RAM   (rw) : ORIGIN = 0x40000000, LENGTH = 0x00004000
}

Vervolgens wordt in de SECTIONS{} clausule gespecifieerd welke delen van de code waar moeten komen. Men vangt aan met de .text sectie, die gebruikt wordt voor de startupcode (*startup.o (.text)) en de programmacode (*(.text))

.text :
{
  *startup.o (.text)
  *(.text)
  *(.glue_7)
  *(.glue_7t)
} > FLASH = 0
. = ALIGN(4);

De ALIGN(4) statement zorgt ervoor dat na de programmacode de locatieteller wordt verhoogd tot de volgende 32-bit grens

De constantes volgen:

.rodata :
{
  *(.rodata)
  *(.rodata*)
} > FLASH
. = ALIGN(4);

Vervolgens wordt het symbool _etext gedefinieerd als het adres na de laatste codebyte.

_etext = . ;
PROVIDE (etext = .);

Geïnitialiseerde variabelen volgen in de flash na de constantes, dus op het adres _etext. Deze zijn bedoeld voor de ram (Ox4...80), en dienen hier dan ook naar gecopieerd te worden (> RAM). Ook hierna wordt er een symbool gedefinieerd.

.data 0x40000080: AT (_etext)
{
  _data = . ;
  *(.data)
  SORT(CONSTRUCTORS)
} > RAM
. = ALIGN(4);

_edata = . ;
PROVIDE (edata = .);

Ongeïnitialiseerde variabelen, de .bss sectie, hoeven niet in het ram te worden geladen.

.bss (NOLOAD):
{
  _bss          = . ;
  __bss_start   = . ;
  __bss_start__ = . ;
  *(.bss)
  *(COMMON)
  . = ALIGN(4);
} > RAM
. = ALIGN(4);
__bss_end   = . ;
__bss_end__ = . ;
_end = . ;
PROVIDE (end = .);

Dit besluit het linkerscript.

Conclusie

Het valt te betwisten of deze ontwikkelomgeving een goede keuze vormt voor studenten van de richting elektronica-ICT. Spelen met al deze ingewanden is toch wel te hoog gegrepen met onze achtergrond. Met mijn eindwerk -waar ik gcc-arm ga gebruiken- in het verschiet is deze investering echter toch niet voor niets geweest. Vanuit mijn achtergrond was dit alles vrij nieuw, maar echte informatici hebben over deze materie natuurlijk al enkele dikke cursussen achter de kiezen.

lpc21isp

Het gebruik van de lpc21isp tool wijst zichzelf uit. Toch kan ik twee opmerkingen maken. De handshake signalen van de USB-serial converter zijn via jumpers verbonden met de controller (Reset aan DTR, EnableBootLoader aan RTS). Men mag dus niet vergeten -control te gebruiken bij het aanroepen van het programma!

lpc21isp -control test.hex /dev/ttyUSB0 115200 14746

Als in de commandoregel ook -term opgenomen wordt, gaat de programmer in terminal modus als het downloaden klaar is. Dit is handig in sommige gevallen.

OpenOCD debugger

Openocd is een daemon die het mogelijk maakt de ARM via JTAG te bedienen. Er kan gebruik worden gemaakt van simpele hardware die aan de printerpoort is aangesloten. Kant en klare hardware zoals de arm-usb-ocd, die met behulp van een synchrone uart met usb interface de JTAG chain aanstuurt, is echter een betere optie.

OpenOCD implementeert twee communicatiekanalen met de gebruiker: een telnet daemon en een gdb server, waardoor de Gnu debugger gebruikt kan worden.

In bijlage is de gebruikte configuratie te bekijken. De OpenOCD daemon moet met root permissies worden gestert (met sudo), omdat het toegang tot de usb poort nodig heeft. Als argument krijgt het ook -f configuratiebestand mee.

Voorbeeldsessie

thomas@bauknecht ~/hutsepot $ arm-elf-gdb
GNU gdb 6.6
(gdb) source gdbinit
main () at main.c:70
70      }
target state: halted
target halted in ARM state due to debug request, current mode: System
cpsr: 0x4000001f pc: 0x400036dc
requesting target halt and executing a soft reset
software breakpoints enabled
0xe01fc040: 00000001
(gdb) list
65                      IOSET = LED_RED_PIN;
66                      printf("B");
67                      while (RTC_SEC == MIR_SEC) {}
68                      MIR_SEC = RTC_SEC;
69              }
70      }
(gdb) watch MIR_SEC
Hardware watchpoint 1: MIR_SEC
(gdb) continue
Continuing.
Hardware watchpoint 2: MIR_SEC

Old value = 6 '\006'
New value = 45 '-'
0x000002d6 in main () at main.c:70
70      }
(gdb) continue
Continuing.
Hardware watchpoint 2: MIR_SEC

Old value = 45 '-'
New value = 49 '1'
0x000002aa in main () at main.c:64
64                      IOCLR = LED_GREEN_PIN;
(gdb) print MIR_SEC
$2 = 49 '1'
(gdb) quit

stdio.h

Zoals bekend, wordt in de C programmeertaal doorgaans gebruik gemaakt van de printf() en scanf() functies om te communiceren met een gebruiker aan een terminal. Indien er een onderliggend operating system is, kan er gebruik worden gemaakt van de standard io streams die deze biedt. In het geval van een stand-alone toepassing op een microcontroller is dit echter anders. Zo dient de gebruiker zelf printf() te implementeren, ofwel dienen zelfgeschreven putc() getc() functies aan de (in dit geval newlib) C-library te worden gekoppeld. Het 'framework' van de democode implementeert de putc() functie zelf. Er wordt gebruik gemaakt van UART 0 of 1. In de config.h headerfile kan gekozen worden of de printf() functie van newlib wordt gebruikt of een dieet functie van het huis. In dit laatste geval wordt 22kb aan flash gespaard.

Realtime clock

De realtimeclock wordt gedreven door een 32khz referentie. Deze wordt bekomen door de periferieklok door een deler te halen. Aangezien de PLL vermenigvuldigingsfactor gelijk is aan de deler die gebruikt wordt om de periferiebus te klokken, wordt de kristalwaarde bij de berekening gebruikt. (de berekening is met python in interactieve modus gedaan)

>>> pclk = 14745600
>>> PREINT= int((pclk/32768)) - 1
>>> PREFRAC = int(pclk - ((PREINT+1) * 32768))
>>> print "PREINT  = 0x%.8x\nPREFRAC = 0x%.8x" % (PREINT,PREFRAC)
PREINT  = 0x000001c1
PREFRAC = 0x00000000