Bedeutung von crt.s isrsupport.c lowlevelinit.c bei Eclipse

[Max (Gast)]

Hallo.

Ich programmiere AT91SAM7S256 und benutze als Entwicklungumgebung 
Eclipse.
Kann mir jemand die genaue Bedeutung von crt.s isrsupport.c 
lowlevelinit.c erklähren? Vor allem crt.s verstehe überhaupt nicht. In 
isrsupport.c gibt es eine Funktion enableIRQ. Was macht diese genauer? 
Aktiviert alle Interrupts, nee oder? Ich glaube bei mir treten öfters 
Probleme/Unregelmäßigkeiten mit Interrupts auf.
Danke für Hilfe Voraus.

[Martin T. (mthomas) (Moderator)]

Max wrote:
> Hallo.
>
> Ich programmiere AT91SAM7S256 und benutze als Entwicklungumgebung
> Eclipse.

Da hat nichts mit Eclipse zu tun. Eclipse ist ein "besserer Editor". Die 
Fragen betreffen den Quellcode der Anwendung.

> Kann mir jemand die genaue Bedeutung von crt.s isrsupport.c
> lowlevelinit.c erklähren?

Dateien mit diesen Namen enthalten typischerweise:

crt.s - Startup-code für den ARM-code (Exceptions, Stack-Init, 
C-Runtime-Init)

isrsupport.c - Funktionen um IRQ (und evtl. FIQ) auf core-level zu 
aktivieren/zu deaktivieren

lowlevelinit.c - enthält oft nur eine einzige in C implementierte 
Funktion mit der einige Register "früh" gesetzt werden, wird meist vom 
Startup-Code gerufen (im System-Mode mit temporärem Stack-Pointer). Bei 
AT91 üblich: Watchdog einstellen/ausschalten, Frequenzen setzen (PLL, 
Core, PCLK)

> Vor allem crt.s verstehe überhaupt nicht.

Es gibt ein Tutorial von Jim Lynch, darin wird der Startup-Code ganz gut 
beschrieben, weiterhin Application-Notes von Atmel (AT91 startup o.ä.)

> In
> isrsupport.c gibt es eine Funktion enableIRQ. Was macht diese genauer?

Im Prinzip das IRQ-Bit im CPSR löschen. Grundvoraussetzung dafür, dass 
IRQs verarbeitet werden.

> Aktiviert alle Interrupts, nee oder?

IRQ Interrupts, ja. Zudem ist aber auch der AIC noch entsprechend zu 
konfigurieren.

>Ich glaube bei mir treten öfters
> Probleme/Unregelmäßigkeiten mit Interrupts auf.

Zu wenig Information, ...Glaskugel...

[Max (Gast)]

Danke für die Antwort!


>Zu wenig Information, ...Glaskugel...
Also ich benutze 4-PWM-Kanäle PA0(LED), PA1(Sinus), PA2(LED) und 
PA7(Motor).
Das Sinussignal wird mit Interrupts erzeugt. D.h. es wird immer ein Wert 
der Sinustabelle während des PWM-Interrupts in das CUPDR-Register 
geschrieben(Code ist im Anhang).
Dabei tritt bei mir folgendes Problem auf: wenn alle PWM-Kanäle (oder 
sogar wenn 2) aktiv sind zittert das Sinussignal. Wenn aber nur der 
Sinus-PWM-Kanal aktiviert ist, ist  der Sinus stabil.
In Interruptroutine habe ich ein Triggersignal(PA15) für den Oszilloskop 
integriert. Diesem ist anzusehen, dass es auch zittert. Daraus schliesse 
ich, dass es beim Interruptaufruf Unregelmäßigkeiten gibt.
Dann stellt sich aber die Frage warum beim Einkanalbetrieb(Sinus) alles 
stabil ist? Vielleicht ist meine PWM-Initialisierung nicht richtig? Habe 
alles schon etliche Male überprüft.