Hallo, die ersten Schritte mit dem Arduino habe ich erfolgreich hinter mir, muss jetzt aber etwas "Sinnvolles" damit bauen, um meiner geliebten Gattin auch etwas vorzeigen zu können. Also dann eine Steuerung für unsere Beregnungsanlage... Da habe ich 12 Kanäle die individuell programmierbar sind mit 12 identischen Nanos. Diese erhalten mittels Widerstände auf den Platinen jeweils auch einen individuellen Key. Das ist fertig und läuft im Test. Jetzt möchte ich aber ein zentrales Display einpflegen um Laufzeiten, Timerzeiten usw. anzuzeigen. Dazu meine Fragen: 1. Ich möchte einen 13. Nano als Master über i2c mit den 12 anderen verbinden. Das ist wohl noch in den Spezifikationen und sollte funktionieren? 2. Das Display würde ich dann nicht auch noch über i2c laufen lassen wollen sondern über die digitalen Pins. Ist so richtig gedacht? 3. Wenn ich das Prinzip bei i2c richtig verstanden habe, lasse ich den Master seine Runden bei den Slave-Nanos ziehen und checken ob eine Info anliegt, welche er sich dann lädt. Bremst er die Slaves aus wenn er permanent anfragt? Sollte man diese Anfragen lieber Takten? Die Daten sind ja weder zeitkritisch noch für die Funktion der Steuerung wirklich wichtig. Es geht mir nicht um Lösungswege, diese erarbeite ich mir dann schon -ich würde nur gerne wissen ob diese Vorstellungen überhaupt zum Ziel führen könnten. Mir ist natürlich bewusst, dass es viele bessere und elegantere Wege gibt aber man lernt ja trotzdem etwas dazu. Die Leitungslängen betragen übrigens maximal 50cm. Ich bedanke mich im voraus Andreas ..und nehmt Rücksicht auf einen alten Mann - mein erster selbstgebauter Verstärker war noch ein Umbau eines Röhrenradios
Da kommt schon die erste Frage: Wie weit sind die Nanos voneinander entfernt? Bei mehr als 50cm Gesamtlänge: Vergiss I2C und nimm RS232 bzw. RS485 (12x50cm=6m oder wie war das gemeint?). 1. ja 2. Warum das Display nicht auch auf I2C? 3. wird so i.A. gemacht. Andreas Q. schrieb: > Bremst er die Slaves aus wenn er > permanent anfragt? Wenn das alles auf Slave Seite sauber mit Timern gemacht wird, nicht. > Sollte man diese Anfragen lieber Takten? Wie willst Du sonst abfragen? Endlosschleife ohne Timer? Eine solche Endlosschleife macht wenig Sinn. Frage Dich einfach, wie oft Du die Daten anzeigen willst. Ein Wasserstrahl dürfte für eine Sekunde relativ wenig Einfluß auf Deine Wiese haben. ;-) Wenn Du eine Endlosschleife ohne Timer auf den Master planst, wäre das nur machbar, wenn die Slaves per Timer die Masterabfragen auswerten. Dann muß der Master halt warten bis er drankommt und der Slave kann ungerührt seine Aufgaben verrichten.
Es gibt eine Situation, wo ein Slave den Master ausbremsen kann. Das ist, wenn der Slave auf das Datenpaket vom Master sein Acknowledge-Bit schickt, und dann den Pegel auf Low lässt. Durch den Pullup/Open Drain ist dann eine weitere Kommunikation nicht mehr möglich. Aber das lässt sich lösen, in dem man den watchdog-timer mit der I2C-Kommunikation triggert, und wenn die aus bleibt, gehen alle Slaves auf den initialen Zustand.
Andreas Q. schrieb: > Hallo, die ersten Schritte mit dem Arduino habe ich erfolgreich hinter > mir, muss jetzt aber etwas "Sinnvolles" damit bauen, um meiner geliebten > Gattin auch etwas vorzeigen zu können. Sei ein Mann! Männer machen unsinniges Zeug, einfach weil es ihnen gefällt. Das sollte jede Gattin erkennen und akzeptieren. Also mach weiter Dinge, die dir gefallen, aber für andere überhaupt keinen Sinn oder Nutzen haben.
...RS485 ist definitiv die bessere Lösung für Deine Anwendung. I2C ist per Definition dafür gemacht worden, zwischen zwei ICs Daten auszutauschen, idealerweise auf der gleichen Platine. Das ist kein Feldbus. RS485 ist ein Feldbus. Du hast auch 3 Leiter (D+,D-,GND), aber die Reichweite und die Störfestigkeit ist besser. Mit dem Datenformat hast Du auch mehr Flexiblität.
PittyJ schrieb: > Sei ein Mann! > Männer machen unsinniges Zeug, einfach weil es ihnen gefällt. Das sollte > jede Gattin erkennen und akzeptieren. > Also mach weiter Dinge, die dir gefallen, aber für andere überhaupt > keinen Sinn oder Nutzen haben. Genau!
Also ... I2C ist zwar vom Ursprung auf Leiterplatte vorgesehen, kann aber auch deutlich länger verwendet werden, hab hier in relativ störbehafteter Umgebung n I2C mit 8 Slaves verteilt auf 40m Leitung seit 6 Jahren am laufen, es geht problemlos. Kommt auf die Taktrate an, mit paar kHz läuft das. Ob und wie stark es die Busteilnehmer ausbremst kommt auf die Programmierung an. Die AT-Megas haben einige Interrupts, auch beim I2C (TWI), also RX-Complete und TX-complete, sinnvoll verwendet gibt das kaum Last. Schickst Du den Controller in Warteschleifen zum Abfragen von Statusbits sieht die Sache anders aus.
Da geb ich dir Recht. Das mit den 50 cm stimmt überhaupt nicht. Du kannst ohne Probleme 5 bis 10 m nehmen ohne Probleme. Wenn es länger werden soll gibt es auch Lösungen.
Moin, Ja, klar kann's sein, dass sowas auch in Einzelfaellen funktioniert. Man kann auch Leberkaes' auf einem Buegeleisen braten oder Wuerstchen mit einer Kaffeemaschine heiss machen. Trotzem gibts eben auch Gruende, warum man das normalerweise mit einer Pfanne oder einem Topf auf einem Herd macht. Ich wuerde fuer 12 Teilnehmer auf verschiedenen PCBs keinen I2C Bus nehmen. Ich wuerde nicht mal fuer 12 Teilnehmer auf einem PCB einen I2C Bus nehmen, sondern die auf mehrere Busse verteilen. Gruss WK
PittyJ schrieb: > Männer machen unsinniges Zeug, einfach weil es ihnen gefällt. Das sollte > jede Gattin erkennen und akzeptieren. Machen Frauen doch auch schon immer
Dergute W. schrieb: > Ich wuerde fuer 12 Teilnehmer auf verschiedenen PCBs keinen I2C Bus > nehmen. Ich wuerde nicht mal fuer 12 Teilnehmer auf einem PCB einen I2C > Bus nehmen, sondern die auf mehrere Busse verteilen. Solche Aussagen sind für den TO nicht hilfreich da sie keine Begründung beinhalten. Sicherlich kann man I2C für viele Teilnehmer auf einem Board verwenden wenn die Gesamtkapazität getrieben werden kann (das ist übrigens eine Begründung). Lange Leitungen sind absolut nicht empfehlenswert da der Bus (diese zwei Open-Drain und Pullup-getriebenen Leitungen) sehr empfindlich auf äussere Stör-Einstreuungen ist. So kann "ein Störer" sowohl Start/Stop Konditionen auslösen als auch mitten im Datentransfer Pegel oder Flanken versauen und damit die I2C-Kommunikation zum Aufhängen bringen oder wertlos (da fehlerbehaftet) machen.
Weingut P. schrieb: > I2C ist zwar vom Ursprung auf Leiterplatte vorgesehen, kann > aber auch deutlich länger verwendet werden Kann ich bestätigen. Bei mir ca. 1m aber mit Bus-Treibern, welche 400pF treiben können. Das Läuft mit 25kHz seit Jahren stabil
Dergute W. schrieb: > Ja, klar kann's sein, dass sowas auch in Einzelfaellen funktioniert. Man > kann auch Leberkaes' auf einem Buegeleisen braten oder Wuerstchen mit > einer Kaffeemaschine heiss machen. Kann für ein Bastelprojekt in Ordnung sein, besonders wenn man "beliebig" mit der Datenrate zurück gehen kann. Aber nicht umsonst werden solche Busse anders gestrickt und ich würde mir die Sache so nicht antun! Trotzdem wünsche ich Spass und Erfolg... Gruß Rainer
> Kann für ein Bastelprojekt in Ordnung sein, besonders wenn man
Wenn ich lese "Steuerung Beregnungsanlage" dann klingt das fuer mich
nach draussen, lange Leitung, Feuchtigkeit, Potentialdifferenz beim
naechsten Gewitter in der Naehe. Man muss da schon mit dem Klammerbeutel
gepudert sein um dann noch I2C zu nutzen. Erst recht wenn man noch
Anfaenger ist der selbst banalste Sachen nicht beruecksichtigt (z.B
Hardwaretimeout fuer Ventile) und sich dann alles unter Wasser setzt.
Olaf
p.s: Wer sich jetzt fragt was Hardwaretimeout bedeutet, (shame on you)
vor jedes Ventil das irgendwas gefaehrliches einschaltet kommt ein
retriggerbares Monoflop. Wenn dann die Steuerung ihr Ein-Kommando nicht
regelmaessig einmal pro Sekunde sendet z.B weil sie defekt ist oder sie
Software abgekackt ist, dann laeuft das Wasser nur fuer 1s, eine Heizung
ist nur kurz aktiviert und nicht fuer immer.
12 Teilnehmer mit jeweils (bis zu) 50cm Leitung macht zusammen 6 Meter. Dafür ist I²C nicht ausgelegt. Ich würde auch zu RS-485 raten. Bei Chip45 kannst du ganz ähnliche Board wie Arduino nano kaufen, wo RS-485 Treiber schon drauf sind. Die sind gerade im Sonderangebot: https://www.chip45.com/atmega644-usb-rs485-modul.html?language=de
Olaf schrieb: > Wenn ich lese "Steuerung Beregnungsanlage" dann klingt das fuer mich > nach draussen, lange Leitung, Feuchtigkeit, Potentialdifferenz beim > naechsten Gewitter in der Naehe. Man muss da schon mit dem Klammerbeutel > gepudert sein um dann noch I2C zu nutzen. +1 So sieht es nun mal aus. I2C kann hier funktionieren, aber warum will man das unbedingt ausprobieren? Es gibt so viele andere und von vorn herein bessere Möglichkeiten.
Ich würde das ganz anders machen. Ich würde jeden Nano ein 433 mhz Set verpassen. Dann jeden Nano ein CODE zuweisen. Dann einfach eine Loop-Schleife machen und wenn der Nano SEINEN Code "hört" soll er machen was ihn der Code sagt. An NANO 13 (hoffe der bringt kein Unglück) kommt ein 1404 Display (20 Zeichen x 4 Zeilen) und eine schöne Tastatur. Damit kann ich dann die Programme einstellen mit den Befehlen die er an Nano 1-12 senden soll. Und wenn ich an einige Nanos noch Feuchtigkeitsmelder anschließe (Die die aussehen wie ein V) können die an BOSS-Nano zurückmelden das es Zeit ist den andern Nanos zu sagen sie sollen was machen. ;) Der Vorteil ist, das alle Nanos Autak arbeiten. Je nach gewünschter Leistung (Programme, Zeitsteuerungen etc.) könnte es aber passieren das BOSS-Nano was klein wird im Speicher. Dann würde ich ihn gegen ein 2560 austauschen. Da ich vergesslich bin, aber auch kein Garten habe, werde ich so eine Bewässerungsanlage diesen Sommer selbst bauen, für meine Blumenkästen damit mir nicht wieder meine Kräuter verdursten.
I2C hat halt den Charme nicht unbedingt mit Quarz arbeiten zu müssen, da Timing unkritisch (Baudrate), keinen zusätzlichen Pegelwandler zu benötigen, fertige Devices dazu zu klemmen zu können ohne eigene Logik (z.B. LM75)
Hallo, erst einmal vielen Dank für diese Menge an Antworten. Diese werde ich erst einmal durcharbeiten. Ich habe fast Sorge, dass da noch mehr Fragen bei mir aufpoppen werden. Viele Grüße aus Berlin
Weinbauer schrieb: > I2C hat halt den Charme nicht unbedingt mit Quarz arbeiten zu müssen, da > Timing unkritisch (Baudrate), keinen zusätzlichen Pegelwandler zu > benötigen, fertige Devices dazu zu klemmen zu können ohne eigene Logik > (z.B. LM75) Also die meisten moderneren Controller können heute UART auch ohne externen Quarz. Deren RC Oszillatoren sind entweder genau genug kalibriert oder können zumindest abgeglichen werden. Abgesehen davon weiß ich auch nicht warum die Verwendung eines ext. Quarzes jetzt ein Showstopper sein sollte. Wem tut das weh? Das ist die lahmste Ausrede die man sich vorstellen kann. Die Wahrheit, wie du auch andeutest, lautet: Faulheit.
:
Bearbeitet durch User
> I2C hat halt den Charme nicht unbedingt mit Quarz arbeiten zu müssen, da > Timing unkritisch (Baudrate), Mal abgesehen davon das heute viele Microcontroller einen RC-Oszillator haben der genau genug ist um RS232 brauchbar zu betreiben, wenn man sich noch nicht mal einen Quarz leisten kann ist eh alles zu spaet. > keinen zusätzlichen Pegelwandler zu benötigen, Man braucht die Pegelwandler bei RS232, RS422, RS485 nicht weil sie fuer die serielle Verbindung notwendig sind sondern weil sie fuer die zuverlaessige Uebertragung ueber mehrere Meter notwendig sind. Und diese Bausteine sind die absolut unverzichtbare Mindestvoraussetzung. Im industriellen Umfeld hast du selbstverstaendlich noch einen Transientenschutz und Potentialtrennung. Und das bauen wir da nicht ein weil wir Langeweile haben oder weil die Geraete damit billiger werden, nein einfach weil es notwendig ist. Hier sind doch sonst immer alle schnell dabei ueber irgendwelche Geraete zu laestern, alles auch China scheisse zu finden, aber den eigenen Kram aus Faulheit/Unfaehigkeit noch 100x grottiger zu bauen und das okay zu finden geht in Ordnung? Einfach nur weil geht ja von 12 bis Mittags? Olaf
Olaf schrieb: > Hier sind doch sonst immer alle schnell dabei ueber irgendwelche Geraete > zu laestern, alles auch China scheisse zu finden, aber den eigenen Kram > aus Faulheit/Unfaehigkeit noch 100x grottiger zu bauen und das okay zu > finden geht in Ordnung? Einfach nur weil geht ja von 12 bis Mittags? Mir ist leider auch schon aufgefallen, dass das Forum grundlegenden Pfusch sehr ausdauernd verteidigt. Letztens erst wieder im TSOP Löt-Thread. Da wird auf Teufel komm raus, jede Pfusch-Methode hochgehalten und für die sauberste und einfachste Lösung bekommt man Unflätigkeiten. Auch bei SW kann man das täglich sehen. Redundanter Pfusch Code wird hochgelobt, Beispiele wie man sauber arbeiten könnte werden verspottet. Pfusch wird hier hoch gehandelt. Ob das mit der hohen Ossi-Dichte korreliert? Man weiß es nicht. Aber es erschreckt doch ein wenig. Weil eben die guten Lösungen nicht unbedingt aufwendiger sind. Vor allem nicht in der Gesamtbetrachtung.
> Pfusch wird hier hoch gehandelt. Ob das mit der hohen Ossi-Dichte > korreliert? Man weiß es nicht. Ich denke da redest du dir was ein. Zumal man daraus ja auch wer weiss was ableiten koennte. Stell dir mal vor es gaebe hier eine hohe Ossidichte und der Grund dafuer ist das die noch schreiben koennen, waehrend die Wessis eher auf dem Level von Podcasts angekommen sind. :-) Olaf
Hallo Andreas, ich arbeite privat am einem ähnlichen Projekt. Allerdings sind meine Ventilkästen über den Garten verteilt, so dass mein CAN-Bus 350m lang ist. Bei mir sind die Identitäten im Eeprom hinterlegt. Eine nette Spielerei bei mir ist ein Firmware-Upload über CAN. Mal sehen wie lange es hält ... LG, Sebastian
Meine Güte, der TO schrieb von seinen ersten Gehversuchen per Arduino, der hat eben von Haus aus keinen Pegelwandler on Board, ob er im Stande ist ne Platine zu basteln mit Pegelwandler weißt weder Du noch ich und dann ziehst Du die Nummer mit Industrieanwendung auf? ... Lass den/die doch mal erst gehen lernen, zum Marathon gehts dann erst später, deutlich später. Man KANN die Takte abgleichen, aber weißt Du ob der TO das kann? Der Arduino in der ATMega-Ausführung hat 8 oder 16 MHz Quarz, also auch keinen Baudratenquarz, solange die dann unter sich bleiben kein Problem, hängt der TO aber n USB-RS485-Pegelwandler dran kann das unschön werden. Und ich bin WESSI, ist mir aber auch wurst, ich finde es gut wenn sich jemand in neues Terrain wagt und dort seine Kenntnisse selbst erarbeitet und knobelt und bügel den nicht mit Industriestandard 9873193-schlagmichtot zu. Das hat nichts mit Pfusch, sondern mit Lernen zu tun, Schritt für Schritt.
Angehängte Dateien:
-
nw1.png
54 KB
Ich würde mir mal NMEA-0183 (basiert auf EIA RS422) anschauen. Gibts fertige Parser für, ist aber auch 'n Klacks zu programmieren Ganz witzig könnet auch "SP-Netz" sein. Geht auf Altmeister Rolf-Dieter Klein zurück und wurde in mc 4+5/1983 (also noch in der 8080-Zeit) beschrieben. just my 2ct
heinz schrieb: > Weingut P. schrieb: > >> I2C ist zwar vom Ursprung auf Leiterplatte vorgesehen, kann >> aber auch deutlich länger verwendet werden > > Kann ich bestätigen. Bei mir ca. 1m aber mit Bus-Treibern, welche 400pF > treiben können. Das Läuft mit 25kHz seit Jahren stabil Hallo Heinz, das Problem beim I2C ist nicht der Treiber, es ist der Pullup-Widerstand. Einfach einmal das Signal SDA am Oszi ansehen. Der Übergang High-Low ist eine scharfe Ecke, weil der Open-Drain-Transistor 20..50mA ziehen kann und damit die Kabelkapazität entladen kann, die 5mA die er gegen den Pullup treiben muss fallen da kaum ins Gewicht. Anders bei der Low-High-"Flanke". Da ist es der arme Pullup-Widerstand, der bei 1k und 5V anfangs 5mA, aber mit steigendem Pegel immer weniger in das Kabel leiten kann. Das Signal zeigt am Oszi eine Ladekurve. Nun die Zeit heilt alle Wunden, jetzt kann man an der Timebase vom Oszi drehen und die Kurve wird wieder zum Eck. Oder anders ausgedrückt, wenn man sich mit den Bits viel Zeit lässt, ist dieser Umstand akzeptabel. Open Collector, Open Drain, Wired Or, funktionieren gut, sind billig wenn der Übergang Low-High zeitlich keine große Rolle spielt (lowaktive Alarmsignale wie Int, Reset...).
Andreas Q. schrieb: > Also dann eine Steuerung für > unsere Beregnungsanlage... > Da habe ich 12 Kanäle die individuell programmierbar sind mit 12 > identischen Nanos. Ich hinterfrage das Projekt bereits hier. Warum 12 verschiedene Nanos? Viel mehr als Magnet auf/zu machen die doch nicht. Ich habe so ein Projekt auch mal geplant, mein Ansatz war ein Mikrocontroller im Keller. Entweder einen, der 12 Pins frei hat oder halt noch ein Shift-Register dran. Darüber dann diese typischen China-Relaiskarten steuern, aber bitte mit 24V Ventilen und nicht 230V. Dann hat Deine Gattin länger was von Dir... Mein Projekt ist übrigens gescheitert. Nicht an der Elektronik, sondern an ganz praktischen Fragen. Die Rohrverbinder bekam ich nie ganz dicht beim Testen. Wie sollte ich das Rohrnetz im Winter entleeren? Frostfreie Verlegung 80cm tief scheidet aus ohne Bagger. Anschluss einer solchen Anlage ans Trinkwassernetz verbieten die Stadtwerke. Was tun, wenn ein Ventil hängt? Mein gut laufendes Fallback ist Gattin mit Gießkanne. Dein Setup klingt nach einer sehr komplexen und verbastelten Integration. Außer Dir kann das niemand bedienen und warten. Wie willst Du das Verhalten programmieren? Wie den Zustand administrieren? Wenn Du einen Programmierfehler machst, ein Bauteil korrodiert etc., dann hängt die ganze Anlage. Das wird die Inbetriebnahme nicht lange überleben, fürchte ich. Ich würde mehr mit Standardbauteilen arbeiten, die nur lose gekoppelt sind (Sonoff, Shelly...) und sich leicht austauschen lassen. Elektronik würde ich im Haus lassen und draußen nur Ventile arbeiten lassen. Hast Du einen Server, auf dem die Logik laufen könnte? Dann könntest Du da mit OpenHAB, FHEM etc zaubern. Z.B. Wetterbericht berücksichtigen bei der Planung, Gießprogramm programmieren und visualisieren. Kommunikation über MQTT-Protokoll auf LAN oder WLAN. Die Software gibt es bereits, stabil und kostenlos. Recht einfach wäre auch ein Raspberry Zero ohne alles drum und dran. Der kann alle Ventile steuern und auch einen WebServer hosten zum Administrieren.
Andreas Q. schrieb: >ob eine Info anliegt Welche könnte das sein? "Ich lebe noch" , "Ventil offen" ? Der Master eignet sich gut dazu alle Slaves mit Uhrzeit und Bewässerungsparametern zu versorgen. Wenn welche geändert werden. "Schlafen" die Slaves die meißte Zeit? Oder sind sie durchgehend aktiv? Nicht das der Master denkt sie wären ausgefallen nur weil sie erst geweckt wurden. Das ist wichtig Protokoll zu entwickeln. Da wäre es einfach die Slaves z.B. das Verhalten einer RTC (DS1307 o.ä.) beizubringen. Datum und Uhrzeit sind da schon drin und die anderen Werte (ID, Status, Zeiten) könnten darüber abgelegt werden.
:
Bearbeitet durch User
Du kommst aus Berlin? Kann dir da was zum I2C Bus mit vielen Teilen zeigen. LG Heinz
Olaf schrieb: > Und das bauen wir da nicht ein weil wir Langeweile haben oder weil die > Geraete damit billiger werden, nein einfach weil es notwendig ist. Hi, Olaf, Andere, Das liegt daran dass hier in diesem Forum geschätzt 80% Hobbyisten unterwegs sind. Allerdings haben einige derer die unangenehme Eigenschaft, professionelle Beiträge von Leuten die das beruflich machen, niederzubrüllen. Bei manchen Beleidigungen kommt man sich vor, als hätte man es mit pupertierenden 15jährigen zu tun. Wenn ich dann persönlich angegangen werde, ziehe ich mich einfach zurück. Für den Threat-Eröffner ist das schade, weil er nichts lernt. Übrig bleiben dann die Bastellösungen. Und ich spreche jetzt nicht von den Superduper-Industrielösungen. Oft werden kleine Verbesserungen schon als übertrieben dargestellt. Der TO könnte ja gerne dann überlegen, welche Vorschläge er weiter verfolgt. Aber dass Dritte die Beiträge anderer Dritter als Müll abwerten, geht gar nicht.
Wie von vielen anderen schon angemerkt, die Anzahl an Teilnehmern ist für I2C nicht das Problem, sondern eher die Strecke. Ich habe für den Arduino mal RS485 Aufsteckboards gesehen, dazu sollte es bestimmt auch noch passende Bibliotheken geben, die das vereinfachen. Damit sollte es auch für Anfänger nicht schwer sein. Wünsche dir weiterhin viel Spaß an dem Projekt =^.^=
小さな猫の女の子 schrieb: > Wie von vielen anderen schon angemerkt, die Anzahl an Teilnehmern ist > für I2C nicht das Problem, sondern eher die Strecke. Leider hat der TO nicht über die Örtlichkeit gesagt, an der die ganze Geschichte installiert werden soll. Bei meinen VIEL kleinere geplanten Projekt werden 2 Blumenkästen mit Wasser versorgt was eine Mini-Pumpe aus einen großen Putzeimer hoch pumpt. Das ganze liegt relativ geschützt entweder auf den Balkon o. die 2. Anlage in meinen Arbeitszimmer auf der Fensterbank. Wenn Teile der Anlage des TO außen sind, wobei ich bei 12 Nanos mal ausgehe, halte ich eine Verkabelung grundsätzlich für falsch. Grund : Sie ist zu teuer da man sie Witterungsunempfindlich machen muss. Und selbst in der Wohnung ist sie einfach nur aufwendig und hässlich. Weshalb mein Vorschlag via Funk (433 Mhz o. Wlan falls ESP) sinnvoller ist. ALLE Nano arbeiten autak. Die Zentrale kann ihre Funktionstüchtigkeit bis zu ein gewissen Punkt überprüfen. Die Fehlersuche ist um Faktor 10 einfacher. Und die Probleme mit den i2c Signal sind auch nicht vorhanden. Fakt ist einfach. Ich liebe I2C. Aber nur via sehr kurzer (max. 15 cm) Strecke. Das ist einfach die max. Entfernung der Platine zum Display wenn ich beides in ein Gehäuse baue. Wobei sich da gerade die 2 Frage stellt. Was machen die 12 Nanos eigentlich. ?? Sind sie mit Boden-/Feuchtigkeitssensoren ausgestattet um einen Rückmeldung zu geben. Wenn ja, wie will der TO über i2C diese Daten empfangen. Ich frage das ernsthaft, da ich das nie gemacht habe. Über Funk würde ich einfach folgendes senden. Bodensensor 1 x pro Stunde abfragen und die Daten so senden Als Klartext sogar. ;) Nano 4 --- Bodenfeuchte 42 % --- Code 43251254 Den Code errechne ich mit einen Schlüssel jedes mal neu. Der BOSS-NANO weiß dann das an der Stelle wo Nano 4 ist, der Boden noch relativ gut ist. Den Rest macht dann das individuelle Programm was in BOSS-NANO eingestellt ist. Ach und nur so nebenbei. Ich gehe davon aus das alles mit kleiner 24 Volt läuft. Ansonsten wären mir die Shellys sicherer. Muss man dann bloss außen sicher einpacken.
小さな猫の女の子 schrieb: > die Anzahl an Teilnehmern ist > für I2C nicht das Problem, sondern eher die Strecke. Und auch die nicht vorhandene Fehlertoleranz. I²C ist eben nicht dafür gemacht, einen Fehlimpuls wegzustecken. Im günstigsten Fall bleibt der Bus stecken und im ungünstigsten Fall muss man die Teilnehmer neu starten. Es gibt Recovery Routinen, aber man muss auch erstmal erkennen, das der Bus hängt. Und wenn ein Teilnehmer SCL dauerhaft auf Low zieht, weil er Amok läuft, gibts nichts anderes als den Neustart. Am besten führt man also eine Reset Leitung mit zu den Teilnehmern.
Hallo, jetzt kann ich mich mal endlich zu Wort melden. So viele Beiträge habe ich nicht erwartet und vor allem nicht, dass sich derartig die Geister scheiden können. Erst einmal vielen Dank für jeden Beitrag, aber es ist dann doch so, dass ich finde, dass einige ihre Meinung recht absolut vertreten. Natürlich, und ich dachte, dass ergibt sich aus dem Kontext meiner Frage, bin ich mit dem Arduino ein Anfänger. Und die weltbewegende Aufgabe einer Programmierung einer Gartenbewässerung spricht ja wohl auch für sich. Nur finde ich ein Lernen über den Nachbau fertiger Beispiele nicht sehr zielführend und kämpfe mich lieber durch die Probleme welche in der Praxis auftauchen. Na klar könnte man bestimmte Sachen gleich perfekt machen, aber muss man das hier wirklich? So umgehe ich Probleme die ich nie kennen und lösen lerne und die mich dann vielleicht eiskalt woanders einholen. Natürlich ist es ja auch ein Grund für meine Frage andere gangbare und wahrscheinlich bessere Wege aufgezeigt zu bekommen. Für mich habe aber festgestellt das einige Lösungen doch etwas overacted wären. Das Projekt ist doch just for fun und sollte es nicht funktionieren kann ich auf Grund einer sehr modularen Aufbaus viele Sachen korrigieren. Im schlimmsten Fall funktionierts einfach nicht und Plan B (Ehefrau) dreht an den Ventilen. Konkret noch einmal zu meinem Projekt: Die Bewässerungsanlage existiert seit vielen Jahren, muss aber zur Zeit händisch bedient werden. Die (noch Hand-) Ventile befinden sich alle an einer Stelle. In unmittelbarer Nähe ist dann eine geschützte Installation meiner kompletten Anlage möglich. D.h. Kabellängen existieren eigentlich nur theoretisch und dann im 12V Bereich. Die 50cm Leitungslänge für den i2s ergeben sich eigentlich nur aus den Leiterbahnen und der Verdrahtung von einigen Platinen auf denen die Arduinos mittels kleiner Shields stecken. Insgesamt sind dann 14 Nanos und ein Mega zu Gange. Das ist zum einen dem modularem Aufbau als auch der Komplexität der Steuerung geschuldet - sowas wie hardwaremäßige Objektprogrammierung. (bei den Nanos sind fast alle Pins belegt). Des weiteren ist eine Fehlersuche dann manchmal auch mit einem Multimeter möglich. Sensoren habe ich nur der übergeordneten Steuerung zugeordnet, da ich denke, wenn es vor dem Haus regnet dann regnet es auch hinterm Haus. Bodenfeuchtigkeit usw. werden nur grob erfasst. Wozu auch - ich habe doch nur Sträucher und Gras, äh Rasen und keine Orchideenzucht. So werde ich beim i2C bleiben. Wo ich dann noch mal zu meiner 2. Frage komme. Der Master (ist ja auch interessant was da für Diskussionen wegen dieser Begriffe laufen) fragt ja regelmäßig bei den 12 Slaves an ob einer eine aktualisierte Info hat (Änderung Laufzeit 1 Laufzeit 2 Ventilstellung usw.). Eine Änderung die an einem der 12 Kanäle Kanal gerade vorgenommen wird soll möglichst zeitnah mit einem konkretem Wert im Display angezeigt werden. Ist es dann besser des Display nicht auch noch am i2C zu hängen, um diese Kommunikation nicht auszubremsen oder ist das kaum spürbar? Über meine 3. Frage ärgere ich etwas- da hätte ich wohl auch selber erkennen dürfen. Und nach soviel Text noch eine neue Frage, die hoffentlich nicht genauso blöd ist. Um die Infos aus den Slaves für das Display aufzubereiten möchte ich Textbausteine verwenden. Jetzt habe ich mal ein zweidimensionales byte Array [40][20] deklariert und mit Zufallsinhalt gefüllt. Nach dem Kompilieren wird mir ein unveränderter Speicherplatz im Nano angezeigt. Ich dachte eigentlich, dass mir dann ca. 8000 Bytes weniger zur Verfügung stehen sollten. Wo ist da mein Denkfehler? Vielen Dank an die die bis jetzt durchgehalten haben. Einen schönen Sonntag Andreas aus Berlin Entschuldigung an alle auf deren Tipps und Vorschläge ich nicht persönlich eingegangen bin.
Andreas Q. schrieb: > Die 50cm Leitungslänge für den i2s ergeben sich eigentlich nur aus den > Leiterbahnen und der Verdrahtung von einigen Platinen auf denen die > Arduinos mittels kleiner Shields stecken. Insgesamt sind dann 14 Nanos > und ein Mega zu Gange. Das ist zum einen dem modularem Aufbau als auch > der Komplexität der Steuerung geschuldet Eine schöne Bastelei! Mir stellt sich jetzt lediglich die Frage, wozu du 14 Nano brauchst, wenn doch die ganze Hardware quasi auf einem "Haufen" im Umkreis von ca. 50cm sitzt. Trotzdem sind alle Ports der Nanos belegt. Was ist denn da dran?Hast du überall noch Sensoren verteilt, die über Nanos mit den Nanos "zu Hause" sprechen? Du siehst, dass ich mir den ganzen Aufbau nicht recht vorstellen kann. Vielleicht bin ich ja der Einzige... Gruß Rainer
Andreas Q. schrieb: > Jetzt habe ich > mal ein zweidimensionales byte Array [40][20] deklariert und mit > Zufallsinhalt gefüllt. Wenns nicht benutzt wird, merkt das der Compiler und schmeisst es raus.
Matthias S. schrieb: > Wenns nicht benutzt wird, merkt das der Compiler und schmeisst es raus. Darauf wäre ich wirklich nicht gekommen, werde mal eine sinnlose Funktion einbauen- Danke Rainer V. schrieb: > Eine schöne Bastelei!... Ja ist es wirklich aber ich wollte ein Rundumpaket schnüren. Nur falls das wirklich von Interesse ist: Alle Slaves hängen in Reihe - wenn einer fertig ist gibt er das Startsignal an den Nächsten weiter der, wenn aktiv, mit seiner eigenen Zeit sein Ventil schaltet. Ein Startmöglichkeit ist über Timer (Urlaub) oder über eine separat einstellbare Schleife mit manuellen Start. Außerdem kann man jedes Ventil noch einfach an/aus schalten. d.h. jeder Kanal hat 3 Taster (Timer, manuell, direkt an/aus), 2 Potis für die Zeiteinstellungen (Timer, manuell), 3 LED die den jeweiligen Zustand der 3 Möglichkeiten darstellen, Ventilansteuerung, 2 x i2C, Startsignal, Done-Signal und ein Pin für den Key, der über einen Spannungsteiler, der auf der Platine sitzt, eingepflegt wird. Dazu kommt noch die Möglichkeit einer manuelle Pause und ein manuelles "Next"-Signal. Des weiteren noch ein Puls damit die LED's aller Slave, wenn sie blinken, dieses gleichmäßig machen und nicht eine Lichtorgel nachäffen. Sind wir schon bei 17 Pins. 0 und 1 benutze ich nur im Notfall also fast voll belegt. Der 13. Nano für Display mit Menüführung, der 14. für die übergeordnete Bedienung. Am Mega hängen die Sensoren mit ihren eigenen Einstellmöglichkeiten, ein weiteres Display für die Timerprogrammierung, die Taster deren Menüführung usw. Mehr schreibe ich sicherheitshalber nicht, damit ihr mir keinen Arzt auf den Hals hetzt. Alles zusammen hätte ich alternativ mit 3 Mega oder evtl. auch mit einem und etlichen Multiplexern bauen können. Das hätte ich aber bei einer Fehlersuche mit Sicherheit nie in den Griff bekommen. So habe ich einen modularen Aufbau in dem den ich einzelne Komponenten prüfen kann und halbwegs eine Kontrolle der Signalwege haben. Und falls die Frage auftaucht - nein ich wollte keine Bedienung über einen Touchscreen o.ä.. Auf meinem Display erkennt man auf eine Blick was alle 12 Kanäle machen. Wenn man etwas einstellen will geht alles mit einem Griff, ohne eine Menüführung mit gefühlt 100 Ebenen. Danke noch einmal an alle Andreas aus Berlin
Andreas Q. schrieb: > Alles zusammen hätte ich alternativ mit 3 Mega oder evtl. auch mit einem > und etlichen Multiplexern bauen können. Das hätte ich aber bei einer > Fehlersuche mit Sicherheit nie in den Griff bekommen. 3 Mega sind zuviel, einer reicht dicke aus. Mit Material um sich zu schmeißen, bewirkt genau das Gegenteil. Alles wird nur unnötig komplex und die Fehlersuche zum Albtraum. Schon eine fehlersichere Vernetzung mehrere CPUs ist eine Wissenschaft für sich. Daran haben sich schon Generationen von Anfängern verhoben und das Projekt in die Tonne schmeißen müssen. Mehrere CPUs braucht man nur, wenn schnelle Echtzeit benötigt wird, z.B. das Ventil muß innerhalb 10µs öffnen, sonst vertrocknet die Pflanze. Die Erweiterung von IOs läßt sich viel bequemer mit dummen Erweiterungs-ICs machen (74HC595, 74HC165, PCF8574) bzw. Analogmuxer (74HC4051). Damit bleibt die gesamte Steuerung in einer Mainloop, d.h. schnell, sicher und einfach.
Peter D. schrieb: > Damit bleibt die gesamte Steuerung in einer Mainloop und ist viel einfacher auf nur EINER CPU zu debugen, als den Fehler irgendwo zu suchen!
Hi, danke für die Erläuterungen. Ist ein echtes Bastelprojekt und dementsprechend mußt du jetzt auch an den Problemen basteln. Z.B. daran, dass du 12 mal die "i2c" zum Laufen kriegen mußt. Genau genommen, hast du dir alle möglichen Probleme halt 12 mal auf den Hals geschafft und glaube mir, jede Lösung zählt prinzipiell erst mal genau einmal, auch wenn die anderen Teile exakt gleich scheinen. Also Mühe ohne Ende! Ich will dir das jetzt aber nicht ausreden, sondern rate dir, dir erst mal eine Teststrategie für die ganze Anlage zu überlegen...du mußt dir "sinnvolle" Teilaufgaben stricken, die gut geprüft werden können. Danach kannst du den Komplex vergrößern, wobei dir klar sein muß, dass Funktionierendes-A zusammen mit Funktionierendes-B nicht automatisch Funktionierendes-(A+B) sein wird! Trotzdem viel Spass und natürlich auch Erfolg! Gruß Rainer
Jain, bei Dir wird das wohl so sein, ich muss aber meine Möglichkeiten und meine Kenntnisse berücksichtigen. Im Grunde habe ich mein Vorhaben in 4 verschiedene Projekte gesplittet. Jedes ist für sich (mit kleinsten Hilfskonstruktionen) funktionsfähig und prüfbar. Die Verknüpfungen untereinander erfolgen mit nur einigen wenigen Verbindungen, welche ich gut unter Kontrolle habe. Bitte verstehe mich richtig, ich bin nicht unbelehrbar, aber der größte Teil ist fertig und jetzt noch einmal ganz von vorn anfangen - da bin ich wirklich nicht motiviert genug. Aber ich habe hier bereits viele Denkanstöße erhalten, die bei einem neuen Projekt (vielleicht ja sogar "Gartenwasser 2.0") sicher einfließen werden. Vielen Dank Andreas
Andreas Q. schrieb: > Im Grunde habe ich mein Vorhaben in 4 > verschiedene Projekte gesplittet. Jedes ist für sich (mit kleinsten > Hilfskonstruktionen) funktionsfähig und prüfbar. Die Verknüpfungen > untereinander erfolgen mit nur einigen wenigen Verbindungen, welche ich > gut unter Kontrolle habe. das wird jeder verstehen und das ist normal, aber! Andreas Q. schrieb: > jetzt noch einmal ganz von vorn anfangen - da bin > ich wirklich nicht motiviert genug. ist nicht hilfreich wenn das Konzept falsch war, man verzettelt sich und das Projekt steht sill. Falsche Konzepte die im "Kleinen" funktionieren können eben nicht beliebig vergrößert werden, dann bleibt nur übrig ein neues Konzept: Andreas Q. schrieb: > "Gartenwasser 2.0" beginnen, wenn das Konzept stimmig ist!
Moin, Andreas Q. schrieb: > Bitte verstehe mich richtig, ich bin nicht unbelehrbar, aber der größte > Teil ist fertig und jetzt noch einmal ganz von vorn anfangen - da bin > ich wirklich nicht motiviert genug. Also ich denk' mal, das kannst du natuerlich so machen, wie du Bock hast - auch ohne dich lange dafuer zu rechtfertigen. Es ist ja dein Projekt. Deshalb schrub ich z.b. ja auch weiter oben: " Ich wuerde nicht ...blabla..." und nicht: "Man darf auf keinen Fall ...blabla... und wer das trotzdem so macht ist voll doof". Gruss WK
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.