Von NXP gibt es die kostengünstige ARM-Familie M0. Dazu gibt es auch ein günstiges Entwicklungssystem: http://www.embeddedartists.com/products/lpcxpresso/lpc1114_xpr.php Ich versuche gerade herauszukriegen, wie schnell eine Multiplikation ist ( Kann man gut für FIR-Filter gebrauchen ). Ich finde nur das Datenblatt von ARM. Es gibt leider Prozessoren mit 1Cycle und mit 32 Cycle. Wie viel braucht aber der LPC1114.
Dann probiers doch mal aus. In ner ausreichend großen Schliefe solltest du 1 oder 32 gut erkennen können. Also herausfinden welche der beiden Multiply-Implementationen verwendet wurde. Da es aber im DB und in den Broschüren zu den Cortex-M0 uC von NXP nicht ausgezeichnet wurde, würd ich davon ausgehen, dass die 32 Takte vVersion drin ist. (Schlachtet das Marketing doch sofort aus, oder?)
>Dann probiers doch mal aus. In ner ausreichend großen Schliefe solltest >du 1 oder 32 gut erkennen können. Also herausfinden welche der beiden >Multiply-Implementationen verwendet wurde. Kann ich nicht, weil ich noch keine habe. Ich überlege nur, ob ein M0 für Filter geeignet wäre. >Da es aber im DB und in den Broschüren zu den Cortex-M0 uC von NXP nicht >ausgezeichnet wurde, würd ich davon ausgehen, dass die 32 Takte vVersion >drin ist. (Schlachtet das Marketing doch sofort aus, oder?) Da hast Du recht, das wäre ein starker Hinweis. Wenn der Arm allerdings 32 Zyklen braucht, ist er auch nicht mehr so weit von einem AVR mit Hardware-Multiplizierer entfernt. Wenn ich richtig gesehen habe, soll der M0 Kern ja mit 12000 Gates auskommen. Das wäre auch ein Argument gegen den 1-Zyklen Multiplizierer.
Im Internet bin ich dazu auf folgendes gestoßen:
1 | Unfortunately, GCC currently assumes that you have the slower |
2 | multiplier (even though the LPC11xx actually uses the fast |
3 | implementation), and thus when it sees a multiplication by a constant, |
4 | it will do this using adds/shifts - which it thinks will be faster. |
http://knowledgebase.nxp.com/showthread.php?t=591 Ich habe das mal mit dem gcc 4.5.1 getestet:
1 | int multest(int var) |
2 | {
|
3 | return var * 23; |
4 | 93c: 0043 lsls r3, r0, #1 |
5 | 93e: 181b adds r3, r3, r0 |
6 | 940: 00db lsls r3, r3, #3 |
7 | 942: 1a18 subs r0, r3, r0 |
8 | } |
9 | |
10 | int multest(int var1, int var2) |
11 | {
|
12 | return var1 * var2; |
13 | 93c: 4348 muls r0, r1 |
14 | } |
LPC111x User Manual: "providing high-end processing hardware including a single-cycle multiplier."
Erstaunlich, mit nur 12000 Gates. Ich frage mich, wie viel davon braucht wohl der 32x32 Multiplizierer?
Wer behauptet denn, dass der Cortex M0 Core mit Hardware-Multiplier mit 12K Gates auskommt? Zitat: "12K gates in the minimum configuration", also ohne.
Welche Entwicklungsumgebung verwendet Ihr denn? Soweit ich weiß, gibt es ein Plugin für Eclipse. Da ich schon relativ viel mit dem GCC gemacht habe, würde ich GCC einem Compiler von IAR vorziehen ( Code-Kompatiblität ). Allerdings habe ich auch keine Lust, eine Woche in die Installation der Entwicklungssoftware zu investieren.
Eclipse for C++ (ohne Plugin) / Codesourcery GCC Aber warum muß es nochmal der M0 sein? Am Preis kann es nicht liegen da die LPC13xx eher billiger sind. 100Stk Preise Farnell:
1 | (8k Flash, 4k RAM) |
2 | LPC1111FHN33/201 1.58€ |
3 | LPC1311FHN33 1.40€ |
4 | |
5 | (32k Flash, 8k RAM) |
6 | LPC1114FHN33/301 2.29€ |
7 | LPC1313FHN33 2.05€ |
8 | |
9 | (24k Flash, 8k RAM) |
10 | LPC1113FBD48/301 2.58€ |
11 | LPC1313FBD48 (32k/8k) 2.42€ |
Hinzu kommt das die 13er mit max. 72MHz laufen können. Die Interrupt Latenz ist bei denen mit 12 Takten auch geringer als beim M0 (16 Takte) und der M3 kann dividieren.
>Eclipse for C++ (ohne Plugin) / Codesourcery GCC Hmm, leider habe ich Deinen Post zu spät gelesen. Ich habe die IDE von Code-RED installiert, wie von der NXP-Seite empfohlen. Es ging noch eine Weile, bis ich den Treiber auf XP manuell installiert habe, dann lief es aber problemlos. Wie kann ich den ein Programm zum LPCXpresso ohne die IDE übertragen? >Aber warum muß es nochmal der M0 sein? Am Preis kann es nicht >liegen da die LPC13xx eher billiger sind. So richtig ist mir die Einteilung der ARMs in M0 und M3 nicht klar. Für mich sieht es so aus, als wenn die M3 meistens schneller und mit mehr Speicher ausgestattet sind. Durch Zufall habe ich bei ebay ein LPC1114 XPresso ersteigert. Eigentlich wollte ich einen LPC1768. Jetzt werde ich erst mal ein wenig mit dem LPC1114 experimentieren.
Alles klar. Ich hatte das erst so verstanden das du dich auf den M0 eingeschossen hattest weil der Chip so billig ist und das LPCxpresso Board nur zur Evaluierung gedacht ist. Mit dem klaren Ziel vor Augen irgendetwas in Stückzahlen zu bauen. Die LPCxpresso IDE ist ja ein Eclipse mit einem Plugin und Treibern für dieses Board. Benutze ich dafür auch. Das Board verwende ich aber nur zum Testen. Bei der "normalen" SW-Entwicklung für die Zielschaltungen kommt dann das nackte Eclipse zum Einsatz. Das nehme ich auch für AVR und STM32. Der LPC1114 ist an sich nicht schlecht. Damit habe ich mir mal eine Variante der Wordclock aufgebaut (mit 1MHz Takt). Reicht dafür völlig aus. Es gibt nur leider wie auch beim LPC13xx keine große Auswahl an Gehäusen.
chris schrieb: > So richtig ist mir die Einteilung der ARMs in M0 und M3 nicht klar. Der M0 Core ist kleiner und für den Hersteller ein paar Cent billiger. Für einen Kunden, der grosse Stückzahlen einsetzt, spielt jeder Cent eine Rolle. Bei Einzelstücken oder Kleinserien lohnt es aber eigentlich nicht, sich mit zwei etwas verschiedenen Controllern ähnlicher Klasse abzugeben. > die M3 meistens schneller und mit mehr Speicher ausgestattet sind. Wenn der Core aufgrund viel Flash und komplexer I/O einen eher kleinen Teil der gesamten Chipfläche ausmacht, dann spielt es für die Produktionskosten kaum noch eine Rolle, ob das nun ein M0 oder ein M3 ist. Ein M0 lohnt sich also nur bei Controllern mit wenig Flash und einfacher I/O.
Gerade eben habe ich ein Arm-Forum entdeckt, dass dem MC-Forum hier doch sehr ähnlich sieht: http://embdev.net/forum/arm-gcc Da gab es wohl ein Abspaltung. Ein wenig habe ich auch das Gefühl, dass die ARM-Fraktion hier eher unterrepräsentiert ist.
chris schrieb: > http://embdev.net/forum/arm-gcc > Da gab es wohl ein Abspaltung. Name: embdev.net Address: 188.40.52.210 Name: mikrocontroller.net Address: 188.40.52.210 Fällt dir wenigstens daran was auf? Wo du schon den unübersehbaren Text in "Neuer Betrag" nicht gesehen hast ;-) : "Neu: Beitrag in Englisch Hier klicken, um den Beitrag in Englisch zu schreiben. Der Beitrag wird dann sowohl auf Mikrocontroller.net als auch auf Embdev.net eingeblendet und steht dadurch einem größeren Publikum zur Verfügung."
Für meine ersten Experimente würde ich gerne einen kleinen Soundgenerator realisieren. Dazu benötige ich eine Schleife die mit ca. 30KHz läuft und eine 8Bit PWM. Die Frage ist jetzt, wie bekomme ich die Zeitkonstante Schleife hin. Variante 1: Das ganze mit freertos realisieren. Dort ist mir aber unklar, mit welcher Rate die Tasks aufgerufen werden. Variante 2: Die Ausgabe in den Timer-Interrupt einarbeiten. Es gibt in der "driver" lib Code für den Timer. Allerdings müsste ich dazu den Treiber "vermurksen", weil sich dort ja schon Code für den Interrupt befindet. Wie würdet Ihr vorgehen?
Hat jemand von euch schon einmal mit FreeRTOS gearbeitet? Es hat einen Wikipedia Eintrag und dürfte ganz bekannt sein. Von CodeRED wird ein Beispiel mit FreeRTOS mitgeliefert. Die Taskwechselfrequenz ist dort auf 1kHz eingestellt. Für Audioanwendungen bräuchte ich mindestens 20kHz, eher 40kHz. Der Prozessor läuft mit 48MHz.
Tonausgaben macht man eigentlich in einem Timer Interrupt. Der LPC11xx hat vier davon + den Systicker.
Schon klar. Beim LPC1114 wird eine Driver-Library mitgeliefert. Dort gibt es schöne Treiber für die Timer ( einfach zu initialisieren ). Unpraktisch ist nur, dass in Treiberroutine im Interrupt nur ein Syscounter hochgezählt wird. Ich wollte vermeiden, die Treiber-Lib zu verändern und dort in den Interrupt meinen Code reinzuquetschen.
Diese Driver Lib kenne ich nicht, muß ich mir mal ansehen. Aber ein RTOS so schnell umschalten zu lassen halte ich für keine gute Idee. Bin mir auch nicht sicher ob die Umschaltzeit konstant ist. Da passiert ja doch einiges bei einem Context-switch wenn es nicht gerade ein einfacher Scheduler ist.
>Bin mir auch nicht sicher ob die Umschaltzeit konstant ist.
Hmm, dieses Argument habe ich noch nicht bedacht. Das würde natürlich
auch dagegen sprechen.
Im Moment kämpfe ich mit der IDE. Ich habe das System von Code-RED
heruntergeladen und installiert. Die IDE ist Eclipse basiert. Alle
Code-Beispile lassen sich auch gut kompilieren.
Allerdings schaffe ich es nicht, eine neues Source-File ins Projekt
aufzunehmen. Ich kann es zwar in den Projektordner rein kopieren, wenn
ich aber kompilieren will, erhalte ich immer die Fehlermeldung
"undefined reference to ..xyz.. ".
Die include Files sind im Header angegeben:
#include "...xyz...h".
Auch Eclipse selbst unterstreicht die Funktionen rot mit der Bemerkung
...xyz... nicht zu finden. Wie zum Donnerwetter mache ich Eclipse klar,
dass die Files da sind?
Wenn ich es richtig verstehe, setzt die Code-Red IDE auch auf das
Eclipse plugin CDT auf.
> Ich kann es zwar in den Projektordner rein kopieren, wenn
Die Datei muß in das Projektmanagment aufgenommen werden. Bei Dateien
die über "New->Source file" erzeugt werden (z. B. rechte Maustaste
auf Projektordner) geschieht das automatisch.
Ansonsten mit rechter MT auf Projekt- bzw. einem Unterordnereintrag
und "Import..." auswählen. Dann unter "General->File System" den
Ordner mit der vorhandenen Datei auswählen. Im nächsten Schritt
lassen sich die gewünschten Dateien ankreuzen und in das Projekt
übernehmen.
Michael, vielen Dank. Das sind sehr hilfreiche Hinweise. Das ARM-CMSIS ( CMSIS - Cortex Microcontroller Software Interface Standard ) beinhaltet ein paar äußerst nützliche Treiber. Diese Abstraktionsschicht ist wohl ziemlich gut, wenn man von einem Controller auf den anderen wechseln will. Leider muss ich wohl doch die Timerroutine in der Tiefe selbst programmieren. Es gibt zwar einen PWM-Treiber, irgendwie wird der Timer-Interrupt aber nicht ausgelöst. Im Moment bin ich noch auf der Suche nach dem Datenblatt für die Timer. Im Datenblatt zum LPC1114 steht leider nichts von der Belegung der Register drinn.
chris schrieb: > Das ARM-CMSIS ( CMSIS - Cortex Microcontroller Software Interface > Standard ) beinhaltet ein paar äußerst nützliche Treiber. Welche denn? chris schrieb: > Diese > Abstraktionsschicht ist wohl ziemlich gut, wenn man von einem Controller > auf den anderen wechseln will. > Leider muss ich wohl doch die Timerroutine in der Tiefe selbst > programmieren. Wohl doch nicht so gut? CMSIS kann nur den ARM-Core abstrahieren, bei der Peripherie von den Herstellern hilft nur der Hersteller-Treiber oder man setzt sich direkt mit der Hardware auseinander und schreibt sich die Software selbst. Letzteres ist leider die Regel, da die Treiber oft nur als sehr einfaches Beispiel dienen bzw. nur eine Initialisierungs-API bereitstellen. chris schrieb: > Im Moment bin ich noch auf der Suche nach dem Datenblatt für die Timer. > Im Datenblatt zum LPC1114 steht leider nichts von der Belegung der > Register drinn. Wenn der Timer im ARM-Core sitzt musst du das Datenblatt von ARM zum M0 lesen. Wenn der Timer vom Hersteller kommt, dann sollte die Beschreibung auf im Datenblatt auf der Herstellerseite stehen. Oft sind dort auch direkt die Datenblätter zum z.B. M0 usw. von ARM. Grüße.
Die CMSIS kenne ich eigentlich. Haben die bei NXP jetzt die eigene Peripherie dazu gebastelt? Passt gar nicht zu denen ;). >Im Moment bin ich noch auf der Suche nach dem Datenblatt für die Timer. Du hast wahrscheinlich nur das Datenblatt, brauchst aber das User Manual: http://www.nxp.com/documents/user_manual/UM10398.pdf
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.