URXC - Interrupt im Programm steuern (Bascom)

lwl

Neues Mitglied
10. Mai 2012
5
0
0
38
Sprachen
Hey,

ich habe eine Frage, kann man den URXC - Interrupt in einem laufenden Programm für eine gewisse Zeit (z.B. 1 Sec) deaktivieren und anschließend Aktivieren?

Ich habe nämlich folgendes vor:

Ich möchte mir ein RS485 Netz aus AVRs (Tiny2313 und Mega644p) aufbauen. Es soll ein 2 Draht Bus werden, ich weiß man muss dann zwischen den Datenrichtungen umschalten also senden und empfangen. Es soll ein Single Master Multi Slave System am Ende stehen. In der Form, der Master übergibt ein Befehl (Zieladresse,Quelladresse,Daten[*],Festgelegter Schlusswert)

[*]
Code:
Daten vom Master: t=abfragen (t wäre in dem Fall für Temperatur)
Daten vom Slave:   t=21,5

und die Slaves sollen im gleichen Muster antworten. Aber nur Antworten wenn sie gefragt werden. Ich habe nach einer ganzen weite googlen nun etwas gefunden, was mir helfen kann:

Den URXC - Interrupt, mit dem ich einkommende Zeichen in eine Variable oder ein Array packen kann. Nun meine Überlegung, die ersten 8 Bits (Ziel und Quelladresse soll im Binärsystem übertragen werden) die das Ziel definieren sollen abgefragt werden, sobald diese empfangen wurden soll im Interrupt überprüft werden, ob der Slave gemeint ist oder nicht, wenn nicht soll der Interrupt für 1 Sec oder so deaktiviert damit das Hauptprogramm nicht immer wieder unterbrochen wird. Also kurz um, damit der Slave nicht zu viel Müll erhält, den er dann nach erhalt der ganzen Nachricht erst entschlüsselt und überprüft, war es über für mich.

Oder ist es im allgemeinen einfacher das gesamte Datenpäkchen zu erhalten und erst dann zu konntrollieren? Oder ist es ggf. nicht möglich / total blödsinnig wärend der Laufzeit diesen Interrupt zu aktivieren / deaktivieren?

Dazu noch eine Frage, für mein Vorhaben ist der 2 Drahtbus eigentlich das vorteilhafteste, was ich tuen kann? Hab nämlich auch schon gesehen, es gibt alternativ ein 4 Draht Bus, wo Sende- und Empfangsleitungen getrennt sind. Kann das ggf. bei meinem Projekt Vorteile bringen? Wenn ja was für Bustreiber benötige ich eigentlich dann?

Kann mir da jemand zufällig einen Typ nennen? Und ist es für jede Baugruppe der gleiche? Also für Master und die Slaves?



Ich hoffe mir kann jemand helfen, wenn jemand extreme Schwachstellen an meinem vorhaben Sieht, bitte kurze Rückmeldung bzw. Tipps, wie es besser klappen könnte.



Michael
 
Hallo Michael,

natürlich kannst Du den UART-Recieve-Complete-Interrupt jederzeit aktivieren und deaktivieren. Dafür muß einfach das entsprechende Interrupt-Befähigungsbit gesetzt/gelöscht werden. Beim Mega88 ist das zB RXCIE0 in UCSR0B. Unter Bascom gibts dafür sicher 'ne enable... bzw disable... Funktion.
Alternativ könnte man mit dem Bit RXEN (im selben Register) einfach den ganzen Reciever an/abschalten.

Für das Timing muß dann natürlich ein Timer herhalten, der aber vielleicht eh schon irgendwas sinniges macht, und das nebenbei erledigt.

ABER:
Warum abschalten? Du mußt doch sowieso erstmal auf Deine Adresse lauschen. Wenn die Telegramme eh 'ne feste Struktur haben müssen, und Du erstmal die Adresse prüfen mußt, kannst Du doch ein "Telegramm-interessiert-mich-nicht"-Flag einführen und bei falscher Adresse setzen. Wenn das gesetzt ist, ignorierst Du die eingehenden Bytes bis zum nächsten Telegramm.
Oder Du zechnest das Telegramm komplett auf, und wertest danach das Adressbyte aus.
 
Ich meinte ja, wenn nach erhalt der Adresse erst abschalten, wenn die falsche Adresse es ist. Aber evtl. mach ichs mit dem komplett einlesen und einfach per Interrupt die Information erst in Strings schreiben und dann über ein internen Zähler alles in einen Array schreiben. also erste Array Element: Zieladresse, 2te: Quelladresse,... . Vielleicht änder ich das Datenpaket also die Zusammenstellung noch ein mal.

Müsste nur gucken, dass alle Daten den gleichen Typ und länge haben.

Aber was wäre den mit der Verdrahtung? Was wäre besser?

Gibts sonst noch ggf. Tipps aus Erfahrungen?



Michael
 
Warum soll es unbedingt der UART sein?
Dein Problem ist nämlich, daß immer nur ein Slave im Netz seinen Sender (Tx) aktiviert haben darf. Da es ja praktisch unvermeidbar ist, daß die unterschiedlichen Slaves unterschiedliche Pegel auf Leitung Slaves-->Master legst, hast Du da Quasi 'n Kurzschluß.
Du müßtest sicherstellen, daß nur der adressierte Slave seinen Transmitter aktiviert. und auch rechtzeitig deaktiviert. Ansonsten muß der Pin immer Tristate sein. Wie das jetzt mit, ggf dazwischengeschalteten Pegelwandlern (für RS232/485) ist, weiß ich nicht.

Was spricht gegen SPI oder TWI?
 
Dagegen spricht die Reichweite weil i2c und SPI Bus nur mit kurzen Verbindungsleitungen klappt und RS485 kann auch über bis zu mehreren 100 m funktionieren. Und das ist das primäre was sonst Probleme geben könnte. Und wenn man das Protokoll vernünftig erstellt sollte es normal nich passieren, dass mehr als ein Gerät den Bustreiber auf Senden stellt. Im Normalfall sollen alle Bustreiber auf empfangen stehen, zumindest habe ich das auf mehren Webseiten gelesen. Zumindest im 2 Drahtbus ist es ja mit dem hin und herschalten so.

Ein freier Gedanke von mir, wo ich hoffe nicht gesteinigt zu werden:

Alternativ könnte man noch eine weitere Ader mit geben, die von einem Gerät zusätzlich auf High gesetz wird und alle anderen diesen Draht überwachen und sobald dort ein High liegt, kann dieser nicht umschalten. Nur ob dies auch bei größeren reichweiten geht weiß ich nicht und wie weit sowas Störungsfrei ist. Vorallem würden so 2 Pins zusätzlich blockiert werden.



Michael
 
Hallo Michael!

Hast du dir mal den Thread von Markus angesehen?
RS485 Systembus

Auch wenn er dort mit BASCOM gearbeitet hat, könnte der ganze Thread doch einige Infos für dich enthalten. :wink:


Grüße,
Cassio
 
Nein, wenn Du bei 'nem AVR den Hardware UART-Transmitter aktivierst, wird der korrespondierende TxD-Pin zum Ausgang, hat also immer einen aktiven TTL-Pegel. Vcc oder Gnd.
Ohne was dazwischen muß also sichergestellt sein, daß nie mehrere AVR mit verbundenen TxD-Pins gleichzeitig ihren Transmitter aktivieren können.

ABER:

Du willst ja zwischen den UART-Bus und jeden AVR einen Bustreiber setzen (eben den MAX485 bzw ein entsprechendes Derivat). Wie das mit dem elektrischen Schutz bei mehreren Sendern auf einer Leitung ist, weiß ich da auch nicht, aber wenn die Signale auf dem Bus Sinn ergeben sollen, mußt Du auch da die stummen Transmitter abschalten. Dafür haben die ICs aber AFAIK entsprechende Enable-Pins. Entsprechend kannst Du auch den Empfangszweig im Treiber abschalten/unterbrechen lassen. Wie stellst Du nach dem wiedereinschalten des Empfängers im Slave sicher, daß nicht grad ein Telegramm über den Bus läuft, wo zufällig das erste Byte der Adresse des Slaves entspricht (aber eben Bestandteil der Nachricht ist)? Also daß der Slave sich dann adressiert fühlt?
Letztendlich ist alles eine Frage Deines Protokolles.
Gibt es reservierte Bytes? (zB für Telegrammstart/-ende)
Gibt es eine saubere Struktur der (möglichen) Telegramme?
Wie sollen verstümmelte Telegramme behandelt werden, wie/wann wird dann insbesondere der Bus wieder freigegeben?
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)