Hallo Forumsgemeinde,
ich bräuchte mal einen Tipp von euch, wie ihr folgendes lösen würdet
(unten meine Überlegungen)
Ich plane den Garten ein bisschen zu "digitalisieren" - also
Bodenfeuchtesensoren, Temperatursensoren, Regenmesser etc.
In Summe werden es 12 Sensoren sein, die vom "zentralen Punkt" ca. je
10-40 Meter weg sind (Kabellänge). Sensoren liefern fast alle ein
Spannungssignal.
Wie würdet ihr die Sensordaten aufbereiten, um Sie dann relativ
störungssicher, mit ca. 1Hz auslesen/übertragen zu können?
Meine Idee:
a) Jeden Sensor mit Chip (kleinen Atmel etc.) ausstatten, dass er
seriell senden kann - der zentrale uC hat einen MUX und ließt dann ab
und zu mit (1Hz)
=> habe noch keinen MUX gefunden ... zur Not müsste ich den selbst bauen
(Tipp?)
b) SPI nutzen und verstärken
c) Sensor in Frequenzsignal umsetzten und dann am uC die Frequenzen
messen
Habt ihr bessere Ideen ?
Frank schrieb:> SPI nutzen und verstärken
SPI ist wie I2C ein Bus für AUF der Leiterplatte.
Frank schrieb:> Sensor in Frequenzsignal umsetzten und dann am uC die Frequenzen> messen
Habe ich auch schon gemacht war ganz ok, würde ich aber nicht nochmal
machen.
Ich würde etwas wie CAN vorschlagen, das ist auch beinahe beliebig
skalierbar.
Frank schrieb:> Habt ihr bessere Ideen ?
Seriell ist schon ok, nicht aber RS232C, das hat ausser dem Nachteil,
dass man multiplexen muss die Beschränkung auf offiziell 15 m - ich
würde einen Bus wie z.B. RS485 verlegen. Dann kann man von Sensor zu
Sensor verlegen und braucht nur 1 Anschluss an der Zentrale.
Georg
Die grundlegende Frage: wie willst du verdrahten? Wenn eh jeder Sensor
seine eigene Leitung bekommt, kannst du auch das Spannungssignal
verwenden, 12 Spannungseingänge sind kein Problem.
Wenn dir aber eher eine lineare Verdrahtung von Sensor zu Sendsor
vorschwebt dann RS485. CAN bringt hier keine Vorteile (reiner
master/slave möglich).
Frank schrieb:> Meine Idee:> a) Jeden Sensor mit Chip (kleinen Atmel etc.) ausstatten, dass er> seriell senden kann - der zentrale uC hat einen MUX und ließt dann ab> und zu mit (1Hz)> => habe noch keinen MUX gefunden ... zur Not müsste ich den selbst bauen> (Tipp?)
Dann nimm doch Halbduplex-RS485-Transceiver (z.B. MAX3483) an jedem
Kabel-Ende. Jeder Transceiver hat ein DE (Driver Enable) und ein /RE
(Receiver Enable) Signal, und damit und beispielsweise einem 74HC138
(für die /RE) bzw 74HC238 (für die DE) kannst Du dann den einzelnen
Sensor selektieren. Und RS-485 geht einige 100m weit. Abschluss- und
Failsafe-Widerstände nicht vergessen!
fchk
Ich würde einen Kleinst-µP, für jeden Teilnehmer, verwenden und dann
einen offenen Ring mittels RS485 - notfalls RS232 - aufbauen. Bei so
geringer Belastung kannst Du die Daten jeweils "Durchleiten". D.h. der
jeweilige µP empfängt die Daten und leitet sie, gefolgt von dem eigenen
Datenpaket weiter. Hat der µP keine zweite serielle Schnittstelle, so
reicht auch eine, durch Software emulierte, Schnittstelle aus.
Der letzte Mohikaner bekommt dann alle Daten, hübsch der Reihe nach und
hat somit auch keine Probleme mit irgendwelchen Kollisionen und
ähnlichem Schweinkram.
Die Reihenfolge richtet sich nach der physikalischen Reihenfolge, oder
jeder Teilnehmer packt eine/seine Adresse dazu.
Also ich würde CAN den Vorzug geben, da jeder Knoten beliebig ohne große
Absprache senden und empfangen kann. Bei RS485 muss man sich ja immer
ein wenig Gedanken um die Koordinierung machen.
Immer wieder gerne genommen für solche kleinen Sensorknoten: LPC11C24,
im Grunde den STM32 sehr ähnlich. Als Besonderheit hat der den
CAN-Transceiver gleich mit eingebaut.
Oder den STM32F042 im SSOP20, dazu ein MAX3051 als CAN-Transceiver, der
ist schön klein (SOT23-8) und sparsam.
Harald schrieb:> Bei RS485 muss man sich ja immer> ein wenig Gedanken um die Koordinierung machen.
Es gibt das schon eine fertige Lösung, die sich um die Koordinierung
kümmert: Modbus.
Uwe Bonnes schrieb:> Wenn der Stromverbrauch der CAN Tranceiver nicht stoert, ist CAN auch> eine gute Wahl.Harald schrieb:> MAX3051 als CAN-Transceiver, der> ist schön klein (SOT23-8) und sparsam.
Dafür gibt es vielen CAN Transivern mit sleep Pin, um in einen low power
Modus zu gehen.
Microchip hat auch einige die sehr günstig sind unter anderem auch im
QFN Package, falls interessant.
100Ω W. schrieb:> Es gibt das schon eine fertige Lösung, die sich um die Koordinierung> kümmert: Modbus.
Ja, habe ich auch schon mit gearbeitet. Muss man halt alles nur in SW
ausführen, aber funktionieren wird das, keine Frage!
War auch nur als meine persönliche Meinung zum Thema gedacht, ohne dabei
andere Vorschläge schlecht machen zu wollen.
Was der OP daraus macht ist mir eigentlich egal.
Harald schrieb:> LPC11C24
Ja hätte ich vermutlich auch genommen. CAN ist doch ziemlich einfach.
Und Single Chip kann auch seinen Charme haben.
RS485 würde auch gehen. Würde ich mir wahrscheinlich einen Controller
suchen der den Multiprocessor Mode unterstützt. Dann kann man relativ
leicht adressieren und der Controller kann zu 99.9% im Sleep verbringen.
Muss man sich halt etwas Gedanken zu Protokoll und Sicherung (z.B CRC)
machen. Kollisionen könnte man bei so langsamen Daten so gut wie
ausschließen.
Das nimmt einem CAN halt größtenteils ab.
Bei nicht differentiellen Übertragungen (RS232, 1-Draht) kann man auf
den Strecken schnell ein Problem durch die unterschiedlichen
Massepotentiale bekommen. Von daher würde ich etwas Differentielles
vorziehen. Zusätzlich dann noch die Störsicherheit.
Peter D. schrieb:> Ich würde mir ja ein 8-Pinner AVR mit internem CAN-Transceiver wünschen.
Das wäre mal gut, dann muss der Quarz aber gleich mit drin sein. Ich
habe mir auch schon mehrere Male Gedanken um einen besonders kleinen
CAN-Knoten gemacht, der auf dem Tisch mit Hausmitteln noch bequem zu
bauen ist (jaja, ich weiß, dass das hier nicht gefordert wurde):
LPC11C24 oder STM32F042 mit MAX3051, dazu ein Quarz im 2016 Package. Als
Netzteil den MAXM15064 (MAXM, nicht MAX), der macht 5V/300mA aus bis zu
65V(!) in einem unglaublich kleinen Package. Funktioniert sehr gut!
Harald schrieb:> Ich habe mir auch schon mehrere Male Gedanken um einen besonders kleinen> CAN-Knoten gemacht, der auf dem Tisch mit Hausmitteln noch bequem zu> bauen ist
Was sollte der denn deiner Meinung nach so können? Ich überlege auch
schon lange sowas zu bauen, als Auflötplatine ähnlich einem ESP, nur bin
ich immer unschlüssig was an sonstiger Perepherie so Sinn macht. Ein
paar Analogeingänge, SPI, I2C, etc.
Was auch ginge wäre ein LIN Bus.
Als Slaves dann jeweils nur einen UJA1023 verwenden, dann musst du die
Slaves nicht mal seprat programmieren sondern nur vom Master
konfigurieren.
Kevin M. schrieb:> als Auflötplatine ähnlich einem ESP, nur bin ich immer unschlüssig was> an sonstiger Perepherie so Sinn macht. Ein paar Analogeingänge, SPI,> I2C, etc.
Vor allem ist ein ESP nicht nur ein WLAN Knoten sondern der uC darin
PROGRAMMIERBAR. Das macht den Reiz aus. Ob dann 1 Analogeingang oder 4
ist eher egal, klug wäre es sowieso den CAN auf mehreren
unterschiedlichen Prozessoren einer Familie (eben allen mit on board
CAN) laufen lassen zu können.
MaWin schrieb:> Vor allem ist ein ESP nicht nur ein WLAN Knoten sondern der uC darin> PROGRAMMIERBAR.
Klugscheißer, darum geht es doch.... Einen mini CAN Knoten auf Basis
eines programmierbaren uC mit einem Transüber und Versorgung, der noch
andere Schnittstellen bereitstellt. So kann man ihn standalone benutzen
oder in einem größeren Projekt bei dem man noch etwas Analogaufbereitung
o.ä. braucht. Oder eben um einen Sensor auszulesen.....
Kevin M. schrieb:> Was sollte der denn deiner Meinung nach so können?
Einfach nur der uC mit allen sinnvollen Pins rausgeführt. Nur dass, was
man immer braucht (Quarz, Reset, Power, Transceiver) auf einem eigenen
Board.
