PIC32 - XC32 - Assembler

Michael schrieb:

> Jetzt habe ich keine richtige Kontrolle mehr über die "Zeit" weil ich
> eben in C programmiere
> In Assembler wusste ich ja noch das ein Befehl (außer ein paar Ausnahmen
> wie GOTO) nur einen Takt benötigen wodurch ich exakte Zeiten bestimmen
> konnte, was oft sehr nützlich sein konnte.

Das kannst Du auf nem MIPS auch in Assembler nicht besser. Die branch 
prediction macht das praktisch nahezu unmöglich.

> Bin ich jetzt komplett auf TIMER angewiesen?

Timer sind der bessere Weg.

> Ich wollte jetzt nur einmal zum testen eine LED Blink Programm in
> Assembler schreiben.

Warum ?

> Den grundlegenden aufbau von dem MIPS Assembler verstehe ich langsam,
> jedoch habe ich keine Ahnung wie ich das an dem PIC32 anwenden kann.
> Z.B. wie spreche ich eine PORTx oder LATx "Register" an, handelt es sich
> jetzt überhaupt noch um Register oder um Speicherbereiche im RAM ?
>
> Es fällt mir schwer mich weiter in den PIC32 einzuarbeiten, wenn ich
> kein LED Blink Programm in Assembler als Grundlage habe, dass ich
> langsam modifizieren kann um zu experimentieren.

Lass Dir von deinem bereits in C geschriebenen Beispiel vom Compiler 
halt mit "-S" in Assembler ausgeben.

Michael schrieb:
> In Assembler wusste ich ja noch das ein Befehl (außer ein paar Ausnahmen
> wie GOTO) nur einen Takt benötigen wodurch ich exakte Zeiten bestimmen
> konnte, was oft sehr nützlich sein konnte.

Ab einer gewissen Komplexität der Prozessoren ist eine exakte 
Zeitkalkulation von Befehlsfolgen mindestens schwierig bis praktisch 
sinnlos. Dann empfiehlt es sich eine Suche nach exakten Taktzählern, wie 
Timern, Systicks, TSCs etc.

Bis zu einem gewissen Grad kann man noch mit selbst kalibrierendem Code 
dagegen halten, d.h. mit Schleifen, deren Verhalten anfangs mal gemessen 
wird. Wenn dann allerdings nichtdeterministische Methoden wie Caches und 
global arbeitende Sprungvorhersagen dazu kommen, dann ist auch das nur 
noch begrenzt einsetzbar.