Erstmal einen schönen Abend an alle hier im Forum.
Ich bin ursprünglich aus der Softwareentwicklung und habe bereits aus
dem Studium Grundkenntnisse im Bereich Microcontroller. Da dies schon
etwas her ist, benötige ich für einen NeuEinstieg ein paar Hinweise und
Tips. Folgende Aufgabe soll gelöst werden:
Ich benötige einen Microcontroller, der Daten von analogen und digitalen
Quellen aufnimmt und via Funk (WLan wäre optimal) an einen PC sendet und
von dort auch Daten empfangen kann. Sollte es keine preisgünstige Lösung
via WLan geben, will ich auf ein feigegebenes Funkband (866MHz/2,4GHz)
ausweichen und als Server einen weiteren Microcontroller einsetzen, der
dann ankommenden Daten via LAN weitergeben kann bzw. Befehle sendet oder
zumindest Daten zwischenspeichert und für den Abruf vom PC via LAN
bereit hält.
einfache Beispiele:
Temperaturmessung, Regelung Heizungsthermostat, Türsicherung,
Beleuchtung
Hintergrund:
Die Daten sollen in einem zentralen PC automatisch archiviert werden.
Der PC übernimmt eine zentrale Rolle im Haus. Eine eigene WebOberfläche
stellt mir alle Informationen und vieles mehr bereit.
Klingt nach typischer HomeAutomation, soll aber nicht in einem eigenen
HomeAutomation-Gerät passieren und viel mehr können als übliche
HomeAutomation-Lösungen.
Und jetzt die Frage: Welchen Microcontroller sollte man dafür einsetzen,
bei kleinem Geldbeutel, energiearmen Betrieb (Akku) und geringer
Baugröße ?
Bevorzugte Programmierung wäre C oder Basic.
Herzlichen Dank, Mike
Mike wrote:
> Ich bin ursprünglich aus der Softwareentwicklung
Heißt das, Du hast schon viel mit LAN/WLAN gemacht?
Ich denke mal, WLAN/Bluetooth ist so die Königsklasse (schön viel
Verwaltungsaufwand, Treibergerödel usw.).
Zum Basteln einfacher ist RFM12 (billig, aber alles muß man selber
machen) oder teuer: ZigBee (Atmel Raven).
Mal danach googlen.
Einfach ist Funk aber nicht und auch nicht sonderlich zuverlässig.
Generell sind MC-Anfänger gut beraten, wenn sie erstmal klein anfangen
(LED blinken, Timerinterrupt, Entprellen, UART, Text-LCD).
Peter
Akku: Es gibt halt Stellen, wo nicht unbedingt Strom in der Nähe ist.
Also WLAN pack ich dann erstmal in die Schublade. Bleibt also der
RFxx-Weg.
vermutlicher Weg:
RF_xx + ATmega_yy = Funkboard auf Sensor/Aktor-Seite (I2C) = Clients
RF_xx + ATmega_ZZ = Funkboard auf Server-Seite mit Anschluß an PC
(RS232)
Wie kann ich dann mehrere Clients mit nur einem Server zusammen bringen
?
Hallo Mike,
ich selbst arbeite mit ARM-Controllern die ein direktes LAN Interface
haben: der CC7U bzw CC9U von Digi. Vorteil: man kann diese direkt unter
µCLinux betreiben, das macht einiges leichter. Digitale Ports sind
vorhanden, analoge kann man per I2C anbinden, oder einen "Hilfs-AVR"
dazunehmen. Allerdings liegen die Module jeweils bei 50-100 Euro (plus
ggf. Entwicklungskit).
Welche Bandbreiten benötigt dein Projekt denn ?
matthias
...ich habe mal eben aus Neugier bei Schuricht nachgesehen: was ist von
den Bausteinen von "Nordic" zu halten nRF24Z1 und nRF905 - kennt die
jemand ? damit könnte man doch eine Funklösung aufbauen...
Wow, die ARM-Module sind wirklich ziemlich teuer. Eher nichts für viele
kleine Sensörchen und den privaten Haushalt. Auf LAN könnt ich ja gut
verzichten. Es soll/muss halt Funk-basierend sein. Die Client-Seite (ich
nenn es mal SensorClient) ist ja mit RF12+ATmega relativ preiswert
hinzubekommen. Sofern man viele davon mit einem Server-Modul bedienen
kann.
Das ist die Quizzfrage.
Mike
was deine Frage nach mehreren Sendern angeht: es scheint wohl keine
Kommunikationsprotokolle (Layer 3++) für die einfachen Funkmodule zu
geben, daher würde ich etwas vorschlagen, wa aus dem Feldbusbereich
kommt (und eigentlich leicht zu implementieren ist) - dazu müsstest du
aber überall Transceiver-Module verwenden (also Senden UND Empfangen):
1. der zentrale Sender pollt die Clients der Reihe nach, damit kann auch
ein einzelner Ausfall eines Clients leicht festgestellt werden, und du
stellst sicher, dass immer nur einer sendet.
2. Token-Passing: jeder Sender erhält eine ID und sendet zunächst seine
Daten, dann sendet er das Token an den nächsten Client. Dazu müssten
sich aber zumindest benachbarte Clients funktechnisch erreichen können.
matthias
Polling !!! ... die Lösung !
Es ist sowieso nicht gedacht, dass die SensorClients sich
'verselbständigen'. Diese sollen nur Meßwerte und Status ermitteln und
zwischenspeichern. Mit dem Server frage ich dann Step by Step alle
SensorClients ab. ... Aber wie kann ich nur einen bestimmten
SensorClient ansprechen.
z.Bsp. ClientX - Sende mir die Temperatur vom Gewächshaus ?
meine Gdanken freier Lauf:
Gut anhand einer zu definierenden Zuordnung ID = ClientX. Dann müßten
die Clients den Empfang auswerten und mit Ihrer ID vergleichen und
sofern identisch dann die Antwort senden.
Polling setzt aber voraus, dass die Funkmodule der Clients ständig den
Empfänger aktiviert haben, was viel Strom (Batterie!) braucht.
Kurz ein schneller Vorschlag aus dem Bauch raus:
Client-Modul:
ATMega8
RFM12 Funkmodul
Einige IOs herausführen (GIO, I2C)
Lithium Bat oder 1/2 x Mignon mit Stepup Regler
Jedem Modul wird beim flashen eine eindeutige ID mit eingebrannt. Anhand
der ID wird u.a. ein Zufallsgenerator gesäht. Das Modul ist
grundsätzlich in einer "standby" Betriebsart mit abgeschaltetem
Funkmodul. Wenn eine bestimmte Zeitspanne, z.B. 60 s (mit einem
Zufallswert addiert), vergangen ist, versucht das Modul seine Daten zu
senden (listen before talk) bis es eine Bestätigung vom Master bekommt.
Weitere Sendeversuche werden z.B. nach einigen Sekunden (+ Zufall)
gemacht.
Der Master kann z.B. ebenfalls aus einem Mega8 + Funkmodul bestehen, der
die Daten via serieller Schnittstelle an einen PC weitergibt und/oder
auf einer SD-Karte speichert.
Oder einen SC12, einen ARM oder einen größeren AT Mega nehmen um einen
LAN-Anschluss zu haben, dann hat man das ganze gleich im Netz, oder,
oder, oder...
Stefan
Stefans Idee halte ich für ziemlich gut, das entpricht ziemlicn genau
dem Mechanismus den auch ein TCP/IP etc verwendet um kollisionsfrei
senden zu können, wenn das Medium gerade "belegt ist" (auch wenn wir
heutzutage alle Switches verwenden, im Prinzip ist Ethernet nach wie vor
CSMA/CD-behaftet).
Und die IDs würde ich auch genauso im EEPROM als "Geräteadresse"
hinterlegen, irgendwie musst du doch ohnehin deine Messstellen
auseinander halten können.
matthias
Schau dir doch mal das Modul von Florian Scherb an (Beitrag:
Nachbaubares Funkmodul auf Basis des RFM12). Dieses Modul nutzt das
RFM12 und kann bis zu 128 Clients verwalten. Eventuell verrät er dir ja
auch nach welchen Protokoll er die Clients verwaltet.
Sven
