Hallo! Ich wäre sehr dankbar für eure Tipps zu meiner derzeitigen Problemstellung: Ich muss Sensorwerte aus einem Motorprüfstand über Funk an einen PC übertragen. Die Sensoren können wia SPI angesprochen werden. Daher schwebt mir im Moment motorblockseitig das ZigBit von Atmel ATZB-24-A2/B0 (oder eventuell auch nur der darin integrierte AT86RF230 Receiver) vor. Die Platzfrage ist hier auch nicht ganz unterheblich. http://at.mouser.com/new/atmel/atmelzigbit/ PC-seitig würde ich dann der Einfachheithalber mit einem Digi XBee-Modul (Serie 1) und einem Explorer USB Board arbeiten. - Hat irgendjemand Erfahrung damit, ob das Atmel ZigBit-Modul problemlos mit einem XBee-Modul kommunizieren kann? - Oder gibt es ein XBee-Modul, das ich direkt an den SPI-Bus motorseitig anschließen kann? Ich bin auch froh um alle generellen Anmerkungen, bessere Alternativvorschläge und Tipps. Schonmal Danke, Jeanette
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"
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.