www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Dezentral Eingänge einlesen und entfernt wieder ausgeben!?


Autor: Andreas B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
while(1)
{
data = Port B;
send data;
}

Fiktiver Code für Empfänger:
while(1)
{
data = receive;
Port B = data;
}

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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: StinkyWinky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Andreas B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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):
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!

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Justus Skorps (jussa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Andreas B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! ;-)

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Andreas B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andreas B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Volker Schulz (volkerschulz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-Tutorial NICHT 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.