Hallo, mal eine Frage aus reiner Neugier betreffend ARM-Controllern (oder Prozessoren, je nach dem). Zur Zeit verwende ich LPC2k Controller. Wobei ich meist auch das externe Businterface benutze, da ich relativ viel selber gebaute Peripheriebausteine habe, realisiert mittels CPLDs oder FPGAs. Da nur grössere Controller auch ein Businterface haben, verwende ich hauptsächlich LPC23xx und LPC24xx. Praktisch ist, dass man beim LPC24er auch noch SDRAM anschliessend kann. Jedoch denke ich, ist ARM7 je länger je mehr veraltet. Keiner mehr redet von ARM7, alle verwenden ARM9 oder Cortex M3. Wie ist eure Meinung dazu? Was ist zur Zeit "State of the art", wenn man ein externes Businterface möchte? Ich habe bisher noch keinen M3 gesehen, welcher ein solches hat. Beim ARM9 gibt es das zwar, jedoch heisst es oftmals, die seien zu kompliziert, um sie ohne Betriebssystem verwenden zu können. Ist da was dran? Würdet ihr zu einem Umstieg auf irgend ein bestimmtes ARM9 oder M3-Derivat raten? Es müsste natürlich was sein, das auch gut erhältlich ist. Vor TQFP208 und Konsorten habe ich keine Angst, aber BGA geht gar nicht. Das bereitet nur Ärger. Des Weiteren: M3 hat ja Harvard-Architektur. Da kann ich wohl nicht mehr mein eigenes Bootloader-Programm benutzen, welches das auszuführende Programm von einer SD-Karte ins RAM lädt und dann ausführt, oder? Fragen über Fragen. Was meint ihr zu der Geschichte?
Die STM32 haben sehr wohl ein externes Businterface (beim den anderen, wie LPC1700, Stellaris usw, hab ich es grad nicht im Kopf). Allerdings haben sie damit auch ein übles DMA-Problem gewonnen, was den Nutzen doch etwas einschränkt. Ob Daten den Core über zwei Busse betreten oder über einen ist weit weniger relevant, als die Frage nach den Adressräumen. Und da haben alle ARMs und Cortexe exakt einen einzigen Adressraum. Insofern sollte man sich von dem verbreiteten Unfug, alles mit getrennten I/D-Bussen auch dann als Havard zu bezeichnen, wenn es einen gemeinsamen Adressraum hat, nicht irritieren lassen.
> M3 hat ja Harvard-Architektur.
Aber Von-Neumann Programmiermodell.
Latürnich kannst du von RAM oder ExtRAM laufen.
VG,
/th.
Einen Controller vorschlagen ohne jegliche Informationen bezüglich des Anwendungsfall ist relativ sinnlos. Cortex-M3 Controller kann ich STM32 sehr empfehlen. Von der Peripherie her wird relativ viel geboten, Libs für die Entwicklung sind ebenfalls vorhanden. Im November wird auch eine low-power Variante auf den Markt kommen. Brauchst du das externe Businterface nur um mit einem CPLD oder FPGA zu kommunizieren? Eine SPI würde doch zur Not auch helfen oder wäre das zu langsam? lg Rooney
Die Cortex-M3 Derivate von Atmel (ATSAM3S/U/X) verfügen über ein externes BUS Interface mit jeweils eigenem DMA Channel. Es ist auch sehr einfach dieses zu verwenden. Auch die LPC17xx haben einen "external memory Controller". Dieses ist für RAM, ROM und SD-Karten geeignet und kann auch einem eigenen DMA Channel zugewiesen werden. Bei allen Cortex-M3 stehen mehrere DMA Channels zur Verfügung.
Albert ... schrieb: > Bei allen Cortex-M3 stehen mehrere DMA Channels zur Verfügung. Jo, nur sollte man bei den STM32 lieber nicht mit DMA auf diesen externen Speicher zugreifen wollen. Oder nur mit DMA drauf zugreifen wollen. Jedenfalls aber vorher das Erratasheet lesen.
A. K. schrieb: > Albert ... schrieb: > >> Bei allen Cortex-M3 stehen mehrere DMA Channels zur Verfügung. > > Jo, nur sollte man bei den STM32 lieber nicht mit DMA auf diesen > externen Speicher zugreifen wollen. Oder nur mit DMA drauf zugreifen > wollen. Jedenfalls aber vorher das Erratasheet lesen. Dazu kann ich nichts sagen. bei den Controllern von Atmel und NXP hatte ich nie ein problem mit der DMA. Da habe ich auch schon alle DMA Channels testweise ausgelastet und gleichzeitig die CRC Unit mitarbeiten lassen. Und es ist nie etwas schiefgelaufen. Nur Debuggen fällt bei der ganzen Geschichte etwas schwer.
Das Businterface brauche ich vor allem, um mit der externen Peripherie zu kommunizieren. Wie gesagt ist im CPLD (oder je nach Anwendung ein FPGA) ein mehr oder weniger komplexer Peripheriecontroller itnegriert, der diverse Sachen erledigt, welche die Peripherie in den üblichen Controllern gar nicht hat. Ein paralleles Interface wäre mir aufgrund der Geschwindigkeit schon recht. Was mir an Peripherie wichtig wäre: - Integrierte PWM (am liebsten 6fach, für Motoren) - Integrierte SPI und UART-Schnittstellen - Media card interface - Ethernet Wenn der Controller noch zusätzliche Spielereien wie ADCs oder DACs hat, ist mir das auch recht, aber die oben genannten sind am wichtigsten. Neben dem Businterface ;-) Und Taktraten bis 100 MHz oder so wären gut. Der Stromverbrauch ist in meiner Anwendung nicht so kritisch, aber ich muss viel rechnen und ich brauche einigermassen viel Speicher. Am externen Bus hängt noch ein grosser FLASH-Speicher, welcher u.a. die FPGA-Konfiguration enthält, ausserdem werden gewisse Programmteile dort hin ausgelagert. Das Businterface dient also nicht nur zur Kommunikation mit dem FPGA.
Stephan schrieb: > Am externen Bus hängt noch ein grosser FLASH-Speicher, welcher u.a. die > FPGA-Konfiguration enthält, ausserdem werden gewisse Programmteile dort > hin ausgelagert. Wie hat man sich das vorzustellen? Bei Prozessoren ohne Cache laufen Programme aus externem Speicher ausgesprochen langsam.
A.K., ja es läuft langsam. Macht aber nix, da die weniger wichtigen Programmteile, wo es nicht auf Performance ankommt, in dieses externe FLASH abgelegt werden. Dinge, welche wichtig sind, und sehr schnell sein müssen, wie z.B. Interrupthandler oder gewisse mathematische Berechnungen sind im internen Flash.
LPC1788 - 100MHz max. CPU Frequenz - 512kByte on Chip Flash - 96kByte on Chip RAM (davon sind 2 mal 16kByte extra für DMA zugriffe ausgelegt) - LCD Controller (Bis 1024x768 Pixel mit 24Bit Farbtiefe) - 8 DMA Channel - USB - 3x I²C - 5x UART - Ethernet 10/100Mbit - CAN mit 2 Channels - PWM mit 6 Ausgängen - 12 Bit ADC - 10 Bit DAC - 4x Timer - CRC Unit - LQFP 144 oder LQFP208 Gehäuse Alternativ den LPC1768. Gibt es auch bei Farnell zum kaufen. Den LPC1788 habe ich auf die schnelle nicht gefunden.
Stephan schrieb: > A.K., > ja es läuft langsam. Macht aber nix, da die weniger wichtigen > Programmteile, wo es nicht auf Performance ankommt, in dieses externe > FLASH abgelegt werden. Dinge, welche wichtig sind, und sehr schnell sein > müssen, wie z.B. Interrupthandler oder gewisse mathematische > Berechnungen sind im internen Flash. Ich würde sogar schnelle Funktionen im RAM ausführen, denn auch internes Flash ist langsam und man braucht bei den meisten Controllern ab höheren Frequenzen Wait-States.
Rooney Bob schrieb: >> A.K., >> ja es läuft langsam. Macht aber nix, da die weniger wichtigen >> Programmteile, wo es nicht auf Performance ankommt, in dieses externe >> FLASH abgelegt werden. Dinge, welche wichtig sind, und sehr schnell sein >> müssen, wie z.B. Interrupthandler oder gewisse mathematische >> Berechnungen sind im internen Flash. > > Ich würde sogar schnelle Funktionen im RAM ausführen, denn auch internes > Flash ist langsam und man braucht bei den meisten Controllern ab höheren > Frequenzen Wait-States. Na das mir der Geschwindigkeit kommt doch sehr auf die Architektur and ein wenig auch auf die Geschwindigkeit des Flash an. So verliert man ganzzahlige Faktoren wenn man vom internen Flash auf externes Flash geht aber nur im Bereich vielleicht 10% gegenueber SRAM im LPC1xxx. Allerdings ist der Performance Verlust bei anderen Flash Anbindungen z.T. erheblich mehr. Alles in allem erlaubt internes Flash jedoch eine sehr gute Performance verglichen mnit externem Flash. Robert
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.