At86RF212 INT wird nicht ausgelöst

Gibt es einen wesentlichen Grund, warum du nicht die erprobten
Routinen von µracoli benutzt, sondern zwingend deine eigenen
zimmerst?  Eigentlich machst du dir die Arbeit damit nur unnütz
schwer, und mit den vielen "magic numbers" im Code wird der Code
auch nicht gerade besser lesbar.

Auf den ersten Blick ist es nicht einfach zu sagen, was da denn
schief geht.  Suspekt ist zumindest, dass du zwischen dem Start
des Sendens (SLP_TR-Impuls) und dem Herunterschaufeln des Frames
noch eine unbestimmte Zeit wartest, bis sich irgendwie irgendwas
auf der USART getan hat.  Wenn zu diesem Zeitpunkt die Präambel
dann schon aus dem Sender raus ist und du dann noch nicht das
erste Datenbyte gefüttert hast, dann bekommst du einen underrun,
und die Übertragung bricht ab.  Die Präambel hat 5 Octets, was bei
20 kbit/s (die du meiner Meinung nach benutzt, BPSK-100 gibt es
gar nicht) einer Zeit von 2 ms entspricht.

Übrigens: die Register für manufacturer ID und version number sind
read-only. ;-)

Hallo Jörg,

danke für dein schnelle Aatwort und für deine Tipps.
Ich habe die Routinen von µracoli nicht benutzt weil beim kompileren die 
anderen .h dateien nicht erkennt werden ich weiss nicht warum
Kennst du eine komplette Version von diesem µracoli_Projekt ?

Es gibt noch ein paar Sachen die mir noch unklar sind und zwar:

Jörg Wunsch schrieb:
>Suspekt ist zumindest, dass du zwischen dem Start
>des Sendens (SLP_TR-Impuls) und dem Herunterschaufeln des Frames
>noch eine unbestimmte Zeit wartest, bis sich irgendwie irgendwas
>auf der USART getan hat.

Meintest du damit das ich das hier geschrieben habe nach dem SPL_TR das 
hier geschrieben habe ?

while ( !( UCSR0A & (1<<UDRE0)));
    UDR0=trx_reg_read(0x01);

Jörg Wunsch schrieb:
> BPSK-100 gibt es  gar nicht

Ich habe mich nur verschrieben ;)

Jörg Wunsch schrieb:
> Übrigens: die Register für manufacturer ID und version number sind
> > read-only. ;-)

Ich habe mich einfach bei der funktion vertan aber danke für deinen 
Tipp.


Danke Im Voraus!

Sokol Halimi schrieb:

> Kennst du eine komplette Version von diesem µracoli_Projekt ?

Google hätte dir die Antwort deutlich schneller geliefert als
ich, bereits der "Auf gut Glück!"-Knopf hätte es getan:

http://savannah.nongnu.org/projects/uracoli/

> Meintest du damit das ich das hier geschrieben habe nach dem SPL_TR das
> hier geschrieben habe ?

Ja.  Bei 19200 Bd dauert ein Zeichen allerdings nur 0,5 ms, insofern
müsste das noch funktionieren, aber glücklich ist das so nicht
hin geschrieben.  Falls du mal eine höhere Datenrate nimmst,
kracht es dann, weil der Sender leer läuft.

Im Prinzip ist die Erstellung und Einbindung eines eigenen Boards
in uracolli recht einfach.

Die folgende kurze Anleitung sollte das Recoden der
Basisroutinen unnötig machen. Hab mir die Verdrahtung mal
angeschaut, kann das Beispiel aber nicht testen, da ich keinen
mega128 hier habe, aber ein bisschen Debugspass soll ja auch
noch bleiben.

So gehts (in 15min):

1) Quellen auschecken:
   cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/uracoli 
\
        co uracoli

2) Ein Headerfile Src/Lib/Inc/boards/board_XYZ.h erzeugen, in dem
   Fall hab ich board_stkm8.h kopiert und angepasst. (siehe Anhang)

3) Einen Eintrag in Src/Lib/Inc/boards/board.cfg erzeugen

1

[acluxi212]

2

comment    = acluxi212 Hardware

3

include    = boards/board_acluxi212.h

4

cpu        = atmega128

5

bootoffset = 0x0

6

ccflags    =

7

f_cpu      = 8000000UL

8

no_app     = diag rdiag sniffer wuart wgpio

9

no_xmpl    = xmpl_keys xmpl_key_events xmpl_leds xmpl_dbg xmpl_timer

10

             xmpl_hif xmpl_hif_echo

11

             xmpl_trx_echo

12

             xmpl_trx_txaret xmpl_trx_rxaack

13

             xmpl_linbuf_tx xmpl_linbuf_rx xmpl_radio_stream

(die vielen Aushnamen bei den Examples und Apps sind deshalb drin,
weil ich zu faul war, Timer und Uart Macros korrekt zu schreiben :-( )

4) scons acluxi212
   aufrufen, es sollte alles problemlos bauen.

5) Jetzt geht es ans debuggen der Macros, JTAG ICE oder dragon wäre 
schön

5a) Zuerst das Programm xmpl_trx_base.hex/elf laden und debuggen.
    Wenn alle SPI Funktionen und der IRQ richtig funktioniert
    landet man in der while() schleife.

5b) danach xmpl_trx_tx.hex laden, vorzugsweise hat man dabei einen
    sniffer laufen.

5c) danach xmpl_trx_rx.hex laden, wenn auf einem anderen Board
    xmpl_trx_tx.hex arbeitet, blinkt die LED im gleichen Takt.

Nun kann man die Library für eigene Anwendungen nehmen und kann sich
auf die Funktionen verlassen.

.

max schrieb:
> soll das jetzt heissen das die datenrate vom usart kleiner gewählt
> werden muss oder grösser

Es soll heißen, dass man zwischen dem SLP_TR-Impuls (der den Sender
im Transceiver anwirft) und dem Herunterladen der Frame-Daten in den
Transceiver nicht irgendwelche potenziell zeitraubenden Operationen
machen sollte.  Nach dem Anfahren der Sender-Baugruppen beginnt der
Sender mit dem Übertragen der Präambel (4 Octets 0x00 zur Synchroni-
sation, dann kommt das SFD-Octet).  Nachdem er damit fertig ist, muss
allerspätestens das erste Octet des Frames selbst (also das PHR-Octet)
im FIFO angekommen sein, ansonsten gibt's einen FIFO underrun.  Da
der Underrun-Interrupt gar nicht ausgewählt worden ist, sieht man das
nicht einmal sofort.

Allerdings sollte ein TRX_END-Interrupt dennoch in jedem Falle kommen,
auch wenn der Sender die Übertragung mit einem FIFO underrun abbricht.