Hallo,
ich suche eine geschickte Lösung für mein Vorhaben.
Also, ich habe in meinem Haus im Keller eine SPS. Auf jeder Etage sitzt
bei mir ein Sicherungskasten.
Nun möchte ich jeder Sicherung eine Sicherungsüberwachung spendieren.
Den Status der Sicherungsüberwachung möchte ich an die SPS mitteilen.
Nun habe ich mir folgendes überlegt:
In jeden Sicherungskasten installiere ich eine "AVR-Box", d.h. die
Eingänge werden dann mit einem AVR eingelesen.
Da ich vorsichtshalber noch ein Netzwerkkabel in den Sicherungskasten
gelegt habe, möchte ich den Status per Bus in den Keller senden.
Im Keller sitzt eine weitere "AVR-Box", die die Daten wieder als
Eingänge für die SPS ausgibt. Natürlich mit Optokopplern, um mit 5V die
24V-Eingänge zu treiben.
Sicherungsüberwachung -> AVR -> Bus -> AVR -> SPS
Der AVR im Sicherungskasten dient als "Master", der kontinuierlich Daten
an den AVR im Keller (Slave) den Status sendet.
Ich würde beispielsweise für den AVR im Sicherungskasten den Port B
nehmen.
Der Portstatus soll dann via Bus an den AVR im Keller gesendet werden.
Dieser AVR hat dann den selben Portstatus wie der im Sicherungskasten.
Alle Sicherungen eingeschaltet:
AVR-Kasten = 0b11111111
AVR-Keller = 0b11111111
Eine Sicherung ausgeschaltet:
AVR-Kasten = 0b11111011
AVR-Keller = 0b11111011
Mir macht nun das Einlesen, Verschicken und Ausgeben theoretische
Gedanken.
Gibt es eine Funktion, die den Port B ausliest und den Wert speichert?
Ich denke, es geht so:
Wenn alle Sicherungen eingeschaltet sind, sind alle Pins am Port B high.
Da es sich um ein Byte handelt, sollte dann der Wert des Ports 255 sein.
Diese 255 möchte ich via Bus versenden.
Der Empfangs-AVR im Keller soll die 255 auf dem Port B nachbilden.
Aber wie schreibe ich das im AVR in C?
Fiktiver Code für Sender:
1
while(1)
2
{
3
data=PortB;
4
senddata;
5
}
Fiktiver Code für Empfänger:
1
while(1)
2
{
3
data=receive;
4
PortB=data;
5
}
Ich hoffe, es ist rübergekommen, was ich gerne umsetzen möchte.
Für den Bus entschied ich mich bereits für RS485, aber damit habe ich
bereits ein wenig Übung.
Nur nicht mit dem "Status einlesen, senden und ausgeben".
Sollte ich nach dem Senden noch ein Delay einbauen?
Was sagt die "Praxis" dazu? Ich hatte mit meiner RS485-Programmiererei
immer eine bidirektionale Verbindung mit ACK der Teilnehmer, aber das
soll hier am Ende nur one-way ohne ACK sein...
Gruß,
Andreas
Hallo Andreas!
Ich gehe mal davon aus, daß Du auf jeder Etage einen Controller
installieren möchtest, der jeweils (?) 8 Sicherungen überwacht und
übermittelt.
Sonst macht der Bus (fast) gar keinen Sinn.
Diese [Anzahl Etagen]*8 Ereignisse kannst Du im Keller nicht alle
ständig auf Port B ausgeben.
Desweiteren ist es doch sicherlich auch nur interessant, einmal zu
übermitteln, wenn eine Sicherung ausgefallen ist. Eine ständige
Übermittlung ist nicht nötig.
So könnte man über einen Port am Controller im Keller auch mehr
Informationen als für 8 Sicherungen übertragen.
Gruß
Jobst
> Der AVR im Sicherungskasten dient als "Master", der kontinuierlich Daten> an den AVR im Keller (Slave) den Status sendet.
Dann hättest Du mehrere Master, welche (asynchron) an den Slave senden
wollen.
Ich würde nur einen Master (im Keller) vorsehen, welcher die Slaves (in
den Etagen) zyklisch abfragt.
> Nun möchte ich jeder Sicherung eine Sicherungsüberwachung spendieren.
Mein Gott, wie oft fliegen denn da die Sicherungen raus? Bei mir alle
paar Jahre mal eine. Wäre es nicht besser, eine vernünftige Installation
zu machen? Ihr doktert immer an Symptomen rum anstatt die Ursache
anzupacken.
>Gibt es eine Funktion, die den Port B ausliest und den Wert speichert?
Nö. Zumindest nicht fertig. Dein fiktiver Code ist aber schon nah an der
Lösung.
Allerdings ist Ein-Ausgabe über Ports, und das Abspeichern von Daten,
die Basis aller Mikrocontroller-Programmiererei. Insofern werden dir
viele Fragen beantwortet, wenn du das avr-gcc Tutorial (hier oben links)
durcharbeitest.
Oliver
Oliver schrieb:
>>Gibt es eine Funktion, die den Port B ausliest und den Wert speichert?>> Nö. Zumindest nicht fertig. Dein fiktiver Code ist aber schon nah an der> Lösung.
Das würde ich so nicht sehen.
Der ganze Ansatz, den der TO naiv einschlägt, ist unsinnig.
Viel einfacher ist es doch, wenn die Zentrale reihum alle Slaves
abfragt:
Wie ist dein Zustand
Und der Slave antwortet
Alles OK, Sicherung 3 ist draussen
Das kann er dann auch mit seinen bisherigen Kommunikationskenntnissen
bewältigen.
> Allerdings ist Ein-Ausgabe über Ports, und das Abspeichern von Daten,> die Basis aller Mikrocontroller-Programmiererei. Insofern werden dir> viele Fragen beantwortet, wenn du das avr-gcc Tutorial (hier oben links)> durcharbeitest.
Full ACK
Andreas B. schrieb:
> Der AVR im Sicherungskasten dient als "Master", der kontinuierlich Daten> an den AVR im Keller (Slave) den Status sendet.
Da liegen schon Deine ersten beiden Probleme!
Erstens: Im Allgemeinen hat mein EINEN Master, dem beliebig viele
Slaves zur Seite stehen. Wenn viele Master nur einem Sklaven Befehle
erteilen, geht das in die Hose. Das wussten schon die alten Aegypter. ;)
Zweitens: "Kontinuierliches" ist bei einem Bus immer schlecht. Wieviel
bekommst Du denn noch mit, wenn Dir 15 Leute gleichzeitig und ohne
Unterbrechung etwas erzaehlen?
> Gibt es eine Funktion, die den Port B ausliest und den Wert speichert?
Die Frage ist nicht ernst gemeint, oder?
Oliver schrieb:
> Nö. Zumindest nicht fertig.
Die Antwort aber hoffentlich auch nicht...
Was Du brauchst ist
a) Einen Master, der den Verkehr auf dem Bus regelt und die
Schnittstelle zwischen Bus und SPS bildet.
b) Slaves, die auf die Kommandos des Masters reagieren und z.B. den
Status der Sicherungen ausgeben.
Das sind alles "basics".
Andreas B. schrieb:
> Ich hoffe, es ist rübergekommen, was ich gerne umsetzen möchte.
Fuer mich kommt es so rueber, als haettest Du eine Idee aber keine
Ahnung und wuerdest gerne dieses Forum benutzen um das Ganze kostenlos
zu verwirklichen. Wenn ich schon lese, dass Du "nur" nicht weiss, wie
man einen Port auf dem Mikrocontroller einliest, klappen sich mir die
Fussnaegel hoch.
Darf ich Dir vorschlagen, erstmal die Grundlagen von Mikrocontrollern
und Bussystemen zu studieren und Dich dann mit detaillierteren Fragen an
das Forum zu wenden, wenn's wirklich mal hakt?
Volker
>Also, ich habe in meinem Haus im Keller eine SPS. Auf jeder Etage sitzt>bei mir ein Sicherungskasten.
Ok.
>jeder Sicherung eine Sicherungsüberwachung spendieren.
Ok.
>Den Status der Sicherungsüberwachung möchte ich an die SPS mitteilen.
Ok.
>Nun habe ich mir folgendes überlegt...
Warum so komplizert? Wenn du eh
>vorsichtshalber noch ein Netzwerkkabel ..
verlegt hast, kannst du doch einfach abgesetzte E/A-Einheiten der
zeitgemäßen SPS nutzen. Diese haben die Möglichkeit, per
Standart-Netzwerkkabel dezentrale Elemente an die SPS anzuschließen. So
kannst du pro Sicherungskasten einen Buskoppler und eine/zwei/drei
Eingangsklemmen planen. Das Ganze gibt es fertig zu kaufen und
funktioniert ohne Basteln.
Etwa so:
Keller SiK 1 SiK 2 SiK 3
.-----------. .-----------. .-----------. .------ ...
| | | | | | |
SPS Buskoppler Buskoppler Buskoppler
Eingänge Eingänge Eingänge
Jobst M. schrieb:
> Desweiteren ist es doch sicherlich auch nur interessant, einmal zu> übermitteln, wenn eine Sicherung ausgefallen ist. Eine ständige> Übermittlung ist nicht nötig.
Jupp, das ist eine gute Idee. Somit wird nicht ständig etwas gesendet,
sondern nur, wenn ein Ereignis eingetroffen ist.
Bensch schrieb:
> Mein Gott, wie oft fliegen denn da die Sicherungen raus? Bei mir alle> paar Jahre mal eine. Wäre es nicht besser, eine vernünftige Installation> zu machen? Ihr doktert immer an Symptomen rum anstatt die Ursache> anzupacken.
Hab ich erwähnt, dass bei mir ständig die Sicherungen rausfliegen?
Schon mal was davon gehört, dass man auch über das Internet auf den
Status einer Anlage zugreifen kann? Es ist doch nur eine Rückmeldung.
6, setzen!
Karl heinz Buchegger schrieb:
> Viel einfacher ist es doch, wenn die Zentrale reihum alle Slaves> abfragt.
Ich hatte NIE erwähnt, dass es mehrere Slaves gibt!
Volker Schulz schrieb:
> Erstens: Im Allgemeinen hat mein EINEN Master, dem beliebig viele> Slaves zur Seite stehen. Wenn viele Master nur einem Sklaven Befehle> erteilen, geht das in die Hose. Das wussten schon die alten Aegypter. ;)
Bei mir wird jeder einzelne Master nur einen Slave bekommen.
Volker Schulz schrieb:
> Zweitens: "Kontinuierliches" ist bei einem Bus immer schlecht. Wieviel> bekommst Du denn noch mit, wenn Dir 15 Leute gleichzeitig und ohne> Unterbrechung etwas erzaehlen?
Auch hier hatte ich NIE erwähnt, dass es mehrere Slaves, gar Master,
gibt!
Volker Schulz schrieb:
> Fuer mich kommt es so rueber, als haettest Du eine Idee aber keine> Ahnung und wuerdest gerne dieses Forum benutzen um das Ganze kostenlos> zu verwirklichen.
Das grenzt schon an Rufmord!
Volker Schulz schrieb:
> Darf ich Dir vorschlagen, erstmal die Grundlagen von Mikrocontrollern> und Bussystemen zu studieren und Dich dann mit detaillierteren Fragen an> das Forum zu wenden, wenn's wirklich mal hakt?
An den Admin, schließ das Forum, alle Antworten stehen sowieso im
Tutorial!
Matthias Lipinsky schrieb:
> kannst du doch einfach abgesetzte E/A-Einheiten der> zeitgemäßen SPS nutzen. Diese haben die Möglichkeit, per> Standart-Netzwerkkabel dezentrale Elemente an die SPS anzuschließen.
Endlich mal einer, der eine weitere Möglichkeit erwähnt!
Sicherlich ist das so machbar, hatte schon an eine ET200S gedacht, aber
die passt nicht gut in den Sicherungskasten, vom Preis her ist das auch
relativ viel. Aber: es funktioniert ohne Bastelei, da gebe ich dir full
ack!
Ich wollte eben schon ein Bild malen, damit mein Vorhaben deutlicher
wird, aber da ich nun auch wie andere am eigenen Leib erfahren habe,
dass man ein besonders guter Crack sein muss um hier im Forum posten zu
dürfen, lass ich das lieber. Aber man darf sich doch mal Anregungen
holen, oder?
Ach, ich muss mich berichtigen (für die Wort-im-Mund-Umdreher):
1
Es steht NICHT ALLES im Tutorial!
...obwohl in fast jeder ersten Antwort immer steht: Guck ins Tutorial!
Wenn euch die "Anfängerfragen" ankotzen, dann antwortet doch gar nicht
darauf! Wieso fühlt ihr euch denn immer angesprochen?
So macht es echt keinen Spaß.
Habt ihr vielleicht schon mal daran gedacht, dass Newbies, die so ein
ähnliches Problem hatten, den New-Newbies so helfen könnten?
Ich denke, wenn das so abläuft, ist es hier ein tolles Forum, aber wenn
man gleich niedergemacht wird, wird man das mikrocontroller.net-Forum
nie wieder besuchen. Aber vielleicht ist das ja der Grund, warum solche
Antworten fallen... Echt schade!
>hatte schon an eine ET200S gedacht
Das habe ich befür.. äh geahnt. Deshalb hab ich das Wort "zeitgemäß"
benutzt.
Und darunter fällt bei mir das nicht. Und das der Preis völlig utopisch
ist, braucht nicht erwähnt zu werden...
Übrigens:
Beruhige dich einfach mal wieder. Es ist einfach so, dass die Verbindung
von mehreren µC über irgendeinen Bus (so wie du vorhast) viel
komplizierter ist, als es ein Laie (der USB-PlugnPlay kennt) denkt. Und
darauf wird einfach hingewiesen.
> Auch hier hatte ich NIE erwähnt, dass es mehrere Slaves, gar Master,> gibt!
aber:
> In jeden Sicherungskasten installiere ich eine "AVR-Box", d.h. die
und
> Im Keller sitzt eine weitere "AVR-Box", die die Daten wieder als
wie passt das jetzt zusammen? mehrere Sicherungskästen aber es gibt nur
je einen Master und Slave?
und außerdem:
> Ach, ich muss mich berichtigen (für die Wort-im-Mund-Umdreher):>>Es steht NICHT ALLES im Tutorial!>>...obwohl in fast jeder ersten Antwort immer steht: Guck ins Tutorial!
deine Fragen im ersten Post war aber nur
> "Status einlesen, senden und ausgeben"
und alle drei Punkte werden im Tutorial ausführlich abgedeckt...
Matthias Lipinsky schrieb:
> Es ist einfach so, dass die Verbindung> von mehreren µC über irgendeinen Bus (so wie du vorhast) viel> komplizierter ist, als es ein Laie (der USB-PlugnPlay kennt) denkt.
Ja, das ist bekannt und nachvollziehbar. Hatte bereits mit einem Master
und mehreren Slaves zu tun.
Justus Skorps schrieb:
> mehrere Sicherungskästen aber es gibt nur> je einen Master und Slave?
Ja. Ich will doch einfach nur eine "Verlängerung" von der SPS im Keller
zum Sicherungskasten ziehen.
Ich möchte das alles so getrennt wie möglich laufen lassen, da ich im
Fehlerfall auf der sicheren Seite sein möchte und sprichwörtlich nicht
im komplett dunklen Haus stehen will.
Ich möchte diese Verlängerung byteweise ausführen.
Die Sicherungsüberwachungen führe ich direkt mit den 5V auf die Eingänge
des AVR's. Evtl. doch noch mit Optokopplern, aber das halte ich für
nicht notwendig (gleiche Spannung vom selben Netzteil).
Dieser AVR liest die den Portstatus ein und schickt die Daten an den
Empfänger im Keller.
Im Empfänger sitzt wieder ein AVR, der die Daten in Ausgänge umwandeln
soll. Diese Ausgänge bekommen 100%-ig Optokoppler, da ich 24V für die
SPS-Eingangskarte treiben muss.
Werden nun statt 8 gar 12 Sicherungsüberwachungen eingelesen, brauche
ich wieder einen AVR, der den Status von den Sicherungen 9 bis 12
einliest und die Daten an einen weiteren AVR im Keller schickt.
Sicherlich kann ich das auch für 16 Bit pro AVR auslegen, aber es kommt
drauf an, welchen µC man verwendet und wie viel Platz man im Gehäuse
hat.
Letzendlich will ich mich nicht darüber streiten, wieviele Eingänge mit
dem AVR eingelesen werden sollen...
Justus Skorps schrieb:
> deine Fragen im ersten Post war aber nur>> "Status einlesen, senden und ausgeben">> und alle drei Punkte werden im Tutorial ausführlich abgedeckt...
Dann verstehe ich aber nicht, warum trotzdem so toll rumphilosophiert
wird.
Vielleicht sollte man mal ein Tutorial darüber schreiben! ;-)
Andreas B. schrieb:
> Karl heinz Buchegger schrieb:>> Viel einfacher ist es doch, wenn die Zentrale reihum alle Slaves>> abfragt.> Ich hatte NIE erwähnt, dass es mehrere Slaves gibt!
Das war Karl Heinz' subtile Art Dir mitzuteilen, wie es am Besten zu
machen waere. ;)
> Volker Schulz schrieb:>> Erstens: Im Allgemeinen hat mein EINEN Master, dem beliebig viele>> Slaves zur Seite stehen. Wenn viele Master nur einem Sklaven Befehle>> erteilen, geht das in die Hose. Das wussten schon die alten Aegypter. ;)> Bei mir wird jeder einzelne Master nur einen Slave bekommen.>> Volker Schulz schrieb:>> Zweitens: "Kontinuierliches" ist bei einem Bus immer schlecht. Wieviel>> bekommst Du denn noch mit, wenn Dir 15 Leute gleichzeitig und ohne>> Unterbrechung etwas erzaehlen?> Auch hier hatte ich NIE erwähnt, dass es mehrere Slaves, gar Master,> gibt!
Das war meine subtile Art, Dir mitzuteilen, wie es am Besten zu machen
waere. ;)
> Volker Schulz schrieb:>> Fuer mich kommt es so rueber, als haettest Du eine Idee aber keine>> Ahnung und wuerdest gerne dieses Forum benutzen um das Ganze kostenlos>> zu verwirklichen.> Das grenzt schon an Rufmord!
Ne, das grenzt nichtmal an. Ich habe beschrieben, wie Dein Thread auf
mich wirkt. Das wird ja wohl noch erlaubt sein...
> An den Admin, schließ das Forum, alle Antworten stehen sowieso im> Tutorial!
Nicht alle... Die Antworten auf Deine Fragen schon. Soll ich jetzt
schreien "Schliesst das Tutorial, da guckt eh niemand rein!"?
> Wenn euch die "Anfängerfragen" ankotzen, dann antwortet doch gar nicht> darauf! Wieso fühlt ihr euch denn immer angesprochen?> So macht es echt keinen Spaß.> Habt ihr vielleicht schon mal daran gedacht, dass Newbies, die so ein> ähnliches Problem hatten, den New-Newbies so helfen könnten?> Ich denke, wenn das so abläuft, ist es hier ein tolles Forum, aber wenn> man gleich niedergemacht wird, wird man das mikrocontroller.net-Forum> nie wieder besuchen. Aber vielleicht ist das ja der Grund, warum solche> Antworten fallen... Echt schade!
Ich habe kein Problem mit Anfaengerfragen und beantworte jede Menge
davon. Die allermeisten haben vorher das Tutorial theoretisch und
praktisch durchgearbeitet, und genau das ist es, was ich erwarte:
Grundlagen. Lass doch erstmal ein paar LEDs blinken und lies ein paar
Taster ein, danach beantworten sich schon 3 Deiner Fragen wie von
selbst...
Volker
Andreas B. schrieb:
> Werden nun statt 8 gar 12 Sicherungsüberwachungen eingelesen, brauche> ich wieder einen AVR, der den Status von den Sicherungen 9 bis 12> einliest und die Daten an einen weiteren AVR im Keller schickt.
Das war doch mal eine Info! Damit brauchst Du auch keinen "Bus" mehr,
sondern lediglich eine Datenverbindung zwischen zwei AVRs. Dann schau
doch jetzt mal im Tutorial nach "I/O Grundlagen" und der "UART"... Dann
hast Du schon mehr als die halbe Miete. Guck bei dem Elektronikversand
Deines Vertrauens mal nach "Pegelwandlern" z.B. von Maxim. Und dann bist
Du eigentlich schon am Ziel. Sollte Dir DANN noch etwas unklar sein,
helfen wir bestimmt alle gerne.
> Sicherlich kann ich das auch für 16 Bit pro AVR auslegen, aber es kommt> drauf an, welchen µC man verwendet und wie viel Platz man im Gehäuse> hat.> Letzendlich will ich mich nicht darüber streiten, wieviele Eingänge mit> dem AVR eingelesen werden sollen...
Ne, das lassen wir lieber. ;)
> Justus Skorps schrieb:>> deine Fragen im ersten Post war aber nur>>> "Status einlesen, senden und ausgeben">>>> und alle drei Punkte werden im Tutorial ausführlich abgedeckt...> Dann verstehe ich aber nicht, warum trotzdem so toll rumphilosophiert> wird.> Vielleicht sollte man mal ein Tutorial darüber schreiben! ;-)
Weil wir 1.) auch ein bisschen Eigeninitiative erwarten koennen und 2.)
Du von einem Bus gesprochen hast, des es wohl gar nicht geben wird.
Volker
Vielleicht ist das ganze an den Begriffdefinitionen gescheitert...
Für mich besteht ein Bus aus mindestens einem Master und einem Slave,
hätte lieber Point-to-Point-Verbindung schreiben sollen.
Den UART muss ich verwenden, das steht fest, aber RS232 kann ich bei 40m
vergessen. Darum die Idee mit RS485, da dort differentiell und nicht
massebezogen übertragen wird. Der MAX487 erweist da gute Dienste.
Übrigens, LED's blinken lassen ist kein Problem, hatte eben nur nie was
mit Portstatus bzw. Pinstatus zu tun und wie man diese Information per
UART verschicken und letztendlich auswerten kann.
Jetzt sollte alles geklärt sein...
Ach ja, @Volker, du weißt doch gar nicht, ob ich Eigeninitiative zeige
oder nicht. Ich habe NIE nach einem fertigen Code oder nach einer
fertigen Schaltung gefragt, sondern nur nach Meinungen dazu.
Andreas B. schrieb:
> Ach ja, @Volker, du weißt doch gar nicht, ob ich Eigeninitiative zeige> oder nicht. Ich habe NIE nach einem fertigen Code oder nach einer> fertigen Schaltung gefragt, sondern nur nach Meinungen dazu.
Mit "Eigeninitiative" meinte ich das selbstaendige Durcharbeiten des
AVR-Tutorials um die Grundlagen zu schaffen...
> Übrigens, LED's blinken lassen ist kein Problem, hatte eben nur nie was> mit Portstatus bzw. Pinstatus zu tun und wie man diese Information per> UART verschicken und letztendlich auswerten kann.
Wenn Du LEDs blinken lassen kannst, ist die Sache mit der Ausgabe doch
schonmal geklaert. Das zweite Kapitel des Tutorials heisst
•I/O-Grundlagen: Wie kann ich Taster und LEDs an einen AVR anschließen
und benutzen?
Da haettest Du dann alle Infos zur Eingabe, also Ports und Portpins
einlesen.
Etwas weiter hinten findest Du dann das Kapitel
•Der UART: Wie kann ich Daten zwischen einem Mikrocontroller und einem
PC austauschen?
Damit waere dann auch die Uebertragung erklaert. Die Sache mit dem Bus
hat sich auch geklaert. Woran scheitert es nun?
> Jetzt sollte alles geklärt sein...
Sehe ich auch so. ;)
Volker
P.S.:
> Darum die Idee mit RS485, da dort differentiell und nicht> massebezogen übertragen wird.
Voellig korrekt!
@Volker, wir kommen so langsam auf einen gemeinsamen grünen Zweig!
grins
Volker Schulz schrieb:
> Woran scheitert es nun?
Wenn, dann nur noch an den festgelegten Variablen für einen ATTiny2313.
;-)
Ich werde den Sende-AVR immer auf Senden beschalten und den Empfangs-AVR
immer auf Empfangen.
Der Sender wird immer nur dann etwas senden, wenn sich der Status am
Port ändert. Das war jedenfalls eine gute eingebrachte Idee.
Jetzt habe ich nur bedenken, dass der Empfangs-AVR die Daten nicht
mitbekommt, aber auf ein ACK möchte ich verzichten.
Wenn es aber nicht anders geht, stricke ich das dann auf eine
bidirektionale Verbindung um und der Empfänger teilt dem Sender mit,
dass dieser Daten empfangen hat.
ICh finde das Ganze viel zu kompliziert!
Wie wäre es, wenn du in jeden Si-Kasten mehrere 74HC165 als abgesetzte
Eingänge installierst. Diese kannst du dann per SPI und einem
Leitungstreiber durch dein verlegtes Ethernetkabel treiben.
SO sparst du dir den unnützen Aufwand mit dem Protokoll, der
Addressierung, der Arbitrierung....
Matthias Lipinsky schrieb:
> Wie wäre es, wenn du in jeden Si-Kasten mehrere 74HC165 als abgesetzte> Eingänge installierst. Diese kannst du dann per SPI und einem> Leitungstreiber durch dein verlegtes Ethernetkabel treiben.>> SO sparst du dir den unnützen Aufwand mit dem Protokoll, der> Addressierung, der Arbitrierung....
Oder I2C mit passenden Treibern für lange Leitungen...
Matthias Lipinsky schrieb:
> Wie wäre es, wenn du in jeden Si-Kasten mehrere 74HC165 als abgesetzte> Eingänge installierst. Diese kannst du dann per SPI und einem> Leitungstreiber durch dein verlegtes Ethernetkabel treiben.
Das ist eine super Idee!
Ich habe mal schnell nach dem 74HC165 gegoogelt und man kann sogar
diesen Baustein kaskadieren! Das finde ich sehr vorteilhaft und besser
als meine Lösung mit zwei AVR's.
Welchen Treiber verwende ich denn dann? Gibt es da etwas spezielles?
Ich habe ja dann drei Leitungen, CLK, Out und Load.
Jörg S. schrieb:
> Oder I2C mit passenden Treibern für lange Leitungen...
D.h. ich bräuchte dann nur zwei Leitungen?!
Andreas B. schrieb:
> Jörg S. schrieb:>> Oder I2C mit passenden Treibern für lange Leitungen...> D.h. ich bräuchte dann nur zwei Leitungen?!
Ja. Dafür wird dann halt die Software aufwändiger.
ich weiß ja nicht wie ihr das handhabt, aber mir ists egal WELCHE der
sicherungen in EINEM kasten geflogen ist.
ich muss so oder so hingehen und sie wieder einsetzen.
damit lässt sich die informationsmenge schonmal deutlich verkleinern und
damit braucht er auch keinen bus mehr. den rest macht er mit
hardwired-and
Andreas B. schrieb:
> @Volker, wir kommen so langsam auf einen gemeinsamen grünen Zweig!> *grins*
Na, woll'n wir mal sehen... ;)
> Volker Schulz schrieb:>> Woran scheitert es nun?> Wenn, dann nur noch an den festgelegten Variablen für einen ATTiny2313.> ;-)
Das AVR-Tutorial ist ziemlich allgemein gehalten und auch die Beispiele
sollten ohne Probleme potierbar sein. Du musst nur die Include-Datei
anpassen.
> Ich werde den Sende-AVR immer auf Senden beschalten und den Empfangs-AVR> immer auf Empfangen.> Der Sender wird immer nur dann etwas senden, wenn sich der Status am> Port ändert. Das war jedenfalls eine gute eingebrachte Idee.> Jetzt habe ich nur bedenken, dass der Empfangs-AVR die Daten nicht> mitbekommt, aber auf ein ACK möchte ich verzichten.
Wenn Du sowieso nur eine Punkt-zu-Punkt-Verbindung hast, wuerde ich in
regelmaessigen Intervallen senden. So hast Du eine Quasi-Fehlerkorrektur
und bekommst auch mit, wenn sich der Sender mal verabschiedet. Das alles
ohne Bidirektionale Verbindung. Koenntest natuerlich auch noch ein
Parity-Bit anhaengen.
> Ich habe mal schnell nach dem 74HC165 gegoogelt und man kann sogar> diesen Baustein kaskadieren! Das finde ich sehr vorteilhaft und besser> als meine Lösung mit zwei AVR's.
Damit hast Du auf jeden Fall schonmal meine Vermutung bestaetigt, dass
Du das AVR-TutorialNICHT durchgearbeitet hast um Dir Grundlagen zu
schaffen. Und genau das hat mich von Anfang an gestoert. Wenn Du das
AVR-Tutorial durchgearbeitet haettest, haettest Du nicht nach dem
Schieberegister googlen muessen; Diese werden dort ausfuehrlich in einem
eigenen Kapitel behandelt. Dann wuesstest Du auch dass Du (zumindest
theoretisch) 3 Leitungen brauchst, da Du das Eingangsregister auf's
Schieberegister ziehen musst (das ist ist eine Art "Sample & Hold fuer
den Fall dass sich waehrend des Schiebens am Eingang etwas aendert). Die
Verbindung Schieberegister -> AVR ist natuerlich nicht so
stoerunanfaellig wie eine RS485-Verbindung. Ich wuerde in Hinsicht auf
zukuenftige Erweiterungen den AVR im Sicherungskasten vorziehen, aber
das sei natuerlich jedem selbst ueberlassen...
Ich klinke mich dann mal aus diesem Thread aus, wuensche Dir aber noch
viel Glueck bei Deinem Vorhaben!
Volker
Thread beobachten
Seitenaufteilung abschalten