Anpassung Atmel MAC Zigbit Module -- Nur Reset & Int?

[Daniel S. (daniel123)]

Hallo

Ich bekomme die Atmel Mac Software in Verbindung mit Zigbit kompatiblen 
Modulen nicht zum laufen. Andere haben es anscheinend hin bekommen, ich 
jedoch nocht nicht :-( .
Müssen nur Anpassungen in der:

pal_board.c
pal_config.h
und
pal_irq.c
gemacht werden?

Reset von PB5 auf PA7
und
Int0 zu Int5  ?

Wie ist es wenn kein externes Eeprom vorhanden ist?
Diese Zeilen dazu in der pal_config.h verstehe ich nicht

//////////////////////////////////////////////////////////////////

/*
 * This board has an external eeprom that stores the IEEE address
 * and other information.
 */
#define EXTERN_EEPROM_AVAILABLE            (1)

/*
 * This board has an external eeprom that stores the IEEE address
 * and other information.
 */
#ifndef EXTERN_EEPROM_AVAILABLE
#define EXTERN_EEPROM_AVAILABLE            (1)
#endif
///////////////////////////////////////////////////////////////////

Ist das ganze noch wo anders definiert?
oder Reicht es aus wenn ich den obigen Teil lösche und stattdessen

#define EXTERN_EEPROM_AVAILABLE            (0)

hinschreibe?

Ich benutze übrigen das Projekt mit dem STK500

REB_5_0_STK500_STK501

Die Uart ausgabe funzt damit wenigsten...
Ein Verbindungsaufbau ist mir noch nicht gelungen.

Müssen noch Adressen vergeben werden?
Oder sind diese jetzt schon irgendwo definiert?

Ich habe die genannten unveränderten Dateien angehangen.


Gruß Daniel

[Jörg W. (dl8dtl) (Moderator)]

Daniel S. schrieb:

> Müssen nur Anpassungen in der:
>
> pal_board.c
> pal_config.h
> und
> pal_irq.c
> gemacht werden?

Sinnvoll ist es, diese von einem naheliegenden Board zu clonen
und einen eigenen Boardtype dafür zu erfinden.  Dafür brauchst
du dann natürlich noch einen Eintrag im zugehörigen pal_boardtypes.h.

Vorsicht, du hast ein REB (radio extender board) 5.0 modifiziert,
wenn ich deinen Dateinamen richtig deute.  Das ist eins für den
AT86RF212, also 868/810 MHz.  Benutzt du ein Zigbit für diesen
Frequenzbereich?

> Reset von PB5 auf PA7
> und
> Int0 zu Int5  ?

Weiß gerade nicht, wie das bei den Zigbits mit den Timestamps
aussieht.  Hängt u. U. auch davon ab, ob es die 900-MHz-Version
ist oder die für 2,4 GHz.

> Wie ist es wenn kein externes Eeprom vorhanden ist?

Dann musst du EXTERN_EEPROM_AVAILABLE zu 0 definieren.  Die
MAC-Adresse wird dann nicht im externen EEPROM erwartet sondern
in den ersten Zellen des ATmega1281-EEPROMs.  (Die RCBs und
REBs haben einen separaten AT25010-EEPROM, der die MAC-Adresse
sowie weitere Parameter während der Boardherstellung programmiert
bekommt.)

> Müssen noch Adressen vergeben werden?

Ja, MAC-Adressen (also EUI-64) sollten die Teile schon haben,
sonst lässt sich der MAC gar nicht initialisieren.

> Oder sind diese jetzt schon irgendwo definiert?

Ich habe meine Programmieradapter für die Zigbits noch nicht fertig,
kann also gerade noch nicht nachsehen, ob da im EEPROM was drin
steht.  Aufgedruckt steht ja offenbar nichts.

Vorsicht mit AVR Studio, das hat eine penetrante Neigung, den EEPROM
beim Programmieren eines Projekts zu löschen.

[Daniel S. (daniel123)]

> Sinnvoll ist es, diese von einem naheliegenden Board zu clonen
> und einen eigenen Boardtype dafür zu erfinden.  Dafür brauchst
> du dann natürlich noch einen Eintrag im zugehörigen pal_boardtypes.h.
>
Ich habe schon versucht diesen Teil Anzupassen, leider ohne Erfolg.
Beim Debugging hängt das Programm dann in einer Fehlerschleife soweit 
ich das erkennen konnte

> Vorsicht, du hast ein REB (radio extender board) 5.0 modifiziert,
> wenn ich deinen Dateinamen richtig deute.  Das ist eins für den
> AT86RF212, also 868/810 MHz.  Benutzt du ein Zigbit für diesen
> Frequenzbereich?

Ja das stimmt, ich nutze ein 900Mhz Board. Ich habe ein Kit von AN 
Solutions. Den Dongle und 3 Bricks, habe aber noch einen weiteren Dongle 
bestellt.

http://www.an-solutions.de/products/900_mhz-ger.html
Diese sind kompatibel mit den Zigbits. Die Bitcloud Beispiele für die 
Meshbean-Boards laufen wenn man den Eintrag für den UID-Chip löscht und 
den Eintrag für die Auswahlwahlschalter (End_device,Coord,Router) 
entfernt.

>> Reset von PB5 auf PA7
>> und
>> Int0 zu Int5  ?
>
> Weiß gerade nicht, wie das bei den Zigbits mit den Timestamps
> aussieht.  Hängt u. U. auch davon ab, ob es die 900-MHz-Version
> ist oder die für 2,4 GHz.

Wie gesagt, 900MHz. Könntest du mal in die angehangenen Files schauen 
(wurden von mir nicht bearbeitet)?
Meine Änderungen scheinen nicht richtig zu sein :-(

>> Wie ist es wenn kein externes Eeprom vorhanden ist?
>
> Dann musst du EXTERN_EEPROM_AVAILABLE zu 0 definieren.  Die
> MAC-Adresse wird dann nicht im externen EEPROM erwartet sondern
> in den ersten Zellen des ATmega1281-EEPROMs.  (Die RCBs und
> REBs haben einen separaten AT25010-EEPROM, der die MAC-Adresse
> sowie weitere Parameter während der Boardherstellung programmiert
> bekommt.)
>

Also hätte der Eintrag so gepasst:
#define EXTERN_EEPROM_AVAILABLE            (0)

Ich hatte nur die böse Vermutung, dass das noch an einer anderen Stelle 
definiert ist.

>> Müssen noch Adressen vergeben werden?
>
> Ja, MAC-Adressen (also EUI-64) sollten die Teile schon haben,
> sonst lässt sich der MAC gar nicht initialisieren.
>
Hmm, naja laufen tun sie ja noch nicht :-(
Der MAC lässt sich nicht initialisieren, ich kenne den Grund aber noch 
nicht.

> Vorsicht mit AVR Studio, das hat eine penetrante Neigung, den EEPROM
> beim Programmieren eines Projekts zu löschen.

Wie kann man das verhindern?

[Jörg W. (dl8dtl) (Moderator)]

Daniel S. schrieb:

> Beim Debugging hängt das Programm dann in einer Fehlerschleife soweit
> ich das erkennen konnte

Das deutet darauf hin, dass die Initialisierung schief gelaufen
ist.  Das kann sein, dass es nur an einer fehlenden MAC-Adresse
liegt, kann aber auch sein, dass er nicht mit dem Transceiver
reden kann.

Da der MAC ja als Sourcecode vorliegt, kannst du dich ja mit dem
Debugger mal durch die MAC- und Transceiver-Initialisierung
durch hangeln.

>> Weiß gerade nicht, wie das bei den Zigbits mit den Timestamps
>> aussieht.  Hängt u. U. auch davon ab, ob es die 900-MHz-Version
>> ist oder die für 2,4 GHz.
>
> Wie gesagt, 900MHz. Könntest du mal in die angehangenen Files schauen
> (wurden von mir nicht bearbeitet)?

Das hilft nicht viel, da reinzuschauen, das Zeug ist zu komplex,
als dass man das auf Anhieb überblicken könnte.

Was mir so erstmal in den Sinn kommt, was man prüfen sollte:

. wie wird der Timer betrieben, meiner Erinnerung nach laufen die
  Timer bei Zigbit vom internen CPU-Takt, bei den Atmel-Boards
  dagegen von extern eingespeisten 1 MHz aus dem Transceiver (CLKM)

. ähnlich gelegen, aber trotzdem ein separates Feature: DIG2 vom
  Transceiver ist bei den Atmel-Boards auf einen input capture
  Eingang des AVR gelegt, bei den Zigbits meines Wissens nicht;
  wenn ich rekursiv durch den MAC-Code greppe, finde ich Konstrukte
  wie

#if (defined BEACON_SUPPORT) || (defined ENABLE_TSTAMP)

  und

#if defined(ANTENNA_DIVERSITY) || defined(DISABLE_TSTAMP_IRQ)

  Irgendwas wirst du also wohl mit ENABLE_TSTAMP oder
  DISABLE_TSTAMP_IRQ anfangen müssen, letzteres finde ich auch im
  MAC User Guide erwähnt.

. wenn /RESET an einem anderen Port liegt, guck dir das mit den
  DDRx- und PORTx-Registern genau an, es genügt dann nicht, etwa
  nur das #define für den Pin-Namen von PB5 auf PA7 zu ändern

. LED und Button Interfaces sind sicher auch verschieden


> Also hätte der Eintrag so gepasst:
> #define EXTERN_EEPROM_AVAILABLE            (0)

Ja, denke ich.

> Ich hatte nur die böse Vermutung, dass das noch an einer anderen Stelle
> definiert ist.

Du kannst den GCC mit -dM -E aufrufen (und allen weiteren Parametern,
die du ihm sonst zum Compilieren mitgeben würdest), dann bricht er
nach dem Präprozessor-Lauf ab und gibt eine Liste aller Makros aus,
die definiert sind.  Da solltest du sehen, ob dieser Makro nach wie
vor 0 ist.

>> Vorsicht mit AVR Studio, das hat eine penetrante Neigung, den EEPROM
>> beim Programmieren eines Projekts zu löschen.
>
> Wie kann man das verhindern?

Meines Wissens muss man (bei Benutzung von JTAG) an mehr als einer
Stelle irgendein Häkchen abwählen.  Genau weiß ich es aber nicht, ich
benutze kein AVR Studio.  (Hab' kein Windows und will auch keins
haben.)

[Daniel S. (daniel123)]

>
> Da der MAC ja als Sourcecode vorliegt, kannst du dich ja mit dem
> Debugger mal durch die MAC- und Transceiver-Initialisierung
> durch hangeln.

Ja, habe ich schon öfters versucht etwas heraus zu finden. Hängt dann 
immer in dieser region...
Falls jemand etwas damit anfangen kann.

////////////////////////////////////////////////////////////////
void pal_alert(void)
{
#if (DEBUG > 0)
    bool debug_flag = false;
#endif
    ALERT_INIT();

    while (1)
    {
        pal_timer_delay(0xFFFF);
        ALERT_INDICATE();

#if (DEBUG > 0)
        /* Used for debugging purposes only */
        if (debug_flag == true)
        {
            break;
        }
#endif
///////////////////////////////////////////////////////////
    }
}

> Was mir so erstmal in den Sinn kommt, was man prüfen sollte:
>
> . wie wird der Timer betrieben, meiner Erinnerung nach laufen die
>   Timer bei Zigbit vom internen CPU-Takt, bei den Atmel-Boards
>   dagegen von extern eingespeisten 1 MHz aus dem Transceiver (CLKM)
>
Fuse steht auf intern, reicht das nicht aus?

> . ähnlich gelegen, aber trotzdem ein separates Feature: DIG2 vom
>   Transceiver ist bei den Atmel-Boards auf einen input capture
>   Eingang des AVR gelegt, bei den Zigbits meines Wissens nicht;
>   wenn ich rekursiv durch den MAC-Code greppe, finde ich Konstrukte
>   wie
>

#if (defined BEACON_SUPPORT) || (defined ENABLE_TSTAMP)

>   und
>

#if defined(ANTENNA_DIVERSITY) || defined(DISABLE_TSTAMP_IRQ)

>   Irgendwas wirst du also wohl mit ENABLE_TSTAMP oder
>   DISABLE_TSTAMP_IRQ anfangen müssen, letzteres finde ich auch im
>   MAC User Guide erwähnt.
Ja könnte sein! Irgendwie sind mir hier zu viele Unbekannte drin :-(

> . wenn /RESET an einem anderen Port liegt, guck dir das mit den
>   DDRx- und PORTx-Registern genau an, es genügt dann nicht, etwa
>   nur das #define für den Pin-Namen von PB5 auf PA7 zu ändern
Hmm ja das stimmt
>
> . LED und Button Interfaces sind sicher auch verschieden
>
Ja stimmt

>> Ich hatte nur die böse Vermutung, dass das noch an einer anderen Stelle
>> definiert ist.
>
> Du kannst den GCC mit -dM -E aufrufen (und allen weiteren Parametern,
> die du ihm sonst zum Compilieren mitgeben würdest), dann bricht er
> nach dem Präprozessor-Lauf ab und gibt eine Liste aller Makros aus,
> die definiert sind.  Da solltest du sehen, ob dieser Makro nach wie
> vor 0 ist.

werde ich mal testen

Ich habe hier im Forum gelesen, dass es bei jemandem lief...
Vielleicht sollte ich da mal nachhaken.

Kannst du mir sonst zu einer anderen Software raten?
In uracoli bist du doch auch irgendwie involviert, oder?
Meine Anwendung soll nur ein Stern-Netzwerk unterstützen und Sensordaten 
zum Coordinator übertragen. Also kein Mesh-Routung oder sowas.

[Daniel S. (daniel123)]

Hab den Beitrag gefunden in dem einer eine ähnliche Modifizierung 
gemacht hat.
Beitrag "ZigBit ZigBee Meshnetics"
Leider war er nur gast.... Christian B. ist der eventuell neuerdings 
hier angemeldet? Vielleicht kennt ihn ja jemand.
Werde das ganze mal mit dem RCB212 Code testen anstatt STK500...
Vielleicht gibts ja unterschiede, wenn der Atmel Support duzu rät..

[Jörg W. (dl8dtl) (Moderator)]

Daniel S. schrieb:

> Ja, habe ich schon öfters versucht etwas heraus zu finden. Hängt dann
> immer in dieser region...

Da bist du schon zu weit.  Du musst die Stelle finden, an der
pal_alert() gerufen wird.

Leider kann man im AVR Studio (im Gegensatz zum AVR-GDB) keinen
Stacktrace abfragen, du kannst dich manuell durch den Stackdump
(im SRAM-Fenster) quälen, aber einfacher ist es wahrscheinlich,
mit "step into" und ein paar Versuchen die Stelle zu finden, die
am Ende das pal_alert() aufruft.

Wie schon gesagt, ich kann mir da nur vorstellen, dass entweder
keine MAC-Adresse im EEPROM steht (das solltest du aber schnell
prüfen können mit dem Programmiergerät deiner Wahl, ggf. musst du
eben erstmal eine MAC-Adresse erfinden), oder aber dass die
Kommunikation mit dem Transceiver fehlschlägt.

>> . wie wird der Timer betrieben, meiner Erinnerung nach laufen die
>>   Timer bei Zigbit vom internen CPU-Takt, bei den Atmel-Boards
>>   dagegen von extern eingespeisten 1 MHz aus dem Transceiver (CLKM)
>>
> Fuse steht auf intern, reicht das nicht aus?

Nein, du musst in der Board-Konfiguration dafür was anpassen.  Die
Fuse legt ja nur erst einmal den CPU-Takt fest, der wird auch bei
den Atmel-Boards vom internen RC-Oszillator genommen.  Der MAC (und
auch die Schichten darunter) brauchen aber einen Timerkanal, und
der bekommt bei den Atmel-Boards 1 MHz vom CLKM des Transceivers
eingespeist (in den Eingang T1).  Die Zigbits machen das nicht,
also werden am Ende deine Timer alle nicht laufen.  (Sollte aber
nicht so schwer sein, das umzustellen, da der Atmel-MAC die
Taktquelle des Timers auf internen RC-Oszillator umschaltet, wenn
der Transceiver schlafen gelegt wird.  Im Prinzip musst du den
Timer so betreiben, dass er immer in diesem Modus läuft.)

> Ja könnte sein! Irgendwie sind mir hier zu viele Unbekannte drin :-(

Hast du dir die Stelle im MAC User Guide mal rausgesucht?

> Kannst du mir sonst zu einer anderen Software raten?

Wenn du nicht gen ganzen großen MAC brauchst, kannst du natürlich
auch mal µracoli probieren.

> In uracoli bist du doch auch irgendwie involviert, oder?

Naja, codemäßig nicht so viel, ich biete Axel eher logistische
Unterstützung an (also den ganzen administrativen Kram auf
savannah.nongnu.org).

> Meine Anwendung soll nur ein Stern-Netzwerk unterstützen und Sensordaten
> zum Coordinator übertragen. Also kein Mesh-Routung oder sowas.

Das müsste eigentlich auch mit µracoli zu machen sein.  Du hast halt
keine MAC-Unterstützung zur Zuweisung von kurzen Adressen oder sowas,
das musst du dir bei µracoli zu Fuß organisieren.

[Jörg W. (dl8dtl) (Moderator)]

Daniel S. schrieb:
>>   Irgendwas wirst du also wohl mit ENABLE_TSTAMP oder
>>   DISABLE_TSTAMP_IRQ anfangen müssen, letzteres finde ich auch im
>>   MAC User Guide erwähnt.
> Ja könnte sein! Irgendwie sind mir hier zu viele Unbekannte drin :-(

Hatte jetzt noch etwas mehr Zeit, mir das anzusehen.  Das ist Kapitel
10 im MAC User Guide, überschrieben "Platform Porting".  Das solltest
du dir wohl unbedingt anschauen, wenn du mit dem Atmel-MAC weiter
machen willst.

[Daniel S. (daniel123)]

Das klappt irgendwie noch nicht.
Habe mir das Kapitel man angeschaut, leider ist da ja auch alles eher 
grob beschrieben.

Habe versucht die Config Files nach:

-  RF212.IRQ = MCU.PE5 (INT5)
-  RF212.RSM = MCU.PA7
-  RF212.SLPTR = MCU.PB4
-  RF212.SPI_SEL = MCU.PB0
-  RF212.SPI_SCK = MCU.PB1
-  RF212.SPI_MOSI = MCU.PB2
-  RF212.SPI_MISO = MCU.PB3

anzupassen.

Ich habe Versucht nach dem RCB_5_3-Board Beispiel vorzugehen.
Wie kann der Timestamp abgeschaltet werden?
Falls er überhaupt an ist....ist mir noch nicht ganz klar.
von
#define NO_OF_TRX_IRQS                  (2)
zu
#define NO_OF_TRX_IRQS                  (1)

????

Externer Ram wird dort auch verwendet, soweit ich das sehen konnte.

/* Enable external Memory Interface (IO, LED, USB) */
XRAM_ENABLE();

Oder was bedeutet das?
Die LED Button Port habe ich versucht anzupassen

Die Ausgabe musste auch von USB auf UART1 im Makefile umgestellt werden.

Und ich weiss micht genau wie ich die Interrupts von int0 auf int5 
umstelle. Hab es zwar probiert, überall bei aus
int0 und intf0
int5 und intf5
zumachen

//////////////////////////////////////////////////////////////////////// 
/

    /*
     * Set the handler function.
     * The handler is set before enabling the interrupt to prepare for 
spurious
     * interrupts, that can pop up the moment they are enabled
     */
    irq_handler[trx_irq_num] = (irq_handler_t)trx_irq_cb;

    if (trx_irq_num == TRX_MAIN_IRQ_HDLR_IDX)
    {
        /* Init Main TRX interrupt */
        /* Select rising edge */
        EICRA |= _BV(ISC50) | _BV(ISC51);
        /* clear pending interrupt */
        EIFR = _BV(INTF5);
    }
    else if (trx_irq_num == TRX_TSTAMP_IRQ_HDLR_IDX)
    {
        /* Init RX TIME STAMP interrupt */
        /* The input capture interrupt of timer is disabled */
        TIMSK1 &= ~(_BV(ICIE1));
        /* Rising edge on input capture pin used to trigger IRQ */
        TCCR1B |= (_BV(ICES1));
        /* Input capture flag is cleared */
        TIFR1 |= (_BV(ICF1));
    }
}
//////////////////////////////////////////////////////////////////////

außerdem noch

////////////////////////////////////////////////////////////////////
/* Number of used TRX IRQs in this implementation */
#define NO_OF_TRX_IRQS                  (1)

/* Mapping of TRX interrupts to ISR vectors */
#define TRX_MAIN_ISR_VECTOR                     (INT5_vect)
#define TRX_TSTAMP_ISR_VECTOR                   (TIMER1_CAPT_vect)

/** Enables the transceiver interrupts. */
#define ENABLE_TRX_IRQ(trx_irq_num)     do {    \
    if (trx_irq_num == TRX_MAIN_IRQ_HDLR_IDX)   \
    {                                           \
        /* Enable Main TRX interrupt */         \
        EIMSK |= _BV(INT5);                     \
    }                                           \
    else if (trx_irq_num == TRX_TSTAMP_IRQ_HDLR_IDX)    \
    {                                           \
        /* Enable RX TIME STAMP interrupt */    \
        TIMSK1 |= _BV(ICIE1);                   \
    }                                           \
} while (0)

/** Disables the transceiver interrupts. */
#define DISABLE_TRX_IRQ(trx_irq_num)     do {   \
    if (trx_irq_num == TRX_MAIN_IRQ_HDLR_IDX)   \
    {                                           \
        /* Disable Main TRX interrupt */        \
        EIMSK &= ~(_BV(INT5));                  \
    }                                           \
    else if (trx_irq_num == TRX_TSTAMP_IRQ_HDLR_IDX)    \
    {                                           \
        /* Disable RX TIME STAMP interrupt */   \
        TIMSK1 &= ~(_BV(ICIE1));                \
    }                                           \
} while (0)

/** Clears the transceiver interrupts. */
#define CLEAR_TRX_IRQ(trx_irq_num)     do {     \
    if (trx_irq_num == TRX_MAIN_IRQ_HDLR_IDX)   \
    {                                           \
        /* Clear Main TRX interrupt */          \
        EIFR = _BV(INTF5);                      \
    }                                           \
    else if (trx_irq_num == TRX_TSTAMP_IRQ_HDLR_IDX)    \
    {                                           \
        /* Clear RX TIME STAMP interrupt */     \
        TIFR1 = _BV(ICF1);                      \
    }                                           \

//////////////////////////////////////////////////////////////////////


und hier noch

////////////////////////////////////////////////////////////////////

/*
 * This macro saves the trx interrupt status and disables the trx 
interrupt.
 */
#define ENTER_TRX_REGION()      { uint8_t irq_mask = EIMSK; EIMSK &= 
~(_BV(INT5))

////////////////////////////////////////////////////////////////////////


Ich bin im Moment ratlos!

[Jörg W. (dl8dtl) (Moderator)]

Daniel S. schrieb:

> Ich habe Versucht nach dem RCB_5_3-Board Beispiel vorzugehen.
> Wie kann der Timestamp abgeschaltet werden?

DISABLE_TSTAMP_IRQ definieren sollte wohl genügen, wenn ich den
porting guide richtig verstehe.

Den IRQ-Vektor hast du angepasst (Makro TRX_MAIN_ISR_VECTOR)?
Die ISR für den Timestamp-Vektor kann natürlich weg.

> Externer Ram wird dort auch verwendet, soweit ich das sehen konnte.
>
> /* Enable external Memory Interface (IO, LED, USB) */
> XRAM_ENABLE();

Auf dem REB?  Würde mich wundern, die REBs ("radio extender boards")
sind ja zum Aufstecken auf einen STK500/501 gedacht, die benutzen
eigentlich keinen XRAM.

> Die Ausgabe musste auch von USB auf UART1 im Makefile umgestellt
> werden.

USB?  Die REBs haben kein USB, sondern benutzen die USART vom
ATmega1281.  Du hast möglicherweise ein RCB als Basis genommen, die
kann man auf ein Board drauf stecken (wie z. B. das Sensor Terminal
Board von Dresden Elektronik), das einen FT245 besitzt, um die
Ein-/Ausgaben über USB vorzunehmen.  Dieser FT245 (und die LEDs und
Buttons auf dem Sensor Terminal Board) sind in der Tat in den externen
Speicherbereich eingebunden.  Wenn du aber ein REB als Basis nimmst,
solltest du näher an deinem Zigbit-Clone dran sein.

> Und ich weiss micht genau wie ich die Interrupts von int0 auf int5
> umstelle. Hab es zwar probiert, überall bei aus
> int0 und intf0
> int5 und intf5
> zumachen

Das ist erstmal OK (sofern du die Namen in Großbuchstaben hast ;).

>         EICRA |= _BV(ISC50) | _BV(ISC51);

Guck mal ins Datenblatt...  ISC50/51 stehen in EICRB.

>     else if (trx_irq_num == TRX_TSTAMP_IRQ_HDLR_IDX)

Den Teil kannst du wegwerfen, den Makro TRX_TSTAMP_IRQ_HDLR_IDX kannst
du entfernen, da du keinen Timestamp erzeugen lassen kannst.

> #define TRX_MAIN_ISR_VECTOR                     (INT5_vect)

OK, das ist die Antwort auf meine obige Frage. ;-)

> #define TRX_TSTAMP_ISR_VECTOR                   (TIMER1_CAPT_vect)

Der kann weg.

> /** Enables the transceiver interrupts. */
> #define ENABLE_TRX_IRQ(trx_irq_num)     do {    \

In diesen Makros kann jeweils der zweite Teil auch weg.

> #define ENTER_TRX_REGION()      { uint8_t irq_mask = EIMSK; EIMSK &=
> ~(_BV(INT5))

Ja, ich denke, dass das klar gehen müsste.

> Ich bin im Moment ratlos!

Wenigstens nicht radio-los. ;-)

[Daniel S. (daniel123)]

Soooo, ich habe mal alles im "REB_5_0_STK500_STK501" Beispiel angepasst.
Irgendwo muss sich aber noch nen Fehler verbergen.

uint8_t pal_trx_reg_read(uint8_t addr)
{
    uint8_t register_value;

    ENTER_TRX_REGION();

#ifdef NON_BLOCKING_SPI
    while (spi_state != SPI_IDLE)
    {
        /* wait until SPI gets available */
    }
#endif

    /* Prepare the command byte */
    addr |= READ_ACCESS_COMMAND;

    /* Start SPI transaction by pulling SEL low */
    SS_LOW();

    /* Send the Read command byte */
    SPDR = addr;
    SPI_WAIT(); //An dieser Stelle

    /* Do dummy read for initiating SPI read */
    SPDR = SPI_DUMMY_VALUE;
    SPI_WAIT(); 

    /* Read the byte received */
    register_value = SPDR;

    /* Stop the SPI transaction by setting SEL high */
    SS_HIGH();

    LEAVE_TRX_REGION();

    return register_value;
}

In dieser Funktion bleibt das Programm immer bei SPI_Wait() hängen!
Die UART Ausgabe bei dem Verwendeten Beispiel die ab und zu schon ganz 
am Anfang nach einem Reset kam (wo aber der Rest nicht lief), kommt 
jetzt nicht...ist ist schonmal schlecht.
Was kanns noch sein?

[Daniel S. (daniel123)]

Vielleicht bin ich ja bald nicht mehr radio-los ! :-)
Mir ist da ein kleiner Fehler bei der Initialisierung LEDs unterlaufen.
Naja vorher hatten die es auch schon so unschön stehen gehabt...

//voher
void pal_led_init(void)
{
    /* Entire port is used for LEDs. */
    LED_PORT = 0xE0;
    LED_PORT_DIR = 0xE0;
}

//nachher...
void pal_led_init(void)
{
    /* Entire port is used for LEDs. */
    LED_PORT |= 0xE0;
    LED_PORT_DIR |= 0xE0;
}

So konnte es natürlich nicht gehen...
Ich suche weiter!

[Daniel S. (daniel123)]

Hmm läuft so durch beim Debuggen. Ich habe keinen Anhaltspunkt mehr, wie 
ich weiter vorgehen könnte. Die Uart Ausgabe am Anfang des Programms 
läuft auch.
Weitere Textausgaben sollten später beim scannen oder Netzeintritt 
kommen, kommt aber nix :-( . Einen hänger im Programm gibts allerdigs 
wie gesagt nicht mehr.

[Jörg W. (dl8dtl) (Moderator)]

Daniel S. schrieb:
> In dieser Funktion bleibt das Programm immer bei SPI_Wait() hängen!

Sowas deutet immer auf fehlenden SPI-Takt hin, oder aber darauf,
dass man den /SS-Pin des Controllers versehentlich zum Eingang
gemacht hat (dann dient er beim AVR als Umschaltung zwischen Master
und Slave).

Daniel S. schrieb:
> Weitere Textausgaben sollten später beim scannen oder Netzeintritt
> kommen, kommt aber nix :-(

Nun musst du wohl mal paar Debugausgaben einbauen, aber nicht zu
viele, so eine UART ist langsam.  Reicht für den Anfang vielleicht,
bei jedem empfangenen Rahmen einfach ein Zeichen auf der UART
auszugeben um zu sehen, ob sie was empfängt.  Was sich auch manchmal
ganz gut macht ist, an einigen "strategischen Punkten" eine komplette
Kopie aller Transceiver-Register irgendwo in den Speicher zu legen.
Die kannst du dir dann im Debugger angucken.

[Daniel S. (daniel123)]

> Sowas deutet immer auf fehlenden SPI-Takt hin, oder aber darauf,
> dass man den /SS-Pin des Controllers versehentlich zum Eingang
> gemacht hat (dann dient er beim AVR als Umschaltung zwischen Master
> und Slave).

Dieses Problem wurde ja wahrscheinlich durch die LED initialisierung 
hervorgerufen.

>
> Nun musst du wohl mal paar Debugausgaben einbauen, aber nicht zu
> viele, so eine UART ist langsam.  Reicht für den Anfang vielleicht,
> bei jedem empfangenen Rahmen einfach ein Zeichen auf der UART
> auszugeben um zu sehen, ob sie was empfängt.  Was sich auch manchmal
> ganz gut macht ist, an einigen "strategischen Punkten" eine komplette
> Kopie aller Transceiver-Register irgendwo in den Speicher zu legen.
> Die kannst du dir dann im Debugger angucken.

Hmm, empfangen wird er ja wahrscheinlich nicht viel, wenn kein 
Netzeintritt ausgegeben wird, oder?

[Jörg W. (dl8dtl) (Moderator)]

Daniel S. schrieb:

> Hmm, empfangen wird er ja wahrscheinlich nicht viel, wenn kein
> Netzeintritt ausgegeben wird, oder?

Die Assoziierung erfordert schon ein paar Datenaustauschaktionen.
Es wäre halt interessant zu wissen, ob kein einziger funktioniert,
oder ob sie sich auf höherer Ebene nicht verstehen.

Aber man kann auch noch viel tiefer anfangen zu debuggen, und erst
einmal jeweils ein Zeichen über die UART senden für jeden
Interrupt, der ankommt.  Dazu einfach alle Interrupts in der Maske
freigeben.  Vielleicht noch beim Start einer Aussendung ein Zeichen,
dann könntest du auf der UART sowas sehen:

te   (tx-Impuls, TRX_END IRQ)

und auf der anderen

rae  (RX_START IRQ, AMI IRQ, TRX_END IRQ)

[Daniel S. (daniel123)]

Yeah es geht!!!
Hätte ich doch schon vor 2 Wochen einmal kurz den Atmel Support 
angehauen :-) !! Warum einfach, wenns auch schwer geht...
Man muss nur ein paar Ordner aus der Angehängten Datei einfügen.
Es sind zwar nur 2 Beispielprogramme modifiziert, jedoch muss man bei 
den anderen nur im Makefile den Boardtype umstellen.

# Build specific properties
_TAL_TYPE = AT86RF212
_PAL_TYPE = ATMEGA1281
_PAL_GENERIC_TYPE = AVR
_BOARD_TYPE = ZIGBIT_212
_SAL_TYPE = AT86RF2xx
_HIGHEST_STACK_LAYER = MAC

Vielen Dank an Jörg für die Unterstützung!

Gruß Daniel

[David C. (Gast)]

Hallo Daniel,

kannst Du eine Abbildung schicken (oder einfach schreiben)? - ich hätte 
gerne gewüst, wie die Verbindungen auf der Boards aussieht. Ich glaube, 
dass ich STK500 und STK501 nicht korrekt verbunden habe.

Erstmals möchte ich einfach deine Code für Star_Nobeacon Application mit 
STK500 und STK501 ausprobieren.
Eigentlich mein Ziel ist Netz zwischen ZigBit Module erstellen, aber 
habe ich noch nicht geschafft. Dieses Fazit mache anhand meines 
Ergebnises in der Applicatin Star_Nobeacon: LED0,LED1,LED2 blinkeln 
gleichzeitig und stetig, was glaube ich falsch ist.

Aber mit meiner (falschen) Verbindungen zwischen STK500 und STK501 habe 
ich auch gleiche Result.

Danke im Voraus
David

[Daniel (Gast)]

Hallo David

Was für Module hast du denn genau? Beim Nobeaconnetzwerk ist doch ein 
Codebeispiel für STK500_STK501 mit dem REB4.0 Board dabei. Oder hast du 
eine andere Version des REBs? Kann man da überhaupt was falsch 
anschließen?
Manche Beispielprogramme erfordern auch gewisse Tastendrücke, du 
solltest dir den UserGuide unbedingt ansehen. Irgendwo werden die 
Applikationen dort erklärt, auch die Funktionen der LEDs. Mein Code wird 
dir nicht viel nützen, da es an die 900MHz Zigbit hardware angepasst 
ist.
Die entscheidenen Anpassungen finden in

pal_board.c
pal_config.h
und
pal_irq.c

statt.
Am besten du wendest dich an Atmel oder Dresden Elektronik, die können 
meistens kompetente Antworten geben

Gruß Daniel

[Chilachava D. (davidc)]

Hallo Herr Wunsch,

ich möchte auch ZigBit module mit MAC software zum Laufen bekommen, aber 
habe bis jetzt nicht geschafft.

pal_boardtypes.h
pal_config.h
pal_irq.c
pal_board.c

in Application:
makefile
makefile_debug
main.c
Star.aps
Star.ewp

Die sind die Liste, wo ich paar Änderungen gemacht habe.
Anbei können Sie alle Anpassungen in einer .doc File schauen.
Ich habe bis jetzt keine Ahnung, welche Änderungen noch machen muss.

Das Ergebnis ist, dass alle drei LEDs gleichzeitig blinkelt (was 
eigentlich nach der Application Star_Nobeacon falsch sein sollte).

Grüße David

[Daniel (Gast)]

void pal_led_init(void)
{
    /* Entire port is used for LEDs. */
    LED_PORT = 0xE0;
    LED_PORT_DIR = 0xE0;
}

Da solltest du es auf

void pal_led_init(void)
{
    /* Entire port is used for LEDs. */
    LED_PORT |= 0xE0;
    LED_PORT_DIR |= 0xE0;
}

ändern, falls der Rest richtig ist. Ist mir nur so aufgefallen.
Manche Sachen sind nicht so einfach zu finden, ich habe mich auch sehr 
lange damit herum geschlagen. Ich kann dir nur Empfehlen den Atmel 
Support anzuschreiben!! Es kann sehr lange dauern den Fehler zu finden.

Du hast also Zigbit Module mit nem Stk500 und einem STK501, oder wie 
muss ich das verstehen?? Welche Hardware hast du?

Im Anhag habe ich Dateien des RCB_3_2_SENS_TERM_BOARDs mit denen aus dem 
Patch verglichen, darin kannst du erkennen welche Änderungen 
Grundsätzlich gemacht werden müssen. Rot durchgestrichen Sachen wurden 
gelöscht, der Rest in rot wurde hinzugefügt. Alles in weiss wurde nicht 
verändert.

Falls du tatsächlich Zigbits hast, bau doch die Patch-Dateien ein.

http://www.mikrocontroller.net/attachment/76916/ZigBit_212_Patch.20100409.zip

Eine genauere Beschreibung von deiner Seite wäre ganz Hilfreich.

Gruß Daniel

[Chilachava D. (davidc)]

Vielen Dank für die Unterlagen, Daniel!

Ich habe es mit meiner Dateien vergelicht. Nur was mir fellt, dass ist 
die Änderungen mit TRX_IRQ. Es sollte eigentlich auch nichts ändern nach 
diesem Abschnitt:

/*
 * AT86RF230B:
 *
 * TRX_MAIN_IRQ_HDLR_IDX       TRX interrupt mapped to MCU input capture 
pin
 * TRX_TSTAMP_IRQ_HDLR_IDX       Not used
 */

/* Number of used TRX IRQs in this implementation */
#define NO_OF_TRX_IRQS                  (1)

/* Mapping of TRX IRQs to MCU pins */
#define TRX_IRQ                         (TIMER1_CAPT_vect)

Ich habe Hardware selbst gebaut und benutze ZIGBIT_ZDM_A1281_A2 Module, 
die AT86RF230B Trancseiver hat.
In der Schaltplan glaube ich kein Fehler habe :)

Außerdem ist in meiner Hochschule STK500 und STK501 für mich vorhanden 
und ich habe die Applications darauf gespielt.Ich habe gedacht,ob ich 
was finde, die in meiner Projekt auch helfen könnte. Aber hat nichts 
gegeben.

Anbei meine Patch Datei.
Ich möchte diese Wochenende auch benutzen, um das Netz zum Laufen 
schaffen.
Dann melde ich bei der ATMEL an.

Grüße David

[Daniel (Gast)]

Achso, du hast nen AT86RF230B Trancseiver drin, dann musste natürlch 
selbst Hand anlegen.
Was hast du denn selbst für eine Hardware erstellt?
Wofür brauchst du das STK501?
Oder hast du was eigenes gebastelt und verwendest zusätzlich noch nen 
Zigbit?

[Chilachava D. (davidc)]

Hallo Daniel,

STK 501 brauche ich nicht, hatte nur Interesse, wie die Applications von 
MAC auf STK501 aussieht.

Ich habe vier kleine Platine entwickelt, alle mit ZigBiT Module und 
möchte das Netz zwischen denen schaffen.

Grüße David

[David C. (Gast)]

Hallo Daniel,

kannst Du nicht mehr mir einen Rat geben??

Grüße David

[Daniel (Gast)]

Hallo David

Welche für Infos brauchst du denn? Ich habe wie gesagt die 900 MHz 
Module. Aber anhand der Patchdateien und den Vergleichsdateien die ich 
gepostet habe müsstest du nachvollziehen können wo der Fehler liegt.
Wie gesagt, du solltest Atmel anschreiben. Mir haben Sie bei dieser 
Sache auch sehr kompetent geholfen und mir promt die Patchdateien für 
meine Module geschickt.

Gruß Daniel

[David C. (Gast)]

Hallo Daniel,

ich melde mich bei Atmel an.
Vielleicht wäre es am richtigsten, was ich momentan machen könnte.

Danke,
David

[Jörg W. (dl8dtl) (Moderator)]

Daniel schrieb:
> Ich habe wie gesagt die 900 MHz
> Module.

Das Pinout dürfte sich allerdings nicht von der 2,4-GHz-Variante
unterscheiden.

[David C. (Gast)]

Hallo Jörg,

Jörg Wunsch schrieb:
> Das Pinout dürfte sich allerdings nicht von der 2,4-GHz-Variante
> unterscheiden.

Das Pinout des ZIGBIT_900MHz_B0 Moduls ist eigentlich nicht 
unterschiedlich mit meinem ZIGBIT_ZDM_A1281_A2 Modul, hat nur extra fünf 
RF output Pins. Unterschied ist das 900Mhz Modul hat AT86RF212 
Transceiver und mein Modul - AT86RF230B.

Grüße David

[Jörg W. (dl8dtl) (Moderator)]

David C. schrieb:
> Unterschied ist das 900Mhz Modul hat AT86RF212
> Transceiver und mein Modul - AT86RF230B.

Das ist aber aus Sicht des Atmel-MACs nicht erheblich, denn er hat
Vorkehrungen für beide ICs bereits drin.

Daniels Patches beziehen sich ja auf das, was man ändern muss, um
insgesamt mit dem Pinout der Zigbits (das ein wenig anders ist als
anderer Atmel-Module) zurecht zu kommen, also andere Anschlüsse
für Interrupt und Steuerleitungen des Transceiver-ICs an den
ATmega1281.  Da besteht zwischen dem 900er und dem 2400er Zigbit
meines Wissens kein Unterschied.

[David C. (Gast)]

Hallo Daniel und Jörg,

ich bin schon weit gekommen, mein großtes Problem habe ich gefunden. 
Mein Transceiver war AT86RF230_REV_A. und dieser Modul hat selbst vieles 
Problem.
Ich habe neue Platine entwickelt und darauf habe ich neue Version von 
dem Modul ZigBit 2,4GHz gelötet, der sicher AT86RF230_Rev_B hat.

Jetzt bin ich schon weit in der Application Star_Nobeacon, aber ich habe 
noch ein Fehler irgendwo. Wenn LED1 nichts gefunden hat, sollte statig 
leuchten statt blinken. Aber es blinkt immer. Ich denken, der Knoten 
kann nicht PAN Coordinator des Netzes bekommen.

Wo kann der Fehler sein? Ich finde der nicht.
Vielleicht kennt ihr diesen Fall und könnt ihr auch was empfehlen?

////////////////
Scheinbar eine Antwort von Atmel dauert lange.

Grüße David

[Daniel (Gast)]

Kannst ja mal die
pal_board.c ,
pal_config.h  und
pal_irq.c

posten, vielleicht findet sich dort auf Anhieb ein Fehler :-) .

[David C. (Gast)]

Also hier,
hoffentlich findest Du doch was. :-)

[Daniel (Gast)]

Ich konnte leider nichts Auffälliges finden..

[David C. (Gast)]

Ok. Danke Daniel,
ich werde Schritt für Schritt in Debugger weitermachen.

[David C. (Gast)]

Yeah es funktioniert!!!

Ich habe ein dummer Fehler ganz im Anfang gemacht und zwar TAL_TYPE in 
main.c geändert.
Jetzt ist klar, warum der Knote nicht PAN Coordinator des Netzes 
bekommen konnte :-)

Vielen Dank an Daniel und Jörg für die Unterstützung!
David

[David C. (Gast)]

Hallo Daniel und Jörg,

ich habe eine C code geschrieben und möchte in MAC_Application 
hinzufügen. Ich glaube, es ist möglich..:-)

Die Filedirection ist so: Applications/Helper_Files/Master_Init/Src und 
entsprechende Änderungen in Makefile sieht so aus:

# Path variables
## Path to main project directory
..................
PATH_MASTER_INIT = $(MAIN_DIR)/Applications/Helper_Files/Master_Init

## Objects that must be built in order to link
OBJECTS = $(TARGET_DIR)/main.o\
..................
$(TARGET_DIR)/master_init.o\

## Compile
$(TARGET_DIR)/main.o: $(APP_DIR)/Src/main.c
  $(CC) $(INCLUDES) $(CFLAGS) -c  -o $@ $<
..................
$(TARGET_DIR)//master_init.o: $(PATH_MASTER_INIT)/Src/master_init.c
  $(CC) $(INCLUDES) $(CFLAGS) -c -o $@ $<

Aber es meldet trotzdem als folgender Fehler:
Make sure your makefile specifies the output .elf file as Star.elf

Wie habt Ihr eure .c oder .h Files zusammen mit MAC_Application benutzt 
oder wo muss ich noch Anpassungen machen?

MfG
David