-
Thread
ethernet lpcxpresso
UDP verwenden. Mit der lpcXpresso IDE ist auch eine Portierung von uIP als TCP/IP Stack für die LPC17xx mitgeliefert worden. Im Zip Ordner RDB1768Cmsis2.zip im Ordner Installationsordner_von_LPCXpresso\lpcxpresso\Examples\NXP\LPC1000\LPC17xx findest du im Projekt RDBCMSIS2_uIP den fertigen uIP Stack
-
Thread
CAn Empfang beim LPC1768
******************************************************** * can.c: CAN module API file for NXP LPC17xx Family Microprocessors * * Copyright(C) 2009, NXP Semiconductor * All rights reserved. * * History * 2009.05.27 ver 1.00 Prelimnary version, first Release * 13.10.2010
bezüglich CAN2 *****************************************************************************/ #include "lpc17xx.h" #include "type.h" #include "can.h" /* Receive Queue: one queue for each CAN port */ extern CAN_MSG MsgBuf_RX1; extern volatile uint32_t CAN1RxDone; volatile uint32_t CANStatus; uint32
-
Thread
Auswahl zwischen Cortex M3 von NXP, ST, TI
Auswahl stehen mir dabei folgende 3 Firmen: - ST Miccroelectronics mit dem STM32 - NXP mit dem LPC17xx - TI mit der LM3xxxxxx Reihe Wichtig für mich ist eine gute Verfügbarkeit der Controller (ich möchte die Controller auch privat bestellen können, da die Studentenlaufbahn ja irgendwann vorbei
schon den LPC23xx / LPC24xx hat und SW für deren Pheriperie, dann ist es natürlich Sinnvoll dden LPC17xx zu nehmen, denn die haben exakt die gleiche Pheriperie drin. Das hat NXP gut hin bekommen. Für einen neueunsteiger würde ich eher zum STM32 raten. Ich habe selbst schon LPC2368 programmiert
-
Thread
ARM STM32F103 Cortex M3 Board + Linux
mit Liefertermin angekündigt sind kann und sollte man sich nicht verlassen. NXP ist mit seinen LPC17xx auch überfällig. @Jupp: Vergiß den OpenOCD erstmal. Es ist die billigste aber auch die unzuverlässigste Methode um den JTAG Port anzusprechen. Ich kann Dirk nur beipflichten und empfehle
Jupp wrote: > NXP ist mit seinen LPC17xx auch überfällig. Genau wie Atmel mit den SAM3 und Luminary mit der neuen Generation ... Bleibt abzuwarten was das Jahr bringt. @Lupin: Die neuen Luminarys sollen 96k SRAM haben, allerdings
-
Thread
LPC17xx I2C und SPI Interrupts
Hi, hab grad ein merkwürdiges Problem bei meinem LPC1758 Prozessor. Ich möchte gerne I2C und SPI mittels Interrupts integrieren. Beide Sachen laufen auch soweit für sich. Wenn ich über SPI mehrere Bytes übertrage (wobei die weiteren Bytes in der Interruptroutine von SPI dem SPDR überbracht werden) und "gleichzeitig" einen I2C Transfer anstoße um etwas aus dem Eeprom zu lesen, bekomme ich beim I2C teilweise 0xFF statt der richtigen DAten angezeigt. Wenn ich den I2C Transfer erst starte, sobald der SPI Transfer abgeschlossen ist, dann erhalte ich das richtige Ergebnis beim I2C. Gruß Lars
-
Thread
NXP-Interrupt
Hallo zusammen, Kann mir jemand für NXP LPC17xx ein (eifaches) ISR als Beispiel zeigen, und wie man sie einsetzt?. Für AVR gibt es diverse Beispiele. Wie man interrupts aktiviert, wie man die flags setzt u.s.w. aber für Cortex sind die Beispiel
schau dir mal die CMSIS von NXP an (einfach mal googeln). Damit ist es eigendlich ganz einfach, nen LPC17xx zum laufen zu bringen
-
Thread
STM32F4 USB High Speed VCP mit USB3320 PHY
hab solche äußerlich vereinheitlichten Treiber für den STM32F103, Nuvoton NUC120, LPC2478, LPC1343, LPC17xx geschrieben und die .h Datei enthält zum Herausschneiden die .inf für den ganzen Kram - egal, welcher µC dahinter steckt. W.S.
solche äußerlich vereinheitlichten Treiber für den STM32F103, > Nuvoton NUC120, LPC2478, LPC1343, LPC17xx geschrieben und die .h Datei > enthält zum Herausschneiden die .inf für den ganzen Kram - egal, welcher > µC dahinter steckt. So ein Herstellerübergreifender Stack ist natürlich auch eine schöne
-
Thread
Suche Automotiv Mikrocontroller den man mit einem free Compiler kompilieren kann!
LPC2000 = ARM7 Core >> GCC geht. Aber wenn schon einen aus der NXP Reihe, dann lieber den LPC17xx (= Cortex-M3 = Jünger und moderner und somit langlebiger >> auch GCC so wie auch der [[STM32]] weil da auch ein Cortex-M4/M4 drin arbeitet).
> LPC2000 = ARM7 Core >> GCC geht. Aber wenn schon einen aus der NXP > Reihe, dann lieber den LPC17xx (= Cortex-M3 = Jünger und moderner und > somit langlebiger >> auch GCC so wie auch der [[STM32]] weil da auch ein > Cortex-M4/M4 drin arbeitet). Ja, irgend was mit THUMB oder THUMB2 beispielsweise
-
Thread
LPC1788 - startup / .ld-script
berechnen gibt es auch ein Excel Sheet: http://ics.nxp.com/support/documents/microcontrollers/xls/lpc17xx.pll.calculator.xls zu dem _sbrk wirst du in der CodeRed Hilfe fündig: http://support.code-red-tech.com/CodeRedWiki/UndefinedReference?highlight=%28sbrk%29 Das 64Bit Problem dürfte auch eher
\sn.DCIMS\Documents\lpcxpresso_3.6.3_317\workspace2\Lib_CMSIS20_DRIVER\Core\CM3\DeviceSupport\NXP\LPC17xx" -I"C:\Users\sn.DCIMS\Documents\lpcxpresso_3.6.3_317\workspace2\Lib_CMSIS20_DRIVER\Drivers\include" -I"C:\Users\sn.DCIMS\Documents\lpcxpresso_3.6.3_317\workspace2\Lib_CMSIS20_DRIVER\Core\DSP_Lib\
-
Thread
LPC1768 UART Problem beim Senden/Empfangen mehrere Bytes
> Parität, 1 Stop bit, DLAB = 0 > LPC_UART0->FCR = 0x47; Zu viele magic numbers. Für den LPC17xx gibt es Header mit Bitdefinitionen. Achung: PCLKSEL0 kann nicht geändert werden, sobald die PLL0 an ist. Siehe Errata. hoxplus schrieb im Beitrag #4233646: > Wenn ich in einer while Schleife
nicht erkennt ist was in den Einstellungen (Baudrate, Datenbits, Parity) falsch. Der FiFO im LPC17xx erlaubt einem sogar das hier: [c] while (!(LPC_UART0->LSR & UART_LSR_THRE)); LPC_UART0->THR = 'T'; LPC_UART0->THR = 'e'; LPC_UART0->THR = 's'; LPC_UART0->THR = 't'; LPC_UART0->THR
-
Thread
LPC1758 USART Rx disablen
Datenblattes kannst Du alle Fragen selber beantworten. Trotzdem hier ein paar Erläuterungen: Der LPC17xx hat leider keinen USART, nur mehrere UART (S bedeutet "Synchron"). Warum aktivierst Du den RX-Interrupt, wenn du den gar nicht brauchst? Auf Low sollte der Portpin sicher nicht sein, es sei denn
Nur-Senden oder nur-empfangen ist absolut kein Problem, das mache ich bei meinen Projekten mit LPC17xx ständig, weil in meiner Hardware TXD und RXD verbunden sind und ich verhindern muß, daß gesendete Daten auch sofort empangen werden. Erwin
-
Thread
I2C Kommunitkation funktioniert nicht
ARM-GCC Compiler.. Die Bibliotheken habe ich von keil. Vielen Dank!! main.c: [c]/* #include "lpc17xx_timer.h" #include "lpc17xx_clkpwr.h" #include "lc798x.h" #include "lpc17xx.h" #include "i2c.h" //Definition der DS1621 Befehle bzw. Register #define START_CONVERT_TEMP 0xEE #define
uint32_t I2CWriteLength[I2C_PORT_NUM]; #endif /* end __I2C_H */ [/c] i2c.c [c] #include "lpc17xx.h" #include "lpc_types.h" #include "i2c.h" volatile uint32_t I2CMasterState[I2C_PORT_NUM] = {I2C_IDLE,I2C_IDLE,I2C_IDLE}; volatile uint32_t timeout[I2C_PORT_NUM] = {0, 0, 0}; volatile uint8
-
Thread
Union innerhalb von typedef struct (LPC Lib)
Hi, hab mir grad die Examples für die LPC17xx Reihe angeschaut und bei denen wird innerhalb eine struct eine union definiert ohne Bezeichner... Trotzdem läuft das ganze fehlerfrei durch, wie funktioniert das oder hab ich was wichtiges übersehen
Steffen schrieb im Beitrag #1973114: > hab mir grad die Examples für die LPC17xx Reihe angeschaut und bei denen > wird innerhalb eine struct eine union definiert ohne Bezeichner... Normal. Nennt sich "anonymous union". Deren Komponenten können direkt als Komponenten der umgebenden
-
Thread
Welcher Cortex M3?
Hersteller am Markt etabliert. Zum einen ist das ST mit den STM32F10x und zum zweiten NXP/Philips mit den LPC17xx. Ich habe mit beiden gearbeitet, bevorzuge jedoch derzeit die LPC17xx, da sie gegenüber den neueren STM32F105/107 unschlagbar im Preis- Leistungsverhältnis sind und nahezu dieselbe Peripherie bieten
-
Thread
LPC1768 - Linker Script / Startupfile benötigt bzw. Error
__cs3_reset_cortex_m,.-__cs3_reset_cortex_m .section ".text" Die files habe ich aus der lpc17xx.cmsis.driver.library.zip Datei von NXP. Ich habe auch schon mehrere Files probiert, jedoch war der program counter beim Debuggen dann an irgendwelchen abstrusen Adressen... sofern es compilierbar
Initialiserungen der C-Library durchführen und dann ebenfalls main rufen. >... > Die files habe ich aus der lpc17xx.cmsis.driver.library.zip Datei von > NXP. Die Leute von NXP scheinen große Fans des CS3-Systems von Codesoucery. Was scheibt NXP zu den Beispielen? Keine Kurzanleitung wie und mit was man die zusammenbauen
-
Thread
lpc17xx, 8-bit parallel mit \WR: DMA?
Hallo allerseits, ich versuche momentan mit einem LPC1768 unter Verwendung der DMA ein Display anzusprechen, das mit dem Intel 8080 Interface arbeitet. Das wesentliche Problem dabei stellt das WR-Signal dar, das zudem synchron zur DMA laeuft. Dazu habe ich bereits folgenden Beitrag gefunden: http://www.embeddedrelated.com/groups/lpc2000/show/46276.php Hierzu die Passage: "the PWM output = /WR signal is feed back to an input of the device, which itself triggers the DMA for putting out the data byte" Leider finde ich keinen Eingang, der faehig waere, einen DMA request auszuloesen
-
Thread
Fujitsu MCU vs Cortex M3
@Wolf Dir Cotex M3 gibts tatsächlich zum grossen teil ohne Cach. nur (aus dem datenblat zum lpc17xx) Up to 512 kB on-chip flash programming memory. Enhanced flash memory accelerator enables high-speed 120 MHz operation with zero wait states. dei gnu toolchain gibts nicht nur für linux.
Wolf > Dir Cotex M3 gibts tatsächlich zum grossen teil ohne Cach. > > nur (aus dem datenblat zum lpc17xx) > > Up to 512 kB on-chip flash programming memory. Enhanced flash memory > accelerator enables high-speed 120 MHz operation with zero wait states. Ist so was aehnliches wie ein mini-Cache
-
Artikel
LPC-Mikrocontroller
10Bit AD-Wandler und eine Taktfrequenz von max. 72MHz. User Manual der LPC13xx-Familie (PDF) Eckdaten LPC17xx (Cortex-M3). Die LPC17xx-Serie hingegen enthält eine weit größere Peripherie in einem LQFP80/100/144/208 Package. 32..512k Flash, 8..96k SRAM, 6 Timer (mit WD), 6 zusätzliche PWM-Einheiten, teilweise
EEPROM 12 Bit ADC USB Code in ROM USB Bootloader in ROM, programming via copy to mass storage device LPC17xx. Familienübersicht LPC17xx. Bezugsquellen und Preise: LPC1754 mit 128K Flash im LQFP80, der bei Darius für 7€74 (Juli/2011) erhältlich ist,[den LPC1751 (32k/8k) schon für 5€95] und bei Digikey für
-
Thread
J-Link, Keil und JTAG Chain
Hallo, ich habe einen J-Link v8.0, Keil 4.70 und zwei LPC17xx, einmal -65 und einmal -56. Laut der Anleitung von Segger soll es möglich sein mit einem J-Link mehrere Controller gleichzeitig zu debuggen. Wäre ja schön. Die Controller sind auf getrennten Platinen
, nicht aber die Position und IR-Len nicht selber eintragen. Beide Controller haben wie die ganze LPC17xx-Serie die gleiche JTAG-ID. Hat jemand so was schon mal probiert oder eine Idee? Muss jetzt nicht mal unbedingt gleichzeitig sein, ich habe nur keine Lust immer den J-Link umzustecken. Mal vergisst
-
Thread
lpc1768 arm-non-eabi-gcc printf to uart0
include <errno.h> #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include "lpc17xx.h" /* for _get_PSP() from core_cm3.h*/ #undef errno extern int errno; extern char _heap_start; /* Defined by the linker */ extern char _heap_end; /* Defined by the linker
Collition rein und mein eigentlicher Text wird nicht ausgegeben. Hier meine main ... [c] #include <lpc17xx.h> #include <stdio.h> void initUART() { // setup uart0 LPC_PINCON->PINSEL0 |= (1 << 4) | (1 << 6); LPC_UART0->LCR = 0x83; // 8bit, no parity, 1 stop bit, DLAB=1 LPC_UART0
-
Thread
Wunschliste für einen Xmega Nachfolger
nichts umlernen. Auch der Umstieg auf andere Hersteller ist leicht. Ich entwickle z.Zt. ein Board mit LPC17xx, das bis vor kurzem auf STM32 gemünzt war. Der Wechsel war trivial, und auch softwareseitig gibt es schon fertige Bibliotheken, die herstellerübergreifende Treiberroutinen enthalten. Wirklich,
eher High-Performance-Typen, die sind nicht gegen die AtTinys aufgestellt. Ein Vergleich XMega vs. LPC17xx mach ich jetzt aber nicht auch noch, das kann jeder der lesen kann selber tun. >> Deep Power Down für ca. 0.2µA. > > Das ist aber eher Augenauswischerei. Was willst du mit dem Schlafen-
-
Thread
LPC17xx: RTC => Counter Increment Interrupt identifizieren
die Hintertür mit Statusvariablen in der ISR hinkriegen (z.B. IMMIN bis 59 zählen lassen). Aber der LPC17xx hat so viele Register, da kann doch so etwas einfaches und absolut sinnvolles nicht fehlen? Der normale Weg ist doch bei einem "Sammelinterrupt", im Flagregister den Verursacher zu identifizieren
-
Thread
LPC1100, superguenstig, 8-bit? Wird immer unnoetiger
Da hat doch aber die LPC17xx Serie von NXP noch ein besseres P/L Verhältnis, oder? Immerhin kostet der LPC1752 mit 64k Flash, 16k RAM, 100MHz, USB/CAN gerade mal 5,20€ INKL MWSt (HBE). Und der große Brocken (LPC1768) mit 512k
Jörg S. schrieb: > Da hat doch aber die LPC17xx Serie von NXP noch ein besseres P/L > Verhältnis, oder? Bezogen auf die merkwürdige Preispolitik von HBE schon, aber auf Träger ist mit der 80-Pin NXP-Klops für viele Fälle zu gross. LQFP48 gefällt
-
Thread
LPC17xx/STM32F103xx: AHB/APB Takt
ich lese mich gerade etwas in die Datenblätter ein. Habe ich es richtig verstanden, daß - beim LPC17xx APB 0 und 1 den gleichen Takt haben und der Resetwert CCLK/4 ist (also bei "vollgas" mit 100 MHz beträgt der Takt 25 MHz auf den beiden Peripheriebussen)? - beim STM32F103xx APB1 max. 36 MHz und
-
Thread
Einstiegshilfe in ARM-Controller
die Eingänge nicht abrauchen, wenn man >ein 5V-IC dranhängt. Zumindest die Cortex M3 von NXP (LPC17xx) haben 5V tolerante Eingänge.
die Eingänge nicht abrauchen, wenn man >>ein 5V-IC dranhängt. > Zumindest die Cortex M3 von NXP (LPC17xx) haben 5V tolerante Eingänge. Die STM32 auch, wenn auch nicht alle Pins 5V tolerant sind.
-
Thread
lpc1700 - ARM Cortex M3 von NXP: Endlich!
gleichzeitig benutzt werden ... da sind schon viele Leute auf die Nase gefallen! Der 12-Bit AD den neuen LPC17xx ist auch super.
als ein Startupfile von Hand im Makefile einzutragen weil der Compiler kein eigenes hat. Der LPC17xx mag ja ganz toll sein. Solange er nicht lieferbar ist, bringt der niemanden etwas. STM32 ist auch nicht schlecht. Ohne Ethernet kann er aber in der heutigen Zeit in einem beträchtlichen Teil der
-
Thread
ATX Mega mit Ethernet (LAN)
ansonst nen COrtex M3 von NXP ( LPC17xx ) oder STM ( STM32F2xx ) dazu nen PHY ( DPxxx ) oder LAN8710 oder MICREL xxxx (RMII Typen ) billig und enfach im LAN
-
Thread
LPC800 existiert (fast) nicht in diesem Forum
' Peripherie an, w"ahrend bei dem Stromsparern fast alles aus ist. Das macht ein Blinky auf einem LPC17 einfacher als auch dem 'Einsteiger-' LPC800 / LPC1100. > sicherlich die "Tutorien", die ihr hier verlinkt. Ich kann davon nichts > lernen, ich will den GRUNDAUFBAU kennen lernen, nicht eine LED
eines Bausteins LPC8xx in einem Projektsetting). Tsss. Ziemlich gut finde ich dieses hier (obwohl LPC17). Da ist sehr viel erkl"art: http://pygmy.utoh.org/riscy/cortex/led-lpc17xx.html (Falk): > Du hast noch nie C programmiert. Na logisch kümmert sich der Compiler / > die IDE um den Startup
-
Thread
LPC17xx CMSIS => AN10862_4 Toolchain Eclipse
Hallo, hat schon jemand die in der AN10862 genannte Toolchain mit Eclipse unter Linux mit der aktuellen Driver Library zum Laufen gekriegt? Die scheint für Windows "gemünzt" zu sein, was ich aber leider nicht habe. Ich bekomme bei den genannten Targets "ram" und "rom" immer die Meldung "no rule to make target 'ram'", während "clean" geht. Es scheint ein makefileproblem zu sein. Das "clean" scheint wahrscheinlich irgendwo anders herzukommen und zu funktionieren. Eine gaaaanz schnelle Installation auf einem Win XP 32-Rechner zeigt das gleiche Problem, weshalb es wahrscheinlich nicht unbedingt
-
Thread
EEPROM in µC. Warum?
Hallo, ich bin auf der Suche nach einem geeigneten Microcontroller bei NXP auf die LPC17xx Serie gestossen. Die neu angekündigten Controller haben alle nen kleinen EEPROM integriert. Ich kann mir leider keinen Reim darauf machen, wozu der EEPROM gut ist und warum man den nutzen sollte.
-
Thread
Debug Ausgaben
Die Abweichungen werden sich prozentual nicht ändern. Er bräuchte sowas wie das Autobauding vom LPC17xx UART. Das synchronisiert sich mit dem "A" (z.B. von "AT") auf die jeweilige Baudrate. Für den PC gibts sowas AFIAK leider nicht fertich. Um den RC OSC zu trimmen bräuchte man eine Referenz Taktquelle
-
Thread
RTC puffern Goldcap oder Batterie?
required for battery operation. Uses power from the CPU power supply when it is present. (Datasheet LPC17XX) Ich nehme jetzt meine erste Schaltung, damit der SuperCap geladen wird und hoffe das er eine geringe Selbstentladung hat. Vielen Dank noch mal!
-
Thread
Jitter LPC 1769
dort kann man mit einem 32Bit-Wort gleichzeitig 16 Bit GPIOs und eine Bitmaske schreiben. Bei den LPC17xx sind Maske und Daten getrennt, die Zugriffe sind daher nicht atomic. Damit ist es schwer auf den selben Port gleichzeitig sowohl per DMA als auch per regulärem Programm zuzugreifen.
-
Thread
Filter von µC Forum geht nicht richtig
> Im µC Forum >> Filter ARM > > Dann wird der Thread > Beitrag "Cortex M3 Hobby: STM32* oder LPC17* ?" > nicht gezeigt, obwohl in der Überschrift STM32, Cortex und LPC drin > stehen. Das Problem ist behoben, danke für die Meldung.
-
Thread
XBEE Wi-Fi Anbindung
über TCP/IP mit einem Router kommunizieren (TCP Stack ist funktionstüchtig und läuft auf dem µC (LPC17xx) ) ? Danke für euer Interesse Bastian
-
Thread
ARM-Cortex als Anfänger?
Ich würde zum STM32, SAM3/4 oder LPC17xx greifen. Besonders ST schmeisst mit Demo Boards nur so um sich, und ein ST-Link ist bereits mit auf dem Board. Der läuft dann mit den Demoversionen von Keil µVision bzw. IAR, sowie mit div. freien
Ich arbeite seit einen 3/4 Jahr mit einem LPC17xx und LPC43xx. Aus Erfahrung kann ich daher schrieben, dass die STM32 Reihe von der Peripherie her deutlich besser gelungen ist. Auch das CubeMX von ST nimmt einem deutlich die Arbeit ab und initialisiert
-
Thread
Billiger JTAG-Adapter für STM32
! Klar muß auch der Hobbyanwender sehen, was er damit machen will. Und gleich sind z.B. STM32 und LPC17xx nun mal definitiv nicht (geht ja schon mit dem Pincount los. LPC13xx mal außen vor). Also wird mir der billige JTAG-Adapter sicherlich nicht die Entscheidung zwischen den beiden Familien abnehmen
-
Thread
STM32 + ADC + LAN.Aufwand? Erfahrungen?
Im Forum wurden bereits zwei Projekte gepostet, allerdings für LPC17xx. Und die Daten wurden nicht über UDP periodisch gesendet, sondern über TCP und POST asynchron abgerufen.
-
Thread
Erkennung von Prellenden Schaltern
RC-Glied erkennen? Und man beachte, im Beispiel sind das 2600µs, also weit weg von 10µs! Z.B. der LPC17xx hat 8 Capture Eingänge mit 32Bit Auflösung. Damit würde ich das lösen. Deutlich schwieriger wird dann schon die Betätigungsmechanik zu realisieren sein. Für aussagekräftige Messungen sollten 1000
-
Thread
Debuggen für Dummies
musst du dein Programm ins RAM linken & dort debuggen. Spielst du mit einem Cortex-M3 herum (z.B. LPC17xx, STM32, SAM3), kannst du max. 6 HW-BPs setzen, dazu noch Watchpoints (z.B. wenn auf eine Var geschrieben/gelesen/beides wird, oder wenn die Variable dazu noch einen bestimmten Wert annimmt). Btw
-
Thread
I2C Sensor auslesen mit LPC1769
Pullups habe ich angelötet mit 1,8k. Hier mein Code: Main.c: [c]#ifdef __USE_CMSIS #include "LPC17xx.h" #endif //include files: #include "i2c.h" //definitions and declarations: #define PORT_USED 0 extern volatile uint8_t I2CMasterBuffer[I2C_PORT_NUM][BUFSIZE]; extern volatile uint8_
uint32_t I2CWriteLength[I2C_PORT_NUM]; #endif /* end __I2C_H */ [/c] I2C.c: [c] #include "lpc17xx.h" #include "lpc_types.h" #include "i2c.h" volatile uint32_t I2CMasterState[I2C_PORT_NUM] = {I2C_IDLE,I2C_IDLE,I2C_IDLE}; volatile uint32_t timeout[I2C_PORT_NUM] = {0, 0, 0}; volatile uint8
-
Thread
LPC1768 vom ISP Modus die nue Firmware starten
http://sourceforge.net/projects/lpc21isp/ (Nicht von dem Namen vewirren lassen, ist auch für LPC17xx gut.)