AT86RF233 löst keinen Interrupt aus

Mit welcher Software steuerst du den Transceiver an? Welchen IRQ 
erwartest Du?

Am einfachsten zu testen ist der Uebergang von TRX_OFF zu PLL_ON oder
RX_ON, da muss der PLL_LOCK IRQ (IRQ_MASK=1) kommen.

danke für die schnelle antwort!
habe noch etwas rumprobiert...das problem ist nicht der interrupt, 
sondern das wechseln von einem status in einen anderen.
hier einmal die funktion:

1

void setState(uint8_t state)

2

{

3

4

  spi_write(TRX_STATE,FORCE_TRX_OFF);

5

  //while (TRX_OFF != (spi_read(TRX_STATUS) & REG_TRX_STATUS_TRX_STATUS_MASK));

6

7

  while (spi_read(TRX_STATUS) == 0x1F);

8

9

  spi_write(TRX_STATE, state);

10

  while (spi_read(TRX_STATUS) == 0x1F); // aus dieser schleife kommt er nicht mehr raus !!!

11

12

  //while (state != (spi_read(TRX_STATUS) & REG_TRX_STATUS_TRX_STATUS_MASK));

13

14

}

0x1F im Statusregister steht für STATE_TRANSITION_IN_PROGRESS.

Irgendwelche Ideen? :)

also in den status TRX_OFF geht er ohne probleme.
aber dann in den status PLL_ON oder RX_ON zu wechseln klappt nicht.

scheint ein hardware-problem gewesen zu sein.
mit einer anderen platine taucht der fehler nicht auf.

ein fehler, den ich allerdings geamcht hatte war, alle interrupts zu 
aktivieren (IRQ_MASK=0xFF).
nachdem ich nur die aktiviert hatte, die ich auch benutze (TRX_END, 
RX_START) lief mein programm einwandfrei.

Thorsten B. schrieb:
> while (spi_read(TRX_STATUS) == 0x1F);

Vorsicht: der Status steht nur in den unteren 5 Bits, die oberen
3 Bits sind anderweitig belegt!  Du musst also passend maskieren.

Allerdings würde ich nicht permanent auf dem SPI herumhämmern, das
kostet viel Strom.  Besser ist es, zwischendrin einen Moment zu
warten.

>ein fehler, den ich allerdings geamcht hatte war, alle interrupts zu
>aktivieren (IRQ_MASK=0xFF).

Es wäre durchaus interessant zu wissen, welche IRQs noch so auftraten, 
die den Programmablauf störten. Vielleicht gibt das ja noch einen 
Hinweis auf
ein Hardwareproblem (sozusagen als Hilfe für das Boardbringup).