Atmel ZigBit (ATZB-24-A2/B0) und XBee

Zum Thema ZigBee kann ich leider nicht viel sagen, da arbeite ich gerade 
selbst das erste Mal mit.

Ich habe aber bereits ähnliche Funkstrecken wie deine per WLAN 
aufgebaut. Kommt das für dich in Frage, dann hätte ich evtl. den ein 
oder anderen Tipp?

Hat vor allem den Vorteil, dass du PC-seitig nicht viel machen musst 
(die meisten Laptops haben WLAN ja bereits an Board und Software ist 
relativ schnell geschrieben...)

Gbit es für WLAN auch so kleine ICs, an die ich die Sensoren einfach 
über SPI anhängen kann?
Hätte WLAN sonst irgendwelche Vorteile gegenüber ZigBee?
Kriege ich da keine Schwierigkeiten mit dem im Gebäude sonst bestehenden 
WLAN?

XBee mit SPI dürfte meines Wissens nach nur mit der programmable 
Variante gehen - die normalen XBees können das nicht.
Man kann aber einen µC, der SPI kann benutzen und dann per USART die 
XBee (Series 1, 2 etc.) anschließen und die RX/TX-Signale transparent 
weiterleiten.

Jeanette Seewald schrieb:
> Gbit es für WLAN auch so kleine ICs, an die ich die Sensoren einfach
> über SPI anhängen kann?

SPI bin ich mir gerade nicht sicher, gibt aber auf jeden Fall welche mit 
UART. Ist das eine Option? Warum muss es SPI sein?

Ich habe mit denen hier gearbeitet, die kommen mit einer fertig 
programmierten Firmware, die du über UART ansprechen kannst. Das ganze 
funktioniert dann als UART -> Wifi Brücke, es werden z.B. UDP Pakete 
verschickt, die der PC dann empfangen und weiterverarbeiten kann. 
Bedienung ist meiner Meinung nach super einfach. Es können mit dieser 
Firmware sogar GPIO-Pins bedient werden, z.B. kannst du per ADC 
Spannungen messen, digitale IO's schalten usw.

http://www.rovingnetworks.com/products/RN131C

Je nach größe deines Projektes kannst du für die Module dann auch ein 
SDK kaufen (leider nicht ganz billig) und die Firmware auf den Modulen 
selbst entwickeln. Dann ist auch ein SPI-Bus möglich, der hardwareseitig 
vorhanden ist.
Zu den oben genannten Chips gibts auch mehrere Alternativen mit denen 
ich aber noch nicht gearbeitet habe...

> Hätte WLAN sonst irgendwelche Vorteile gegenüber ZigBee?
Höhere Bandbreite und wie gesagt etwas einfacher zu entwickeln, weils 
einfach viel verbreiteter ist. Außerdem PC-seitig wenig bis gar keine 
kosten (bis auf evtl. Softwareentwicklung).

> Kriege ich da keine Schwierigkeiten mit dem im Gebäude sonst bestehenden
> WLAN?

Nein, außer in Extremfällen mit vielen Netzwerken (Habe schon Probleme 
auf Messen gehabt), da ZigBee evtl. aber auf der gleichen Frequenz funkt 
könnte es bei der Strecke ebenfalls zu Problemen kommen. Generell können 
sich auch mehrere Wlan's den gleichen Funkkanal teilen. Außerdem kann 
die Wlan Hardware z.B. beim Starten den besten Kanal auswählen (wie auch 
ZigBee)...

>Ich muss Sensorwerte aus einem Motorprüfstand über Funk an einen PC
>übertragen.

Zuallererst die Grundfrage:
Mit welcher Datenrate sollen die Sensorwerte erfasst und uebertragen 
werden?

Ueber die Zusammenarbeit von XBees und ZigBits kann ich auch nichts 
sagen, u.U. koennte ein 802.15.4-XBee mit einem Atmel-Mac-betriebenen 
ZigBit funktionieren, waere aber zu pruefen. Allerdings wuerde ich um 
Aufwand zu
sparen eher bei einer Sorte bleiben, das erspart eine Menge Stress bei 
der
Integration.

Wenn du nur ein Paar Sender und Empfaenger brauchst (also Messplatz + 
PC), ist selbst ein 802.15.4-Stack schon "overkill", das geht auch 
einfacher (www.uracoli.de).

U.u. ist neben dem ZigBit (dessen Transceiver auch ueber SPI angehaengt 
ist)
auch der Einsatz eines ATmega128RFA1 Modules sinnvoll, dort ist der 
Funktransceiver im AVR integriert und SPI steht voll zu deiner 
Verfuegung.

Eine ganz andere Option waere, wenn der Stromverbrauch keine Rolle 
spielt:
ein Carambola oder aehnlichen OpenWrt-Router + Arduino an den Messplatz,
Sensoren ueber Arduino anbinden, Daten seriell an ans Carambola und von
dort aus per WLAN an den PC senden.

Stromverbrauch spielt zumindest messstationsseitig auch eine erhebliche 
Rolle, da ich dort mit Batterien arbeiten muss, der vorhandene Platz 
sehr eingeschränkt ist und auch das Auswechseln der Batterie schwierig.

Das vorgeschlagene RN131C WLAN-Modul verbraucht im TX-Mode ja ca. 200 mA 
- das ist definitiv zu viel.

Genaue verlangte Datenraten weiß ich noch nicht, da es sich allerdings 
um Temperaturmessung an einem Stahl- oder Alu-Block handelt und sich 
diese eher träge verhalten wird, werden die Anforderungen an die 
Übertragungsraten nicht allzu hoch sein.

Wenn ich das Blockschaltbild des ZigBits richtig interpretiere, müsste 
ich die Sensorwerte über SPI einlesen können, und dann sowohl die 
Möglichkeit haben, diese über den Mikrocontroller zu verarbeiten und 
auszusenden, als auch direkt über den Tranceiver zu gehen (und den 
Mikrocontroller zu umgehen).
Da mein Betreuer (der das Projekt anschließend weiterbearbeiten wird) 
bisher noch nie was my Mikrocontrollern gemacht hat, hätte mir die 
Option gut gefallen, mit dem Mikrocontroller arbeiten zu können (um die 
Messwerte vor dem Versenden bereits zu verarbeiten), aber nicht zu 
müssen, falls sich das für ihn als unpraktisch erweist.

Das ATmega128RFA1 klingt zwar auch gut, da müsste ich aber in jedem Fall 
mit dem uC arbeiten.

Meine Befürchtung ist auch, dass das Mischen von ZigBit und XBee 
schwierig wird. Da meine Sensorchips allerdings nur via SPI angesprochen 
werden können, bräuchte ich ein XBee-Modul, das SPI-fähig ist (ansonsten 
müsste ich wieder über UART und einen uC gehen) - gibt es das?

Jeanette Seewald schrieb:
> Stromverbrauch spielt zumindest messstationsseitig auch eine erhebliche
> Rolle, da ich dort mit Batterien arbeiten muss, der vorhandene Platz
> sehr eingeschränkt ist und auch das Auswechseln der Batterie schwierig.

Das ist schonmal eine gute Info. Dies wäre tatsächlich der Grund FÜR 
ZigBee.


> Das vorgeschlagene RN131C WLAN-Modul verbraucht im TX-Mode ja ca. 200 mA
> - das ist definitiv zu viel.

Hierbei musst du beachten, dass die 200mA ja nur sehr kurz fließen, da 
WLAN nicht dauerhaft im Tx ist, sondern nur sehr kurze Bursts sendet. 
Das genannte Modul ist schon für LowPower Anwendungen geeignet und kann 
entsprechend so konfiguriert werden, dass es die meiste Zeit in einem 
Sleep-Mode ist und nach bestimmten Intervallen kurz aufwacht, 
Sensordaten abfragt, beschriebenes UDP-Paket ins WLAN schickt und dann 
wieder schläft. Ob und wielange hier eine Batterie reicht müsstest du 
mal berechnen, hierzu müsstest du dich etwas ausführlicher mit dem 
Datenblatt beschäftigen.

> Genaue verlangte Datenraten weiß ich noch nicht, da es sich allerdings
> um Temperaturmessung an einem Stahl- oder Alu-Block handelt und sich
> diese eher träge verhalten wird, werden die Anforderungen an die
> Übertragungsraten nicht allzu hoch sein.
>
> Wenn ich das Blockschaltbild des ZigBits richtig interpretiere, müsste
> ich die Sensorwerte über SPI einlesen können, und dann sowohl die
> Möglichkeit haben, diese über den Mikrocontroller zu verarbeiten und
> auszusenden, als auch direkt über den Tranceiver zu gehen (und den
> Mikrocontroller zu umgehen).
> Da mein Betreuer (der das Projekt anschließend weiterbearbeiten wird)
> bisher noch nie was my Mikrocontrollern gemacht hat, hätte mir die
> Option gut gefallen, mit dem Mikrocontroller arbeiten zu können (um die
> Messwerte vor dem Versenden bereits zu verarbeiten), aber nicht zu
> müssen, falls sich das für ihn als unpraktisch erweist.
>
> Das ATmega128RFA1 klingt zwar auch gut, da müsste ich aber in jedem Fall
> mit dem uC arbeiten.

Ich denke, dass du um einen Mikrocontroller nicht herumkommst. Du musst 
ja an irgendeiner Stelle die Befehle, mit denen du deinen Sensor 
(welcher soll hier verwendet werden??) abfragst programmieren und hierzu 
ist auf jeden Fall eine Firmware notwendig.

Die ZigBit Module haben dies bereits an Board. Es handelt sich um einen 
Mikrocontroller (ATmega1281) und einen Transceiver für den ZigBee Funk 
8AT86RF230 Transceiver). Das alles bekommst du als fertiges Modul.
Auch hier musst du für den ATMega eine Firmware programmieren, die 
deinen Sensor kennt und entsprechend abfragt und die Werte entsprechend 
weiterverarbeitet, über ZigBee versendet usw. Auch bei diesem Modul 
musst du dich entsprechend dem oben beschriebenen zum Thema WLAN um 
Sleep-Phasen usw. kümmern.
Der nach unten im Schaltbild herausgeführte SPI-Bus sagt nur aus, dass 
dort dort herankommst um evtl. von anderen Controllern noch mit dem 
Transceiver sprechen zu können, den Bus mitzuhören etc. Der Transceiver 
kann definitiv NICHT mit deinem Sensor kommunizieren. SPI am Receiver 
dient zur Konfiguration desselben und dann zur Datenübertragung von und 
zum ZigBee-Funk.

> Meine Befürchtung ist auch, dass das Mischen von ZigBit und XBee
> schwierig wird.

Kann sein, ich arbeite gerade mit TexasInstruments CC2530 und einem 
XBee. Kommunikation ist möglich, aber ich finde die XBee-Module nicht 
sher benutzerfreundlich. Ich musste viel Zeit zusätzlich investieren bis 
die XBee's liefen, da eine einarbeitung in die Firmware, die hier 
mitgeliefert wird nötig ist.
Du musst dich eben in beide Module einarbeiten. Ich würde empfehlen dich 
zunächst nur mit einer Art ZigBee Module zu beschäftigen und diese auf 
beiden Seiten einzusetzen. Die Atmel's haben ja auch einen UART, so dass 
du diese mit entsprechendem Pegelwandler etc. zur Not auch an einen PC 
anschließen kannst.

> Da meine Sensorchips allerdings nur via SPI angesprochen
> werden können, bräuchte ich ein XBee-Modul, das SPI-fähig ist (ansonsten
> müsste ich wieder über UART und einen uC gehen) - gibt es das?

NEIN, denn: Wie bringst du dem XBee bei wie es mit deinem Sensor reden 
muss. SPI ist nur der Kommunikationskanal, welche Befehle hierüber 
versendet werden bestimmt dein Sensor. Eine Software, die deinen Sensor 
abfragt müsste von dir implementiert werden und dann (auf dem XBee) 
aufgeführt werden (und dafür sind die XBee's erstmal nicht gedacht, auch 
wenns evtl. durchn austausch der Firmware möglich wäre, was ich nicht 
weiss).

Dein Aufbau wird also immer sein:


Sensor <--> µC <------------> Funk (ZigBee, WLAN)
       SPI     SPI, UART, etc

µC und Funk gibt es kombiniert als fertige Module evtl. mit frei 
programmierbaren µC (ZigBit??? bitt prüfen, ich habe das Datenblatt nur 
überflogen).
Im Falle von XBee oder Roving RN131C sind ebenfalls auf dem Modul schon 
µC enthalten (nicht unbedingt frei programmierbar bzw. nur mit SDK und 
Lizenz), ein Austausch der Firmware hierbei ist aber zunächst nicht 
unbedingt vorgesehen. In dem Fall würde ein zusätzlicher µC notwendig, 
der deine "Anwendung" enthalten muss. Meiner Meinung nach eher nicht 
geeignet, weil zusätzlicher µC heisst dann auch mehr Stromverbrauch etc.

Ich glaube ich habe mich jetzt 10x wiederholt, hoffe aber dass ich alles 
halbwegs verständlich rüberbringen konnte.

Gibts eine preisliche Begrenzung? Du kannst ja mal schauen ob du hier 
was
an Hardware findest: http://uracoli.nongnu.org/hwlist.html.

Bei den ZigBits kann man bei stromsparender Programmierung aus 2 R6 
Zellen recht lange leben - Quark - nebuloeses Gewaesch: die Lebensdauer 
haengt natuerlich in erster Linie von der Datenmeng ab. Wie Daniel S 
schon schrieb kann der Mess-Stationssender nur zum Messen und Senden 
aufwachen und danach wieder schlafen gehen. Der USB-Stick oder das Board 
am PC kann dann quasi immer auf RX sein.

Wegen der Datenverarbeitung: Wenn es sich bandbreitemaessig ausgeht, 
dann
wuerde ich versuchen Rohdaten zum PC zu schicken und die dort zu 
bearbeiten/skalieren/wandeln, im einfachsten Fall die Registerwerte aus
den Sensoren.

Ggf. solltest du auch einen Rueckkanal einplanen um die Sensoren zu 
parametrieren, z.B. die Messaufloesung.

>Das ATmega128RFA1 klingt zwar auch gut, da müsste ich aber in jedem Fall
>mit dem uC arbeiten.

... ATmega128RFA1 und ZigBit sind bei Licht betrachtet das gleiche, sie 
unterscheiden sich nur im Gehaeuse und in den technischen Parametern, du 
hast in beiden Faellen einen AVR-Controller, der die Sensoren liest und 
einen Transceiver der die Daten verschickt.

A. W. schrieb:

> ... ATmega128RFA1 und ZigBit sind bei Licht betrachtet das gleiche, sie
> unterscheiden sich nur im Gehaeuse und in den technischen Parametern, du
> hast in beiden Faellen einen AVR-Controller, der die Sensoren liest und
> einen Transceiver der die Daten verschickt.

Stimmt, ich hätte Licht einschalten sollen ;)

Entschuldigt meine späte Reaktion - eine ziemlich fiese Erkältung hat 
mich die letzten Tage flachgelegt.
Danke schon mal für eure Antworten.

Ich verstehe jetzt, was ihr meint.

Ich hatte mich von einer sehr einfachen Annahme blenden lassen: An 
meinen Sensoren hängen auch ICs, die über SPI einfach durch CS aktiviert 
werden können und dann über SDO ihre Werte raushauen. Ich bin bisher 
davon ausgegangen, dass es auch XBees geben müsste, die bereits eine 
Firmware programmiert haben, bei denen ich vom PC aus Befehle übergeben 
kann, um die daran hängenden CS-, SDO-, SDI-Leitungen anzusprechen. Gibt 
es aber, wenn ich euch richtig verstehe, nicht.


Was wäre denn für einen absoluten Funk-Anfänger am einfachsten in Gang 
zu kriegen - XBee, WLAN oder die Atmel Module?

Mikrocontroller mit angehängten XBee im Transparent-Modus. Der µC 
übernimmt dabei die Anbindung der Sensoren über SPI und gibt die Daten 
per USART an die XBee, die die Daten an eine zweite XBee ebenfalls mit 
angehängtem µC zur Signalauswertung sendet.

Ich habe für mich also mal drei Möglichkeiten sensorseitig 
rausgefiltert:

1. Mikrocontroller + xBee
2. ZigBit oder ATmega128RFA1
3. Mikrocontroller + RN131C (o.ä.)

Was für mich trotz' einiger Recherche heute noch nicht greifbar ist, 
ist, welcher Unterschied zwischen diesen bezüglich des 
programmiertechnischen Aufwands liegt. Was sind die Schritte, die 
jeweils programmiert bzw. beachtet werden müssen (Stacks etc.)?

Vielen Dank - das wäre wirklich sehr hilfreich.

>Was für mich trotz' einiger Recherche heute noch nicht greifbar ist,
>ist, welcher Unterschied zwischen diesen bezüglich des
>programmiertechnischen Aufwands liegt. Was sind die Schritte, die
>jeweils programmiert bzw. beachtet werden müssen (Stacks etc.)?

Im Falle der Atmel-basierten Loesung sieht das ungefaehr so aus:

1

wget http://download.savannah.nongnu.org/releases/uracoli/uracoli-src-0.3.1.zip

2

unzip uracoli-src-0.3.1.zip

3

cd uracoli-src-0.3.1

4

make -C src <module>

5

# wuart bridge am PC

6

make -C wuart <module> 

7

# Firmware f. Messgeraet

8

make -C xmpl -f xmpl_trx_tx.mk <module> 

9

# flashen der Firmware

10

avrdude -P usb -c jtag2 -p <mcu> bin/wuart_<module>.hex

11

avrdude -P usb -c jtag2 -p <mcu> bin/xmpl_trx_tx_<module>.hex

Du kannst dann das Beispiel xmpl_trx_tx.c um deine Sensorabfragen
erweitern und das sollte es schon gewesen sein, plus/minus ein bisschen 
Debugging.

Danke für das Codebeispiel, A.W.

Nach noch mehr Recherche, noch mehr Fragen ;)


Mit dem Programmable XBee's (ZB) müsste ich doch eigentlich relativ 
einfach meinen Sensor via SPI abfragen können und das dann per Funk 
rausschicken. Oder ist das Programmieren dieser XBee's eher schwierig?


Hat der ATmega128RFA1 irgendwelche Nachteile gegenüber der 
ZigBit-Module?

Beim ATmega128RFA1 benötige ich ja auch noch eine Antenne, richtig?

Sehe ich das richtig, dass folgender "Ablauf" für die Programmierung 
notwendig wäre:
- sensorseitig müsste ich über einen JTAG-Programmer o.ä. einen 
Bootloader auf den ATmega laden, der mir die Funkverbindung zu meinem 
PC-seitigen ATmega aufbaut
- PC-seitig das selbe + Bootloader für den FTDI-Treiber, damit ich die 
Sensordaten auf den PC laden kann
- Wenn die Funkverbindung per Bootloader steht, müsste ich die 
weiterführende Programmierung des Sensor-ATmegas (Sensoren auslesen 
etc.) auch vom PC über die Funkverbindung aus durchführen können, 
richtig?


Habe ich irgendwelche großen Vorteile, wenn ich ein Evaluiersungsboard 
wie z.B.: 
http://www.dresden-elektronik.de/funktechnik/products/radio-modules/eval-derfmega/description/ 
nehme?

Jeanette Seewald schrieb:
> Danke für das Codebeispiel, A.W.
>
> Nach noch mehr Recherche, noch mehr Fragen ;)
>
>
> Mit dem Programmable XBee's (ZB) müsste ich doch eigentlich relativ
> einfach meinen Sensor via SPI abfragen können und das dann per Funk
> rausschicken. Oder ist das Programmieren dieser XBee's eher schwierig?

mittlerweile bin ich selbst mit den XBee's in meiner Anwendung etwas 
weitergekommen. Es ist so, dass du mit den XBee MOdulen sehr einfach 
eine "Out-Of-the-box" Lösung bekommst um per Funk ein paar Daten zu 
versenden.
Dafür kaufst du zwei XBeemodule, konfiguerierst diese mit eher wenig 
aufwand und danach kannst du im Prinzip auf beiden Seiten per UART Daten 
senden und die Gegenseite gibt diese Daten per UART raus. Im Prinzip ein 
Ersatz für ein serielles Kabel. Wenn dir das reicht, nimm diese Lösung!
Mit der Lösung hast du allerdings dann auch nur wenig (aber immerhin ein 
Bisschen) Einfluss auf die Schlaf-Phasen der XBee-Module und somit auf 
deren Stromverbrauch. Dabei betreibst du die XBEe's im sogenannten 
Transparent Mode. Achtung: In diesem Mode ist auch generell erstmal NUR 
Kommunikation zwischen zwei gleichen XBeemodulen möglich. Sensorseitig 
brauchst du dann einen weiteren µC der Sensordaten abfragt und den 
XBee-UART damit füttert. Hier könntest du irgendein Evaluationboard 
eines beliebigen Herstellers nehmen, natürlich sollte UART an Board 
sein.
Mit dieser Lösung wirst du am schnellsten einen Prototypen zum Laufen 
bekommen und das mit wenig Aufwand, natürlich dann auch nicht gut 
geeignet als Abschlussarbeit oder sowas (denn danach klingt es bei dir 
fast ;) ).

Bei allen anderen Lösungen (und dazu zählen auch die XBee's im API-Mode) 
ist der Programmieraufwand und die Einarbeitung ins Thema ZigBeeund 
Mikrocontroller allgemein wesentlich höher. Dies bringt natürlich auch 
mehr Freiheiten und Eingriffsmöglichkeiten beim Thema Stromverbrauch und 
dem Verhalten deiner Anwendung allgemein. Hier würde ich von den XBee's 
abraten und zur Lösung mit Texas Instruments CC2530 tendieren. Doku und 
Softwareunterstützung mit entsprechendem Framework und Codebeispielen 
ist hier einfach wesentlich besser. Außerdem gibt es ein recht gutes 
Development-Kit (Das CC2530ZDK Mini), was ebenfalls out-ox-the-box läuft 
und man kann sich dann anhand der Codebeispiele langsam seine eigene 
Anwendung daraus bauen.
Die Atmel-Geräte kenne ich leider nicht, da wäre dann noch der Vergleich 
zu TI nötig...

> Hat der ATmega128RFA1 irgendwelche Nachteile gegenüber der
> ZigBit-Module?

kann ich deswegen leider nichts zu sagen...

>
> Beim ATmega128RFA1 benötige ich ja auch noch eine Antenne, richtig?
>

Sehr wahrscheinlich schon. Je nachdem wie "professionell" dein Aufbau 
werden soll und ob das Thema HF, Reichweite etc. dich interessiert kommt 
du fürs erste mit einem "Stück Draht" aus. Das reicht in jedem Fall um 
ein paar Meter zu überbrücken. Das Thema Antenne und Reichweite kann 
dann natürlich beliebig komplex werden ;)

> Sehe ich das richtig, dass folgender "Ablauf" für die Programmierung
> notwendig wäre:
> - sensorseitig müsste ich über einen JTAG-Programmer o.ä. einen
> Bootloader auf den ATmega laden, der mir die Funkverbindung zu meinem
> PC-seitigen ATmega aufbaut
> - PC-seitig das selbe + Bootloader für den FTDI-Treiber, damit ich die
> Sensordaten auf den PC laden kann
> - Wenn die Funkverbindung per Bootloader steht, müsste ich die
> weiterführende Programmierung des Sensor-ATmegas (Sensoren auslesen
> etc.) auch vom PC über die Funkverbindung aus durchführen können,
> richtig?

Nein nicht wirklich. Ein Bootloader hat erstmal nichts mit dem Aufbau 
einer Funkverbindung zu tun. Bitte recherchiere hier nochmal anderweitig 
wozu man einen Bootloader braucht.
Was du meinst ist der ZigBee ProtokollStack, der als Firmware in den 
ZigBee Netzwerkprozessoren wie z.B. dem CC2530 läuft. Mit dieser 
Firmware hast du zunächst wenig zu tun, außer dass du sie über eine API 
"bedienen" musst, sprich du schickst Befehle, die die Verbindung 
konfigurieren und dann entsprechend aufbauen, auch das Versenden der 
eigentlichen Rohdaten geschickt dann hierüber. Als Transportmedium dazu 
dient der SPI-Bus.

Weiterhin brauchst du Sensorseitig deinen Mikrocontroller (ATMega, 
MSP430 etc.) der oben genannte Kommunikation mit dem Netzwerkprozessor 
per API übernimmt. Weiterhin muss diese Firmware deine Sensorwerte 
abfragen. Hier ist dann Programmieraufwand notwendig, deine 
programmierte Firmware wird zum Beispiel via JTAG oder sonst wie (bitte 
Tutorials lesen) in den µC programmiert und läuft dann dort.

PC-Seitig ist das dann ähnlich statt Sensorwerte abzufragen gibt dein µC 
dort die Empfangen Daten via UART an den PC weiter (und was deine 
Anwendung sonst noch so mit sich bringt...)

> Habe ich irgendwelche großen Vorteile, wenn ich ein Evaluiersungsboard
> wie z.B.:
> 
http://www.dresden-elektronik.de/funktechnik/products/radio-modules/eval-derfmega/description/
> nehme?

Empfehlung für ein Evaluationskit siehe oben. Das genannte kostet etwas 
über 100€ und bringt drei Boards mit, die du frei programmieren kannst. 
Weiterhin kommt ein ez430 Adapter mit. Mit diesem kannst du die Boards 
flashen und/oder das Board, das PC-seitig als Empfänger verwendet wird 
an den PC-UART (virtueller Com-Port über USB) adaptieren.

Daniel S. schrieb:
> Hier würde ich von den XBee's
> abraten und zur Lösung mit Texas Instruments CC2530 tendieren.

Wenn man so masochistisch ist, im 3. Jahrtausend noch mit einem
8051 als CPU anzufangen. ;-)

Jörg Wunsch schrieb:
> Wenn man so masochistisch ist, im 3. Jahrtausend noch mit einem
> 8051 als CPU anzufangen. ;-)

sehr konstruktiver Kommentar...
Was empfiehlst du für Alternativen?

und: in diesem Fall meiner Meinung nach total egal was an dieser Stelle 
für ein Prozessor verbaut ist...

Daniel S. schrieb:

> Was empfiehlst du für Alternativen?

Der ATmega128RFA1 wurde ja schon genannt.  Ich wüsste auf Anhieb
keinen Parameter, in dem er wirklich schlechter wäre als der
CC2530 (OK, wenn man mehr als 128 KiB Flash braucht, müsste man
stattdessen den neuen ATmega256RFR2 nehmen, hätte dann aber auch
statt 16 gleich 32 KiB SRAM).  Dafür implementiert er eine
zeitgemäße CPU.  TI hat zwar auch seit geraumer Zeit einen
Singlechip mit MSP430-Kern, aber eben bislang immer noch keinen
für 2,4 GHz.

> und: in diesem Fall meiner Meinung nach total egal was an dieser Stelle
> für ein Prozessor verbaut ist...

Segmentierten SRAM will man meiner Meinung nach aber im 3. Jahrtausend
nicht mehr haben.

Nicht, dass ich unbedingt den AVR-Kern hier bis aufs Messer
verteidigen möchte, MSP430 oder Cortex-M* sind gewiss auch etwas,
was ich als moderne CPU akzeptieren könnte.

Den sensorseitigen separaten Mikrocontroller wollte ich mir eben durch 
Verwendung der programmable XBee's sparen.


Daniel S. schrieb:
> Was du meinst ist der ZigBee ProtokollStack, der als Firmware in den
> ZigBee Netzwerkprozessoren wie z.B. dem CC2530 läuft. Mit dieser
> Firmware hast du zunächst wenig zu tun, außer dass du sie über eine API
> "bedienen" musst, sprich du schickst Befehle, die die Verbindung
> konfigurieren und dann entsprechend aufbauen, auch das Versenden der
> eigentlichen Rohdaten geschickt dann hierüber. Als Transportmedium dazu
> dient der SPI-Bus.

Worauf ich eigentlich hinauswollte ist folgendes: Mein Sensor-Modul (mit 
Tranceiver etc.) ist irgendwo im Prüfstand verbaut, wo man schlecht 
hinkommt. Gibt es eine Möglichkeit, das auf dem Mikrocontroller laufende 
Programm (das die Sensoren ausliest) vom PC aus über die Funkverbindung 
zu ändern? Zum Beispiel kann ein Mikrocontroller so programmiert werden, 
dass er einen über Funk dranhängenden Mikrocontroller mit einem neuen 
Programm lädt?

Jeanette Seewald schrieb:
> Den sensorseitigen separaten Mikrocontroller wollte ich mir eben durch
> Verwendung der programmable XBee's sparen.

Achso, die kenne ich leider nicht.

> Worauf ich eigentlich hinauswollte ist folgendes: Mein Sensor-Modul (mit
> Tranceiver etc.) ist irgendwo im Prüfstand verbaut, wo man schlecht
> hinkommt. Gibt es eine Möglichkeit, das auf dem Mikrocontroller laufende
> Programm (das die Sensoren ausliest) vom PC aus über die Funkverbindung
> zu ändern? Zum Beispiel kann ein Mikrocontroller so programmiert werden,
> dass er einen über Funk dranhängenden Mikrocontroller mit einem neuen
> Programm lädt?

Japp, genau dafür brauchst du dann den Bootloader, völlig richtg!

Jeanette Seewald schrieb:
> Zum Beispiel kann ein Mikrocontroller so programmiert werden,
> dass er einen über Funk dranhängenden Mikrocontroller mit einem neuen
> Programm lädt?

Ja.  Das Stichwort dafür heißt üblicherweise "over-the-air upgrade"
(OTAU).  Normalerweise spendiert man dafür beim Endgerät noch einen
Flash-Puffer der gleichen Größe, wie der normale Programmspeicher
ist.  In diesem werden die einzelnen über Funk empfangenen Teile
der Firmware zwischengespeichert, und wenn alles fehlerfrei zusammen
gekommen ist, dann wird die Firmware des Controllers aus diesem Puffer
neu geschrieben.

Jörg Wunsch schrieb:
> Daniel S. schrieb:
>
>> Was empfiehlst du für Alternativen?
>
> Der ATmega128RFA1 wurde ja schon genannt.  Ich wüsste auf Anhieb
> keinen Parameter, in dem er wirklich schlechter wäre als der
> CC2530 (OK, wenn man mehr als 128 KiB Flash braucht, müsste man
> stattdessen den neuen ATmega256RFR2 nehmen, hätte dann aber auch
> statt 16 gleich 32 KiB SRAM).  Dafür implementiert er eine
> zeitgemäße CPU.  TI hat zwar auch seit geraumer Zeit einen
> Singlechip mit MSP430-Kern, aber eben bislang immer noch keinen
> für 2,4 GHz.

OK, ist ein Argument und sehe ich ein. Da aber am ZigBee Stack hier eher 
nichts entwickelt oder geändert werden soll find ich die Wahl des 
hierfür verwendeten Prozessors bzw. dessen Architektur nach wie vor 
unkritisch für dieses Projekt.

> Segmentierten SRAM will man meiner Meinung nach aber im 3. Jahrtausend
> nicht mehr haben.

finde ich wie gesagt für das Projekt hier eher unkritisch. Wäre aber 
tatsächlich dann das Argument für die Atmel Chips, die ich aber nicht 
kenne und daher auch nicht empfohlen habe. Mag sein, dass die besser, 
schneller und einfacher sind!

Jörg Wunsch schrieb:

> (OTAU).  Normalerweise spendiert man dafür beim Endgerät noch einen
> Flash-Puffer der gleichen Größe, wie der normale Programmspeicher
> ist.

... kommt natürlich dann auch drauf an ob man nur einen Prototypen baut 
oder bei Serienproduktion auf jeden Cent angewiesen ist.

MIT Puffer ists natürlich die sauberste Lösung...

das ist ja ein laenglicher Thread geworden, hier nochmal ein paar
Antworten.

Jeanette Seewald schrieb:
> Hat der ATmega128RFA1 irgendwelche Nachteile gegenüber der
> ZigBit-Module?

Eher nein, vergleichmal die Datenblaetter vom ATmega1281 (ZigBit)
und vom RFA1.

Jeanette Seewald schrieb:
>Gibt es eine Möglichkeit, das auf dem Mikrocontroller laufende
>Programm (das die Sensoren ausliest) vom PC aus über die Funkverbindung
>zu ändern?

z.B. der Wibo (wireless bootloader) von µracoli.

Jörg Wunsch schrieb:
> (OTAU).  Normalerweise spendiert man dafür beim Endgerät noch einen
> Flash-Puffer der gleichen Größe, wie der normale Programmspeicher
> ist.

Beim Wibo haben wir auf den sog. Angstflash  verzichtet. Wenn durch 
Funkstoerungen das Image zerstoert ist muss man halt nochmal alles 
uebertragen. In "ruhigen" Gebieten ohne Funkstoerung gabs kaum 
nennenswerte
Probleme ... man kann ja auch beim Flashen etwas dichter an den Knoten 
herangehen und die Sendeleistung auf max. stellen. Der Zusatz-Flash 
waere nur dann sinnvoll, wenn der Empfaenger die zertoerten Teile des 
Image nochtraeglich einzeln anfordern kann. Das verlangt aber komplexere 
Software, die mehr Speicher und damit auch laenger beim OTAU braucht. 
Damit erhoet sich dann aber wieder die Wahrscheinlichkeit einer 
Funkstoerung ... man kann darueber sicher viel
philosophieren oder mal eine Doktorarbeit schreiben ;-)

Jeanette Seewald schrieb:

> Habe ich irgendwelche großen Vorteile, wenn ich ein Evaluiersungsboard
> wie z.B.: http://www.dresden-elektronik.de/funktechnik/produ...
> nehme?

Fuer den Prototypen sind die Eval-Module sicher eine gute Idee, wenn
du aber SMD loeten kannst, wuerde ich es gleich so machen. Die neuen 
Mini-Module von DE (die mit den Pads unter dem Modul) sind fuer 
Einzelstueckzahlen schlecht zu handhaben und die PCB-Bestuecker langen
fuer die Bestueckung kleiner Stueckzahlen richtig in dein Portemonaie - 
letztens war sogar die Rede davon, dass die Einzel-Bestueckung (10er 
Stueckzahl) teuerer als das gesamte Modul war (vielleicht hatte der
Bestuecker aber auch nur keine Lust auf den Job).

Wenn du die Module auf einem eigenen PCB verbaust, dann achte drauf, 
dass sich unter der Chip-Antenne keine Masseflaeche befindet.

A. W. schrieb:
> Die neuen
> Mini-Module von DE (die mit den Pads unter dem Modul) sind fuer
> Einzelstueckzahlen schlecht zu handhaben

Lötpaste und Ceran-Kochfeld benutzen. ;-)

Das wäre dann aber eher ein Thema fürs Unterforum „Platinen“.

Vielen Dank für die ausführlichen Antworten. Das mit dem wireless 
bootloader ist schon mal ausgezeichnet.


Ich habe jetzt mal versucht, eine HW-Stückliste für einen Prototypen mit 
dem ATmega128rfa1 zusammenzustellen:

Sowohl Sensor- als auch PC-seitig brauche ich:
- 1 x ATmega128rfa1
- 1 x Stecker für ISP oder JTAG
- 1 x Chip antenna
- + Kondensatoren, Quarze etc. die im Datenblatt bei der Basic 
Application (Table 32-1) drinnen sind - brauche ich da wirklich alles?

Und dann noch auf jeden Fall PC-seitig (und für den ersten 
Versuchs-Prototypen zur Sicherheit wahrscheinlich auch sensorseitig):
- 1 x FT232 + notwendige Beschaltung

Habe ich irgendetwas wichtiges übersehen?

Jeanette Seewald schrieb:

> - 1 x Chip antenna

Wenn du eine Chipantenne benutzen willst, brauchst du auch einen
Balun, sinnvollerweise einen Filterbalun.  Chipatennen sind für
gewöhnlich asymmetrisch gespeist.

Alternativ kannst du auch einen einfachen Dipol dranhängen.  Sowas
habe ich hier getan:

http://uracoli.nongnu.org/clt2012/

Allerdings ist die Antenne dort etwas zu lang geraten; 40 mm
gestreckte Länge haben sich im Nachhinein als Optimum erwiesen.

Das Weglassen der Filter (wie ich es dort gemacht habe) ist nicht
unbedingt zu empfehlen; es war hier der Einfachheit geschuldet.
Kann man machen, solange man 1.) nur in ETSI-Land arbeiten will
(FCC hat strengere Regeln bezüglich der Nebenwellenaussendung)
und 2.) die Sendeleistung ein wenig herabsetzt, um Reserve zu
den Fordernungen der EN 300 220 zu bekommen.  Ich habe -5 dBm
Sendeleistung im Workshop als Maximum empfohlen.

> - + Kondensatoren, Quarze etc. die im Datenblatt bei der Basic
> Application (Table 32-1) drinnen sind - brauche ich da wirklich alles?

Den 32-kHz-Quarz brauchst du nur, wenn du im Sleep noch einen
genauen Timer laufen haben möchtest.  Wie du auf den Tic-Tac-Toe-
Boards sehen kannst, habe ich dort drauf verzichtet.  Man kann
trotzdem auch aus dem Sleep aufwachen, indem man den Watchdog im
Interruptmodus nutzt.

> Und dann noch auf jeden Fall PC-seitig (und für den ersten
> Versuchs-Prototypen zur Sicherheit wahrscheinlich auch sensorseitig):
> - 1 x FT232 + notwendige Beschaltung

Wenn du genügend freie Pins hast, kannst du auch einen FT245 nehmen,
dann hast du keine Probleme mit der Baudrate zwischen FTDI und
Controller.

Jörg Wunsch schrieb:
> Wenn du eine Chipantenne benutzen willst, brauchst du auch einen
> Balun, sinnvollerweise einen Filterbalun.  Chipatennen sind für
> gewöhnlich asymmetrisch gespeist.
> Alternativ kannst du auch einen einfachen Dipol dranhängen.

Auch ein interessantes Beispiel. Da Geld bei mir allerdings keine Rolle 
spielt, Platz aber schon werde ich wohl besser eine Chipantenne nehmen.


> Wenn du genügend freie Pins hast, kannst du auch einen FT245 nehmen,
> dann hast du keine Probleme mit der Baudrate zwischen FTDI und
> Controller.

Ich hab' mal bei einem Seminar einen FT232 verwendet, kann mich aber 
nicht erinnern, dass da irgendwas bezüglich Problemen mit der Baudrate 
erwähnt wurde - inwiefern gibt es da Probleme?


Ich habe auch nochmal ein bisschen nach den programmable XBee ZB's 
gesucht, habe allerdings keine vernünftigen Quellen gefunden, was an 
möglicher mindest-HW dafür benötigt wird (die wollen einem immer das 
komplette Development-Kit für 350 Euro andrehen).
Kann ich folgendes USB-Board auch für die programmable ZB's verwenden?
https://www.sparkfun.com/products/8687
Brauche ich unbedingt noch einen separaten Programmer um den separaten 
Controller zu programmieren?
Hat da irgendjemand Erfahrung damit?

Jeanette Seewald schrieb:

> Auch ein interessantes Beispiel. Da Geld bei mir allerdings keine Rolle
> spielt, Platz aber schon werde ich wohl besser eine Chipantenne nehmen.

Das ist keine Frage des Gelds.  Der Balun will eine ordentliche
Masseanbindung, sonst funktioniert er nicht.  Ich habe schon zu
viele Designs gesehen, in denen der Entwickler dachte, er könnte
die vom Hersteller empfohlenen 4 kleinen Vias für die Masse doch
auch gleich durch ein großes ersetzen …

Kleine Antennen sind einfach nur schlechter als große, die Physik
kannst du nicht überlisten.  Du kannst genausogut einen Dipol auf
der Platine durch eine Mäander kürzer layouten, dann strahlt er
eben weniger ab und kommt in die Region der Chipantenne, sowohl
vom Gewinn als auch von der Größe.  Du kannst auch eine Drossel
von 1 nH oder so zur elektrischen Verlängerung vorschalten vor die
Dipolschenkel, aber vermutlich kannst du sie auch einfach gleich
so verkürzen, die Fehlanpassung fällt kaum nennenswert ins Gewicht.
Reichweite brauchst du ja vermutlich sowieso nicht viel.

Chipantennen sind keine Wunderantennen.

Welche Forderungen an die Gesamtgröße hast du denn?

> Ich hab' mal bei einem Seminar einen FT232 verwendet, kann mich aber
> nicht erinnern, dass da irgendwas bezüglich Problemen mit der Baudrate
> erwähnt wurde - inwiefern gibt es da Probleme?

Die „Gegenseite“ (also der Controller) muss halt mit der gleichen
Baudrate arbeiten wie der FT232.  Wenn du den ATmega128RFA1 vom
Quarz betreiben willst, damit er einen stabilen Takt hat (für die
Baudrate), dann hast du trotzdem das Dilemma (außer der höheren
Stromaufnahme für den Quarz und der längeren Anschwingzeit nach
einem Sleep), dass die 16 MHz relativ schlecht zu üblichen Baudraten
passen.

Beim FT245 erfolgt die Taktung explizit (über die /RD- und /WR-
Signale), damit gibt es keine exakt einzuhaltende Baudrate.  Wenn
du also die 12 Pins dafür am Controller sowieso noch frei hast, dann
würde ich diesen einem FT232 allemal vorziehen.

Aus PC-Sicht benehmen sich beide ICs ohnehin gleich, außer dass man
halt beim FT245 eine x-beliebige Baudrate einstellen kann, ohne dass
er die Kommunikationsfähigkeit mit seiner Umwelt verliert.

Für den Dipol bräuchte ich dann allerdings noch bei jedem Schenkel ein 
R-C-Glied statt des Balun-Filters, richtig? Für welche Grenzfrequenz 
sollten die denn ausgelegt sein?

Ich versuche gerade eine Bestellliste zusammenzustellen.
Gibt es bei der Auswahl des 16 mHz-Quarz und dem Ferrite Bead etwas zu 
beachten bzw. hättet ihr mir einen konkreten Artikel-Tip/Vorschlag.

Jeanette Seewald schrieb:
> Für den Dipol bräuchte ich dann allerdings noch bei jedem Schenkel ein
> R-C-Glied statt des Balun-Filters, richtig?

Im Prinzip ja, aber siehe Tic-Tac-Toe: wenn man sich ein wenig in
der Sendeleistung beschränkt und lediglich an die europäischen
ETSI-Regelungen gebunden ist, dann kann man sich das auch sparen.
Solange der Dipol symmetrisch abstrahlen kann, wird die erste
Oberwelle auch so schon gut genug unterdrückt.

> Für welche Grenzfrequenz
> sollten die denn ausgelegt sein?

Schau mal hier:

http://www.dresden-elektronik.de/funktechnik/products/reference-designs/rcb/

den Schaltplan des RCB230 V3.2 an.  Dieses hat eine integrierte
symmetrische Antenne (das ist mit die beste 2,4-GHz-Antenne, die
ich bislang gesehen habe) und die entsprechenden Tiefpässe.

> Gibt es bei der Auswahl des 16 mHz-Quarz und dem Ferrite Bead etwas zu
> beachten bzw. hättet ihr mir einen konkreten Artikel-Tip/Vorschlag.

Konkrete Vorschläge sollten doch in der Applikationsschaltung
enthalten sein.  Aber viel ist da nicht zu beachten.  Generell, je
kleiner der Quarz in der Bauform, um so länger braucht er zum
Anschwingen (und damit der Transceiver an „Totzeit“, bis er aus dem
Schlaf erwacht ist).  Die Ferritperle/-drossel kann man auch
einsparen, wenn einem die Verkopplung von Digital- und Analogteil
egal ist (bspw. weil man den ADC sowieso nicht nimmt oder nur mit
geringer Genauigkeit braucht).

Ist es u.U. nicht doch einfacher ein fertiges Modul zu nehmen?
Da ist eine Zertifizierung drauf, alles legal, kein aufwendiges 
selberausmessen, ... wenn Geld schon keine Rolex spielt wird ja
meist auch ein rasches Result erwartet.... ist nur so eine
Ueberlegung.

A. W. schrieb:
> Ist es u.U. nicht doch einfacher ein fertiges Modul zu nehmen?

Das ist aber schon etwas demotivierend, nachdem ich gerade angefangen 
hatte, mich da richtig hineinzuleben und Spaß zu haben ;)

Was für ein fertiges Modul würdest du denn vorschlagen?

>Das ist aber schon etwas demotivierend, nachdem ich gerade angefangen
>hatte, mich da richtig hineinzuleben und Spaß zu haben ;)

Will natuerlich nicht als Spassbremse agieren, ich dachte die Sensoren
anzusteuern und die SW dazu zu schreiben, waere schon viel.

Gibt es denn schon neue Erkenntnisse hinsichtlich des Datenaufkommens 
und der Echtzeitanforderungen?

>Was für ein fertiges Modul würdest du denn vorschlagen?

Vielleicht dieses hier:
https://shop.dresden-elektronik.de/module/2-4-ghz-2/avr-module/mega128-22c00.html

A. W. schrieb:
> Vielleicht dieses hier:
> https://shop.dresden-elektronik.de/module/2-4-ghz-...

Danke, die hatte ich mir auch mal angeschaut, allerdings sind da bei mir 
noch ein paar Fragen offen:

- Was bedeutet: "Alle Funkmodule sind bereits mit einer Wireless UART 
ausgestattet und damit sofort betriebsbereit."?

- Es gibt dafür mehrere Zusatzboards: deRFnode, deRFbreakout-Board, 
deRFtoRCB - Für eine Programmierung müsste das deRFbreakout-Board und 
ein AVR Dragon ausreichen, richtig?

>- Was bedeutet: "Alle Funkmodule sind bereits mit einer Wireless UART
>ausgestattet und damit sofort betriebsbereit."?

Wenn man die Module an eine RS232 haengt kann man Wireless Chatten/ 
Daten uebertragen ... also aehnlich wie xbee.

 PC1 <-> Modul1 ... [HF-Magie] ... Modul2 <-> PC2

>- Es gibt dafür mehrere Zusatzboards: deRFnode, deRFbreakout-Board,
>deRFtoRCB - Für eine Programmierung müsste das deRFbreakout-Board und

Wenn du SMD Module (22C00) bestellst, dann nutzt dir das deRFbreakout 
nix, es ist nur bei den bestifteten Modulen 22A00 nutzbar. Durch die 
vielen
kleinen Pins sind die Steckkraefte aber recht hoch und die Pins neigen 
dann dazu abzubrechen - also als Programmiersockel denke ich ist das 
eher
ungeeignet aber als Development Plattform sicher gut zu gebrauchen.

>ein AVR Dragon ausreichen, richtig?
Ja, mit einem Dragon kannst du den RFA1 programmieren und debuggen.

Empfehlenswert ist noch einer der beiden Pegelwandler, ein Debug-UART 
ist beim Schreiben der SW immer wieder nuetzlich:

https://shop.dresden-elektronik.de/zubehor-1/usb-pegelwandler-stick-basic.html
https://shop.dresden-elektronik.de/zubehor-1/rs232-pegelwandler.html

Den USB Stick kann man auch so patchen, dass der RFA1 mit versorgt wird.

A. W. schrieb:

> Wenn du SMD Module (22C00) bestellst, dann nutzt dir das deRFbreakout
> nix, es ist nur bei den bestifteten Modulen 22A00 nutzbar.
Ja, deshalb, dachte ich, ist es einfacher für den ersten Test eines der 
A-Module zu verwenden, oder gibt es so was ähnliches auch für die 
SMD-Module?

> Durch die vielen
> kleinen Pins sind die Steckkraefte aber recht hoch und die Pins neigen
> dann dazu abzubrechen - also als Programmiersockel denke ich ist das
> eher
> ungeeignet aber als Development Plattform sicher gut zu gebrauchen.
Was wäre denn ein geeigneter Programmiersockel?


> Ja, mit einem Dragon kannst du den RFA1 programmieren und debuggen.
>
> Empfehlenswert ist noch einer der beiden Pegelwandler, ein Debug-UART
> ist beim Schreiben der SW immer wieder nuetzlich:
Wenn ich mit dem Dragon programmieren und debuggen kann (den PC stecke 
ich ja einfach per USB-Kabel dran) - wofür brauche ich dann noch die 
Pegelwandler bzw. was mache ich damit?

Jeanette Seewald schrieb:
> Wenn ich mit dem Dragon programmieren und debuggen kann (den PC stecke
> ich ja einfach per USB-Kabel dran) - wofür brauche ich dann noch die
> Pegelwandler bzw. was mache ich damit?

Debugausgaben aus dem laufenden Programm, ohne dass man da zwischen-
drin anhalten muss oder dergleichen.  Nennt sich „printf-Debugging“.
;-)

>Ja, deshalb, dachte ich, ist es einfacher für den ersten Test eines der
>A-Module zu verwenden, oder gibt es so was ähnliches auch für die
>SMD-Module?

soweit ich weiss nicht. Mach es so wie beschrieben. Fuer das fertige
Geraet mit eigenem PCB nimmst du dann die C-Module.

>Was wäre denn ein geeigneter Programmiersockel?
Keine Ahnung ob es 0-Kraftsockel fuer solche Module gibt, ich glaube
eher nicht oder aber die sind sehr teuer, das lohnt fuer die paar 
Geraete
nicht.

Wenn du wirklich sehr viele programmierte Module brauchst, dann kannst 
du bei DE mal anfragen ob sie dir einen Bootloader oder eine andere SW 
vorprogrammieren.

> Wenn ich mit dem Dragon programmieren und debuggen kann (den PC stecke
> ich ja einfach per USB-Kabel dran) - wofür brauche ich dann noch die
> Pegelwandler bzw. was mache ich damit?

Neben dem printf-Debugging kannst du mit einem seriellen Bootloader auch
die Module flashen. Das ist langsamer als ueber JTAG, spart aber ein 
weiteres Geraet im Setup und evtl. auch Platz auf dem Arbeitstisch.

Ich danke Euch sehr!

Noch eine (vorerst) letzte Frage: Wie sieht es mit 
Beschleunigungen/G-Kräften aus? Ich habe versucht, Werte für den 
ATmega128RFA1 oder sonstige Mikrocontroller zu finden - nada. Habt ihr 
irgendwelche euch bekannten Limits?

Jeanette Seewald schrieb:
> Habt ihr
> irgendwelche euch bekannten Limits?

Ich würde mal sagen, dass deine Lötstellen das Nadelöhr sind.  Was
die aushalten, ohne abzureißen, hält auch der Rest eines ICs aus.

A. W. schrieb:
> Du kannst dann das Beispiel xmpl_trx_tx.c um deine Sensorabfragen
> erweitern und das sollte es schon gewesen sein, plus/minus ein bisschen
> Debugging.

Hallo A.W.,

ich habe nun die deRFmega128-Module vor mir und würde gerne mit Hilfe de 
xmpl_trx_tx (bzw. rx)-Beispielen von uracoli eine Verbindung aufbauen.

Wenn ich die Anleitungen richtig verstanden habe, müsste ich mit 
AVR-Studio wie folgt vorgehen können:

1. uracoli-src-0.4.0 herunterladen
2. xmpl_trx_tx.aps öffnen
3. in den Project Configurations das "derfa" wählen
4. compile and run

Ich habe allerdings folgende Schwierigkeiten:
- das derfa ist in den Configurations nicht in der Liste zum Auswählen 
enthalten
- wenn ich einfach mal irgendein anderes board nehme, kommt der 
Compile-Fehler: C:/winavr.../ld.exe: cannot find -luracoli_<gewähltes 
board>.


Ich weiß, dass nicht alle Beispiele für alle Module zur Verfügung stehen 
(und da das derfa die im Beispiel verwendeten LEDs nicht besitzt, 
vermute ich, dass das hier der Fall ist).
Was müsste ich tun, um das Beispiel lauffähig zu kriegen?

Was habt ihr denn an Platine? Hat irgendwer ein Layout?  Ich hab auch so 
Module ...Habt ihr noch Platinen über?

>Ich weiß, dass nicht alle Beispiele für alle Module zur Verfügung stehen
>(und da das derfa die im Beispiel verwendeten LEDs nicht besitzt,
>vermute ich, dass das hier der Fall ist).
>Was müsste ich tun, um das Beispiel lauffähig zu kriegen?

oops, dass AvrStudio 4 habe ich schon seit etwas laengerer Zeit etwas 
verstiefvaeterlicht.

Warum es derfa1 nicht gibt? Vermutlich habe ich mal alle Module aus dem
aps-Files geworfen, dass muss ich mir mal genauer anschauen.


Also es ist nun folgendes zu tun:

cmd.exe starten
cd .....\uracoli-src-0.4.0
make -C src derftorcbrfa1

Danach gibts die liburacoli_<board>.a und der Build aus dem
AVR-Studio sollte dann funktionieren.

Ein Problem kann bei obigen Make-Aufruf noch auftreten und zwar, wenn du 
WinAVR nutzt, dann kommt eine Fehlermeldung in der folg. Art:
============================================================
gmkdir -p ../lib
process_begin: CreateProcess(NULL, gmkdir -p ../lib, ...) failed.
============================================================

"gmkdir" ist ein Gnu-Makedir und wird bei den neuen AVR-Toolchains
genutzt (damit es mit dem Windows mkdir nicht kollidiert). Bei WinAVR
war der Name noch mkdir. Am einfachsten, du kopierst (nicht umbenennen)
die Datei ...\\WinAVR-20100110\utils\bin\mkdir.exe nach gmkdir.exe im 
selben Verzeichnis.


Schau mal, ob es klappt.

A. W. schrieb:
> Schau mal, ob es klappt.

Danke für die schnelle Hilfe und die tolle library/examples - damit kann 
man echt beinahe aus dem Stehgreif zumindest eine Zahl hinübersenden :)

Das gehört jetzt zwar nicht mehr direkt zu dem Thread, aber da ihr mir 
bisher so super weitergeholfen habt, hoffe ich einfach nochmal darauf.

Ich versuche jetzt mit dem ATmega128RFA1 über SPI Sensorwerte des 
LTC2498 auszulesen.

Die Werte, die ich erhalte ergeben jedoch keinen Sinn (zB wenn ich den 
Temperatursensor auf dem Chip auslesen will, steigen die Werte stetig 
an) und ich finde das Problem nicht.

Mein Code ist eigentlich recht simple (uart-init etc. habe ich jetzt 
hier mal weggelassen, da das problemlos funktioniert):

1

void SPI_MasterInit(void)

2

{

3

  //Outputs: MOSI, SCK, SS

4

  DDRB = (1<<DD_MOSI)|(1<<DD_SCK)|(1<<DD_SS);

5

6

  //Enable SPI, Master-Mode, set clock rate fck/16

7

  SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0);

8

}

9

10

11

int SPI_MasterTransmit(char MOSI)

12

{

13

  //start Transmission

14

  SPDR = MOSI;

15

16

  //white for transmission complete

17

  while(!(SPSR & (1<<SPIF)));

18

19

  //returned data from slave to master

20

  return SPDR;

21

}

22

23

24

int main()

25

{

26

27

  char str[20];

28

29

  // Thermoelement an CH0 und CH1

30

  char masterOut1 = 0b10100000;

31

  //char masterOut2 = 0b10000000;

32

33

  // interne Temperaturmessung:

34

  char masterOut2 = 0b11000000;

35

36

  char result;

37

  uint32_t masterIn = 0;

38

  uint32_t Temp = 0;

39

40

  uart_init();  

41

42

  SPI_MasterInit();

43

44

45

  for(;;)

46

  {

47

48

    _delay_ms(500);

49

50

    //CS des Thermochips auf low

51

    PORTB &= !(1<<DD_SS);

52

53

54

    //Byte1

55

    result = SPI_MasterTransmit(masterOut1);    

56

    masterIn = (result & 0b00011111);  //die ersten drei Bit löschen

57

58

    //Byte2

59

    result = SPI_MasterTransmit(masterOut2);

60

    masterIn = (masterIn<<8) + result;

61

62

    //Byte3

63

    result = SPI_MasterTransmit(0);

64

    masterIn = (masterIn<<8) + result;

65

66

    //Byte4

67

    result = SPI_MasterTransmit(0);

68

    masterIn = (masterIn<<8) + result;

69

70

71

    //CS des Thermochips auf high

72

    PORTB |= (1<<DD_SS);

73

74

75

    masterIn = (masterIn>>5); //die letzten 5 Bit löschen

76

77

    sendestring(" masterIn: ");

78

    sprintf(str, "%ld", masterIn);

79

    sendestring(str);

80

81

    //bei interner Temperaturmessung: Temperatur in °C berechnen laut Datenblatt Seite21

82

    Temp = (masterIn*4/1570)-273;

83

84

    sendestring(" Temp: ");

85

    sprintf(str, "%ld", Temp);

86

    sendestring(str);

87

88

    _delay_ms(2000);

89

  }

90

91

92

  return 0;

93

}

Sieht einer von Euch vielleicht, woran es liegen könnte?

Jeanette Seewald schrieb:
> Das gehört jetzt zwar nicht mehr direkt zu dem Thread

Dann mach doch einen neuen Thread auf, wir lesen auch in den anderen
Unterforen mit.

Jörg Wunsch schrieb:
> Dann mach doch einen neuen Thread auf, wir lesen auch in den anderen
> Unterforen mit.

Das habe ich versucht, hat aber nicht so geklappt:
Beitrag "Re: LTC2498 und Atmega128rfa1: c-code Beispiel"