ich lese mich gerade durch die Datenblätter von Atmel. und habe noch einige fragen zu diesem Thema. 1.(Interrupts) wenn ich das richtig verstanden habe können diese sich gegenseitig unterbrechen aber nur wenn eine höre Priorität vor liegt ( int0 darf int1, int2 aber nicht int1) ist das richtig so? 2.(Taktgeschwindigkeit) im Datenblätter steht das ein Quarz mit 20MHz und eine maximale Prozessor Taktgeschwindigkeit von 240MHz zulässig sind, die Peripherie maximal 80% so schnell getaktet werden darf wie der Prozessor aber nicht schneller als 180MHz. Warum ist hier immer die rede von 180MHz Prozessor Taktgeschwindigkeit? 3.(SPI) wenn ich richtig liege kann ich jedem SPI Kanal eine eigene Taktgeschwindigkeit zuordnen ist das richtig (SPI1.1 mit 2MHz SPI1.2 mit 8MHz usw.)? ich danke euch im voraus Michel
noch etwas das ich nicht verstehe ist: die MMU wie schnell ist diese da NAND Flach ja mehr oder weniger schnell ist und SDRam mit 100 MHz betrieben wird.
Interrupt-Priorität: Kann ich jetzt gar keine Aussage zu machen. In Linux kannst Du nur bestimmen, ob Deine Interrupt-Routine unterbrechbar ist oder nicht. CPU-Geschwindigkeit: 180 MHz für den Typen im erweiterten Temperaturbereich, 210 MHz bei 0-70 Grad. SPI: die Takte sind programmierbar, ja. MMU: ist schnell genug. Das NAND-Flash wird übrigens NICHT verwendet, um Programmcode auszuführen. Das Programm wird ins SDRAM kopiert und dort ausgeführt.
Hallo Michel, du hast es ganz richtig erkannt. Ich habe gerade meinen Stack auf diesen Prozessor (AT91SAM9XE) angepasst und bin zu einem entäuschenden Ergebniss gekommen. Egal wie ich es anstelle, Er ist genau so langsam wie die ARM7(AT91SAM7X,LPC2468). Es ist nicht nur der SDRAM-BUS, sondern auch der FLASH der die Geschwindigkeit drückt(in disem Fall intern). Alles was unter 4 wait states liegt, führt zu einem "TILT". Die Atmel - Lib(Startup.c) gibt 6 wait states vor.??? Eigentlich kannst du dir deisen Prozessor ersparen.
@manni erstaunt mich etwas! Das Flash im SAM9XE512 ist ganz anders aufgebaut als im SAM7X und wenn da keine groben Schnitzer drin sind im Memory Interface von seiten Atmel, dann ergibt schon das neue, breite Flash, einen Sprung in der Performance. Dazu ist der ARM926 bei gleicher Taktrate und gleichem Speicherzugriff schlichtweg 30% schneller durch die verbesserte CPU gegnueber einem ARM7. Das alles gesagt, hat der 9260, um den es urspruenglich ging, den Vorteil eines stattlichen on-chip SRAM Blockes. Fuer rechenintensive Controll Algorithmen lassen sich Programmteile dorthin kopieren und bei voller Rechengeschwindigkeit abarbeiten. Es handelt sich dabei naemlich um TCM (tightly coupled memory), die schnellste Option verfuegbar bei ARM9. Also, SAM9XE und SAM9260 sind zwei verschiedene Paar Stiefel und da gibts es sicher noch Optimierungspotential. Robert
Hallo Robert, zu Block1: ich könnte heulen. Ist aber so. Ich tackte den AT91SAM7X nur mit 50MHz und den AT91SAM9XE mit 98..MHz. Gerade davon habe ich mir eine Geschwindigkeitsverbesserung versprochen. Nur wenn ich von den 6 wait states auf 4 wait states gehe, dann ist er minimal schneller. zu Block2 Ist ne gute Idee. Aber..., was für ein Programieraufwand und das kopieren kostet ja auch Zeit. Ich wäre wirklich für jede Information dankbar. Zurzeit komme ich nur auf 98..MHz(PLL) und 4 Waitstates. Wenn jemand weiß, wie man auf die 240MHz kommen soll... manni
hallo manni, frage zu deinem test: hast du sowohl icache udn dcache enabled? wo liegt den dein code? wenn der im externem sdram liegt dann wundern deine ergebnisse nicht weiter. wie breit ist dein sdram? alles was zeitkritisch ist sollte im internen sram liegen, nur das hat single cycle access. selbst das interne flash ist zwar 128 bit breit aber hat eine zugriffszeit von 60ns. gruss gerhard
Hallo Gerhard
Das war der Tipp der Woche
ich habe nun den ICache sowie den DCache aktiviert und siehe da,
er ist doppelt so schnell.
IAR Anpassung:
Ich habe die 4 Zeilen nach "label:" eingefügt.
resetHandler:
/* Set pc to actual code location (i.e. not in remap zone) */
LDR pc, =label
label:
/* Set I Cache and D Cache*/
MRC p15, 0, r0, c1, c0, 0 ; read CP15 register 1 into r0
ORR r0, r0, #(0x1 <<12) ; I Cache enable
ORR r0, r0, #(0x1 <<2) ; D Cache enable
MCR p15, 0, r0, c1, c0, 0 ; write CP15 register 1
/* Perform low-level initialization of the chip using
LowLevelInit() */
LDR r0, =LowLevelInit
LDR r4, =SFE(CSTACK)
MOV sp, r4
MOV lr, pc
BX r0
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.