AT91SAM7S256: Verständnisfragen.

[Dirk H. (xplod)]

Hallo zusammen.

Ich bin gerade dabei, ein wenig mit einem AT91SAM7S256 zu "spielen", und 
habe soweit mein erstes "Minimalprojekt" am laufen (Die Grundlage, auf 
der alle anderen später aufbauen sollen).

Allmählich begreife ich auch die Struktur des Programmaufbaus, 
allerdings hätte ich da noch einige Fragen zu der Umsetzung:

1.) Bei vielen Beispielanwendungen ist als erste zu linkende Datei immer 
eine "CRT.S" Datei enthalten. Soweit ich es verstanden habe dient diese 
Datei dazu, direkt auf Position 0x0000000 die System Interrupts per 
Sprungkommando einzubinden ( bedeutet "_vec_reset:   b  _init_reset" 
Sprung nach Funktion _init_reset? Oder ist das ein "b" ein define? Ich 
habe "b" nirgends als assemlberbefehl finden können)

2.) Könnte man die Datei crt.s auch als normales C-File anlegen? 
Prinzipiell müsste ich ihm ja nur sagen, dass auf Adresse 0x0000 direkt 
eine Sprungoperation auf eine Funktion reset_event_handler ausgeführt 
werden soll. Aber wie macht man sowas in C? Wenn ich in dieser Datei 
einfach nur

void reset_event_handler(void)
{
  init_frequency();
  ....
  main();
}

schreibe, dann kommt der Debugger durcheinander. Ist ja auch 
verständlich, da alle anderen System Interrupts des Vectors mit teilen 
dieser Funktion belegt sind.

3. Bin ich auf dem Holzweg, wenn ich eine Datei MIN_CRT.s schreibe, die 
nichts anderes enthält als:

.global _vec_reset            
.global _vec_undef            
<...>
.text
.arm
.align
<...>
_vec_reset:   b   reset_event_handler
_vec_undef:   b   undefined_event_handler
<...>

dass ich von dort aus direkt die C-Funktionen anspringen könnte? Wenn 
ich "_vec_reset:   b   main" schreiben würde, wäre dann alles so, wie 
man es bei einem Standard C-Projekt erwarten würde, nämlich dass der 
Prozessor im Defaultzustand in die void main(void) Funktion springt? 
Oder sollte man sowas unterlassen?

[Dirk H. (xplod)]

Ich habe noch was vergessen:

4. Ich habe ein Problem mit dem PIO-Interrupt:

void pin_interrupt_enable(int pin_mask)
{
  volatile AT91PS_PIO PIO_p = AT91C_BASE_PIOA;
  PIO_p->PIO_PER  |= pin_mask; // enable PIO for pin
  PIO_p->PIO_IFER |= pin_mask; // enable glitch filter
  PIO_p->PIO_IER  |= pin_mask; // enable interrupt for pin
  PIO_p->PIO_ASR  |= pin_mask; // use PIO-A funtions
  
}// end of void pin_interrupt_enable(int pin, int iecr)

void set_interrupt_handler(int iecr, int fcn)
{
  volatile AT91PS_AIC AIC_p = AT91C_BASE_AIC;

  AIC_p->AIC_SMR[iecr]  = AT91C_AIC_PRIOR_HIGHEST;
  AIC_p->AIC_SMR[iecr] |= AT91C_AIC_SRCTYPE_INT_POSITIVE_EDGE;
  AIC_p->AIC_SVR[iecr]  = fcn;
  AIC_p->AIC_IECR   |= ( 1 << iecr); // enable PID2 interrupt
  AIC_p->AIC_ISCR   |= ( 1 << iecr); // set PID2 interrupt (???)
} // end of void set_interrupt_handler(int iecr, ISRFcnPtr fcn)

void dummy_interrupt_handler(void)
{
  <...> // mache irgendwas + breakpoint
}
int main()
{
  const int button1 = (1 << 19);//PA19 = bt1
  const int LED1 = ( 1 << 18 );
  
  pin_interrupt_enable(button1);
  set_interrupt_handler(AT91C_ID_PIOA, (int)dummy_interrupt_handler); // AT91C_ID_PIOA = 2
  
<...> 

  while ( 1 )
  {
    idle_task(LED1);
  }
  
  return 1;
  
}

Leider funktioniert dies nicht. Die Funktion dummy_interrupt_handler 
wird nie angesprungen. Im AIC-Register steht auch nie ein "Operation 
pending, o.ä. Bei den AVRs gibt's einen globalen Interrupt_enable, 
leider habe ich den nicht gefunden. Weder in der Doku noch in den 
Beispielapplikationen. Bin ich blind, oder gibt's den nicht und ich habe 
einen anderen Fehler eingenaut?

Wofür benütige ich das   "PIO_p->PIO_ASR  |= pin_mask; // use PIO-A 
funtions"? Es war in den Beispielen enthalten, aber ich habe nicht 
gefunden, wofür das gut ist. Die Beschreibung in der Atmel Doku ist da 
scheinbar etwas dürftig...

[Proc P. (proc)]

Hallo Dirk, habe das gleiche Problem:
Beitrag "Externer Interrupt auf AT91SAM7X-EK mit Eclipse"
Hast Du Deines schon gelöst?

[Dirk H. (xplod)]

Nein, leider nicht.

Würde mich interessieren, ob hier überhaupt jemand Eclipse und einen 
AT91SAM miteinander einsetzt...

[Proc P. (proc)]

Hallo Dirk,
weiß inzwischen woran es liegt (an ethernut; brauche ich leider wegen 
tcpip) kann es aber auch nicht reparieren.

Ohne ethernut läuft bei mir folgendes Testprogramm:

void ex_int_handler (void) 
{ 
  volatile unsigned int ulDummy;    
  AT91C_BASE_AIC->AIC_IDCR = 0xFFFFFFFF; 
  AT91C_BASE_AIC->AIC_ICCR = 0x04000000; 
  AT91C_BASE_PIOB->PIO_CODR=AT91C_PIO_PB19;  // LED1 im Interrupt zum Test anmachen
  asm("mrs r7,CPSR"); 
  asm("bic r7,r7,#0x80");
  asm("msr CPSR,r7"); 
  AT91C_BASE_AIC->AIC_IECR = 0x04000000; 
  AT91C_BASE_AIC->AIC_IVR = 0x0;
  AT91C_BASE_AIC->AIC_EOICR = 0x0;
  ulDummy = AT91C_BASE_PITC->PITC_PIVR;
  AT91C_BASE_AIC->AIC_EOICR = ulDummy;

}

und in

main(){
 ...
  AT91C_BASE_PIOA->PIO_PER=INTTAST;    
  AT91C_BASE_PIOA->PIO_ODR =INTTAST; 
  AT91C_BASE_PIOA->PIO_CODR=INTTAST; 
  AT91C_BASE_PIOA->PIO_PPUER=INTTAST; 
  AT91C_BASE_PIOA->PIO_ASR=INTTAST; 
  AT91C_BASE_PIOA->PIO_OWDR=INTTAST; 
  AT91C_BASE_AIC->AIC_SMR[AT91C_ID_PIOA]=AT91C_AIC_SRCTYPE_INT_POSITIVE_EDGE | 0; 
  AT91C_BASE_AIC->AIC_SVR[AT91C_ID_PIOA]=(unsigned int)ex_int_handler; 
  AT91C_BASE_PIOA->PIO_IFER=INTTAST; 
  int io_status = AT91C_BASE_PIOA->PIO_ISR; 
  AT91C_BASE_AIC->AIC_IECR=(1 << AT91C_ID_PIOA); 
  AT91C_BASE_PIOA->PIO_IER=INTTAST;   
 ...
  while(1){
   ... // hier LED2 blinken lassen
  }