www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR I/O Interface mit RS232


Autor: Lucas W. (maesto)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guden!

Bin noch relativ neu hier im forum und hoffe auf gute hilfe.

Ziel:
Ein in (Hutschienen) Segmente unterteiltes I/O Out/Input interface.
Dabei nimmt ein Master vom RS232 Port des Pc's ASCI zeichen (Zahlen) an, 
und sendet diese auf einen (TWI/CAN) Bus Die segmente Prüfen, ob sie das 
entsprechende Rele haben. Falls Ja Schalten sie dieses an(außer wenn es 
bereits an ist. Dann wird es ausgeschaltet.)

Input sind komplett vom Output Master getrennt (heist die inputsegmente 
besitzen einen eigenen Master, welcher die Daten annimt, und per RS232 
Kabel an einen PC sendet)

Lösungsansatz:

Ich muss dazu sagen in sachen Mikrocontroller bin ich noch neu und hab 
kaum bis garkeine Ahnung. Jedoch setzte ich hier mal meine 
Lösungsansätze rein.

Master:
Master wartet per Interrupt auf ein RS232 Zeichen. Wenn ein ankommt, 
speichert er das angekommene Asci Zeichen als Variable ab, damit es von 
einem evtl. folgendem zeichen nicht überschrieben wird. Die Interrupt 
Routine setzt noch eine Variable (Name: empf) auf 1 und beendet sich 
damit auch schon wieder.

Nun wird durch diese auf 1 gesetzte Variable eine Funktion tätig. Diese 
sendet das Zeichen über TWI oder UART oder auch CAN an die I/O segmente. 
(Weiß nicht so richtig welches der 3 Systeme ich letztenendes nutze.) 
Nun gibt die Funktion noch den Speicher der Variable frei. Und setz die 
variable (Name: empf) wieder auf 0 zurück. Nun wartet der Controller 
wieder auf ein interrupt. Die Funktion macht wärend der zeit solang 
nichts, bis die Variable wieder 1 beträgt.

Die Variablen in denen das ASCI zeichen gespeichert wird sollte immer 
unter einem anderen Namen gespeichert werden, damit ein neues ASCI 
zeichen dieses nicht überschreibt. (bei jeder Ausführung eine Variable 
um +1 hochzälen.

Ich werd mal mit meinen kentnissen im laufe des Wochenendes einen 
Quellcode einfügen. Ich denke das sich der Master mit einem einfachen 
ATtiny realisieren lassen wird. Jedoch habe ich keine Ahnung, wie die 
Hardware für RS232 und TWI/UART/CAN/RS232 an diesen angeschlossen wird, 
geschweige denn wie die Hardware dafür aussieht. Um entsprechende Links 
würde ich mich sehr freuen. Für das Senden/Empfangen von 
Can/UART/TWI/RS232 werden warscheinlich Funktionen/Libs bestehen. Werde 
diese dann auch nutzen, weil ich will ja das Rad nich neu erfinden... 
I/O Hardware denke ich bekomme ich hin.

Meim Input Master funktioniert das ganze dan rückgängig (Wartet am 
TWI&co und sendet am RS232 anstatt andersrum.)

Segment:

Out:
Das Segment empfängt auf dem Bus Liegende ZEichen und wertet aus, ob er 
diesen Ausgang überhaupt besitzt. Wenn nein wartet er auf das nächste 
Zeichen. Falls er den Entsprechenden Ausgang besitzt, schaltet er diesen 
um.

In:
Wenn ein Interrupt durch eine Taste ausgelößt wird wird ein 
entsprechendes Zeichen auf dem Bus ausgegeben.

Ich denke auch hier das dies mit einem ATtiny lösbar ist. Jedoch fehlt 
mir dort auch entsprechendes Hardwarehissen für den Bus.

Uff das war jetzt mal eine Lange erklärung. Ich hoffe man kann sie 
verstehen, und ich wirke nicht zu aufdringlich. Ich setz mich mal an 
Quellcode ran.

Gruß: maesto

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lucas,

vorab: ASCI = ASCII, Rele = Relais.

TWI ist sicher eine Möglichkeit, CAN ist sowohl hardware- als auch 
softwaretechnisch. um einige Potenzen komplizierter bzw. mit einem ATiny 
nicht zu realisieren.

Wieviele RS232 soll Dein PC denn haben, um einen Input-Master und einen 
Output-Master anzusteuern? Du würdest dafür 2 benötigen.

Welcher Grund liegt zugrunde, dass Du nicht einen Controller als 
RS232-TWI-Umsetzer verwendest und mit diesem Deine Slaves ansprichst?

Otto

Autor: Lucas W. (maesto)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guden Otto

Mein grund dahinter war das dadurch mein Programmcode einfacher wird. 
Einen zweiten RS232 hätte ich durch einen Adapter bekommen. Der ATiny 
ist nicht zwingend notwendig. WAr nur son gedanke von mir. Naja ich geh 
dann mal weiter C büffeln :D

Gruß Lucas

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Master bietet sich der Mega162 (inzwischen wohl durch die A-Variante 
oder etwas ganz anderes) ersetzt.
Der hat nämlich gleich zwei USART.
Besser wäre ein Ansatz, bei dem die Sklaven Adressen bekommen (z.B. 
einstellbar über DIP-Schalter).
Dann kann man sich nämlich eine Sklaven-Hardware ausdenken, die man 
einfach vervielfacht...
Dann muss man sich nur noch für einen (in deinem Fall einfach zu 
programmierenden) Bus entscheiden, und die Sache läuft.

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

Bewertung
0 lesenswert
nicht lesenswert
Zu deinen Vorstellungen bezüglich Software:

Die ganz grobe Idee ist so in Ordnung, aber auch nicht.
Du hast da ein paar ganz grobe Verständnis-Böcke geschossen.


> Falls Ja Schalten sie dieses an(außer wenn es
> bereits an ist. Dann wird es ausgeschaltet.)

Keine gute Idee.
Lass den PC Buch führen ob das Relais an oder aus ist undl ass ihn 
explizit sagen, wie er das Relais haben möchte.
Solche automatische Pulsumschaltungen (jeder Puls ist eine Umschaltung 
in die jeweils andere Lage) können ein ganz gewaltiger Schuss ins Auge 
sein. Besser ist es, wenn derjenige der das Kommando hat (=PC) Klartext 
spricht, wie er das Relais geschaltet haben möchte.

Deine Vorstellungen bezüglich UART Empfang sind ein wenig, na ja, 
daneben.

Du willst einen Ringbuffer haben, in dem die ankommenden Zeichen 
zwischengespeichert werden und auf ihre Verarbeitung warten. Google ist 
hier dein Freund.

Warum kann eigentlich der Rückweg nicht über dieselbe serielle 
Schnittstelle laufen? UART geht in beiden Richtungen!

Alles in allem: Bei dem was du dir vorgenommen hast, musst du (je 
nachdem welche Vorkenntnisse du in Programmierung hast) mit 1/2 bis 3/4 
Jahr Aufwand rechnen. Für ein Einsteigerprojekt ist das alles viel zu 
umfangreich. Man kann allerdings die Aufgabe in Teile aufsplitten und 
jeden Teil einzeln für sich bearbeiten und damit spielen, bis man etwas 
Erfahrung damit gesammelt hat. WEnn du dann erst mal mit allen 
Teilsystemen Erfahrung gesammelt hast, kannst du dich hinsetzen und ein 
neues Gesamtprogramm schreiben. Der Versuch das von Anfang an alles in 
einem Projekt ohne Vorstudien hinzubekommen, wird wahrscheinlich in die 
Hose gehen.

Autor: Lucas W. (maesto)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab gerade dies :Beitrag "AVR-GCC: UART mit FIFO" hier 
gefunden dürfte doch eigendlich gehen oder?? Dann hätt ich wenigstens 
schonmal die ein und ausgabe vom USART.

gruß Lucas

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Ein mutiges Projekt...
Also, zuerst einmal grundlegend: Alle Module sollten gleichen Aufbau 
haben. Mittels einer Adresse werden sie angesprochen. Wieviele denkst 
du, einzusetzen? Bleibst du unter 256 könntest du 1 Byte zur Erkennung 
in dein "Telegramm" einbauen.
In RS232- Sytemen würde ich einen Controler mit 2 USART einsetzen und 
die Module hintereinanderschalten. Adressen werden per Dip-Schalter oder 
Steckbrücken vergeben.
Nun zum Telegramm:
Senderadresse, Empfängeradresse, Nutzbyte (optional Steuerbyte)
Für In- bzw.Output wäre denkbar, einfach den Adressbereich zu splitten. 
1-127 Eingang, 128-255 = Ausgang, 0=Master.
Wie solls funktionieren...
Telegramm wird losgeschickt 0, 129, 0x01101100
1. Modul empfängt über USART 1 und schreibt in Ringpuffer. Bei der 
Auswertung ist klar, nicht mein Job, also über USART 2 weiter.
Modul 129 empfängt so irgendwann und stellt fest, ist für mich. Also 
raus mit dem Bitmuster und damit Relais setzen. 1 = an, 0=aus.
Soweit, so gut. Will man nun dem Master verkünden, ich hab meinen Job 
erledigt, kann dieses Modul auch ein Telegramm erzeugen, genauso wie ein 
Eingabemodul und auf den Rückweg schicken.
Telegramm zurück: 129,0,0x01101100
So kann der Master prüfen, ob alles klar ist.
Wenn In- oder Outputs bunt gemischt werden, auch kein Problem, dann 
kommt noch ein Byte hinzu, welches die Richtung bestimmt und vielleicht 
noch ein paar Steuerbits aufbereitet,wozu auch immer.
Wichtig ist zu wissen, das die Telegrammblöcke nicht "gemischt werden 
dürfen. Also, wenn ein Eingabemodul einen Block sendet, so darf diese 
Sendung nicht mit einem anderen Telegramm vermischt werden. Das ließe 
sich bzw. durch getrennte Ringpuffer sicherstellen.
Ein Ringpuffer ist wirklich nicht schwer...
Eingang erkannt, dann Adresse von Ringpuffer holen, Schreibzeiger 
erhöhen.
Wenn Wert größer Ringpuffer, dann Schreibzeiger auf 0 und auf die 
Adressse vom Ringpuffer addieren - Zeichen eintragen
Bearbeiten:
Schreib und lesezeiger gleich, dann kein neues Zeichen
sonst
Adresse vom Ringpuffer holen, Lesezeiger erhöhen. Wenn Wert größer 
Ringpuffer, dann Lesezeiger auf 0 und auf Ringpufferadresse addieren. 
Zeichen lesen.
Damit man weiß, welches Zeichen gerade gelesen wird, muß ein Index 
mitgeführt werden, der sagt, welches Byte gerade bearbeitet wird. dieser 
Zähler entspricht der Telegrammlänge.
Ich hoffe, es sind ein paar nützliche Hinweise. Das Prinzip sollte sich 
auch auf andere Kopplungen adaptieren lassen.
Gruß oldmax

Autor: Lucas W. (maesto)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bins mal wieder :D

Jetzt wo Ferien sind, hab ich endlich wieder mehr zeit, um mich um mein 
"Projekt" zu kümmern. Bin durch den Beitrag von oldmax inzwischen 
jedenfalls in der Theorie schonmal weiter. :D

Ich werde das Konzepz von oldmax ziemlich übernehmen. Leuchtet alles 
sehr gut ein. Ich werde schonmal bauartgleiche Slaves haben, die 
entweder die Pins als Eingang, als Ausgang nutzen, oder einen 
Gleichstrom von 0-10 Volt ausgeben. Werd ich wascheinlich über 
Steckbrücken lösen.

Die Slaves werden aus 2 DIP-Schaltern, mit je 8 Schaltern bestehen (Für 
die Adresse). Diese werden an ein Schieberegister Angeschlossen, welches 
dann an einem ATmega128 angeschlossen wird. Daher der ATmega128 2 USARTs 
hat kann ich das obere Konzept übernehmen. Der Master wird ein einziger 
MAX232 sein, der die Daten von dem letzten Slave an den PC schick, und 
die daten vom PC an den ersten Slave schickt.

Die I/O geschichte ist ja jetzt kein großes thema, jedoch die 0-10 Volt 
wird lustig :D Daher das ganze ja nur eine Betriebsspannung von 5 Volt 
hat, werd ich die voltzahl vom Ausgang über einen DC/DC Wandler 
verdoppeln müssen.
(Die Spannung wird eine Steuerspannung für einen Dimmer sein.)

Ein "Protokoll" hab ich mir durch obriges dann auch schon 
zusammengedacht.

[Adress Byte][Adress Byte][Nutzbyte (Welcher pin An/Aus)][Schaltbyte (An 
oder Aus)]

Soweit so gut.

Nur was ich bisher nicht verstanden hab, wenn die Daten dann am UART 
ankommen, ist das ja sogesehen eine ellenlange 1/0 zahlenfolge.(Hier 
jehweils dann 32 Bit lang) Wie klappt das denn, das der Chip diese 
Zahlenfolge an genau den richtigen Stellen aufteilt. Wie das 
Programmiertechnisch gelöst wird hab ich keine Idee.

Die Schieberegister werd ich mir auch noch irgendwo ein Beispiel 
raussuchen müssen, das ich das Programmiert bekomme. Aber immerhin ich 
bin schonmal weiter.

Ich werd mir demnächst mal die Teile dafür besorgen und auf nem 
Seckbrett mal (In einzelne Teile unterteilt) das ganze zusammenstecken, 
und sehn was so rauskommt. :D

Gruß: maesto

PS: Achja vielen Dank für die jetzt schon so Zahlreichen Antworten :D

Autor: Lucas W. (maesto)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hehe musste gerade feststellen das es den ATmega 128 nur im TQFP Gehäuse 
gibt...

Gibt es da irgendne möglichkeit wie man den auch auf ein Steckbrett 
bekommt ich will mir ja für die anfänge nicht die Finger wund löten.

(Abgesehen davon das er bei mir dann warscheinlich beim versuch den 
irgendwie auf Lochraster o.ä. zu kriegen beim Löten den Hitzetod sterben 
würde :D )

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Gibt es da irgendne möglichkeit wie man den auch auf ein Steckbrett
>bekommt ich will mir ja für die anfänge nicht die Finger wund löten.

Auf Lochraster ist hiermit kein Problem:
http://www.futurlec.com/SMD_Adapters.shtml

Warum einen Mega128? Nimm doch was im DIP-Gehäuse.

Autor: Lucas W. (maesto)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werd mich warscheinlich nochmal umsehen welcher chip noch in frage 
kommt. Der ATmega 162 wirds warscheinlich :D

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.