Hallo,
heute habe ich mal wieder eine kleine Frage:
Ich habe es hinbekommen (viel Kaffe, viel Fluchen, ein fähiger
Kollege), einen STR711 dank Anglia mit einem lauffähigen Programm zu
versehen:
#include <71x_lib.h>
#include <71x_map.h> // Damit Registerdefinitionen bekannt sind
#include <stdio.h>
int main (void)
{
RCCU_Div2Config( ENABLE );
RCCU_MCLKConfig( RCCU_DEFAULT);
RCCU_FCLKConfig( RCCU_RCLK_2 );
RCCU_PCLKConfig( RCCU_RCLK_2 );
RCCU_PLL1Config( RCCU_PLL1_Mul_12, RCCU_Div_1 );
RCCU_RCLKSourceConfig( RCCU_PLL1_Output );
GPIO_Config( GPIO1, 0xFFFF, GPIO_OUT_PP );
while(1)
{
GPIO1->PD = 0;
GPIO1->PD = 0xFFFF;
}
}
Das Programm wackelt also so schnell wie möglich mit einem Port.
Ich kuck mir das Gewackel mit dem Frequenzzähler so an und stelle fest:
4,0 MHz!
Ich hätte mir etwas mehr erwartet, der externe Oszillator läuft mit 8
MHz, und mit den entsprechenden Einstellungen sollte der Core mit 48
MHz laufen und die I/O-Schnittstelle mit 24 MHz.
Kann das wirklich sein, oder mach' ich da was falsch?
Da kann ich ja nen AVR nehmen, der kann das locker!
Hat jemand ne Ahnung?
Beste Grüße -
Franz
Kannst du dir mal das Disassembly anschauen? Dann siehst du wie viele
Befehle der Compiler daraus tatsächlich gemacht hat. Vermute mal stark,
dass das mehr als nur ein Ein/Aus ist.
Das ist eine gute Idee! Danke!
Muß mal kucken wie man das macht... ;-)
Stimmt denn das Clock-Gesetze?
RCCU*
Ich bin das Datenblatt gewissenhaft durchgegangen, kann aber keinen
Fehler finden.
Disassembly-such
so... ich glaub ich hab was Verwertbares gesucht ->
(GPIO1->PD = 0;)
mov r2, #0 ; 0x0
strh r2, [r3, #12]
(GPIO1->PD = 0xFFFF;)
mvn r2, #0 ; 0x0
strh r2, [r3, #12]
b 0x40000330
Das dauert also fünf Zyklen, das wären 9,6 MHz (48/5).
Kann das sein, oder vertu' ich mich da so arg?
Danke -
Franz
Das kann man so einfach nicht sagen, da das Ding eine Pipeline hat.
Da dein Programm schön vor sich hin kreiselt ( while(1) ), kommt
ziemlich oft ein Sprungbefehl dazu, der dann die Pipeline
"aufbricht".
Schreib mal ein paar Ein/Auszyklen hintereinander, also 10 Stück in der
while-Schleife.
Eine weitere Frage ist, bist du im 16- oder 32-Bit Modus?
ich befinde mich im 32-bit Modus...
macht das soviel aus?
den Thumb-Modus habe ich ausprobiert, hat aber nur dazu geführt, dass
der Bootloader nicht mehr seinen Dienst verrichtet hat und
Platinenarbeit nötig war, den Notfall-Bootloader zu aktiviern G Ich
dachte schon, dass der Chip über den Jordan gegangen sei...
Wobei es mich ja schon mal jucken würde 16-bit Coder zu erzeugen. Aber
wie????
Zu den multiplen Befehlen:
Ich hab des Gewackle nun 10 mal wiederholt bevor die Schleife von vorne
beginnt. Das bringt überhaupt nix an Geschwindigkeit. Leider!
Mist!
Du hast net zufällig noch eine Idee? Oder?
Danke -
Franz
hab von den str7* keine ahnung aber einige ideen was da sein kann...
1. prog läuft im flash und flash läuft nicht auf vollem cpu-takt
2. ios sind nicht schnell genug
3. die pll tut nicht was sie soll
du könntest ja mal probieren z.b den spi-bus zum laufen zu bringen und
einfach irgendwelche bytes rauszuschieben...
für gewöhnlich lässt sich die spi-clk bis auf peripherie-clk
hochdrehn...
und der sprung geht tatsächlich in einem takt? ich würd auf 2 tippen =>
8Mhz..
im datenblatt steht drinnen, dass du einen waitstate hast ab 33Mhz wen
n du nicht im flash-burst-mode bist.. damit wärest du dann bei deinen
4Mhz!
also ab mit dem prog in den ram und mal schaun was dan passiert ;)
73
ähm... kleine Frage: ich weiß ich bin Neuling... wie bekomm ich denn das
Programm (ich flashe mit Anglia ins Flash) das Programm in das Ram?
Danke -
Franz
irgendwie sagt man das dem compiler... schau mal nach wie andreas das
bei seinem mp3-player gemacht hat... irgendson schräges attribute ist
da der funktion mitzugeben und dann wird sie beim start ins ram
geschoben..
73
Also vorneweg, mein Beitrag ist sicher nicht ganz unvoreingenommen aber
nichtsdestotrotz richtig.
STR7 hat dasselbe Problem das auch die frueheren Versionen des LPC2000
habe. Die schnellste Toggle Frequenz ist massgeblich durch interne
Interfaces zwischen verschiedenen Bussen runtergebremst. Da gibt es
beim ARM 3 Bus Ebenen, den sogenannten Local Bus, der schnellste aber
meistens reserviert fuer das SRAM, den AHB, "High-Speed bus" und den
APB, den "Peripheral Bus". Im Normalfall haengen die Port Pins am APB
und dazwischen hanegen der AHB und der Loacal Bus. Diese Busse muessen
synchronisiert werden und im Endefeekt bedautet das, die Pins sind
langsamer als erwartet. Die 4 MHz Toggle Rate bekommst Du tatsaechlich
mit einem 8 MHz AVR hin.
Wir (Philips) haben also auch solche Beschwerden bekommen und daraufhin
die Portstruktur bei neueren ARM7 Teilen geaendert. Der LPC214x und
LPC2101/2/3 koennen also bis zu 15 MHz toggle Frequenz erzeugen bei 60
MHz CPU Takt.
Soweit sogut. Sollte die Hauptanwendung allerdings port toggeln sein
und der AVR schnell genug also z.B. 8 MHz toggle bei 16 MHz AVR, dann
rate ich tatsaechlich vom ARM ab. Der ARM rechnet viel schneller,
schiebt viel schneller breitere Daten hin und her, kostet sogar weniger
wenn das Flash 64k oder groesser sein soll (mindestens die Philips Typen
;-) aber er ist grundsaetzlich nicht der beste Prozessor fuer
Bitverarbeitung, schon eher fuer 32-bit Verarbeitung.
Also zusammenfassend: ARM fuer bit toggeln maessig aber trotzdem stark
abhaengig von der Implementierung, die schnellste Implementierung ist
ca. 4x schneller als die langsamste obwohl derselbe Core verwendet
wird!
Gruss, Robert
p.s. fall Du es mit einem LPC2103 z.B. ausprobieren moechtest, das
Board gibts im Shop fuer 39.90 das schnelle Pin Toggeln benuetzt
spezielle Register.
pps, das Board vom Shop laeuft angeblich mit 60 MHz, der Chip kann 70
MHz.
na dann weiß ich ja bescheid!
Danke für den Tipp!
Noch was: gibts denn die Philips-Kontroller auch mal mit geordneten
Ausgängen, wo man beim Routen nicht immer Knoten im Hirn bekommt?
Praktisch wär sowas halt, wenn man z.B. Parallel-Wandler auslesen
möchte, oder Busse aufbauen will.
Liebe Grüße -
Franz
