Forum: HF, Funk und Felder µracoli in Betrieb nehmen


von Axel J. (axeljaeger)


Lesenswert?

Hallo,
Ich habe folgendes Problem:

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.

Ich hab die Hoffnung aufgegeben, die Beispielsoftware von Atmel 
anzupassen und hatte mit der Radio Evaluation Suite von Atmel schon ein 
bisschen rumgespielt. Die entsprechende Firmware für den USB-Stick 
emuliert ja bereits eine serielle Schnitstelle. Leider kommen da die 
Daten nicht einfach raus, sondern es gibt eine Art Menü, wo man 
verschiedene Funktionen auswählen kann.

Außerdem ist nicht so ganz klar, ob ich die Software fürs Messen so 
einfach vom Raven aufs Zigbit portiert bekomme (1284P auf Raven, 1281 
Zigbit)

Nun bin ich auf µracoli gestoßen und das schien alle meine Probleme zu 
lösen:

(1) Unterstützung für Zigbit laut dieser Website: 
http://www.mikrocontroller.net/articles/Meshnetics_Zigbee#.C2.B5racoli
(2) Hinweis auf Firmware für den USB-Stick, der direkt empfangene Daten 
ausgibt: http://uracoli.nongnu.org/manual/dev/pgDevCDC.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?

Laut der Dokumentation hier: 
http://www.nongnu.org/uracoli/manual/app/group__grpAppWuart.html
müsste ich nur dieses Example auf den Stick flashen,in den Data Mode 
schaffen und hätte schon das, was ich haben will.

Ich habe die entsprechende Firmware auf den USB-Stick geschafft. Jetzt 
leuchtet eine blaue LED. Wenn ich mit einem Terminal-Programm, in meinem 
Falle screen auf Mac, versuche auf den Stick zuzugreifen, bekomme ich 
kein Echo. Ich weis allerdings nicht mit welcher Baudrate screen 
standardmäßig die Verbindung versucht. Es gibt allerdings auch keinen 
Hinweis, welche Baudrate denn zu nehmen sei. Das einzige, was ich sehe, 
ist das Blinken der roten LED, wenn ich eine Taste drücke.

Hat jemand dieses schonmal diese USB-Stick-Firmware oder µracoli 
generell auf ZigBit in Betrieb genommen?

von Dirk J. (dirk-cebu)


Lesenswert?

Ich kenne nur Miracoli, macht auch weniger Arbeit ;)

von A. W. (uracolix)


Lesenswert?

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

von Axel J. (axeljaeger)


Lesenswert?

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....

von A. W. (uracolix)


Lesenswert?

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.

von Axel J. (axeljaeger)


Lesenswert?

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?

von A. W. (uracolix)


Lesenswert?

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.

von A. W. (uracolix)


Lesenswert?

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

von Axel J. (axeljaeger)


Lesenswert?

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?

von A. W. (uracolix)


Lesenswert?

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)

von Axel J. (axeljaeger)


Lesenswert?

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.

von A. W. (uracolix)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.