mikrocontroller.net

Forum: Compiler & IDEs At86RF230 initialisieren


Autor: Christian Moschner (moetown)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich habe hier ein Problem beim Initialisieren des At86Rf230.
Ich versuche nach Datenblatt vorzugehen, das heißt:
nach Einschalten min 510µs warten, dann RST Low und SLP_TR Low, wieder 
6µs warten, dann RST High und TRX_OFF Command senden, dann wieder 510µs 
warten.
Anschließend lese ich das TRX_STATUS Register aus und bekomme 16 als 
Wert zurück. Diesen lasse ich mir durch eine LED anzeigen (blinkt 
16mal).
Problem 1: Es sollte 8 mal blinken, was für TRX_OFF steht
Problem 2: Es gibt laut Datenblatt keinen Registereintrag vom Wert 16.

Kann es sein das MSB und LSB verdreht sind? Habe dazu aber keinen 
Hinweis im Datenblatt gefunden.

Danke Christian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Moschner wrote:

> nach Einschalten min 510µs warten, dann RST Low und SLP_TR Low, wieder
> 6µs warten, dann RST High und TRX_OFF Command senden, dann wieder 510µs
> warten.

Nach dem Einschalten musst du nicht zwangsweise einen Reset machen,
das Teil landet beim power-on sowieso im Zustand P_ON.

> Kann es sein das MSB und LSB verdreht sind?

Verdreht im Vergleich wozu?  Das dafür wichtigste, nämlich die
Initialisierungswerte deines SPI-Subsystems, hast du in deinem Code
weggelassen.  Da kann man beim AVR ja auch die Bitreihenfolge
festlegen (mit dem DORD-Bit).

Außerdem solltest du vielleicht dazu schreiben, was für einen
Controller du benutzt.

Obligatorische Schleichwerbung für Axel:

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

Autor: Christian Moschner (moetown)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg, die
>Initialisierungswerte deines SPI-Subsystems, hast du in deinem Code
>weggelassen
habe ich von Atmel übernommen (siehe Code) und auf meinen µC angepasst, 
leider hab ich keine Ahnung was du mit DORD-Bit meinst.

>> Kann es sein das MSB und LSB verdreht sind?
>Verdreht im Vergleich wozu?
Wenn ich bei 0b00010000 (16), MSB und LSB vertausche kommt 0b00001000 
(8) raus, das sollte ja das Ziel sein, TRX_OFF.

Was mich dabei wundert ist, wenn ich das VERSION_NUM Register abfrage 
bekomme ich eine 0b00000010 (2) als Rückgabewert (defaul Wert), ohne MSB 
und LSB zu vertauschen.

>Außerdem solltest du vielleicht dazu schreiben, was für einen
>Controller du benutzt.
Ich benutze einen Atiny84V als Controller.

Danke für den Link, werde ihn mir gründlich durchlesen.

Autor: Christian Moschner (moetown)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg, habe herausgefunden das es das DORD-Bit beim Attiny84 nicht 
gibt. Die Daten die via SPI gesendet werden, verlassen das 
Schieberegister mit dem MSB voran.

Aber was komisch ist, ich habe mir mal das Zusammenspiel von CLK und 
MISO angeschaut, das ist immer um 1 Bit nach links verschoben, also 
0b1000001 wird zu 0b00000010 und das MSB geht verloren. Ich habe schon 
den Takt von 128kHz auf 1 MHz geändert aber da erhalte ich genau das 
selbe Ergebnis.

Auch mit deiner SPI Funktion komme ich beim Register lesen auf Werte die 
jeweils um ein Bit nach links verschoben sind.
static uint8_t SPITransfer(uint8_t data)
{
        USIDR = data;
        USISR = _BV(USIOIF);
        do {
                USICR = _BV(USIWM0) | _BV(USICS1) |
                        _BV(USICLK) | _BV(USITC);
        } while ((USISR & _BV(USIOIF)) == 0);
        return USIDR;
}

uint8_t rf230_regrd(uint8_t regno)
{
        uint8_t rv;

        ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
        {
                PORTA &= ~_BV(7);
                (void)SPITransfer(0x80 | regno);
                rv = SPITransfer(0);
                PORTA |= _BV(7);
        }
        return rv;
}

Ich habe mal ein Bild vom MISO Signal nach Abfrage des TRX_CTRL_0 
Registers gemacht. Laut Datenblatt hat es ein Reset Value von 0b00011001 
(25) aber das Oszi zeigt 0b00110010 an und die LED blinkt 50 mal.

Woher könnte dieser zeitliche Versatz kommen? Bin langsam am 
verzweifeln...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Moschner wrote:

> Hallo Jörg, habe herausgefunden das es das DORD-Bit beim Attiny84 nicht
> gibt.

Ja, ich wusste ja nicht, dass du eine USI mit dem ATtiny hast.

> Aber was komisch ist, ich habe mir mal das Zusammenspiel von CLK und
> MISO angeschaut, das ist immer um 1 Bit nach links verschoben, ...

Déjà vu.  Axel hat mir ähnliches erzählt, und ich glaube mich zu
erinnern, dass die Frage war, welchen Pegel das SCK-Pin beim Initiali-
sieren bekommt.

Ich habe meine tiny230-Platine aber gerade Axel in die Hand gedrückt
für seine Experimente, ich kann es jetzt selbst nicht nachmessen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Errm...  Was mir noch einfällt: was für eine Chip-Version hast du
da?  Meldet die sich als 1 oder 2?  Da gab es Unterschiede im
Timing des MISO-Signals.  Möglicherweise ist hat die USI mit dem
alten Timing ein Problem...

Autor: Christian Moschner (moetown)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Errm...  Was mir noch einfällt: was für eine Chip-Version hast du
>da?

>>Was mich dabei wundert ist, wenn ich das VERSION_NUM Register abfrage
>>bekomme ich eine 0b00000010 (2) als Rückgabewert

das ganze dann um ein Bit nach rechts verschoben macht AT86RF230 
Revision A ...leider

Ich führe jetzt nach jedem Read ein Bitshift >> 1 ein, damit ich 
wenigstens 7 von 8 Bit vernünftig interpretieren kann.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem dürfte sein, dass MOSI wenige Nanosekunden nach der
steigenden Flanke von SCK bereits den Pegel wechselt.  Das
SPI-Interface des AVRs verträgt das, da es vorher sampelt, die
USI (und das SPI eines ARM oder AVR32) verträgt das aber nicht.

Rev. B verzögert den Pegelwechsel bis zur fallenden Flanke von
SCK.

Abhilfe: das Verhalten von Rev B lässt sich durch Einschleifen
eines Latches in der Hardware nachbilden.  Falls du das nicht
kannst/willst, müsste es mit Bitbang-SPI noch funktionieren, da
der AVR seine PINx-Bits bereits sampelt, bevor die aktuellen
Werte von PORTx aktiv werden.  Du kannst also an PORTx eine
steigende Flanke erzeugen und unmittelbar danach in PINx den
Pegel am Pin einlesen, der bis zum Takt davor dort angelegen hat.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal das Oszi-Bild von meinem AT86RF230 rev B.  Es ist deutlich
zu erkennen, dass die Pegel sich jeweils erst mit der fallenden
Flanke von SCK wieder ändern.  Ich vermag natürlich nicht wirklich
zu sagen, ob das bei der USI ein Problem ist oder nicht.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nette Spikes auf der gelben Leitung ;)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
> Nette Spikes auf der gelben Leitung ;)

Einfach nur schlecht geerdet.  Die anderen beiden Tastköpfe hatten eine
Kroko-Klemme für die Masse, der gelbe aber nur so einen Stöpsel, der
auf einen Pfostenstecker passt, da hatte ich gerade nichts passendes
an Masseleitung da, wo ich ihn hätte draufstecken können.

Autor: Christian Moschner (moetown)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@ Jörg
Danke für das Oszibild, werd mal bei Atmel anfragen ob das Problem 
bekannt ist.

Mein Progrämmchen läuft soweit, hab nur eine Sorge mit dem Sleep Modus. 
Obwohl ich alles, wie im Datenblatt beschrieben, gemacht habe, sinkt der 
Stromverbrauch nie unter 7.9mA, was darauf schließen läßt, dass sich der 
AT86RF230 permanent im PLL_ON Status befindet.

Könnte mal jemand über den Code drüber schauen ob ich eventuell doch 
noch etwas vergessen habe, um in den sleep-mode zu gelangen und damit 
die µA-Marke erreiche. Ich hatte nämlich vor die µCs aus einer Batterie 
/ Powercap zu speisen.

Danke

Autor: Christian Moschner (moetown)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe das Problem mit Hilfe von Atmel beheben können.

Das Problem mit dem SPI konnte durch ein neues Board mit Rev.B gelößt 
werden.

Die 7,9mA trotz sleep mode, flossen durch die Z-Diode die auf dem Board 
als Schutz gegen Überspannung dient. Ich habe die Spannungsversorgung zu 
Board gekappt, und direkt auf Pin2 vom Jumper gelegt um somit die 
Z-Diode zu umgehen.

Alles in allem verbrauchen der ATTiny84V und das Board mit dem AT86RF230 
Rev.B im sleep mode 22µA.

Was noch ein guter Tip von Atmel war, man sollte die Pins vorm schlafen 
gehen alle auf low setzen (ausser RST und SLP_TR) und beim aufwecken 
wieder zurück schreiben, das half bei mir von 92µA auf 22µA Verbrauch zu 
kommen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Moschner wrote:

> Alles in allem verbrauchen der ATTiny84V und das Board mit dem AT86RF230
> Rev.B im sleep mode 22µA.

Immer noch ziemlich viel.  Ich bin schon mit den 3 µA bei meinem Board
völlig unzufrieden, es müssten weniger als 1 µA drin sein.  Ich
vermute jedoch, dass der Rest in Kriechströmen draufgeht, die durch
Flussmittelreste unter dem AT86RF230 entstehen.  Sowas lässt sich aber
leider beim Handlöten nicht wirklich vermeiden.  Industrielles Löten
vermeidet das, indem das Lot + Flussmittels als Pastendruck nur an
den Stellen aufgebracht wird, an denen es auch gebraucht wird.

Autor: thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,
hast Du dein At86RF230 Projekt erfolgreich beenden können bzw. verfolgst 
Du es noch aktuell? Ich bin gerade dabei auch eine 
Datenübertragungsstrecke aufzubauen, allerdings sind die Informationen 
im Internet dazu recht spärlich.
Gruß thomas

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fang einfach mal einen neuen Thread im HF-Forum an, dann wird dir
sicher geholfen werden.  Der hier ist einfach uralt und eigentlich
auch im falschen Forum.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.