Forum: Mikrocontroller und Digitale Elektronik Flash Waitstate Bedeutung (ARM)


von Peter (Gast)


Lesenswert?

Hallo,
ich bin grad das Datenblatt vom XMC1100 (ARM M0) durchgegangen. Dort 
steht unter Flash Memory Parameters unter anderem folgendes:

Flash Wait States Min Typ Taktfrequenz
                   0  0,5     8MHz
                   0  1,4    16MHz
                   1  1,9    32MHz
Die Readtime per Word ist mit 50nS angegeben.
Mich würde mal interesieren was dies konkret für die CPU Performance 
bedeutet? Macht es überhaupt sinn die CPU bei 32MHz zu betreiben? Weil 
er liest ja jeden Befehl aus dem Flash und der kann maximal 20MHz. 
Übersehe ich da etwas?
Kann ich evt. Programm aus dem Ram ausführen? Falls ja wie sage ich das 
dem Compiler?
Danke schonmal für eure Hilfe.
Gruß
Peter

von Falk B. (falk)


Lesenswert?

@ Peter (Gast)

>Mich würde mal interesieren was dies konkret für die CPU Performance
>bedeutet?

Dass der Zugriff auf den Flash bei höheren Takten etwas langsamer ist, 
als es theoretisch sein könnte.

> Macht es überhaupt sinn die CPU bei 32MHz zu betreiben?

Sicher. Denn die CPU läuft bei allen Operation, vor allem denen, die 
nicht auf den FLash zugreifen (Logisch, arithmetische Operationen in der 
CPU) mit voller Geschwindigkeit.

>Kann ich evt. Programm aus dem Ram ausführen?

Keine Ahnung ob das der IC kann.

von Jim M. (turboj)


Lesenswert?

Peter schrieb:
> Weil er liest ja jeden Befehl aus dem Flash

Aber nicht einzeln. Thumb2 hat jede Menge 16-Bit Befehle, und da kann er 
zwei auf einmal lesen.

Außderdem dürften für aufeinander folgende Zugriffe keine Wait States 
anfallen, d.h. nur Branches, Interrupts und Loads aus dem Codesegment 
sind primär betroffen. Im Handbuch steht dazu aber leider nix konkretes.

von W.S. (Gast)


Lesenswert?

Peter schrieb:
> ich bin grad das Datenblatt vom XMC1100 (ARM M0) durchgegangen.

O ja.

Mein Rat: klinke diese Mißgeburten von Infineon aus - lieber heute als 
morgen.

Ich hatte mich auch mal für die XMC1X00 Chips interessiert, hatte auch 
mal so ein XMC1100-Bootkit auf der Embedded in die Hand gedrückt 
bekommen. Nun gut dachte ich, der Spezial-Segger auf diesem Kit schien 
ja recht interessant zu sein - aber:

1. das Speicher-Layout dieser Chips ist bejammernswert. Ab 0 - also wo 
jeder Cortex M0 seine Interrupvektoren hat, ist keine Flash, sondern ein 
ROM. Die Vektortabelle ist auch nicht verlagerbar, sie ist IMMER auf 0. 
Der eigentliche Flash geht auf ner krummen Adresse los, m.E.n. ab 
10001000h und dabei ist nach Manual der erste Sektor (wieviel auch 
immer) nicht frei verfügbar.

2. Ich hab dann mal den Chip ausgelesen, wenn ich mich recht erinnere 
von 0..AFF. Weiter geht's nicht, denn der restliche ROM ist 
lesegeschützt und man bekommt nen DataAbort, wenn man es dennoch 
versucht. Dabei ist mir aufgefallen, daß ALLE Interrupt-Vektoren ins ROM 
zeigen.

3. Offenbar kann man diese Chips NUR dann benutzen, wenn man sich sein 
Zeugs per "DAVE" generieren läßt. Wer einen Cortex M0 einfach so 
programmieren will, wie es auf allen anderen Cortex M0 Chips üblich ist, 
der fällt grandios auf die Schnauze.

4. Der Chip hat einen Bootlader - aber der Boot-Mode, also wie der Chip 
hochkommt, hängt von einem internen, programmierbaren Register ab. Es 
gibt KEIN Portbein, anhand dessen man auswählen kann, ob man die gerade 
vorhandene Firmware oder den Bootlader haben will. Man kann sich also 
sehr leicht komplett aussperren - so ähnlich wie es ne Menge AVR-Fans 
schon getan haben. Aber als Briefbeschwerer ist der Chip zu leicht.

5. Ich hatte auf der letzten Embedded so einen "Spezialisten" von 
Infineon darauf angesprochen - und dieser erwies sich als schlichtweg 
inkompetent. Er meinte, daß die Interrupt-Vektoren ins RAM zeigten, was 
schlichter Unsinn ist.

Also, die Chips mögen ja bei Rutronik so einigermaßen billig sein, aber 
seit ich weiß, wie abstrus diese Dinger intern organisiert sind, kommen 
diese XMC's zumindest für MICH überhaupt nicht mehr in Frage. Es gibt 
genug andere Produkte, wo man nen besseren Chip für's gleiche Geld 
kriegt.

W.S.

von Falk B. (falk)


Lesenswert?

@ W.S. (Gast)

>1. das Speicher-Layout dieser Chips ist bejammernswert. Ab 0 - also wo
>jeder Cortex M0 seine Interrupvektoren hat, ist keine Flash, sondern ein
>ROM. Die Vektortabelle ist auch nicht verlagerbar, sie ist IMMER auf 0.

>inkompetent. Er meinte, daß die Interrupt-Vektoren ins RAM zeigten, was
>schlichter Unsinn ist.

Wie kann ich dann eigene ISRs nutzen? Muss ich die in der Firmware 
anmelden, und diese werden dann von der echten ISR (im ROM) aufgerufen. 
Das klingt nicht nach kurzer Latenz. Wie man Probleme löst, die man 
vorher nicht hatte ;-)

von W.S. (Gast)


Lesenswert?

Falk Brunner schrieb:
> Wie kann ich dann eigene ISRs nutzen?

Diese Frage wußte der Fachmann auch nicht zu beantworten - nur soviel 
wußte er: man braucht dafür Code im RAM an bestimmten Stellen - und den 
erzeugt wohl der Startupcode je nach Konfiguration des Ganzen per DAVE.

Das klingt mir alles sehr eigensinnig.

W.S.

Bitte 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
Noch kein Account? Hier anmelden.