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.
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
