LPCxpresso Mikrocontroller Projekt mit Cortex M0/3

Hallo,
ich habe früher mal mit den PIC's einige Projekte (Drehzahlmesser, Adapter für Flugsimulator, Regler für Bürstenmotoren) realisiert. Vor einiger Zeit bin ich auf die AVR's umgestiegen, kann mich aber nicht so richtig damit anfreunden. Für meine zukünftigen Vorhaben zu wenig Speicher, zu wenige Timer und zu langsam. Im Moment untersuche ich daher die ARM Cortex-M0/M3 Microcontroller von NXP. Für diese gibt es eine recht günstige Entwicklungsplattform und Toolkette. Hier sind mal ein paar Links:

http://ics.nxp.com/lpcxpresso/
http://code-red-tech.com/index.php
http://www.embeddedartists.com/
http://knowledgebase.nxp.com/lpcxpresso.php

Ich habe mir das LPCXpresso Base board und die LPCXpresso's mit LPC1114 und LPC1769 beschafft um die ersten Erfahrungen zu sammeln.
Mir ist klar das dieses System auch etliche Nachteile hat, möchte aber hier NICHT diskutieren ob es nicht auch noch besser geeignete Systeme gibt bevor ich nicht mindestens ein Projekt realisiert habe!
Die Frage ist ob sich vielleicht jemand mit LPCxpresso und der Code-Red Toolchain beschäftigten möchte oder schon Erfahrungen hat und wir vielleicht eine Arbeitsgruppe ins Leben rufen könnten. Dies würde sicher auch meiner eigenen Motivation nützen.
Mir geht es im wesentlichen um Flugmodelle und Telemetrie. Ideen hätte ich genug um die nächsten Jahre beschäftigt zu bleiben.

Für den Anfang reicht übrigens ein LPCXpresso Board für unter 30,- €. Compiler und IDE (Eclipse) gibt's kostenlos.

Also falls jemand Lust hat mitzumachen, bitte melden.

Gruß
Cord

Hallo Cord,

ich bin auch gerade dabei, mir die ARM-Welt mal anzusehen. In letzter Zeit habe ich meine kleinen uP Projekte und MPX-Sensoren auf AVR Basis erstellt und bin auch ganz zufrieden mit dieser Umgebung.
Wenn schon ARM Basis, dann wollte ich schon auf den ARM-3 Kern gehen. NXP habe ich nicht näher betrachtet, ich habe mit an der ARM Auflistung von mikrocontroller.net orientiert. Die STM32F103x Linie passt gut zu meinen Anforderungen, LQFP48 lässt sich noch einigermassen löten und es ist genug I/O frei, da SWD anstelle von JTAG doch einige Pins spart.
Ob NXP da eine Alternative ist, müsste das Datenblatt ergeben, 100%tig festgelegt habe ich mich noch nicht.
Ich habe das STM32 discovery Board (ca. 14€) und vor 8 Tagen Atollic TrueSTUDIO sowie CoIDE installiert. Die ersten Gehversuche mit Hardware Anbindung stehen noch aus. Als erstes will ich den MPX Sensorbus anbinden und den ADC testen, ob der wirklich 12bit in der Praxis bringt. Die Doku von über 1500 Seiten muss ja auch zumindest teilweise genauer in Augenschein genommen werden.

Gruß Ingo

ingo_s schrieb:

Hallo Cord,
Ich habe das STM32 discovery Board (ca. 14€) und vor 8 Tagen Atollic TrueSTUDIO sowie CoIDE installiert. Die ersten Gehversuche mit Hardware Anbindung stehen noch aus.
Gruß Ingo

Zum Vergrößern anklicken....

Ja, sieht auch sehr interessant aus. Allerdings ist das TrueSTUDIO ja auch keine Freeware. Ich meine eine komplette Toolkette mit Eclipse, Gnu-Compiler und Debugger als Freeware wäre nicht schlecht, ist mir aber erst mal zu viel Aufwand das alles einzurichten. Da kämpft man an allen Fronten gleichzeitig. Daher hab ich mich erst mal für Code-Red entschieden. Will man C++ codieren, kostet das allerdings auch schon wieder.
Verwendest du CMSIS? Ich werde das mal probieren, ob allerdings wirklich besser portierbarer Code dabei herauskommt muss sich erst zeigen.
Ich will erst mal ein Summensignal vom Empfänger und ein Signal vom Drehzahlsensor einlesen und alles auf Micro-SD Karte speichern. Dann kann ich später auch die berechneten Daten online protokollieren und auf dem PC z.B. mit Excel auswerten. Das Schreiben von Daten (FAT32) funktioniert schon mal, jetzt muss ich mich erst mal mit den Clocks, Timern usw. auseinandersetzen.

Cord

Von TrueSTUDIO gibt es eine freie light Version, mit einigen Einschränkungen die mir aber noch nicht genau angesehen habe, weil ich im Moment lieber die CoIDE benutze.

Schau mal bei CooCox.org vorbei, da habe ich die freie IDE her. Die Installation deckt alles ab, und unterstützt meinen ST-Link. NXP wird auch unterstützt, aber nicht alle Jtag Adapter.

Einige NXP Datenblätter habe ich mir inzwischen angesehn, da ich aber auf 12bit ADC scharf bin, kommen die NXP im Moment nicht in die engere Wahl obwohl die auch schon recht viel von meinen Anforderungen abdecken.

Was mir bei den STM32 und den anderen störend aufgefallen ist, die haben meistens kein EEPROM.

Gruß Ingo

Auch ich könnte mich als „Laie” in Sachen „C” für ein Projekt auf der Basis der NXP ARM Prozessoren interessieren. Sowohl von TI, wie eben auch bei NXP gibt es eine vom Installer vollständig installierte Toolchain, was mich nach ersten Bemühungen mit dem ARM von ST zum Aufgeben bewegt hat. Die LPCExpresso Boards sind auch gerade wegen der integrierten JTAG-Schnittstellen für das „Brennen” und das „Debuggen” außerordentlich interessant! Was mich bisher von dem Kauf eines Boards bei NXP abhielt war, neben der Auslastung mit anderen Projekten auch die Überlegung welches Board das geeignetste wäre. Eigentlich fände ich es interessant wenn der Controller auch ein Floating Point Einheit enthält.

Hellmut schrieb:

Was mich bisher von dem Kauf eines Boards bei NXP abhielt war, neben der Auslastung mit anderen Projekten auch die Überlegung welches Board das geeignetste wäre. Eigentlich fände ich es interessant wenn der Controller auch ein Floating Point Einheit enthält.

Zum Vergrößern anklicken....

Hallo Hellmut,
das kenne ich, wer die Wahl hat...
Erst mal bin ich mit dem LPCXpresso ganz zufrieden. Mit dem debuggen freunde ich mich gerade an, ist schon interessant z.B. alle Register als Memory-dump vor sich zu haben. Wenn du eine integrierte Floating Point Unit brauchst, müsstest du allerdings schon einen Cortex-M4 Controller nehmen. Die LPCXpresso's gibt's allerdings nur als M0 und M3.

Gruß
Cord

Hi,
ich hab mal ein Projekt bei Google Code gestartet:

http://code.google.com/p/lpcxpresso-rc

Würde mich freuen, wenn vielleicht doch noch jemand mitmacht!

Gruß
Cord

Hallo,
bisher habe ich folgendes implementiert:
- Graupner HoTT Summensignal
- RPM Signal
- Servo Ausgänge
- LCD (EA DOGS 102x64)

Das Auswerten und die Ausgabe der Signale ist recht einfach, z.B.:

// attach LED to channel 1
if(Recv.channel[0] > 1500) GPIO_SetValue(0, LED);
else GPIO_ClearValue(0, LED);

// mix servo channels
ServoArray.channel[0].pulseLength = (Recv.channel[0] + Recv.channel[1]) / 2;
ServoArray.channel[1].pulseLength = (Recv.channel[2] + Recv.channel[3]) / 2;

Hier werden mal die Pulslängen des Summensignals angezeigt:



Gruß
Cord

Hallo,

ich baue mit ARM7 (+ Rowley Crossworks Shell) nach 10 jahren PIC und bin sehr zufrieden. Allerdings nichts für den Modellbau. Der ARM7 ist natürlich
nichts für Lochraster wie der PIC, sondern man verwendet am besten günstige Einsteigerplatinen, die es ab 100 Euro gibt und die alles haben. Eigene
Sachen kann man als Aufstecklösung realisieren. Trotzdem würde mich mal ein Autopilot reizen,der ARM7 ist ideal das zu verarbeiten, was da an Daten
anfällt.

Hier mein Bauprojekt mit grafischem Display und eigenem Grafikcontroller auf Atmel Basis, der vom ARM7 angesteuert wird. Derzeit erfolgt nur
eine Zeitausgabe vom Zeitsignal und eine Temperaturmessung sowie die Ausgabe auf SD Karte. Die SD Treiber sind allerdings geklaut (Chan's FAT Driver)
zu komplex um ein FAT32 System selbst zu programmieren und die MMC Hardware auf dem LPC ist auch schwer zu verstehen, wenngleich die SD Karten
recht einfach sind und auch mit einem PIC habe ich die schon blockweise beschrieben, aber eben kein Dateisystem.

Das Board ist von micro4u, http://www.micro4you.com/store/dev-tools/arm/lpc2368-development-board.html
der Grafikcontroller wurde in microcontroller.net von Benedikt entwickelt, ich habe damals Platinen fertigen lasse und dort verkauft,
die Rowley Crossworks Shell habe ich für 127 Euro in der Privatlizenz gekauft, sie ist einfach besser als alles was an
Freeware angeboten wird, fix und fertig mit GNU-C Compiler, Builder, Einzelzeilen Debugger Projektmanager, allen Headern usw. Das Programmiertool
ist auch von olimex und arbeitet per JTAG über USB, Entwicklung ist meist im RAM (32k), damit das Flash geschont wird.

Ich meine eine komplette Toolkette mit Eclipse, Gnu-Compiler und Debugger als Freeware wäre nicht schlecht, ist mir aber erst mal zu viel Aufwand das alles einzurichten. Da kämpft man an allen Fronten gleichzeitig.

Zum Vergrößern anklicken....

Tja, vor den Erfolg wurde der Schweiss gesetzt. Freeware ist mir auch zuviel Zirkus mit Eclipse usw. Ich wollte auch nur Install & Play haben. Und da blieb eben nur eine
Kommerzversion. Nach der Installation hat man ein weisses Editorfeld und kann loslegen. Die Treiber würde ich aber alle woanders besorgen, das Rad muss nicht zigmal
neu erfunden werden. USB ist mir egal wie es funktioniert, ich benutze es nur einfach. Ebenso wie die SD Karte. Die zu programmieren kann ich zwar anhand der Spec
aber der Treiber für den LPC 2368 hat 20 Funktionen für alle Arten von Dateimanagement und fertig. Da kann man gleich loslegen mit dem was man eigentlich will.

Wozu eine FPU? Mit 72Mhz intern fliegt der LPC schnell genug um Berechnungen zu machen.

ps. Der Tank mit Nitro im Bild gehört nicht dazu :-)

Gruss,
Ralf

cord schrieb:

Vor einiger Zeit bin ich auf die AVR's umgestiegen, kann mich aber nicht so richtig damit anfreunden. Für meine zukünftigen Vorhaben zu wenig Speicher, zu wenige Timer und zu langsam. Im Moment untersuche ich daher die ARM Cortex-M0/M3 Microcontroller von NXP.

Zum Vergrößern anklicken....

Hallo Cord,

mir geht es ganz genauso. Ich habe einiges mit den Atmel-AVR Chips gemacht und hatte das Gefühl, da allzu schnell an die Grenzen zu kommen (Speicher, Geschwindigkeit, Peripherie).
Ich habe dann mal auf Verdacht ein paar ARM-Boards zusammen gekauft (mbed nxp lpc1768, Olimex SAM7-H256 u.a., Olimex LPC-H2106), einfach um mal was zu Spielen zu haben. Im Moment bin ich bei Olimex' LPC-P1114 angelangt, die mir noch am zukunftssichersten erscheinen. Als Entwicklungsumgebung habe ich mir Crossworks von Rowley geholt, kann ich empfehlen. Zum Flashen/Debuggen nehme ich den ARM-USB-OCD und den SWD Adapter von Olimex.
Mein Interesse liegt in der Robotik, da gibt es sicher viele Überschneidungen mit dem Modellbau und so wäre ich tatsächlich an einer Zusammenarbeit interessiert.
Mir schwebt so eine Suite von Funktionen vor, die man sich bausteinartig zusammenstückeln kann. Interessant fände ich in der Zukunft ein eigenes Bord ...

Lass mich doch mal wissen, ob und wie man sich beteiligen kann an Deinem Projekt.
Um dann nicht noch das zusätzliche Problem mit unterschiedlichen Entwicklungssystemen zu haben habe ich mir jetzt doch mal den LPCXpresso geordert (LPC1114 und LPC1769, nebst Base Board). Im Endeffekt würde ich aber wohl zurückkehren zu Olimex LPC-P1114: sind mit 16€ halt schön günstig. Und wenn ich wirklich mal tiefer in die "Schwarm-Robotik" eindringen will zählt der Preis ...

Viele Grüße,
Christoph

(Homepage)

Hyla schrieb:

Mein Interesse liegt in der Robotik, da gibt es sicher viele Überschneidungen mit dem Modellbau und so wäre ich tatsächlich an einer Zusammenarbeit interessiert.
Mir schwebt so eine Suite von Funktionen vor, die man sich bausteinartig zusammenstückeln kann. Interessant fände ich in der Zukunft ein eigenes Bord ...

Lass mich doch mal wissen, ob und wie man sich beteiligen kann an Deinem Projekt.

Zum Vergrößern anklicken....

Ja, ich versuche auch das ganze modular aufzubauen. Die Ansteuerung von vielen Servos wäre evtl. eine Gemeinsamkeit. Welche Module hättest du denn geplant?
Ein eigenes Board soll es übrigens auch noch werden.
Ich hab meinen Source-Code ja bei Google abgelegt, wäre das für dich auch eine Möglichkeit?

Um dann nicht noch das zusätzliche Problem mit unterschiedlichen Entwicklungssystemen zu haben habe ich mir jetzt doch mal den LPCXpresso geordert (LPC1114 und LPC1769, nebst Base Board).

Zum Vergrößern anklicken....

Das ist ja mal interessant, berichte doch bitte mal ob sich die Code Red Umgebung wesentlich unterscheidet.

Ich hab gerade mal eine Liste mit der Pinbelegung der aktuellen Module erstellt: http://lpcxpresso-rc.googlecode.com/files/LPCXpresso-rc_pinning_01.numbers.pdf

Z.Zt. implementiere ich gerade die MMC/SD-Card Schnittstelle von ChaN fürs Logging, anschliessend werde ich mich an eine Drehzahlbegrenzung für Verbrenner machen.

Gruß
Cord

Hi,

hab Deinen Code jetzt mal kompiliert und mit dem Ausprobieren angefangen.
Die Servo-Signale sehen gut aus, sehr präzise.

Wie schon gemailt würde ich mir eine "Servo-Stop"-Funktion wünschen,
also einen "Eintrag", welcher Servo in Betrieb ist und welcher nicht.
Auch die Ansteuerung des EA Dog Displays konnte ich heute mal testen.
Ich hab etwas gebraucht um zu realisieren, dass man den Reset-Eingang
des Displays "händisch" auf 3V legen muss, weil das Ding andernfalls im
Dauer-Reset hängt. Naja, wer lesen kann ...

Wie man sehen kann, haut das so ganz nicht hin. Ist aber klar, weil
ich halt ein anderes Display nehme (ist ein DOGM-132). Die Ansteuerung
ist ähnlich aber nicht identisch und auch die Größe des Displays ist anders
(132x32 bei mir, 102x64 bei Dir). Das bringt mich gleich auf meinen nächsten
Vorschlag: wie wäre es, wenn man den Display-Treiber universeller auslegen würde,
also beispielsweise zumindest mal alle Varianten der DOGs berücksichtigen würde?
Es gibt da außer der Ansteuerung mit SPI Bus noch I2C und die übliche 4Bit/8Bit-
Version, wie sie bei üblichen LCDs verwendet wird. Außerdem Grafik- und Text-
varianten. Wäre allerdings mindestens eine Fleißaufgabe

Außerdem würde ich vorschlagen, so weit wie möglich die vorhandenen Sourcen
von LCPXpresso zu verwenden (es gibt ja schon Treiber für alles mögliche).

Ein Elend ist nebenbei das Durcheinander mit den Pin- und Signalbezeichnungen.
Die Expansion-Ports J5 und J6 haben andere Bezeichnungen als der Steckplatz
für das LPCXpresso-Modul usf.
Dein Schema war da eine echte Hilfe aber auch so braucht das unnötig lange,
bis man sich die Anschlüsse auf dem BaseBoard zusammen gesucht hat ...

Deine Sourcen waren jetzt für den LPC1768/9 bestimmt. Hast Du vor dabei zu
bleiben, oder willst Du zweigleisig weitermachen (und den LPC1114 weiter
verwenden)? Also Cortex-M0 verwenden oder gleich beim Cortex-M3 bleiben,
weil einfach "bigger & better"?

Übrigens: Weiter so

Grüße,
Christoph

Hyla schrieb:

Hi,

hab Deinen Code jetzt mal kompiliert und mit dem Ausprobieren angefangen.
Die Servo-Signale sehen gut aus, sehr präzise.
Anhang anzeigen 763057
Wie schon gemailt würde ich mir eine "Servo-Stop"-Funktion wünschen,
also einen "Eintrag", welcher Servo in Betrieb ist und welcher nicht.

Zum Vergrößern anklicken....

Kann man natürlich machen. Dafür ist ja der Source-Code da.

Auch die Ansteuerung des EA Dog Displays konnte ich heute mal testen.
Ich hab etwas gebraucht um zu realisieren, dass man den Reset-Eingang
des Displays "händisch" auf 3V legen muss, weil das Ding andernfalls im
Dauer-Reset hängt. Naja, wer lesen kann ...

Wie man sehen kann, haut das so ganz nicht hin. Ist aber klar, weil
ich halt ein anderes Display nehme (ist ein DOGM-132). Die Ansteuerung
ist ähnlich aber nicht identisch und auch die Größe des Displays ist anders
(132x32 bei mir, 102x64 bei Dir). Das bringt mich gleich auf meinen nächsten
Vorschlag: wie wäre es, wenn man den Display-Treiber universeller auslegen würde,
also beispielsweise zumindest mal alle Varianten der DOGs berücksichtigen würde?

Zum Vergrößern anklicken....

Klar, wäre nicht schlecht. Ich hab z.Zt. allerdings kein anderes Display zu testen da.

Es gibt da außer der Ansteuerung mit SPI Bus noch I2C und die übliche 4Bit/8Bit-
Version, wie sie bei üblichen LCDs verwendet wird. Außerdem Grafik- und Text-
varianten. Wäre allerdings mindestens eine Fleißaufgabe

Zum Vergrößern anklicken....

Ich hab mir schon einen Pegelwandler gebaut, um auch die üblichen 5V Versionen verwenden zu können, aber noch nicht getestet.

Außerdem würde ich vorschlagen, so weit wie möglich die vorhandenen Sourcen
von LCPXpresso zu verwenden (es gibt ja schon Treiber für alles mögliche).

Zum Vergrößern anklicken....

Sehe ich auch so, Vorschläge?

Ein Elend ist nebenbei das Durcheinander mit den Pin- und Signalbezeichnungen.
Die Expansion-Ports J5 und J6 haben andere Bezeichnungen als der Steckplatz
für das LPCXpresso-Modul usf.
Dein Schema war da eine echte Hilfe aber auch so braucht das unnötig lange,
bis man sich die Anschlüsse auf dem BaseBoard zusammen gesucht hat ...

Zum Vergrößern anklicken....

Ich hab mal eine Tabelle angelegt, wo die Pinbelegungen eingetragen werden. Kann ich dir mal als Excel-Datei zuschicken.
http://code.google.com/p/lpcxpresso-rc/downloads/detail?name=LPCXpresso-rc_pinning_01.numbers.pdf

Deine Sourcen waren jetzt für den LPC1768/9 bestimmt. Hast Du vor dabei zu
bleiben, oder willst Du zweigleisig weitermachen (und den LPC1114 weiter
verwenden)? Also Cortex-M0 verwenden oder gleich beim Cortex-M3 bleiben,
weil einfach "bigger & better"?

Zum Vergrößern anklicken....

Erst mal werde ich aus Zeitgründen wohl nur mit dem LPC1769 weitermachen.

Übrigens: Weiter so

Zum Vergrößern anklicken....

Ja, danke, ich wünsche mir mehr Zeit dafür
Im Moment ist das Projekt etwas ins Stocken geraten, weil ich einen Kollegen beim Bau einer Fräse unterstütze.
Aber bei zum Saisonbeginn möchte ich auf jeden Fall etwas einsatzfertig haben.

Gruß
Cord

Also gut ...



Thema 'Servo':

die Structure Servo_t bekommt ein Element dazu:

Das Element 'used' steht (klar) für Servo gebraucht (1) oder nicht (0).
Dann der IRQ Handler (TIMER2_IRQHandler) in ServoCtrl.c:

Hier bekommt der jeweilige Servo nur dann einen Puls, wenn er verwendet wird.
Schließlich muß das (z.Z. in main.c) auch gesetzt werden:

Scheint zu gehen

Gleich noch eine Frage: im obigen IRQHandler gibt es eine Abfrage für den 'Match channel' MR0 oder MR1.
Wozu ist das? Oder besser: Wo wird das definiert (habe ich nicht gefunden)? Und irgendwie sieht
der Code zu MR1 unfertig aus, es gibt z.B. nur den ServoArray.channel[0]. Kann man das einfach
dem Teil für MR0 nachempfinden, oder gabs da Probleme? Oder ist es unnötig?

Grüße,
Christoph

cord schrieb:

Im Moment ist das Projekt etwas ins Stocken geraten, weil ich einen Kollegen beim Bau einer Fräse unterstütze.

Zum Vergrößern anklicken....

Ähh ... wer braucht denn eine Fräse?
Tsstsstss ...


Christoph

Hi,

Tut sich hier eigentlich noch was? Cord, Dein Projekt hat mir sehr weiter geholfen, gehts damit noch voran?

Christoph

Hyla schrieb:

Hi,

Tut sich hier eigentlich noch was? Cord, Dein Projekt hat mir sehr weiter geholfen, gehts damit noch voran?

Zum Vergrößern anklicken....

Hab im Moment keine Zeit dafür, fliegen und Instandhaltung der Modelle geht vor. Im Herbst soll es aber weitergehen.

Was hast Du denn schönes gebaut?

Gruß
Cord