LPC1347 GPIO taktet zu langsam

So wie die Fragestellung aussieht würde ich auch nicht davon ausgehen, 
dass  der Fragesteller weiß mit welcher Frenquenz die CPU läuft. Und die 
Dokumentation zum LPC1347 hat er sich sicher auch nicht durchgelesen und 
versucht etwas zu verstehen. Nur mal schnell Rumstochern und dann das 
Forum  arbeiten zu lassen finde ich etwas mutig...

@temp
So wie die Antwortstellung aussieht, ist diese aber auch nicht besonders 
zielführend. Kluge Sprüche klopfen kann ich auch. Abgesehen mal davon, 
habe ich niemanden gebeten meinen Code zu verbessern. Mich interessiert 
nur die Ursache der Diskreptanz zwischen meinen Erwartungen und den 
Messwerten. Eigentlich dachte ich, dass ein Forum dafür da ist und nicht 
damit sich einige namenlose "Schlauköpfe" profilieren. Schäm dich.

Aus dem Manual ist mir durchaus bekannt, dass die Werte in den Registern 
SYSPLLCTRL und SYSAHBCLKDIV für die Takterzeugung relevant sind. Die 
Clock selection war meines Erachtens auch korrekt. Seltsamerweise haben 
meine Veränderungen an MSEL und PSEL nicht zu erwarteten Ergebnissen 
geführt, obwohl der Debugger die entsprechenden Zeilen anstandslos 
abgearbeitet hat. Erst als ich das Projekt neu angelegt habe, konnte ich 
mit dem main clock spielen. Entscheidend bei der Fehlersuche war das 
Herausführen vom main clock an CLKOUT.

@Jim
Ich nehme an, dass die Codeausführung tatsächlich recht langsam ist und 
nun kein Weg an Disassembler und Taktezählen vorbei führt. Danke für die 
Tipps, ich werde die beherzigen.

Ich kann das auf meinem LPC1347 Board nachvollziehen. Der Takt wird 
schon richtig über die PLL auf 72 MHz gestellt. Nur im Code sind ja 
mehrere Unterprogrammaufrufe und da hängt es sehr an der Optimierung des 
Compilers. Wenn ich für die chip und board lib Optimization -o3 und -lto 
einschalte, für das Projekt auch -o3 dann komme ich auf 1,12 MHz. -lto 
darf beim Hauptprojekt nicht eingeschaltet sein, dann werden die lib 
Aufrufe wegoptimiert und der Pin toggelt nicht mehr.

Alexander schrieb:
> So wie die Antwortstellung aussieht, ist diese aber auch nicht besonders
> zielführend. Kluge Sprüche klopfen kann ich auch. Abgesehen mal davon,
> habe ich niemanden gebeten meinen Code zu verbessern.

Och, weder ich noch andere haben versucht deinen Code zu verbessern. 
Ausserdem ist das auch nicht deiner, wie du selbt geschrieben hast. Mal 
abgesehen von den 10 Zeilen.

Alexander schrieb:
> Mich interessiert
> nur die Ursache der Diskreptanz zwischen meinen Erwartungen und den
> Messwerten.

Sorry, wie kannst du überhaupt von was Erwartungen haben was du nicht 
verstehst? Oder hast du die Lib die du verwendest analysiert und 
verstanden. Wenn ja, würden sich die Fragen erübrigen. Den Hinweis die 
GPIO Register sebst zu beschreiben hast du ja schon erhalten. Deine 
Eierei an den Optimierungen ist doch nur ein Nebenkriegsschauplatz.
Gerade wenn es auf Highspeed bei GPIOs ankommt, ist jeder Aufruf einer 
Funktion aus einer Lib großer Mist. Für das Toggeln des Bits 7 im Port 0 
reicht bei deinem uC folgende Zeile:

1

  while (1)

2

    LPC_GPIO->NOT[0]=(1<<7);

3

4

was als Assembler ergibt:

5

6

    4A01        ldr r2, =0x50002300

7

    2380        movs r3, #0x80

8

    6013        str r3, [r2]

9

    E7FD        b 0x00000290

Dazu muss man aber das Usermanual gelesen haben. Und wenn man das hat, 
kommt man nicht auf die Idee schnelles GPIO-Handling mit 
Bibliotheksfunktionen zu machen.
http://www.nxp.com/documents/user_manual/UM10524.pdf

Jim M. schrieb:
> Oder Dein Oszi ist zu langsam - oder der Pin selber, bei 72 MHz sieht
> man das eventuell nicht mal mehr im Oszi.

Nö,
mit der Schleife ohne calls wie von temp beschrieben

1

  while (1)

2

    LPC_GPIO_PORT->NOT[0]=(1<<7);

tickert es für mein Oszi sicht- und messbar mit ziemlich genau 12 MHz. 
Das es mit den C-calls langsamer läuft ist klar und würde mich auch 
nicht stören, ich lasse selten LED per Software mit 800 kHz blinken.
Und das die Linker Optimierung nicht immer funktioniert habe ich schon 
öfter gehabt, vor allem auch bei Code mit Debug Infos.

Nachtrag:
und auch meine mbed Variante mit bösem C++ läuft mir mit 2,2 MHz schnell 
genug:

1

#include "mbed.h"

2

3

int main()

4

{

5

    DigitalOut      testPin(P0_7);

6

7

    while(1) {

8

        testPin = !testPin;

9

    }

10

}

@temp
Bittogle war nicht das Ziel, sondern nur ein Mittel zum Zweck.

Ich bezweifle nicht deine Fachkompetenz, womöglich programmierst du auch 
die USB Schnittstelle selbst. An deiner arroganten Art solltest du 
jedoch nicht weniger arbeiten, als ich an meinen 
Mikrocontrollerunkenntnissen.

An der Optimierung herumzueiern habe ich gar nicht vor, ich denke da 
hast du unbewusst auf einen Beitrag von Johannes reagiert.

Deine kurze und knappe Antwort hätte es von vornherein auf den Punkt 
bringen können:
"Der Code ist einfach schlecht und wenn man Wert auf die Performance 
legt, sollte man nicht auf Standardbibliotheken setzen, sondern alles 
selbst programmieren. GPIO Takt ist bei LPC1347 gleich dem main clock in 
Verbindung mit dem System Clock Divider. Main Clock lasst sich wiederum 
an CLKOUT Pin herausführen und einfach nachmessen. Nachzulesen auf Seite 
12ff UM10524."

Ich danke allen für die Hilfe. Auch dir temp, obwohl mir deine Art zu 
antworten nicht besonders schmeckt. Das Problem hat sich für mich 
erledigt.

auf so Provokationen solltest du hier gar nicht eingehen, 
Programmiersprachen, OS, 8 oder 32 Bit µC und noch einiges sind 
Religionen hier und die Diskussionen versauen dann nur die Threads. Und 
gerade die selbstgekrönten Assemblergötter lauern nur auf solche Themen.
Ich habe das jedendsfalls so verstanden das es nur ein Test war und dann 
die Enttäuschung das da soviel Overhead reinkommt. Aber so ein Beispiel 
taugt mMn nicht zur Beurteilung der Leistung, ein paar Takte mehr oder 
weniger liefern sofort grob unterschiedliche Frequenzen. Interessanter 
an dem LPC1347 ist die gute Peripherie wie die vielen 32 Bit Timer und 
USB incl. Ansteuerung dazu im ROM.