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
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/
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.
Angehängte Dateien:
-
SPI.png
260 KB
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.
1 | static uint8_t SPITransfer(uint8_t data) |
2 | {
|
3 | USIDR = data; |
4 | USISR = _BV(USIOIF); |
5 | do { |
6 | USICR = _BV(USIWM0) | _BV(USICS1) | |
7 | _BV(USICLK) | _BV(USITC); |
8 | } while ((USISR & _BV(USIOIF)) == 0); |
9 | return USIDR; |
10 | }
|
11 | |
12 | uint8_t rf230_regrd(uint8_t regno) |
13 | {
|
14 | uint8_t rv; |
15 | |
16 | ATOMIC_BLOCK(ATOMIC_RESTORESTATE) |
17 | {
|
18 | PORTA &= ~_BV(7); |
19 | (void)SPITransfer(0x80 | regno); |
20 | rv = SPITransfer(0); |
21 | PORTA |= _BV(7); |
22 | }
|
23 | return rv; |
24 | }
|
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...
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.
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...
>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.
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.
Angehängte Dateien:
-
oszi.png
7,4 KB
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.
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.
@ 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
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.
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.
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.