Hallo Irrlicht,
leider habe ich zur Zeit auch sehr wenig Zeit, deshalb liegen auch erst einmal meine ganzen Projekte auf Eis.
Bezüglich der Experimente: Da hatte ich eigentlich nicht vor, die komplett alleine zu machen und hatte gehofft, dass du auch eigene Test durchführst.
Ich melde mich wenn es was neues gibt. (Dauert aber noch etwas)
Gruß
Karsten
Eine im Modul eingespeicherte Adresse ist für mich eine fixe Adresse.
Für mich auch, aber ich würde ja auch nicht die Adresse speichern!!!
Ich würde die Position speichert (oder den Modultyp anpassen). Zwar ist diese dann fix und kann nicht geändert werden, aber die Adresse wird immer noch vom Buscontroller vergeben und somit gibt es keine Adress-Kollisionen.
Ja, aber wenn man es so macht, dass ein Controllermodul "ab Werk" Adresse Null hat, dann wird es problematisch, wenn ein zweiter Controller, auf einer zweiten Hutschiene, dazu kommt.
Meine Idee war, dass der Buscontroller / Busconnector /... halt 2 Adressen hat. Einmal die interne Adresse 0 und die exteren von einem übergeordneten Buscontroller vergebene Adresse.
Wenn Du auf Hausautomation setzt, kommt übrigens recht schnell ein rechtgroßer Adressraum zusammen. Anders als bei komplexen Modulen auf 'ner Hutschiene, wo man mit 8 Bit Adressraum richtig derbe viel machen kann. Aber wenn schon ein simpler Lichtschalter 'ne eigene Adresse bekommt, wird es rasch eng.
Bin daher am überlegen, ob wir den Adressraum nicht auf 16 Bit erweitern.
Ja das stimmt wohl, vorallem wenn man im Wohnzimmer so an die 10 Module problemlos verbauen kann 
Die Überlegung wäre da entweder die 16Bit-Adressen, wobei das natürlich aufwändiger bei der Abfrage ist, es müssen ja immerhin 2Byte ausgewertet werden. Als Alternative / oder zusätzlich kann man natürlich bei der Hausautomatisierung in jedem Stockwerk einen eigenen Subbus anlegen und da sollten 256 Adressen ausreichen (oder nicht?). Bei 10 Räumen pro Etage und 10 Modulen pro Raum wären das immer noch nur 100 Module / Adressen. Da aber nicht in jedem Raum 10Module sitzen sondern im Schnitt vielleicht so 5, wären das 50 Adressen. Die 8Bit könnten also für 5 Stockwerke reichen.
Wobei: Man sucht sich dämlich nach dem Fehler, wenn man einen Lichtschalter einbaut, der schon eine Adresse eingespeichert hat, die sich aber mit einem anderen Teilnehmer überschneidet und man vergisst die Taste zu betätigen.
Dafür könnte man dem Bus ja ein paar Diagnoseverfahren spendieren. Zum Beispiel alle Adressen ansprechen die vom Buscontroller vergeben wurden oder Auflistung aller angemeldeten Module (Das fehlende Modul ist dann für die Fehler zuständig). Man könnte aber auch eine Broadcast-Adresse vergeben, worüber man dann eine neue Initialisierung starten könnte.
Zu Deinen beiden Beispielen: "Programmierter Taster" vs. "Programmierter Buscontroller":
Ich würde notmalerweise die zweite Variante bevorzugen. Unter Vorbehalt des weiter unten Geschrienbenen.
Ja da würde ich auch den programmierten Buscontroller bevorzugen, dann kann man die Programme einfacher anpassen und muss nicht zu jedem Schalter/Schaltermodul rennen.
Bei der Hausautomatisation fallen wohl üblicherweise ohnehin keine großen Datenmengen an, schließlich arbeitet auch KNX mit 'ner lahmen Übertragungsrate.
Insofern kommen wir, mit unserem geilen 2,5MHz-Bus, niemals in Timing-Probleme.
Da muss sich natürlich zeigen, ob die 2,5MHz auch über längere Strecken problemlos möglich sind. Bzw. würde ich da die Geschwindigkeit anpassen wollen.
Wenn ich das richtig sehe, wäre das bei einer dezentralen Lösung anders?
Da kann, sobald der Schalter und die Lampe sich gegenseitig kennen, anschließend der Controller wegfallen?
Der wird also praktisch nur einmal, für die Adresszuweisung benötigt, ab
da laufen die anderen Teilnehmer autark, selbst wenn man den Controller
entfernt?Zugegeben, das hat was! Ist das echt so?
Im Grunde ist das so richtig, was natürlich dann nicht mehr funktioniert, wäre die Kommunikation über die Busgrenzen hinweg. Aber bei nur einem Bus ist der quasie wirklich überflüssig, hatte ich so noch garnicht drüber nach gedacht.
Wenn nicht, hätte ich persönlich Multimaster gerne vom Tisch und würde gerne alles über den Controller laufen lassen.
Man kann ja auch selbst beim Multimaster alles über einen Controller laufen lassen.
Was wir auch machen könnten, wäre eventuell die Auslegung des Busses für beide Betriebsweisen. Das kann man ja z.B. in die defines des HBUS-Dekoders einbauen, da braucht man das beim programmierne nur einstellen und schon läuft das entsprechend.
Was ich mich halt frage, bei Multimaster:
Angenommen, der Controller haut gerade richtig viel Daten an Module raus, die jeweils durch Rücksendung bestätigen.
Dann sind beide RS485-Wege permanent belegt.
Das stimmt natürlich, aber das kann dir auf deinem System auch passieren, wenn das Datenvolumen so groß wird, dass der Bus nicht ausreicht. Da ist dann der Programmierer an der Reihe und muss entweder das Volumen reduzieren oder einen neuen Subbus anlegen, um den jeweiligen Bus zu entlasten.
Wenn nun ein Schalter so Multimaster-mäßig direkt an einen anderen
Teilnehmer senden können soll, wird es wesentlich aufwändiger, mit der
Konfliktvermeidung. Es gibt halt nicht den einen (Controller), über über
das ganze Geschehen wacht und wie ein Verkehrspolitist den Verkehr
regelt.
Das hatte ich ja bereits erwähnt, dass das mit den Konflikten Probleme machen könnte.
Da muss also jeder Teilnehmer richtig viel Intelligenz mitbringen.
Das erschwert wiederum Firmware-Updates.
Was jetzt die Intelligenz mit Firmware-Updares zu tun hat, kann ich nicht nachvolziehen. Mir ist schon klar, dass bei mehr Intelligenz die Firmware größer wird, aber die Updates sollten doch immer gleich funktionieren, bzw deine HBUS-Decoder sind ja auch nicht gerade mit 3 Zeilen Code fertig oder?
Ich denke jetzt müssen wirklich erst mal Prototypen und Test her, um die Machbarkeit der ganzen Ideen zu überprüfen und dann schauen wir weiter. Sonst drehen wir uns ja doch nur im Kreis und sind nächstes Jahr noch am diskutieren ob Multimaster oder nicht, ... und wenn sich rausstellt, dass iergendwas nicht praktikabel ist, dann steht die Entscheidung ja schon fest.
EDIT: Endlich ist der Post fertig!!!
Bei allen Modulen, die an der Daisy-Chain hängen, kann so eine fixe Adresse problemlos vermieden werden.
Aber die Daisy-Chain reicht halt nicht weit, es sei denn, man setzt auch da RS485 ein. Aber das treibt den Aufwand wieder hoch.
Man könnte auch in den entfernten Modulen einfach die Position einspeichern, die sonst per Daisy-Chain übertragen worden wäre, dann ist wenigstens das Problem mit den festen Adressen aus der Welt.
Aber dazu müssen die beiden Controller bereits miteinander kommunizieren können.
Sprich: Die müssen die jeweilige Adresse des anderen kennen.
Woher?
Der Controller des Übergeordneten Busses hat doch bereits die Adresse 0, somit kann der von allen am Bus angeschlossenen Modulen (somit auch Buserweiterungsmodulen) angesprochen werden.
Ich gehe davon aus, dass ein Modul nur auf Aufforderung durch den Controller Daten sendet.
Ausnahme: Das erwähnte Nullbyte, das darf jedes Modul jederzeit senden - sofern der Bus gerade frei ist.
Das Problem ist aber genau das, dass du nicht feststellen kannst, ob der Bus frei ist.
Laut gedacht halt so: Der Bus ist im Ruhezustand hochohmig. In dem Moment, wo ein Modul sendet, ändert sich das. Das muss man detektieren können.
Obwohl mir gerade schwant, dass das wieder eine neue Fehlerquelle ist. Hochohmige (lediglich terminierte) Signale sind prinzipiell empfindlich.
Wegen RS485 zwar nicht so doll empfindlich, aber dennoch ...
Der Zustand des Busses müsste ja in dem Datenblatt deines RS485-Wandlers definiert sein.
Irgendwas vertüddeln wir jetzt. Du oder ich.
Wie soll das gehen, z.B. einen KNX-Teilnehmer direkt an den HBUS anzuklemmen?
KNX ist doch schon allein bedeutend lahmer, als der MoSteuS-Bus, mit seinen 2,5MHz Takt. Dazu können wir gar nicht direkt kompatibel sein, dafür wird immer ein spezielles Modul erforderlich sein.
Der einzige der von KNX redet bist du, ich habe nie erwähnt, dass ich für die Haussteuerung KNX-Teilnehmer einsetzen werde/möchte. Ich würde gerne eigene Module bauen, die auf meine Bedürfnisse zugeschnitten sind und die Idee war halt, die grundlegende Kommunikation identisch ist, damit HBUS-Module quasie ohne änderung (nur einwenig in der Software) an dem Hausbus eingestezt werden können (umgekehrt natürlich auch).
Dann ist das Verfahren ja doch nicht so ganz dezentral. Mindestens diesen ersten Befehl holt sich der Schalter vom Buscontroller. Erst ab da kann er multimastern, also jederzeit und an jeden Teilnehmer senden?
Also ich wüsste nicht, was die Diskussion über zentral und dezentral mit Multimasterbetrieb zu tuen hat?! Das sind doch völlig verschiedene Sachen.
Woher weiß die Lampe Nr. 27, dass sie auf den Schalter Nr. 18 reagieren soll, wenn man nichts zu programmieren braucht?
Natürlich geht es nicht ganz ohne programmieren. Dennoch ist es der Lampe egal, von wo sie den Befehl zum einschalten bekommt.
Hier zwei Beispiele (Annahme, die Lampe XY ist bereits am Bus angeschlossen und hat eine Adresse bekommen)
Bespiel programmierter Taster:
Beispiel programmierter Buscontroller
So wie ich das zur Zeit sehe, sollten wir jetzt erst ein paar Tests in der Realität durchführen, um zu überprüfen was machbar ist (und wie). Um anschließend genauer abschätzen zu können, welche Ideen Sinn machen und was nicht praktikabel ist.
EDIT: Was mir gerade noch bezüglich Daisy-Chain für externe Komponenten eingefallen ist, wäre ein Dais-Chain-Emulator. Darunter versehe ich Gerät, dass man an das externe Modul anschließen kann und was dann dem Modul den Daisy-Chain emuliert, also dem Modul die im Emulator eingestellte Position mitteilt. Danach ist das Modul dann in der Lage (Wie HBUS-Module) eine Adresse beim Buscontroller anzufordern.
Wenn auf der zweiten Schiene aber ein eigener Controller zum Einsatz kommt, der wiederum Herr in seinem "HBUS-Universum" ist, das wiederum bis zu 255 Module neben dem Controller erlaubt, dann muss jeder dieser Controller eine eigene Adresse haben, die im Adressraum des ersten Controllers enthalten sein muss.
Die kann der erste aber nur dann per Daisy-Chain zuweisen, wenn man eine entsprechend vieladrige Strippe zwischen beiden Schienen vorsieht.
Will man beide Schienen lediglich per Zweidraht- oder Vierdraht-RS485 abwickeln, dann muss der zweite, dritte, vierte ... Controller eine fixe Adresse bekommen, weil sie (mangels Daisy) anders nicht vom Hauptcontroller zugewiesen werden kann.
Wie du bereits vorher erwähnt hattest, könntest du ja daort auch Daisy-Chain über RS485 realisieren. Aber an sich benötigst du die Position ja nicht, du kannst ja auch Module adressieren, ohne das sie eine Position bekommen haben. Wenn du jetzt z.B. den Bus um eine Schiene erweiterst (die ein eigenes HBUS-Universum ist) dann kann man in der Software des neuen Hauptcontrollers dierekt einspeichern um welchen Hauptcontroller es sich handelt (Hauptcontroller Schiene 2) und der übergeordnete Bus weiß dann was sich dahinter verbirgt. Fixe Adressen sollten vermieden werden, da der jeweilige Hauptcontroller diese eventuell bereits vergeben hat.
Oder aus den angeschlossenen Modulen wird ein neuer Typ-Code generiert.
Damit meine ich, dass der Typ des Buscontrollers (zu übergeordneten Bus) von den angeschlossenen Modulen abhängt. Beispiel: hat die Einheit ein Display und eine Tastatur dann ist es eine Bedieneinheit, der Buscontroller ist nun vom "Typ" ein Bedienmodul. Sind nur Ausgabemodule angeschlossen ist der Buscontroller ein Ausgabemodul, ... (so in etwa jedenfalls) Wenn man nun davon ausgeht, dass keine Einheit identisch ist und somit dessen Typ auch verschieden, dann kann der übergeordnete Buscontroller an hand des Typs schon die Funktion erkennen und benötigt nicht zusätzlich noch die Position.
Aber das doppelte Versenden sorgt ja kaum für mehr Traffic, bei Vierdraht.
Die Daten von den Modulen zum Controller laufen über zwei Signalleitungen (nennen wir sie c & d).
Der Controller sendet Daten, die für ein anderes Modul bestimmt sind, dann über die Signalleitungen a & b zu dem jeweiligen Zielmodul.
Da wir bei Vierdraht Vollduplex fahren, erhöht sich nicht der Durchsatz auf einem Leitungspaar, gegenüber der multimasterfähingen Zweidraht-Version.
Wenn du davon ausgehst, dass du von Modul B daten empfangen kannst und gleichzeitig Daten an Modul C senden kannst?! In der Theorie sicher möglich, jedoch bezweifle ich, dass das im allgemeinen kollisionsfrei funktioniert, da die Module den Empfang auch teilweise bestätigen werden. Wenn die Module die Daten nicht bestätigen würden, dann wüsstest du garnicht, ob die Daten angekommen sind. Wenn aber das Modul C gerade alle Daten von A erhaltne hat und diese dann bestätigt, A aber gleichzeitig noch Daten von B abruft, dann kommt es zur Kollision!
Also Konflikte soll es überhaupt nicht geben können.
Das ist aber Wunschdenken oder? Na gut wenn du nur einen Master hast der immer nur mit einem Slave kommuniziert, dann klappt das.
Wenn ich es richtig sehe (hier bitte ich darum, mitzudenken und mich gegebenenfalls zu korrigieren), kann dabei nichts schief gehen, wenn mehrere Module zeitgleich oder zeitlich überlappend &h00 senden.
Das würde ich im allgemeinen mal als Falsch beurteilen, Wenn die Module genau gleichzeitig senden (nur wenige Takte versetzt) dann klappt das möglicherweise noch. Wenn die aber wirklich überlappend versendest, dann weiß ich nicht, wie der Controller das dan interpretiert, da das Signal ja dann auch eigentlich zu lang ist und du dir möglicherweise die Start und Stop-Bits "zerstörst". Das war jetzt aber nur für 00, was ist wenn ein Controller etwas anderes sendet? Dann überwiegt trotzdem die Null und du bekommst den Rest nicht mit. Des weitern kann das einzelne Modul nicht feststellen, ob gerade eine Datenübertragung stattfindet. Kollisionen sind da vorprogrammiert!!!
Mein Tip: Entweder Multimaster oder einen Master und dann mit polling (evtl ausgelöst durch ein seperates Signal)
Wer KNX-Nodes anschließen will, setzt halt ein KNX-Modul auf die Schiene und geht von da aus per Kabel zu den externen Nodes.
Ich dachte wir wollten die kompletten Busse identisch halten, damit man den HBUS einfach zu einem externen Modul verlängern kann (und da da sogar 4 Adern ausreichen) Desweiteren kann man die Module dann an eine beliebige Busebene anschließen. Natürlich könnte man auch protokoll umsetzer auf KNX bauen aber welchen Sinn hätte das? (Außerdem würdest du die sicher nicht bauen, da nicht benötigt und wer KNX einsetzt der wird wohl KNX einsetzen)
Ein Modul auf dem HBUS ist ein komplexes Ding. Ist nicht einfach ein Lichtschalter.
'Nen Lichtschalter möchte man einfach hinzufügen und unkompliziert mit 'ner bestimmten Lampe verheiraten.
Dann muss man halt der Lampe sagen, dass sie fortan auf den neuen Schalter reagieren soll.Auf dem HBUS sieht es anders aus. Da klemmt man den neuen Schalter an ein Modul.
Also ich sehe da keinen Unterschied oder denkst du bei der Hausinstallation nehme ich nen Schalter aus dem Baumarkt, schließe die beiden Busleitungen da an und fertig? Ne ne, da sitzt doch auch ein Modul zwischen wo der Schalter erst mal ran muss. Und die Lampe werde ich wohl auch nicht wegen einem Schalter von der Decke schrauben, warum auch der Schalter hohlt sich vom Buscontroller seinen Befehlt (Hier "Lampe-12 Ein/Aus" und fertig ist di Sache, da brauch man nix mehr programmieren)
Sorry, wenn ich vielleicht zu dämlich bin, die Vorteile von Multimaster zu erfassen. Dann kläre man mich bitte auf.
Also erstmal hat natürlich alles vor und Nachteile, möglicherweise überwiegen für dich zur Zeit die Nachteile vom Multimaster. Ich werde mal versuchen die Vor und Nachteile gegenüber einem System mit nur einem Master, aber seperat ausgeführtem Hin und Rückkanal beschreiben.
Vorteil
Nachteil
Wenn ich noch etwas vergessen habe, bitte ich um Benachrichtigung.
Hallo Irrlicht
Idee: Jeder weitere Bus ist aus Sicht des Hauptcontrollers ein einziges (halt sehr komplexes) Modul.
Nur müssen wir da die automatische Adresszuweisung per Daisy-Cahin
knicken, weil zweischen den Bussen u.U. dutzende Meter Leitung liegen.
Ein zweiter Bus muss also eine fixe Adresse erhalten, die im dortigen
Controller in der Software abgelegt wird, um DIP-Schalter zu vermeiden.
bei der Idee stimme ich mit dir überein. Bei der Adresszuweisung entsteht dann hal das Problem, was bei allen Hausinstallationen auftreten wird, die Lokalisierung. Jedoch muss das Verbindungsmodul nicht zwangsweise eine feste Adresse haben, die Zuweisung an sich kann ja auch wie auf dem HBUS funktionieren, nur dass der Modultyp/die Position entsprechend eingestellt werden müssen (im Code). Oder aus den angeschlossenen Modulen wird ein neuer Typ-Code generiert.
Also ich nenne es die ganze Zeit einfach HBUS, was die elektrische Seite betrifft.
Die Firmware für die HBUS-Decoder, also den ganzen Protokollkram, würde ich genauso nennen, wie das System: MoSteuS.
Die Bezeichnung HBUS kommt doch von deinen Verbindungsstecker. Wahrscheinlich habe ich mich unglücklich ausgedrückt, meinte eine Bezeichnung für das Bussystem über das externe Komponenten angeschlossen werden bzw das was minimal vorhanden sein muss (2x Signal, Vcc, Gnd) und das dazu gehörende Protokoll (was natürlich dann auch auf dem HBUS läuft. Des weiteren könnte es bei der Vermarktung unter dem Namen HBUS ja dann probleme geben, wenn die Bezeichnung auf dne Hersteller der Gehäuse eingetragen ist.
Der HBUS-Decoder tut 'ne ganze Menge.
Er entlastet den Anwender komplett von dem ganzen Protokollkram. Darum
kümmert sich der Decoder, wie ein Standard-IC mit fixer Funktion.Wer ein neues Modul entwickeln will, muss daher hardwareseitig einfach
die entsprechenden Leitungen des HBUS-Decoders anrouten und es passt.
Aus dem Teil mit den HBUS-Decodern halte ich mich wohl erst einmal raus. Weil:
Öh, letzter Stand war doch der, dass wir Vierdraht vorsehen, für RS485!?!
Bei 4-Draht RS485 ist aber kein Multimaster-Betrieb möglich. Multimaster-Betrieb bedeutet, dass jeder Teilnehmer von sich aus mit den anderen Kontakt aufnehmen kann. Es kann also jedes Modul an jedes andere Modul Daten senden.
Beispiel:
Modul A - Buscontroller
Modul B - Lauflichtmodul
Modul C - Ausgabemodul
Ablauf der Lauflichtdatenübertragung vom Lauflichtmodul zum Ausgabemodul
Version 1 - 1 Master (der Buscontroller ist Master)
Version 2 - Multimaster-Betrieb
Ich hoffe, dass das mit dem Multimaster jetzt für dich besser verständlich ist. Natürlich ist bei 3 Modulen der Bus noch recht überschaubar, bei 3 Lauflichtmodulen, 6 Ausgabe Modulen und einem Buscontroller sieht das aber schon anders aus, wenn alle Daten doppelt versendet werden müssen (erst zum Buscontroller und dann von dort zum jeweiligen Modul)
Wir müssen nochwas klären, bezüglich Interrupt und Konfliktvermeidung.
Was mir gerade noch für das Vermeiden von Konflikten einfällt, wäre das abfragen ob der Bus in den letzen x ms (oder ns) einen Flankenwechsel hatte.
Ja so ist das wenn man nicht alles hin schreibt was man denkt.
Ich hatte zusätzlich noch mit 50% Protokolloverhead gerechnet (worst case). Somit komme ich statt 80.000 Lampen halt nur auf 40.000 Lampen.
Irrlicht
Nun zu deinen letzten Posts
Ich gehe davon aus, dass der Controller, wenn es sich um einen AVR handelt, bis zum Anschlag ausgelastet ist, wenn er Daten mit 2,5MHz über den HBUS schaufelt.
Da sehe ich wenig Restpower, um noch einen zweiten Bus mit hoher Geschwindigkeit zu bedienen.
Insofern dürfte es wurscht sein, ob man die Busse trennt oder alle Daten über einen einzigen Bus peitscht.
... dann können diese Synchronisationsdaten doch im Datenstrom vom ersten HBUS enthalten sein!?!?
Das ist sicherlich möglich (einfach den 2.HBUS über einen Busconnector an den ersten hängen), jedoch muss dann der Controller auf dem 2. Bus den gesammten Verkehr auf dem ersten Bus mitlauschen
Wenn dessen UART, wie Pesi schon richtig feststellte, halt bei 2,5MHz seine Obergrenze hat, dann legt das halt die Obergrenze für den Datenstrom auf dem HBUS fest. Und damit ist der Controller praktisch ausgelastet, diese Datenmengen bereit zu stellen.
Im Hutschienenmodul sitzt halt immer die Grundplatine (ich nenne sie "Motherboard"), welche immer:
a) Die Schnittstellenverbinder zur Außenwelt bereit stellt. Also steckbare Klemmleisten und so.
b) Den aufgesteckten HBUS-Decoder enthält.
c) Den Verbinder zum HBUS enthält (zweireihige Pfostenleiste, von unten bestückt).
a und c sind klar, aber das mit dem HBUS-Decoder hab ich noch nicht so ganz verstanden. Klar die daten vom RS485 müssen iergendwie zu den Kontrollern auf den Karten im Modul, aber da reicht doch auch ein einfacher MAX485 und schon hast du nen UART?!
Wenn also der Begriff "Modul" fällt, sollte damit immer ein Hutschienenmodul gemeint sein, welches durchaus mehrere Platinen beinhalten kann, die dann aber halt "Erweiterungskarten" genannt werden sollten.
Gute Idee, wende ich bereits an ( Karte und Modul)
Wenn alles aus einem einzigen Netzteil gespeist wird, müsste gewährleistet sein, dass im Falle eines Kurzschlusses an externer Peripherie nur die Lastsicherung durchbrät, die Spannungsversorgung der Module aber weiterhin gewährleistet ist.
Einfach ein Einspeisemodul bauen, in dem die Sicherungen für die Leitungen sitzen. Bei Kritischen Modulen kann intern auch noch eine seperate Sicherung vorgesehen werden.
Die entscheidung zwischen Interrupt und Polling ist so eine Sache und Das ist ein wirklich schwieriges Thema, aber ich würde die ultimativ zeitkritischen Interrupt-Signale dann eher direkt dem Controller-Modul zuführen.
Alle "normalen" Interrupts, die auch etwas Aufschub verdauen können, dann halt per Protokoll im RS485-Datenstrom untergebracht.
Die Frage wäre sowieso wann solche Interrupts auftreten und wie zeitkritisch sie dann sind. Wenn man Sicherstell, dass der Bus alle paar 100ms mal frei ist dann sollte das auch ausreichend sein. Alternativ müssen die Karten so kombiniert werden, dass die Interrupts in dem Modul ausgewertet werden, in dem sie entstehen. (Auslösende und auswertende Karte in einem Modul unterbringen)
Ja, dickes Ding!
Das war so der erste Einfall, den ich äußerte. Tatsächlich muss ich mir das nochmal ansehen, wie das physikalisch aussieht, was der UART rausgibt und wie das dann auf den RS485-Leitungen aussieht. Möglicherweise geht das gar nicht.
Bei Wired-OR würde das ganz leicht gehen, aber bei RS232 vom UART auf RS485?
Entweder jedes Modul/jede Karte einzel poolen oder die Module selber senden lassen und zwar alle einzeln.
Streichen wir eines der beiden letztgenannten Signale, würde ich sagen.
Lass uns mit nur einem Interrupt-Signal arbeiten.
Wir müssen aber auch noch eine Reset-Leitung vorsehen.
Ein Signal wüsste ich noch:
Ein Output-Enable-Signal.
Wobei Output Enable bei bestimmten Modulen auch gewisse Ausgänge aktivieren könnte, für Beleuchtungsaktivierung im Notfall oä. (möglicherweise auch dierekt manuell bedienbar?)
Neue Belegung (11 Pole belegt):
Muss man nochmal überlegen, wie man damit umgeht, wenn man zwei
Subsysteme hat, also zwei getrennte Hutschienen, mit jeweils eigenem
Controller und diese Controller per RS485 untereinander kommunizieren.
Auf dem dem übergeordneten Bus sind sie einfach nur "normale" Module und haben somit auch von dem dortigen Buscontroller eigene Adressen zugewiesen bekommen.
Frage: Gehst Du davon aus, dass es im laufenden Betrieb hinzugesteckt wird?
- Ich nicht. Obwohl ich es gut fände, wenn das ginge.
War Anfangs davon ausgegangen, dass man das ja machen könnte. Aber selbst wenn man das nicht kann, ist es für das Modul kein unterschied, denn iergnedwann bekommt es Sannung und muss sich eine Adresse besorgen.
So ich habe mir in den letzten Tagen auch noch ein paar Gedanken gemacht.
Eine Datenübermittlung könnte so aussehen (wobei die Daten auch mehrere Byte groß sein könnten):
Ablauf der Adressierung
Vorschlag Adressanfrage:
Probleme und zu klärende Fragen:
Ok dann haben wir jetzt den HBUS und den externen Bus, beide Busse nutzen RS485.
Die Bussysteme sollten deshalb getrennt sein, damit wenn eine Einheit dauerhaft iergendwelche daten über den HBUS sendet (z.B: Ausgangsänderungen bei Lauflichtern) nicht das Gesamtsystem blockiert ist, bzw mehrere dieser Lauflichteiheiten vorhanden sein können und untereinander über den externen Bus vernetzt sind und sich so z.B. synchronisieren können. (wenn man natürlich nur ein externes Bedienpult anschließt und der HBUS nicht dauerhaft ausgelastet ist, würde es auch mit einem Bussystem funktionieren, jedoch gibt es einige Gründe dies trotzdem nicht zu realisieren)
Interessant ist, dass mein Bus-Connector-Modul dir zu teuer und zu aufwendig ist, du jedoch in jedes Modul einen HBUS-Dekoder einbauen willst. Des weiteren würde ich wenn dierekt den Bus-Connector in den jeweiligen Hauptcontroller des HBUSes integrieren.
Das mit der Spannungsversorgung über den HBUS wird schon Klappen, die Frage wäre halt ob 2 oder 3 Leitungen (jeweils für GND und VCC). Bei Größerer Last müsste man dann zwischeneinspeisungen einbauen. (eventuell bei 3 Leitungen eine nur für den Steuerungspfad reservieren, damit bei einem Fehler (Kurzschluss/Überlast) nicht die gesammte einheit nicht mehr erreichbar ist.
Die entscheidung zwischen Interrupt und Polling ist so eine Sache und ich würde mich da garnicht so dierekt festlegen. Würde beides vorsehen/integrieren (bedeutet 1-2 Leitungen für Interruptauswertung reservieren)
Zu der Adressverwaltung sollten wir uns dann mal noch näher gedanken zu machen, finde es schade dass die Daisy-Chain dann nur für die erstmalige Adressierung genutzt wird und danach nicht mehr.
Das mit den zeitversetzen Bits setzen könnte schwierig werden, dafür müssten die Controller sehr synchron laufen. Vorallem wenn du von mehr als 10 Modulen ausgehst sind das schon mehrere Byte, die nach etsprechender Spezifikation (mit Start und Stop-Bit oä.) übertragen werden müssen.
HBUS-Belegung
- VCC für Steuerung
- 2x VCC für Lastteil
- 3x GND
- 4 Leitungen für den eigentlichen Bus
- 2 reserviert für Interrupts oder Poolinganfragen (wenn die Leitung auf Masse liegt, werden alle relevanten Module gepoolt)
Die Adressierung würde ich so machen, dass der Hauptcontroller eine feste Adresse hat (wenn jeder Hauptcontroller die gleiche HBUS Adresse hat ist man beim Austausch der Module sehr flexibel).
Wenn ein Modul auf den Bus aufgesteckt wird, meldet es sich bei genau dieser Adresse (das neue Modul ist in diesem Fall der Master, der Hauptcontroller der Slave) und teilt dem Hauptcontroller mit um was für ein Modul es sich handelt und bekommt im Anschluss von dem Hauptkontroller eine Adresse übermittelt. Der Hauptkontroller kennt somit alle Module mit deren FUnktion und der jeweiligen Adresse. Ob diese Adresse auch bei Spannungsausfall im Modul gespeichert werden soll oder zurückgesetzt wird wäre zu überlegen bzw kann das während der Programmierung eingestellt werden. (bietet beides vor und Nachteile, bei der Speicherung benötigt das Modul dann jedoch so ein schönen RESET-Taster um die Adresse zu löschen)
So das war es erst einmal von meiner Seite
Gruß
Karsten
Hallo Irrlicht,
ja so hat jeder seine eigenen Definitionen, ich hatte mir das genau anders herum gedacht, dass der Hauptbus alle Einheiten verbindet und jede Einheit ihren eigenen Subbus hat. Bei deiner Anwendung mit nur einer "großen" Einheit ist dein System aber auch verständlich. Mein Vorschlag wäre daher den über den HBUS geführten Bus als Lokalbus und den für die Vernetzung der Moduleinheiten verwendeten Bus als Globalbus (Bezeichnung gefällt mir noch nicht) zu bezeichnen, so dass das für beide Anwendungen passt.
Natürlich ist auch RS485 möglich, wo bei das ja nix mit SPI / I2C zu tun hat, man könnte ja quasi einen SPI über RS485 realisieren. Alternativ gäbe es ja auch für I2C noch ICs um die Reichweite zu erhöhen. Außerdem ist der Bus ja nicht so extrem lang, da du ja keine 1m langen Hutschienen in deinen Schaltschrank setzen wirst (oder doch?). Zur Not müsste man die Einheiten dann kleiner wählen / trennen und über den Globalbus verbinden. Dann würde eine Einheit nur noch so aus 3-5 Modulen bestehen.
Zum scannen des Busses würde ich vorschlagen, dass das jedes Modul für sich macht. dann würde es auch möglich sein das System im laufenden Betrieb zu erweitern. Das würde in etwa so ablaufen, dass das Modul, wenn es auf den Bus gesteckt wird alle möglichen Adressen anpingt und wenn keine Antwort kommt diese Adresse dann übernimmt. (Gut bei über 100 möglichen Adressen dauert das ein wenig, aber das System kann man bestimmt noch optimieren) Oder das Modul fragt bei dem Hauptmodul/Adressverwaltungsmodul an, welche Adresse/Adressen noch frei sind. (beides erfordert jedoch den Multimaster-Betrieb, wäre jedoch auch für die Haussteuerung/den Globalbus geignet. Erinnert mich iergendwie an DHCP)
Die Daisy Chains würde ich für die Kommunikation zwischen nebeneinadner liegenden Modulen vorsehen, wenn diese nur zusammen funktionieren und z.B. eine schnelle Anbindung untereinander benötigen oder sich gegenseitig IO-Signale senden, z.B. für Interrupts. (Oder um einfach nur abzufragen, ob ein Nachbar vorhanden ist)
Der Hausbus sollte meiner Meinung nach mit maximal 4 Leitungen auskommen: GND, 5-24V (nur zur Versorgung der Steuerungen, nicht jedoch für die "Last"), Signal+ und Signal-
Der HBUS würde dann so aussehen (Teilweise von dir übernommen)
- 4 Signale für RS485/Bus
- Spannungsversorgung 5-24V (Spannungsregler auf jedem Modul, wobei bei 5V für Peripherie eher 8-24V nötig wären. Möglich wäre ja auch 2 Leitungen zu nehmen und einmal 5V und einmal 24V oder so (welchen Sinn das auch immer machen würde)
- Masse Leitung soviele wie Versorgungsleitungen, macht anders auch keinen Sinn. (bei 2x 12V also auch 2xGND)
- Die Daisy-Chains also für die Kommunikation zwischen benachbarten Modulen
Die Spannungsversorgung für externe Komponenten, z.B. SSRs würde ich an jedem Modul (das diese Versorgung benötigt) seperat anschließen.
Auch wäre bei mir nach maximal 10 Modulen sowieso Schluss, würde ja immerhin von der Länge einer Reihe von 40 Sicherungsautomaten entsprechen!
Mit den Interrupt-Signalen würde ich das so handhaben, dass wenn eine wichtige Übertragung nötig wird, das jeweilige Modul eine Gemeinsame Interrupt-Leitung auf Masse zieht, dann wissen alle Module bescheid, dass die aktuelle Kommunikation zu beenden ist. Anschließend muss das anfordernde Modul noch eine Bestätigung bekommen, dass es jetzt senden darf (es sei den man bekommt das über iergendwelche Pakete auf dem Bus gemanaged). Die Interrupt anforderung könnte man ja mit 12V/der Versorgungsspannung realisieren, damit geringe Störungen keine Auswirkungen daruf haben.
Somit wären jetzt 4+4+2=10 bzw. 4+6+2=12 (je nach Spannungsversorgung) durchkontaktierte Leitungen belegt
Hallo
nach überfliegen der MoStreuS-Threads, habe ich die angesprochenen Sachen auch einmal überdacht und Folgendes zusammengesponen. Ich hoffe, dass ich damit den Forderungen von allen gerecht werde. (Sowohl für die Beleuchtung von Karusells, als auch für die Hausautomatisierung)
Das Ganze ist natürlich noch nicht zu Ende gedacht.
Vorab:
- Es gibt zwei Bussysteme/-ebenen, den Hauptbus und den Subbus.
- Mehrere örtlich bei einander sitzende Module ergeben eine Moduleinheit.
Hauptbus:
- Multimasterfähig
-Verbindet die Moduleinheiten miteinander
- Kann als Hausbus verwendet werden
- Wird wahrscheinlich langsamer sein als der Subbus, dafür aber eine lange Reichweite haben
- Er ist für die Übermittlung weniger Daten ausgelegt (Steuerbefehle und ähnliches)
- Hier würde sich RS485 anbieten aber auch Ethernet und Funk wären zusätzlich denkbar
Subbus:
- Vernetzt die Module einer Moduleinheit untereinander
- Hat keine Verbindung zu anderen Moduleinheiten
- Hier würden sich SPI und/oder I2C anbieten
- Ist für ein hohes Datenvolumen ausgelegt
- Unabhängig vom Hauptbus
- Wird nur Räumlich begrenzt eingesetzt
- Hier würde der von Irrlich vorgeschlagene HBUS Anwendung finden
Modul
- Kann von jedem Nutzer nach seinen Bedürfnissen entwickelt werden
- Es sind beliebige Module möglich und auch die "Größe"/ der Funktionsumfang eines Moduls ist nicht begrenzt (Es kann sich dabei z.B. nur um eine Platine mit einem Controller handeln oder aber auch um ein mit Technik volgestopftes Gehäuse an dem mehrere Sensoren und Aktoren angeschlossen sind)
- Ist ein Teilsystem, dass über den Subbus mit den anderen Komponenten kommuniziert
Anmerkung: Die hier vorgestellten Module verstehen sich als Beispiele, des weiteren ist eine Zusammenfassung mehrerer der weiter untern vorgestellten Module denkbar.
Moduleinheit:
- Besteht aus mehreren Modulen die örtlich dicht bei einander sitzen und zusammenarbeiten (müssen)
- Eins der Module ist immer ein Bus-Connector-Modul
Bus-Connector-Modul
- Stellt die Verbindung zwischen Hauptbus und Subbus her
- Muss natürlich nicht als seperates Modul ausgeführt sein, sondern kann auch weitere Aufgaben übernehmen
Was mir gerade noch einfällt, wenn du vor hast, dass der Nutzer die Codes für seine FB programmieren kann, dann solltest du noch ne Überwachung oder Sperre einbauen, dass man einen FB-Code nicht doppelt nehmen kann. (bei einer FB)
EDIT:
turi: was genau meinst du mit Typisierung?
Danke für den Hinweis, habs geändert.
Wenn ich deinen Vorshclag richtig verstanden habe, dann würde ich das nicht machen, da durch das sortieren die Verbindung zwischen i und dem internen FB-Code verlohren geht. Das sortieren würde bedeuten, dass du die Zuweisung "command=i;", wie ich es in dem letzten Code gemacht habe nicht machen kannst, da die Codes ja quasie "durcheinander" sind und du müstest ein doppelt so großes array anlegen, damit du dann wieder die Zuweisung zum internen FB-Code hast.
Du kannst gerne deinen Vorschlag mal in C-Code hier posten, dann kann man das besser vergleichen/diskutieren.
Bei dem Mehrdimensionalen Array kommt es darauf an, ob man während der Systemzeit einen anderen Fernbedienungstyp auswählen möchte oder nicht. Anfangs höhrte es sich das so an, dass turi das vor hat. Somit kannst du nicht einfach sagen, dass das nicht notwendig ist. Wenn nur eine FB genutzt werden soll, hast du natürlich Recht, dass das nicht notwendig.
Hab den vorschlag von Pesi mal versucht in code umzusetzen:
// Befehl zurück setzen
command = 0;
// Auswerten des empfangenen Codes
for( i=1; i<= Maxcode; i++ )
{
if( recivedCode == fb[afb][i] )
{
command = i;
// um die Schleife schneller zu beenden ( nicht notwendig)
i = Maxcode;
}
}
// Hier folg dann die Auswertung von "command"Sieht eigentlich sehr kompakt aus die Lösung.
Also ich würde das mit If-Anweisungen realisieren, ungefähr so:
den auszuführenden Aktionen Nummern zuweisen:
#define Plus 1
#define Minus 2
#define Menu 3
#define Hoch 4
...
Array mit den entsprechenden Codes definieren, entweder voreingestellt oder aber auch über
eine Abfrage (wenn Display vorhanden) "Drücken sie jetzt die Taste für MENU", dass dann
intern unter array[Menu] abspeichern. (die Zahlen entsprechen den gesendeten Codes):
array[Plus] = 16;
array[Minus] = 17;
...
Danach kannst du dann einfach per If-Anweisung die Codes auswerten:
If( code == array[Plus])
...
If( code == array[Minus])
...
Oder bei mehreren FBs (natürlich #define FB1 1 ... nicht vergessen):
array[FB1][Plus] = 16;
...
array[FB2][Plus] = 1;
...
Aktuelle Fernbedienung einstellen:
fernbedienung = FB1;
Danach dann wieder die Codes auswerten:
If( code == array[fernbedienung][Plus])
Befehl ausführen
If( code == array[fernbedienung][Minus])
Befehl ausführenEs besteht natürlich auch die möglichkeit, dass du erst deine empfangenen Codes (so wie es Pesi am Anfang seines Beitrags geschrieben hat) in interne codes umwandelst, dass würde sich aber wohl nur lohnen, wenn du die Codes an mehreren Stellen verwendest oder fremde switch-case-Konstruckte ohne Änderung übernehmen willst. Das liegt daran, dass du ja die Codes dabei dann 2 mal auswerten musst, was natürlich mehr Code und Systemzeit erfordert.
Gruß
Karsten
EDIT: habe gerade noch mal nachgedacht, wie man es noch machen könnte (Pesi hatte sowas auch schon angesprochen):
Zuordnung definieren (die Zahlen entsprechen wieder den FB-Codes):
array[1] = Plus;
array[16] = Menu;
...
Dann den code wie folgt auswerten:
befehl = array[code];
Danach kannst du dann auch wieder switch-case nutzen:
switch (befehl)
{
case Plus: ...break;
case Minus: ...break;
}
Der Nachteil an dieser Version ist jedoch, dass das Array genau so viele Bytes groß sein muss, wie es FB-Codes gibt.
Also sind die 85mA der Strom, der durch eine LED fließt, wenn Rot, Grün und Blau an sind. Das wäre dann pro Farbe ca 28mA. Wie du richtig erkannt hast, sind das dann 680mA pro Zeile. Dazu kommt ja außer den Basisströmen noch der Strom für den µC und was da noch so dran hängt. Denke mal, dass deine 0,8A da realistisch sind. Dein Fehler kommt dann bei der "Wahl" der Spannung. Du hast zwar 9V Versorgungsspannung, davon fallen aber schon 5V an deiner Schaltung ab, somit bleiben nur noch 4V (ich würd mit 5V rechnen) die an dem Spannungsregler abfallen. Daraus volgt, P = 5V * 0,8A = 4W.
Ich frage mich nur gerade, warum du erst ein 9V NT nimmst, und dann die Spannung noch reduzierst. Wenn doch die gesamte Schaltung nur 5V benötigt, kannst du doch einfach ein 5V NT nehmen und hast dann nicht die Probleme mit der Wärme.
Schön, dass das Muster jetzt funktioniert.
Das mit der Leistung ist für mich gerade etwas schwehr nachzuvollziehen, wie genau hast du das berechnet (mit welchen Werten).
61°C Chiptemperatur ist ok, im Datenblatt ist folgende Angabe zu finden:
Operating Temperature Range: 0 ~ +125 °C
In einem geschlossenen Gehäuse liegst du wahrscheinlich über den 25°C Umgebungstemperatur, d.h. du müsstest die Umgebungstemperatur in deiner Berechnung anheben (bedenke auch, dass die Umgebungstemperatur im Sommer gegebenenfalls auch höher ist). Über die im Gehäuse resultierende Temperatur lässt sich jedoch ohne Messung nur spekulieren. Reduzieren lässt sie sich zum Beispiel mit einem Metallgehäuse, statt einem Plastikgehäuse (besserer Wärmeaustauch zwischen Innen und Außen), auch ein größeres Gehäuse bringt etwas. Auch die von dir angesprochenen Lüftungsschlitze werden einiges bringen. Sei dir aber über den Nachteil bewusst, dass sich mit der Zeit Staub in deinem Gehäuse ansammelt. Eine weitere Möglichkeit bei einem Metall-Gehäuse wäre, den 7805/ dessen Kühlkörper thermisch-leitend mit dem Gehäuse zu verbinden, um so einen Teil der Wärmeenergie dierekt nach außen abzuführen.
Hast du zur Zeit Wärmeleitpaste auf dem Kühlkörper? Wenn nicht, würde ich dir empfehlen, dass bald nachzuhohlen, vorher macht es auch keinen Sinn, über die gefühlte/gemessene Kühlkörpertemperatur zu reden.
Gruß
Karsten
Hallo,
das mit dem Glimmen der LEDs könnte auch an deiner Software liegen, jenachdem wie weit du da die Zeilenwechsel schon drin programmiert hast. Wenn du nämlich erst in die nächste Zeile wechselst und dann die LEDs ausschaltest, kann es sein (muss aber nicht), dass dieses verspätete ausschalten durch ein Glimmen/Flimmern sichtbar wird. (Die Intensität wäre nätürlich von mehreren Faktoren habhängig, wie z.B. µC-Takt, verwendete Transistoren, Zeilen-Takt, ...)
Ähnliche Auswirkungen hat natürlich auch ein zu frühes einschalten der LEDs (vor dem Zeilenwechsel).
Meine Überlegung wäre, das Umschalten der Zeile wie folgt zu realisieren:
1. Ausschalten aller LEDs
2. Wechseln der Zeile
3. Einschalten der benötigten LEDs (der aktuellen Zeile)
Weiterhin noch viel Erfolg
Hi,
besteht noch die Möglichkeit welche von den RGB-LED's zu bekommen?
(so um die 100stk. ?)