µracoli in Betrieb nehmen

Ich kenne nur Miracoli, macht auch weniger Arbeit ;)

Hallo Axel.

>Ich möchte von einem Atmel AVR Raven, später Atmel ZigBit-Modul zu einem
>RZUSBStick Messwerte funken. Auf PC-Seite sollen die Messwerte aus einem
>virtuellen COM-Port rausfallen.

Den Atmel Raven muesste ich endlich mal fertig bauen, bisher fehlte 
einfach die Motivation, das schwarze Federvieh aus der Schachtel zu 
lassen, aber die ist ja jetzt gegeben :-)

Der RZ-USB-Stick hingegen ist dabei.

Wenn du das Paket uracoli-0.0.11-rz.zip lädst, könntest du mal das
Programm uracoli-0.0.11/install/bin/xmpl_hif_rzusb.hex flashen, das
weist dir zumindest schon mal die Funktion des COM Ports nach. Die 
blinkende rote LED am Stick signalisiert, das Daten gesendet werden,
da fehlt dir aber momentan die Gegenstelle zum Empfang, es ist ja leider
nur ein Stick im Starterkit.

Normalerweise wird der CDC Treiber unter Linux als /dev/ttyACMx erkannt,
beim MAC sollte es ähnlich sein. Es ist m.E. nicht nötig, die Baudrate
korrekt zu setzen, der Parameter wird zwar entgegengenommen, aber nicht
weiter emuliert: http://www.recursion.jp/avrcdc/driver.html

>Leider sehe ich auf der Website nirgends mehr einen Hinweis auf das
>ZigBit-Modul. Ich nehme daher an, es gibt ein Stück Hardware, was dem
>ZigBit-Modul so ähnlich ist, dass man einfach die Binary rüber kopieren
>kann? Welche Hardware wäre das denn?

Der Name ZigBit taucht nicht so explizit auf, uracoli-0.0.11-wdba.zip 
ist
das Paket für die 2.4GHz ZigBits - wdba1280 ist die Bezeichnung der 
Meshbean Boards, ... auch dort werde ich nachbessern. 
(uracoli-0.0.11-mnb900.zip für die SubGHz Zigbits)

Cheers, Axel

Verstehe ich dich richtig, dass, wenn ich zwei RZUSBSTICK mit 
xmpl_hif_rzusb.hex flashe, an zwei verschiedene Rechner hänge, auf 
beiden ein Terminal auf die jeweilige Schnittstelle aufmache, einfach 
per Funk hin und her schreiben kann? Zwei RZUSBSTICK habe ich da....

xmpl_hif_rzusb.hex ist nur ein lokales Echo Programm, das funkt gar 
nicht,es dient nur dazu, die serielle Schnittstelle zw. PC und AVR zu 
testen und ggf. zu debuggen.

Für deine Anwendung wäre wuart*hex schon das richtige, wenn du zwei 
Sticks hast, solltest du von einem Terminal zum anderen funken können.

Der Stick ist zunächst im Command mode. d.h. du müsstest mal ATD<Enter> 
tippen, damit er in den Datenmode schaltet.

Ah schade, ich dachte, es gäbe vielleicht ein anderes Programm, was out 
of the box macht, was ich will.

Ich hatte ja das Beispiel wuart ausprobiert und außer blinkenden LEDs 
nix gesehen. Ich würde erwarten, dass wenn ich in einem Terminal ATD 
eingebe, ich die Buchstaben auch sehe oder zumindest irgendeine Reaktion 
bekomme.

Gestern bin ich mal mit dem JTAG durchgegangen und habe festgestellt, 
dass das Programm in wuart_init() hängen bleibt, nämlich beim call zu 
radio_set_state(STATE_OFF);

Oben drüber ist ja auch etwas code auskommentiert:

#if 0
    cfgt = radio_config_recall();
#else
# warning "currently no radio_config_recall()"
#endif

Es könnte der Eindruck entstehen, dass da das Funken gar nicht in 
Betrieb genommen hat. Da die LEDs blinken und ja auch schon die 
Interrupt-Behandlung aktiviert wurde, erscheint mir das Verhalten vom 
Stick, eben nur zu blinken, auch plausibel. Hast du eine Idee, woran das 
wohl liegen mag?

Ok, wenn das  Modul nicht in TRX_OFF geht, dann wird wirklich nicht 
gefunkt, aber dass er aus radio_set_state() nicht wieder raus kommt ... 
? Der einzige  Hänger kann bei radio_init() auftreten, wenn der 
Transceiver nach dem Reset nicht in TRX_OFF geht, also radio_error() 
aufgerufen wird.

Hier ist die Wartezeit nach dem CMD_TRX_OFF Befehl zu kurz. Das kann bei 
kleinen Quarzen, die langsam anschwingen mit der Konstante 
CUSTOM_RESET_TIME_MS korrigiert werden.

Um nachzuweisen ob der Stick richtig geht, kannst du auch mal 
xmpl_trx_base*.hex flashen, da wird die Kommunikation mit dem 
Transceiver  getestet.

Achso, der Standardfehler, wie immer .... hast du mal die Fuses 
überprüft?

Fuses für uracoli:
     LF: 0xe2 - 8MHz internal RC Osc.
     HF: 0x11 - without boot loader
     HF: 0x10 - with boot loader
     EF: 0xff

Original Fuses
     LF: 0xde
     HF: 0x91
     EF: 0xfb

Hi,
ja die Fuses passen, daran hat es nicht gelegen.

Hab mal xmpl_trx_base getestet: Ich sehe, dass die rote LED blinkt 10x 
blinkt, dann eine Pause macht. Ich sehe leider hier keine Möglichkeit, 
zu überprüfen, ob und was da gefunkt wird.

Das hif-Beispiel geht hier, ich bekomme ein Terminal und kann mit dem 
Stick sprechen.

Zu der Sache mit der Anschwingzeit: Wo müste ich das definieren? Was 
soll ich für Werte ausprobieren? Bin ich davon überhaupt betroffen, da 
ja durch die Fuses ein RC-Oszi konfiguriert wird? Das dürfte mit einer 
Anschwingzeit eines Quarzes nix zu tun haben?

Außerdem meckert AVR-Studio bei mir immer, ob ich denn wirklich den 
EEPROM-Inhalt behalten will, weil EESAVE gesetzt ist (Durch die von dir 
vorgeschlagenen Fuses). Muss ich ggf. noch was in den EEPROM schaffen?

Hm, also 10x Blinken bei xmpl_trx_base heißt, es kommt kein Interrupt. 
Warum der nicht kam, war kein Einschwingzeiten-Voodoo sondern ein Bug
Der Vergleich in "ERR_CHECK_DIAG(irq_cause != 0,10)" war einfach falsch.

1

Index: Src/Xmpl/xmpl_trx_base.c

2

===================================================================

3

RCS file: /sources/uracoli/uracoli/Src/Xmpl/xmpl_trx_base.c,v

4

retrieving revision 1.8

5

diff -u -r1.8 xmpl_trx_base.c

6

--- Src/Xmpl/xmpl_trx_base.c    22 Dec 2009 16:47:10 -0000      1.8

7

+++ Src/Xmpl/xmpl_trx_base.c    4 Jul 2010 18:07:59 -0000

8

@@ -100,10 +100,8 @@

9

     trx_reg_write(RG_TRX_STATE,CMD_PLL_ON);

10

11

     DELAY_US(TRX_PLL_LOCK_TIME_US);

12

-    DELAY_MS(1000);

13

-    //ERR_CHECK_DIAG(irq_cause != TRX_IRQ_PLL_LOCK,6);

14

-    ERR_CHECK_DIAG(irq_cause != 0,10);

15

-

16

+    DELAY_MS(200);

17

+    ERR_CHECK_DIAG((0==irq_cause),6);

18

     /* done */

19

     LED_SET_VALUE(0);

20

     while(1)

Hat das nur eine Relevanz für das Funkbeispiel oder auch für die 
Anwendung wuart? Es ist ja das Ziel, die zum laufen zu bekommen.

Nein, der Patch bezieht sich nur auf xmpl_trx_base.c.

Bei wuart.c gibts aktuell noch ein anderes Problem,
dass ich mir noch genauer angucken muss.