Tux fliegt zu den Sternen

Aus BraLUG-Wiki

(Unterschied zwischen Versionen)
Wechseln zu: Navigation, Suche
(gcc-arm-none-eabi auf Basis der Energia-Installation)
(Stellaris Launchpad)
 
(18 dazwischenliegende Versionen von einem Benutzer werden nicht angezeigt)
Zeile 7: Zeile 7:
  
 
=Stellaris Launchpad=
 
=Stellaris Launchpad=
 +
 +
[[Bild:Stellaris launchpad.jpg|thumb|200px|Stellaris Launchpad]]
 
[http://www.ti.com/tool/EK-LM4F120XL Herstellerseite...]
 
[http://www.ti.com/tool/EK-LM4F120XL Herstellerseite...]
  
 
=Toolchain=
 
=Toolchain=
 
==Energia==
 
==Energia==
Möchte man sich nicht gleich am Anfang mit der Installation/Konfiguration einer entsprechenden gcc-Umgebung herumschlagen, reicht für erste Experimente [http://energia.nu/ Energia] aus. Das entsprechende Dowload-Paket enthält alle notwendigen Komponenten zum Übersetzen von eigenen Programmen und deren Übertragung auf das Launchpad. Die Archivdatei wird einfach in ein Verzeichnis entpackt und dann kann es sofort (zumindestens bei der aktuellen Version 0101E0010) losgehen. Viele der mitgelieferten Beispiele funktionieren, nach Auswahl des richtigen Board unter dem Menüpunkt "Tools" → "Boards", problemlos.
+
Möchte man sich nicht gleich am Anfang mit der Installation/Konfiguration einer entsprechenden gcc-Umgebung herumschlagen, reicht für erste Experimente [http://energia.nu/ Energia] aus. Das entsprechende Dowload-Paket enthält alle notwendigen Komponenten zum Übersetzen von eigenen Programmen und deren Übertragung auf das Launchpad. Die Archivdatei wird einfach in ein Verzeichnis entpackt und dann kann es sofort (zumindestens bei der aktuellen Version 0101E0010) losgehen. Viele der mitgelieferten Beispiele funktionieren, nach Auswahl des richtigen Boards unter dem Menüpunkt "Tools" → "Boards", problemlos.
  
Nebenbei, unterlagert arbeitet ein gcc-arm-none-eabi! Also kann man auch gleich etwas "Vernünftiges" verwenden. Es bietet sich aber auch an, diese, mit Energia installierte Toolchain, auch ausserhalb dieser IDE zu benutzen, zumal ja damit auch bereits die [http://www.ti.com/tool/sw-lm3s StellarisWare] von TI "gebrauchsfertig" ist. Diese Vorgehensweise soll im folgenden Kapitel beschrieben werden.
+
==Kommandozeilen-Toolchain auf Basis einer Energia-Installation==
 +
Ist schon eine funktionierende Energia-Installation auf seinem Rechner vorhanden, braucht man eigentlich nicht noch einen Compiler zu installieren, unterlagert werkelt dort schon ein arm-none-eabi-gcc. Es reicht also den Pfad zu den Binaries des Compilers mit in die PATH-Variable aufzunehmen, also z.B. die Datei .bashrc im eigenen Homeverzeichnis zu erweitern:
 +
<pre>
 +
# Cross-Compiler-Umgebung fuer Stellaris Launchpad
 +
export PATH=$PATH:$HOME/energia/hardware/tools/lm4f/bin
 +
</pre>
  
==gcc-arm-none-eabi auf Basis einer funktionierenden Energia-Installation==
+
Will man das Rad nicht ständig neu erfinden, sollte man die frei erhältliche [http://www.ti.com/tool/sw-ek-lm4f120xl StellarisWare] von TI (alternativ auch von [https://github.com/yuvadm/stellaris hier]) installieren. Das heruntergeladene Archivfile entpackt man dazu in ein beliebiges Verzeichnis auf seinem Rechner und führt dort das Makefile aus:
 +
<pre>
 +
$ make
 +
</pre>
  
Ausgangspunkt der weiteren Ausführungen ist eine lauffähige Energia-Installation im Verzeichnis ~/energia/.
 
  
.bashrc im eigenen Homeverzeichnis erweitern:
+
Hier ein entsprechendes Makefile, mit dem man dann seine eigenen Programme generieren und auf die MCU flashen kann:
 
<pre>
 
<pre>
# Cross-Compiler-Umgebung fuer Stellaris Launchpad
+
TARGET = main
export PATH=$PATH:$HOME/energia/hardware/tools/lm4f/bin
+
 
 +
STELLARISWARE = ~/work/stellaris/stellarisware
 +
SRC = $(wildcard *.c)
 +
TOOLCHAIN = arm-none-eabi
 +
PART = LM4F120H5QR
 +
CPU = cortex-m4
 +
FPU = fpv4-sp-d16
 +
FABI = softfp
 +
 
 +
LINKER_FILE = $(STELLARISWARE)/boards/ek-lm4f120xl/hello/hello.ld
 +
SRC += $(STELLARISWARE)/boards/ek-lm4f120xl/hello/startup_gcc.c
 +
 
 +
CC = $(TOOLCHAIN)-gcc
 +
LD = $(TOOLCHAIN)-ld
 +
CP = $(TOOLCHAIN)-objcopy
 +
OD = $(TOOLCHAIN)-objdump
 +
SZ = $(TOOLCHAIN)-size
 +
 
 +
CFLAGS = -mthumb -mcpu=$(CPU) -mfpu=$(FPU) -mfloat-abi=$(FABI)
 +
CFLAGS+= -Os -ffunction-sections -fdata-sections
 +
CFLAGS+= -MD -std=c99 -Wall -pedantic
 +
CFLAGS+= -DPART_$(PART) -c -DTARGET_IS_BLIZZARD_RA1
 +
CFLAGS+= -g
 +
CFLAGS+= -I $(STELLARISWARE)
 +
 
 +
LIB_GCC_PATH=$(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
 +
LIBC_PATH=$(shell $(CC) $(CFLAGS) -print-file-name=libc.a)
 +
LIBM_PATH=$(shell $(CC) $(CFLAGS) -print-file-name=libm.a)
 +
LIBSW_PATH=$(STELLARISWARE)/driverlib/gcc-cm4f/*.o
 +
LFLAGS = --gc-sections --entry ResetISR
 +
CPFLAGS = -Obinary
 +
 
 +
ODFLAGS = -S
 +
 
 +
FLASHER=lm4flash
 +
FLASHER_FLAGS=-v
 +
 
 +
OBJS = $(SRC:.c=.o)
 +
 
 +
all: $(OBJS) $(TARGET).axf $(TARGET)
 +
 
 +
%.o: %.c
 +
$(CC) -c $(CFLAGS) $< -o $@
 +
 
 +
$(TARGET).axf: $(OBJS)
 +
$(LD) -T $(LINKER_FILE) $(LFLAGS) -o $(TARGET).axf $(OBJS) $(LIBM_PATH) $(LIBC_PATH) $(LIB_GCC_PATH) $(LIBSW_PATH)
 +
 
 +
$(TARGET): $(TARGET).axf
 +
$(CP) $(CPFLAGS) $(TARGET).axf $(TARGET).bin
 +
$(OD) $(ODFLAGS) $(TARGET).axf > $(TARGET).lst
 +
@echo
 +
$(SZ) $(TARGET).o
 +
 +
 
 +
flash: $(TARGET)
 +
$(FLASHER) $(TARGET).bin $(FLASHER_FLAGS)
 +
 
 +
clean:
 +
rm *.o *.d *.bin *.lst *.axf
 
</pre>
 
</pre>
  
 +
 +
Mit einem kleinen "Hello World", z.B.:
 +
<pre>
 +
#include <stdint.h>
 +
#include "inc/hw_gpio.h"
 +
#include "inc/hw_memmap.h"
 +
#include "inc/hw_sysctl.h"
 +
#include "inc/hw_types.h"
 +
#include "driverlib/gpio.h"
 +
#include "driverlib/rom.h"
 +
#include "driverlib/sysctl.h"
 +
   
 +
#define LED_RED GPIO_PIN_1
 +
#define LED_BLUE GPIO_PIN_2
 +
#define LED_GREEN GPIO_PIN_3
 +
 +
uint8_t i;
 +
   
 +
int main()
 +
{
 +
ROM_SysCtlClockSet(SYSCTL_SYSDIV_4|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);
 +
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
 +
ROM_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, LED_RED|LED_BLUE|LED_GREEN);
 +
i = 1;
 +
while (1) {
 +
ROM_GPIOPinWrite(GPIO_PORTF_BASE, LED_RED|LED_GREEN|LED_BLUE, 0);
 +
ROM_GPIOPinWrite(GPIO_PORTF_BASE, LED_RED|LED_GREEN|LED_BLUE, i);
 +
ROM_SysCtlDelay(5000000);
 +
i *= 2;
 +
if (i>8) i=1;
 +
}
 +
}
 +
 +
</pre>
 +
 +
 +
...kann man nun die Toolchain ausprobieren:
 +
<pre>
 +
$ make
 
...
 
...
 +
 +
$ make flash
 +
...
 +
 +
$ make clean
 +
...
 +
</pre>
 +
 +
Es sollten nacheinander alle drei Farben der RGB-LED auf dem Stellaris-Launchpad blinken.
  
 
=Tipps und Tricks=
 
=Tipps und Tricks=
Zeile 41: Zeile 156:
  
 
Nach dem Restart von udev (Befehl: /etc/init.d/udev restart) kann man auch als Nicht-root zugreifen.
 
Nach dem Restart von udev (Befehl: /etc/init.d/udev restart) kann man auch als Nicht-root zugreifen.
 +
 +
==Benutzung der GPIO-Pins PD0, PD1, PB6, PB7==
 +
Nach zwei Tagen verzweifelter Fehlersuche in einem Programm bzw. der dazugehörigen Schaltung (PB0...PB7 und PD0...PD2 sollten als Ausgänge benutzt werden), habe ich durch Zufall einen interessanten [http://processors.wiki.ti.com/index.php/BoosterPack_Standards_and_Design_Guide#Shared_Pins_on_the_Stellaris_LaunchPad Hinweis] gefunden:
 +
 +
Um auf dem Stellaris Launchpad auch BoosterPacks für das MSP430-Launchpad weiterhin benutzen zu können, sind im Lieferzustand die GPIO-Pins PD0/PB6 und PD1/PB7 jeweils mit einem "Null-Ohm"-Widerstand (R9, R10) verbunden.
 +
 +
D.h. also, wenn man diese Pins benutzen möchte, sollten diese Widerstände ausgelötet oder andere Pins verwendet werden. In meinem Fall werde ich erst mal die Widerstände drin lassen, aber für PD0...PD2 andere Pins benutzen.
 +
 +
==Stellaris Launchpad mit 5V-Peripherie-ICs==
 +
Die MCU auf dem Launchpad wird mit 3,3V versorgt. Laut Datenblatt sind die GPIO-Eingänge 5V-tolerant und die Spannungen der GPIO-Ausgänge wird mit mindestens 2,4V (bei Hight) angegeben, was für die gängigen 5V-ICs reichen sollte. Glücklicherweise befindet sich auf dem Launchpad auch ein Anschluß, auf welchen die 5V der USB-Buchse abgenommen werden kann und über den die 5V-ICs versorgt werden könnten.
 +
 +
Innerhalb des [[Scopeclock|Scopeclock-Projektes]] habe ich dies mit einem Digital-Analog-Wandler (TLC7528) und einer RTC (DS1307), welche beide eine Versorgungsspannung von 5V benötigen, erfolgreich ausprobiert. Als PullUp-Widerstände des I²C-Bus der RTC wurden dabei 4,7kOhm gegen die 3,3V der Launchpad-Spannungsversorgung geschaltet.
 +
 +
==Button 2 (PF0)==
 +
<pre>
 +
...
 +
// Unlock PF0 so we can change it to a GPIO input
 +
// Once we have enabled (unlocked) the commit register then re-lock it
 +
// to prevent further changes.  PF0 is muxed with NMI thus a special case.
 +
//
 +
HWREG(BUTTONS_GPIO_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY_DD;
 +
HWREG(BUTTONS_GPIO_BASE + GPIO_O_CR) |= 0x01;
 +
HWREG(BUTTONS_GPIO_BASE + GPIO_O_LOCK) = 0;
 +
...
 +
</pre>
  
 
=Weiterführende Links=
 
=Weiterführende Links=
Zeile 47: Zeile 187:
 
* [http://www.jann.cc/2012/12/11/getting_started_with_the_ti_stellaris_launchpad_on_linux.html http://www.jann.cc/2012/12/11/getting_started_with_the_ti_stellaris_launchpad_on_linux.html]
 
* [http://www.jann.cc/2012/12/11/getting_started_with_the_ti_stellaris_launchpad_on_linux.html http://www.jann.cc/2012/12/11/getting_started_with_the_ti_stellaris_launchpad_on_linux.html]
 
* [http://recursive-labs.com/blog/2012/10/28/stellaris-launchpad-gnu-linux-getting-started/ http://recursive-labs.com/blog/2012/10/28/stellaris-launchpad-gnu-linux-getting-started/]
 
* [http://recursive-labs.com/blog/2012/10/28/stellaris-launchpad-gnu-linux-getting-started/ http://recursive-labs.com/blog/2012/10/28/stellaris-launchpad-gnu-linux-getting-started/]
 +
 +
Makefile-Templates:
 +
* [https://github.com/scompo/stellaris-launchpad-template-gcc/blob/master/Makefile https://github.com/scompo/stellaris-launchpad-template-gcc/blob/master/Makefile]
 +
* [https://github.com/Wollw/stellaris-launchpad-template-gcc/blob/master/Makefile https://github.com/Wollw/stellaris-launchpad-template-gcc/blob/master/Makefile]
  
 
Unsortiert:
 
Unsortiert:
 
* [https://eehusky.wordpress.com/2012/12/04/using-gcc-with-ti-stellaris-launchpad-a-more-in-depth-look/ https://eehusky.wordpress.com/2012/12/04/using-gcc-with-ti-stellaris-launchpad-a-more-in-depth-look/]
 
* [https://eehusky.wordpress.com/2012/12/04/using-gcc-with-ti-stellaris-launchpad-a-more-in-depth-look/ https://eehusky.wordpress.com/2012/12/04/using-gcc-with-ti-stellaris-launchpad-a-more-in-depth-look/]
 
* [http://www.fischl.de/arm/sllogiclogger_logic_analyser_for_stellaris_launchpad/ http://www.fischl.de/arm/sllogiclogger_logic_analyser_for_stellaris_launchpad/]
 
* [http://www.fischl.de/arm/sllogiclogger_logic_analyser_for_stellaris_launchpad/ http://www.fischl.de/arm/sllogiclogger_logic_analyser_for_stellaris_launchpad/]
 +
* [http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/169023.aspx?pi275769 http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/169023.aspx?pi275769]
  
 
=Kontakt=
 
=Kontakt=
 
[[Benutzer:bergeruw|Uwe]]
 
[[Benutzer:bergeruw|Uwe]]

Aktuelle Version vom 10. November 2013, 01:11 Uhr


Derzeit noch Baustelle...!

Inhaltsverzeichnis

[Bearbeiten] Motivation

[Bearbeiten] Stellaris Launchpad

Stellaris Launchpad

Herstellerseite...

[Bearbeiten] Toolchain

[Bearbeiten] Energia

Möchte man sich nicht gleich am Anfang mit der Installation/Konfiguration einer entsprechenden gcc-Umgebung herumschlagen, reicht für erste Experimente Energia aus. Das entsprechende Dowload-Paket enthält alle notwendigen Komponenten zum Übersetzen von eigenen Programmen und deren Übertragung auf das Launchpad. Die Archivdatei wird einfach in ein Verzeichnis entpackt und dann kann es sofort (zumindestens bei der aktuellen Version 0101E0010) losgehen. Viele der mitgelieferten Beispiele funktionieren, nach Auswahl des richtigen Boards unter dem Menüpunkt "Tools" → "Boards", problemlos.

[Bearbeiten] Kommandozeilen-Toolchain auf Basis einer Energia-Installation

Ist schon eine funktionierende Energia-Installation auf seinem Rechner vorhanden, braucht man eigentlich nicht noch einen Compiler zu installieren, unterlagert werkelt dort schon ein arm-none-eabi-gcc. Es reicht also den Pfad zu den Binaries des Compilers mit in die PATH-Variable aufzunehmen, also z.B. die Datei .bashrc im eigenen Homeverzeichnis zu erweitern:

# Cross-Compiler-Umgebung fuer Stellaris Launchpad
export PATH=$PATH:$HOME/energia/hardware/tools/lm4f/bin

Will man das Rad nicht ständig neu erfinden, sollte man die frei erhältliche StellarisWare von TI (alternativ auch von hier) installieren. Das heruntergeladene Archivfile entpackt man dazu in ein beliebiges Verzeichnis auf seinem Rechner und führt dort das Makefile aus:

$ make


Hier ein entsprechendes Makefile, mit dem man dann seine eigenen Programme generieren und auf die MCU flashen kann:

TARGET = main

STELLARISWARE = ~/work/stellaris/stellarisware
SRC = $(wildcard *.c)
TOOLCHAIN = arm-none-eabi
PART = LM4F120H5QR
CPU = cortex-m4
FPU = fpv4-sp-d16
FABI = softfp

LINKER_FILE = $(STELLARISWARE)/boards/ek-lm4f120xl/hello/hello.ld
SRC += $(STELLARISWARE)/boards/ek-lm4f120xl/hello/startup_gcc.c

CC = $(TOOLCHAIN)-gcc
LD = $(TOOLCHAIN)-ld
CP = $(TOOLCHAIN)-objcopy
OD = $(TOOLCHAIN)-objdump
SZ = $(TOOLCHAIN)-size

CFLAGS = -mthumb -mcpu=$(CPU) -mfpu=$(FPU) -mfloat-abi=$(FABI)
CFLAGS+= -Os -ffunction-sections -fdata-sections
CFLAGS+= -MD -std=c99 -Wall -pedantic
CFLAGS+= -DPART_$(PART) -c -DTARGET_IS_BLIZZARD_RA1
CFLAGS+= -g
CFLAGS+= -I $(STELLARISWARE)

LIB_GCC_PATH=$(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
LIBC_PATH=$(shell $(CC) $(CFLAGS) -print-file-name=libc.a)
LIBM_PATH=$(shell $(CC) $(CFLAGS) -print-file-name=libm.a)
LIBSW_PATH=$(STELLARISWARE)/driverlib/gcc-cm4f/*.o
LFLAGS = --gc-sections --entry ResetISR
CPFLAGS = -Obinary

ODFLAGS = -S

FLASHER=lm4flash
FLASHER_FLAGS=-v

OBJS = $(SRC:.c=.o)

all: $(OBJS) $(TARGET).axf $(TARGET)

%.o: %.c
	$(CC) -c $(CFLAGS) $< -o $@

$(TARGET).axf: $(OBJS)
	$(LD) -T $(LINKER_FILE) $(LFLAGS) -o $(TARGET).axf $(OBJS) $(LIBM_PATH) $(LIBC_PATH) $(LIB_GCC_PATH) $(LIBSW_PATH)

$(TARGET): $(TARGET).axf
	$(CP) $(CPFLAGS) $(TARGET).axf $(TARGET).bin
	$(OD) $(ODFLAGS) $(TARGET).axf > $(TARGET).lst
	@echo
	$(SZ) $(TARGET).o
	

flash: $(TARGET)
	$(FLASHER) $(TARGET).bin $(FLASHER_FLAGS)

clean:
	rm *.o *.d *.bin *.lst *.axf


Mit einem kleinen "Hello World", z.B.:

#include <stdint.h>
#include "inc/hw_gpio.h"
#include "inc/hw_memmap.h"
#include "inc/hw_sysctl.h"
#include "inc/hw_types.h"
#include "driverlib/gpio.h"
#include "driverlib/rom.h"
#include "driverlib/sysctl.h"
     
#define LED_RED 	GPIO_PIN_1
#define LED_BLUE 	GPIO_PIN_2
#define LED_GREEN 	GPIO_PIN_3

uint8_t i;
     
int main()
{
	ROM_SysCtlClockSet(SYSCTL_SYSDIV_4|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
	ROM_GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, LED_RED|LED_BLUE|LED_GREEN);
	i = 1;
	while (1) {
		ROM_GPIOPinWrite(GPIO_PORTF_BASE, LED_RED|LED_GREEN|LED_BLUE, 0);
		ROM_GPIOPinWrite(GPIO_PORTF_BASE, LED_RED|LED_GREEN|LED_BLUE, i);
		ROM_SysCtlDelay(5000000);
		i *= 2;
		if (i>8) i=1;		
	}
}


...kann man nun die Toolchain ausprobieren:

$ make
...

$ make flash
...

$ make clean
...

Es sollten nacheinander alle drei Farben der RGB-LED auf dem Stellaris-Launchpad blinken.

[Bearbeiten] Tipps und Tricks

[Bearbeiten] Zugriff auf /dev/ttyACMx als Nicht-root-Benutzer

Über /dev/ttyACMx (siehe dsmeg-Meldungen nach Einstöpseln des Launchpads) erfolgt die Kommunikation zwischen Linux-PC und Launchpad. Gibt es keine entsprechende udev-Regel, kann nur root auf diese Schnittstelle zugreifen. Also macht sich eine entsprechende Konfiguration für Nicht-Root-User ganz sinnvoll:

Erzeugung der Datei /etc/udev/rules.d/61-stellaris.rules mit folgendem Inhalt:

# Zugriff auf TIs Stellaris-Launchpad regeln
#
SUBSYSTEM=="usb",ATTRS{idVendor}=="1cbe",ATTRS{idP roduct}=="00fd",MODE="0666"
KERNEL=="ttyACM0",ATTRS{idVendor}=="1cbe",ATTRS{id Product}=="00fd",MODE="0666"

Nach dem Restart von udev (Befehl: /etc/init.d/udev restart) kann man auch als Nicht-root zugreifen.

[Bearbeiten] Benutzung der GPIO-Pins PD0, PD1, PB6, PB7

Nach zwei Tagen verzweifelter Fehlersuche in einem Programm bzw. der dazugehörigen Schaltung (PB0...PB7 und PD0...PD2 sollten als Ausgänge benutzt werden), habe ich durch Zufall einen interessanten Hinweis gefunden:

Um auf dem Stellaris Launchpad auch BoosterPacks für das MSP430-Launchpad weiterhin benutzen zu können, sind im Lieferzustand die GPIO-Pins PD0/PB6 und PD1/PB7 jeweils mit einem "Null-Ohm"-Widerstand (R9, R10) verbunden.

D.h. also, wenn man diese Pins benutzen möchte, sollten diese Widerstände ausgelötet oder andere Pins verwendet werden. In meinem Fall werde ich erst mal die Widerstände drin lassen, aber für PD0...PD2 andere Pins benutzen.

[Bearbeiten] Stellaris Launchpad mit 5V-Peripherie-ICs

Die MCU auf dem Launchpad wird mit 3,3V versorgt. Laut Datenblatt sind die GPIO-Eingänge 5V-tolerant und die Spannungen der GPIO-Ausgänge wird mit mindestens 2,4V (bei Hight) angegeben, was für die gängigen 5V-ICs reichen sollte. Glücklicherweise befindet sich auf dem Launchpad auch ein Anschluß, auf welchen die 5V der USB-Buchse abgenommen werden kann und über den die 5V-ICs versorgt werden könnten.

Innerhalb des Scopeclock-Projektes habe ich dies mit einem Digital-Analog-Wandler (TLC7528) und einer RTC (DS1307), welche beide eine Versorgungsspannung von 5V benötigen, erfolgreich ausprobiert. Als PullUp-Widerstände des I²C-Bus der RTC wurden dabei 4,7kOhm gegen die 3,3V der Launchpad-Spannungsversorgung geschaltet.

[Bearbeiten] Button 2 (PF0)

...
// Unlock PF0 so we can change it to a GPIO input
// Once we have enabled (unlocked) the commit register then re-lock it
// to prevent further changes.  PF0 is muxed with NMI thus a special case.
//
HWREG(BUTTONS_GPIO_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY_DD;
HWREG(BUTTONS_GPIO_BASE + GPIO_O_CR) |= 0x01;
HWREG(BUTTONS_GPIO_BASE + GPIO_O_LOCK) = 0;
...

[Bearbeiten] Weiterführende Links

Linux-Toolchain:

Makefile-Templates:

Unsortiert:

[Bearbeiten] Kontakt

Uwe

'Persönliche Werkzeuge