www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS422 / RS485 - Bus Suche Lib für Protokoll


Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
was ich suche ist eine Lib für Bascom, mit der man auf einen RS422/ 
RS485 Bus schreiben und lesen kann. Das Protokoll sollte 
Multimaster-fähig sein.

Hat jemand bereits eine fertibe Bibliothek oder ein Modul, zum 
Einbinden?
Es muß sich an keinen Standard halten, aber es sollte stabil laufen. 
Kann auch was selbst geschriebenes sein!

Kann mir jemand weiter helfen?
Micha.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Ich möchte ein Bussystem mit RS422 aufbauen, welches in 
Halbduplex-Verfahren betrieben wird. Alle am Bus angeschlossenen 
Teilnehmer können Master oder Slaves sein. Jeder Teilnehmer hat eine 
eigene Adresse. Im Bus kann nur ein Master eine Verbindung zu einem 
Slave/Master herstellen. Ein Slave soll aber die Möglichkeit haben, 
SEINEN Master im Bus zu benachrichtigen, wenn sich wichtiges am Client 
tut.

Hierfür benötige ich ein Protokoll. Gerne als fertige Library oder 
Routinen, die ich verwenden kann.

Das Protokoll stelle ich mir in etwa so vor:

Ein Master will eine Verbindung zu einem Slave herstellen, dann schreibt 
er ein Startbyte, Die SlaveAdresse, Ein Controllbyte und eine Checksumme 
auf den Bus. Das Controllbyte zeigt dem Slave an, daß eine Verbindung 
hergestellt werden soll. Ist die empfangene Adresse die Slaveadresse, 
wird er aktiv und sendet eine Bestätogung zurück. Somit steht die 
Verbindung.

Wenn nun Daten verlohren gehen auf dem Bus, ein Störsignal die Daten 
überlagert, erkennt der Slave anhand der Checksumme, das Die Daten nicht 
korrekt übermittelt wurden und verhält sich still (keine Antwort).

Der Master wartet eine angemessene Zeit, und wenn keine Antwort kommt, 
sendet er seinen Verbindungsversuch erneut.

Um die Verbindung zu trennen, sendet der Master an den Slave 
(ControlByte) den Wunsch die Verbindung zu trennen. Wenn der Slave dies 
Bestätigt, ist der Bus wieder Frei.

Wenn eine Verbindung auf dem Bus besteht, haben alle anderen Master und 
Slaves auf dem Bus sich still zu verhalten, bis die Verbindung getrennt 
ist.

Wenn ein Slave SEINEN Master Benachrichtigen will, weil wichtige Daten 
für ihn bereit stehen, so schreibt er das Startbyte, die MasterAdresse 
seines Masters und das Controllbyte (Benachrichtigung) sowie die 
Checksumme auf den Bus. Der Master miß dies bestätigen, dann steht die 
Verbindung. Der Slave wartet auch hier nur eine angemessene Zeit auf die 
Bestätigung des Masters. Trifft sie nicht ein, so wiederholt der Slave 
seine Benachrichtigung.

Grundsätzlich lesen alle Master und Slaves die Daten auf dem Bus mit und 
erkennen so, ob der Bus frei oder Belegt ist. Nur wenn der Bus frei ist, 
kann jeder Master eine Verbindung zu jedem Teilnehmer herstellen oder 
ein Slave eine Benachrichtigung absetzen.

So:

Ich tu mich aber schwer das ich Bascom umzusetzen. Kann mir jemand 
weiter helfen? Canbus möchte ich nicht nehmen, habe mich auf RS422 
festgelegt.

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey, CAN hat alles was du brauchst und ist total easy anzusteuern. Da 
brauchst du dich um fast nichts zu kümmern. Im gegensatzt zu RS422 must 
du dich um Buskollisionen und sowas selber kümmern, und dabei wird es 
dann sehr aufwendig.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soweit ich weiß hat der CAN aber ein Problem mit der Kabellänge. Und 
irgendetwas am CanBus-Timing hat mich auch gestört.

Was die Kollisionen beim RS422-Bus betrifft, dürften sich Kollisionen 
sehr leicht daran erkennen lassen, wenn die Checksumme nicht mehr 
stimmt.

Kannst du mir da vielleicht nicht doch weiter helfen?

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha R. wrote:
> Soweit ich weiß hat der CAN aber ein Problem mit der Kabellänge. Und
> irgendetwas am CanBus-Timing hat mich auch gestört.
>
> Was die Kollisionen beim RS422-Bus betrifft, dürften sich Kollisionen
> sehr leicht daran erkennen lassen, wenn die Checksumme nicht mehr
> stimmt.
>
> Kannst du mir da vielleicht nicht doch weiter helfen?

Hallo Micha,

mal zum Thema Bussysteme!

1.) Was willst Du übertragen? Datenpakete mit fixer Größe oder 
dynamischer
   Größe?
2.) Die Länge der Datenpakete? Kleine (so bis 8 Byte) oder Große?

3.) Übertragungsgeschwindigkeit max. ?

4.) Max. Länge des Busstranges? 10m ? 100m ? 1KM ?

5.) Wieviele Teilnehmer ?

CAN ist für große Datenpakete nicht geeignet, da an jeden 8 Byte nochmal
eine ganze Menge Identifier etc. dranhängt. Da nimmt die Nutzdatenrate
ab.

Was Du beschreibst klingt ganz nach einer Art Profibus DP.
Dieser basiert auch auf einer Art RS485 mit Differenzialpegel, 
halbduplex.
BASCOM ist natürlich nicht gerade die geeignete Sprache, um ein 
Datenprotokoll auf einem µC von Hand zu managen.

Ich habe mal ein RS485 Protokoll mit einem kleinen ATtiny2313 mit UART
realisiert. Der Chip hat das gesamte Bushandling gemacht und die Daten
daraus extrahiert.
Es waren dann im Prinzip viele kleine StandAlone BusController, die ihre 
Daten dann jeweils an Ihr Zielsystem übergeben haben.

Dirk

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also im Hinterkopf habe ich ein Bus, der nicht nach 3 m aufhört, sondern 
sollte durchaus Längen von etwa 500m überbrücken können.

Die Datenrate sollte bei 9600 Baud, vielleicht auch 19200Baud liegen.
Über den Bus sollen Nutzdaten beliebiger Länge transportiert werden, die 
aber ab einer bestimmten Länge Blockweise, vielleicht 256Byte-Blöcke, 
übertragen werden.

Die Teilnehmerzahl will ich auf RS422 bedingt mit 128 maximal 
beibehalten. Sollten es mehr teilnehmer werden, so soll das über 
Bus-Repieter erweiterbar sein.

Hintergrund des Systems ist, ihn universell einsetzbar zu machen. Sei es 
als Hausbus oder als Steuerbus/Controlbus für Geräte aller Art.

Ich will dies als Modul oder Bibliothek realisieren, damit ich diese 
einfach in neue Bascom-Projekte einbinden kann.

Mir fällt da nichts besseres ein, als der RS422 bus.

Sind deine Fragen soweit beantwortet?

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Mir fällt da nichts besseres ein, als der RS422 bus.

Kleiner Hinweis:
RS422 spezifiziert eine Punkt-Zu-Punkt-Verbindung mit differentieller 
Signalübertragung (Differentielles Gegenstück zu RS232).

Was Du suchst ist ein RS485-Bus.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und wo liegt da der Unterschied?
RS422 und RS485?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du eine fertige Lib findest, in der die Probleme, die mit 
Multi-Master-RS485 einhergehen, gelöst sind - ok.

Wenn nicht, dürfte es einfacher sein, grössere Datenmengen in 
CAN-Häppchen zu zerlegen, als dem RS485 einen stabilen Multi-Master 
Betrieb beizubringen. Und 500m sind bei der von dir angepeilten 
Datenrate auch kein Problem.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe zuhause RS422-Treiberbausteine und die will ich auch verwenden.
CAN ist für mich abgehakt.

Wenn du nich eine Idee hast, wie du mir halfen kannst?

Vielleicht möchtest du ja ein Protokoll mit mir zusammen entwerfen? -> 
Für RS422!

Autor: Micha R. (michaavr)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier in Anhang habe ich mal den Ansatz des Protokolls gepostet.
Vielleicht willst du dir das mal anschauen!

Autor: lektrikman1001 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

mit RS422 und den wünschen von dir ist nicht ganz so passend

siehe:
http://de.wikipedia.org/wiki/RS422

ist ein punkt-zu-punkt verbindung und eingeschränkt als bus mit nur 
einen sender zu gebrauchen.

RS485 wäre der richtige.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Link, da steht aber nichts drin, was ich nicht schon weiß.
Hast du noch einen Vorschlag?

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß auch, daß nur ein Master im RS422 Bus geht.
Aber ich hatte weiter oben schon mal geschrieben, daß wenn ein Master 
eine Vervindung hergestellt hat, alle anderen Teilnehmer warten müssen, 
bis der Bus wieder frei ist. Erst dann kann ein Master wieder eine 
Vervindung herstellen.

Es ist also immer nur eine Verbindung aktiv.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lektrikman1001 wrote:
> Moin,
>
> mit RS422 und den wünschen von dir ist nicht ganz so passend
>
> siehe:
> http://de.wikipedia.org/wiki/RS422
>
> ist ein punkt-zu-punkt verbindung und eingeschränkt als bus mit nur
> einen sender zu gebrauchen.
>
> RS485 wäre der richtige.

@Micha R.

So ist es, wie schon geschrieben.
RS422 macht zum Beispiel Sinn, wenn Du eine RS232 fit für größere 
Datenraten,
Entfernungen und Störanfälligkeit machen möchtest. Dann auf RS422 gehen.

RS485 ist vom physikalischen Prinzip gleich wie RS422, jedoch statt 2 
Paaren
nur ein Paar (2 Leitungen).
Gesendet und Empfangen wird auf der selben Leitung.
In der Regel lauschen alle Busteilnehmer den Datenverkehr ab. Der 
Treiber
zum Senden wird über einen DriverEnable Eingang am RS485 IC 
zugeschaltet.
Das Management, wann wer sendet, für wen welche Daten sind, so daß 
Buskollisionen vermieden (oder kontrolliert ausgewertet) werden, mußt Du 
selbst in die Hand nehmen. Es gibt schon eine Reihe von Anwendungen mit 
"Quasi" Standards, doch es wird nie einer so sein, daß er Deinen 
Ansprüchen gerecht wird.

Mal ganz grundsätzlich:

Bei 500m und 19200 (RS485) sollte kein Problem sein. Könntest sogar noch 
höher gehen.
Mir ist nur nicht ganz klar, wozu Du 128 Busteilnehmer brauchst, 
Multimasterfähig und dann noch bei 19200 Baud?

Da geht Deine Reaktionszeit aber mächtig in den Keller.
Ins Protokoll solltest Du auch noch versch. Sicherheitsvorkehrungen
einbauen. Außerdem Sollte auf jeden Teilnehmer kontinuierlich ein
PING ausgeführt werden, um zu sehen, ob er noch am Bus ist.

Beispiel:
Wir haben hier Projekte mit Profibus DP. Netzausdehnung bis zu 1KM.
(Wird dann allerdings über LWLs erweitert)
Fahren so mit 500Kb - 1.5 Mbit bei max. 60 Teilnehmer.
Da kommt der Bus vom Realtime Verhalten schon mächtig ins schwitzen.

Nochmal und ich will es Dir damit nicht ausreden.

Wenn Du Deine Applikation mit BASCOM programmierst und das Handling der
Schnittstelle auf dem gleichen µC laufen lässt, wie Deine Applikation, 
wirst Du einige Schwierigkeiten in Kauf nehmen müssen.

Außerdem:
Bei den RS485 Bausteinen gibt es ganz versch. Ausführungen, was 
Datenrate
und max. Nodes (Teilnehmer) angeht.

Dirk

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine sinnvolle Kollisionserkennung wirst du in Bascom nicht hin bekommen 
-> Löse das Problem also in Hardware.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist keineswegst vorgesehen, die 128 möglichen Busteilnehmer 
auszureizen, im Fall es aber nicht reichen sillte, habe ich mir 
vorgestellt, einen Repeater zu verwenden. Der hat auch eine feste 
Adresse und stellt eine Brücke zwischen 2 Bussen dar.

Als Protokoll habe ich bir vorgestellt, ein Startbyte zu senden, dem 3 
weitere Bytes Folgen. Das zweite Byte ist das Adressbyte, das Dritte ein 
Control-Status-Byte, welches dem Empfänger sagt, was es mit diesem Paket 
auf sich hat. (Verbindung Aufbauen, trennen oder Benachrichtigung oder 
Daten Anhängig). Das letzte Byte ist eine 1Byte-Checksumme.

Startbyte|SlaveAdresse|ControllByte|Checksumme

Diese vier Byte werden gesendet zum Aufbauen einer Verbindung, trennen 
einer Verbindung und als Benachricktigungs-Paket.

Bei Datenübertragung muß eine Verbindung bereits hergestellt sein. Der 
Aufbau des Pakets ist dann so:

Datenlänge (WORD)|die daten stehen hier|Checksumme

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reicht es als Kollisionserkennung nicht aus, das ChecksumByte zu prüfen?

Stimmt diese Checksumme nicht, sendet der Slave kein Acknowledge.
Der Sender wartet aber nur eine kurze Zeit auf dieses Signal. Kommt es 
nicht an, so stimmt etwas nicht und prüft seinen eigenen Dateneingang.

Jetzt kann er das Paket ja nochmal losschicken. Das wiederholt er so 
oft, bis es klappt.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Micha

weisst Du, was im Falle einer Kollision passieren kann?
Es ist fraglich, ob Deine UART überhaupt noch ein Bit erkennt, wenn sich
die Signale mehrerer sendenden Teilnehmer überlagert.

Außerdem einen Datenstring zum Verbindungsaufbau und noch einen anderen
zur Datenübertragung ist absolut nicht ratsam.

Überlege Dir lieber einen mit einer fixen Länge, wo alle benötigten
Daten schon enthalten sind und übertrage Deine Nutzdaten von versch. 
Längen
kaskadiert in mehreren Datenpaketen.

Dirk

Autor: lektrikman1001 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert


und wie wäre es mit SNAP?

http://www.hth.com/snap/

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß nicht, ob ich mich nicht klar ausdrücke.

Aber wenn 2 Sender gleichzeitig senden, kommt beim empfänger Müll an. 
Also stimmt die Checksumme nicht.

Da jeder Sender nun eine Zeit abwartet und feststellt, daß keine 
Bestätigung kommt, versuchen beide Sender erneut zu senden.

Um sucher zu stellen, daß sie nicht wieder gleichzeitig senden, müssen 
sie eine zufällig erzeugte Zeit von beispielsweise 1 bis 200ms abwarten 
und dann den eigenen Empfangspuffer prüfen, ist der leer, sendet er 
nochmal.

Das müßte doch klappen.

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmier es einfach und teste es aus.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha R. wrote:
> Ich weiß nicht, ob ich mich nicht klar ausdrücke.
>
Ich weiss nicht, ob Du es klar verstehst?! ;-)


> Aber wenn 2 Sender gleichzeitig senden, kommt beim empfänger Müll an.

Ja, bei allen Empfängern.

> Also stimmt die Checksumme nicht.
>

Die wirst Du garnicht auswerten können, wenn Deine UART die eingehenden
Daten nicht mehr entziffern kann.

> Da jeder Sender nun eine Zeit abwartet und feststellt, daß keine
> Bestätigung kommt, versuchen beide Sender erneut zu senden.
>

Bei der Datenrate sehr schlecht.
Wie soll den eine "normale" UART während des Empfangs eines Bytes 
mitteilen, daß Sie gerade empängt. Das merkst Du erst, wenn es komplett 
ist. Und wenn in dieser Zeit ein anderer Teilnehmer anfängt zu 
schreiben,
ist wieder alles kapput.

> Um sucher zu stellen, daß sie nicht wieder gleichzeitig senden, müssen
> sie eine zufällig erzeugte Zeit von beispielsweise 1 bis 200ms abwarten
> und dann den eigenen Empfangspuffer prüfen, ist der leer, sendet er
> nochmal.

Ja, so ähnlich wars ,mal bei Ethernet 10BASE-T.
Bei 19200 Baud geht dann ja garnichts mehr. Die Chance, daß eine 
Kollision sich wiederholt ist groß.
Wenn Du dann noch jeden Teilnehmer zum Master machst "prost mahlzeit".

>
> Das müßte doch klappen.

Müssen ist der Wunschvater des Gedankens.

Wie wäre die übliche Methode, daß die Master sich untereinander einen 
Token
umher reichen. Kann man auch als "Absprache" bezeichen.

Dirk

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfach ausprobieren klingt gut. Ich habe das Problem mit der Umsetzung 
in Bascom-Code.

Das Protokoll selbst müßte funktionieren.

Hier nochmal:

Master baut Verbindung auf mit Client

SOH - Start of Header                (0x01)
ADR - Adresse des Clienten           (0xNN)
CSB - Control- und Statusbyte        (0x01)
SUM - Checksumme aus Byte 1 bis 3    (0xNN)

Client liest Header und prüft.

Fall 1:
  Checksumme falsch, der Slave bleibt still.

  Dies dritt ein, wenn Störsignale den Bus beeinflussen,
  2 Sender gleichzeitig senden oder
  ein Byte unterwegs verlohren geht.

Fall 2:
  Die Checksumme stimmt.
  Der Slave prüft, ob die übermittelte Adresse und die eigene Adresse
  übereinstimmt. Der Slave prüft außerdem den Wert vom
  CSB-Byte (Controlbyte), welches angibt ob eine Verbindung hergestellt
  oder getrennt werden soll.

  Soll eine Verbindung hergestellt werden und ADR-Byte stimmt überein,
  sendet er eine Bestätigung:

SOH - Start of Header (0x01)
ADR - Slave-Adresse   (0xNN)
CSB - Bestätigung     (0x01)
SUM - Checksumme      (0xNN)

Erst jetzt steht die Verbinding und alle Busteilnehmer wissen bescheid, 
daß der Bus belegt ist.

Trennen der Verbindung erfolgt ähnlich.

Das CSB-Byte bestimmt durch seinen wert, was dieses Paket bedeutet.

z.B.:

0x01 - OpenRequest
0x02 - CloseRequest
0x03 - OpenACK
0x04 - CloseACK
0x05 - DataAppend

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha R. wrote:
> Einfach ausprobieren klingt gut. Ich habe das Problem mit der Umsetzung
> in Bascom-Code.
>
Dann programmiere sowas nicht in BASCOM.
Jede Programmiersprache hat nun mal ihre Einschränkungen.

> Das Protokoll selbst müßte funktionieren.
>

Probiers aus.


Dirk

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Viel Spass bei der Kollisionserkennung, vor allem wenn du partout 
vorhandene RS4xx-Bausteine verwenden willst. Die sind nämlich nicht auf 
Kollisionen als normalem Betriebszustand eingerichtet (zwar 
kurzschlussfest, ergibt aber keine definierten Pegel), und es ist daher 
keineswegs sicher, dass alle Busteilnehmer dazu die gleichen Ansichten 
haben, d.h. was dem einen seine Kollision kann für den anderen noch ok 
sein.

Leichter tut man sich, wenn man für solche Busse zumindest die 
Transceiver von CAN verwendet, wenn's schon nicht die Signalisierung 
sein soll. Die haben nämlich bei Kollision ein sauber definertes 
Verhalten.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gebs auf!

Ich Programmiere schon zu lange (auch in VB) und habe die Erfahrung 
gemacht, daß es immer eine Lösung gibt. Auch mit Bascom wird sich eine 
finden!

Aber wenn von euch einer Fit in Assembler ist, darf er sich gerne 
versuchen und mir bescheid geben. Ich bin jedenfalls nach wie vor der 
Meinung, das es Funktionieren wird.

Die einzigste Kollision die passieren Kann ist die, daß 2 Master zur 
gleichen Zeit senden. Das wird aber vom Slave erkannt, wenn die 
Checksumme nicht überein stimmt. Wenn das Adressbyte zerstört wäre, 
reagiert er sowieso nicht. Wird das Startbyte nicht erkannt, liest der 
Slave solange ein, bis er eins im Puffer findet (Synchronisieren) und 
wertet ab da den Header aus.

Wird ein Header richtig erkannt, erkennen alle anderen Slaves den Header 
auch und wissen nun, ob eine Verbindung aufgebaut werden soll oder nicht 
und somit, ob der Bus belegt ist. In solch einem Fall wird von anderen 
Busteilnehmern gar nicht erst versucht, Verbindung herzustellen oder 
eine Benachrichtigung abzusetzen.

Die Synchronisation ist ja somit gewärleistet. Ist der Bus von einem 
Master belegt worden, haben alle anderen nur zu lauschen, bis der Bus 
Explizit freigegeben wird.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist bekannt, daß wenn 2 Rs422 Transeiver zur gleichen Zeit auf den 
Bus Schreiben, das Signal auf dem Bus undefiniert ist. Das macht aber 
kein abbruch, den alle Slaves werden dann den gleichen undefinierten 
Pegel erkennen. Entweder H oder L. Kurz: Alle Slaves erkennen dann den 
gleichen Pegel. An der Checksumme spätestens word erkannt, ob Daten 
Korrekt sind oder nicht.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beispiel: 2 Möchtegern-Master sind 500m weit auseinander. Hier sind 
E-Techniker gefragt: Wie stehen die Chancen, dass keiner der beiden die 
Kollision erkennt, weil der Widerstand der Leitung dafür sorgt, dass 
sich auf jeder Seite der eigene Transmitter durchsetzt?

Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha,
ich hab was :
http://www.ibrtses.com/embedded/shortmsgprotocol.html
Das Protokol ist eigentlich multimasterfaehig wurde aber immer nur als 
master slave eingesetzt.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja und wo liegt das Problem?

Master 1 sendet an den 500 m weit entfernten Slave2. Neben dem Slave 2 
sitzt master 2, der an den Slave 1 direkt neben dem 500 m weit 
entfernten Master 1 sitzt.

Was passiert?
Das signal von Master 1 wird beim Slave 2 nicht mehr ankommen, weil das 
Signal dort von Master 2 überlagert wird. Durch prüfen der Checksumme, 
Startbyte und Controlbyte stellt Slave 2 fest, daß die Daten ungültig 
sind oder daß er gar nicht gemeint ist. Folglich wird master 1 nach 
einer gewissen Zeit erneut einen Sendeversuch starten. Umgekehrt 
natürlich auch Master 2.

Wo lieg das Problem?

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi rene, ich schau mir das mal an, danke für den Hinweis.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A.K. wrote:
> Beispiel: 2 Möchtegern-Master sind 500m weit auseinander. Hier sind
> E-Techniker gefragt: Wie stehen die Chancen, dass keiner der beiden die
> Kollision erkennt, weil der Widerstand der Leitung dafür sorgt, dass
> sich auf jeder Seite der eigene Transmitter durchsetzt?

@A.K.

lol

Die Lösung ist ganz einfach.
Der Eine Master ist für die 64 Slaves in West-Richtung, der andere für 
die 64
in Süd-Richtung zuständiges.
Ähnliches Prinzip wie bei Mobil oder Rundfunk.

Übrigens ist es kein Problem mit RS485 Kollisionen zu erkennen.
FailSave sind Sie sowieso alle. Ein zusätzlicher Abgriff zwischen UART 
und RS485 macht Sinn.

Am besten wäre es, das Protokoll so zu gestalten, daß es im Normalfall 
keine Kollisionen gibt.

Dirk

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Satz "a slave device only answers to a command, doesn't transmit 
just by itself" würde ich mit "nicht für Multimaster-Betrieb konzipiert" 
übersetzen.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Am besten wäre es, das Protokoll so zu gestalten, daß es im
> Normalfall keine Kollisionen gibt.

Yep. Drum verwendet mal bei RS485 gerne das oben schon skizzierte Token 
Passing. Der Teufel steckt natürlich auch hier im Detail, aber sei's 
drum. Den Menschen Wille ist sein Himmelreich.

Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@AK
das Datenpacket ist passend fuer Multimaster, die Statusmaschine nicht 
ganz.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat jemand Interesse mit mir soetwas zu Programmieren?

Ja, dann bitte melden!

Autor: Macc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im wesentlich muss man nur zuruecklesen was man gesendet hat und 
vergleichen.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat jemand Interesse, mir seinen Lamborghini zu schenken?

Dann bitte auch melden!!!

@Micha

Willst Du etwas lernen oder benötigst Du eine Dienstleistung.
Außerdem, wenn es Dir jemand programmiert (C oder Ass) und es muß 
geändert
werden???

Dirk

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht hat ja jemand schon mal was passendes Programmiert was funzt?
Dann muß auch nichts mehr geändert werden.

Außerdem finde ich, es grenzt schon an Beleidigung:
"Willst du etwas lernen ober benötigst Du eine Dienstleistung?"

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deinen Lamborghini kannste auch behalten.

Wenn du nichts konstruktives beisteuern kannst, bist du hier falsch!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha R. wrote:
> Soweit ich weiß hat der CAN aber ein Problem mit der Kabellänge. Und
> irgendetwas am CanBus-Timing hat mich auch gestört.

Wenn Dir CAN zu einfach und zu zuverlässig ist, dann laß es eben 
bleiben.

Niemand zwingt Dich, den einfachsten Weg zu gehen.
Manche sind ja gerne Masochisten.

Heutzutage quält sich keiner mehr damit ab, für neue Projekte noch den 
antiquierten RS-485 als Multimaster zu programmieren.

Man findet bestimmt einige uralte RS-485 Implementationen, dürften aber 
allesamt in C geschrieben sein.


Peter

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Außerdem finde ich, es grenzt schon an Beleidigung:
>"Willst du etwas lernen ober benötigst Du eine Dienstleistung?"

Das musst du mal erklären. Das ist eine ganz normale Frage.

Das die Gemeinde der Bascom-Programmierer eher vom Typ "Anfänger" ist 
und der Projekt eher in die Robrik Fortgeschritten passt, wird es für 
dich wohl sehr schwer sein, jemanden zu finden, der dein Projekt in 
Bascom entwickeln möchte.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon allein das Problem:

Der Master sendet das letzte Byte und dann haut ein anderer Interrupt 
dazwischen und er kann nicht sofort nach dem Stopbit den Transmitter 
abschalten.

Der Slave hats empfangen, will antworten, aber der Sender hat noch immer 
seinen Transmitter enabled und der Slave kämpft nun dagegen und das 
Startbit geht flöten.


Und derlei Probleme gibts zuhauf bei RS-485.


Peter

Autor: Sven S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter Dannegger

ja can ist einfach besser. wer quält sich denn noch mit dem alten mist 
rumm ?

@Micha R.

>Soweit ich weiß hat der CAN aber ein Problem mit der Kabellänge.

125 kbit/s bei 500 m ist schon net schlecht.

die vorteile von can liegen klar auf der hand. das protokoll ist bereits 
festgelegt und es ist multi master fähig. die hardware von can und rs485 
nehmen sich nicht viel auser das rs485 nicht multimaster fähig ist.

gruss sven

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven S. wrote:
> @ Peter Dannegger
>
> ja can ist einfach besser. wer quält sich denn noch mit dem alten mist
> rumm ?

Na Masochisten eben ;)


Also wir haben auch nur die allerbesten Erfahrungen mit CAN.

Alle Geräte anstöpseln und läupt.

Ich geb zu, manchmal sind wir zu faul, den 2. Terminator anzustöpseln, 
läuft ja trotzdem.

Nur wenn mal 2 gleiche Geräte benötigt werden, muß man erstmal nur eins 
anstöpseln und die MAC-ID ändern.


Peter

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha R. wrote:
> Vielleicht hat ja jemand schon mal was passendes Programmiert was funzt?
> Dann muß auch nichts mehr geändert werden.
>
> Außerdem finde ich, es grenzt schon an Beleidigung:
> "Willst du etwas lernen ober benötigst Du eine Dienstleistung?"

Was soll daran eine Beleidigung sein ?
Dann bin ich demnächst beleidigt, wenn ich frage ob mir niemand einen 
neuen
CPU-Core entwickelt.
Das Forum ist dazu da, um Hilfestellung zu leisten und keine 
Fertiglösungen
zu präsentieren ohne daß Du Sie selbst durch dokumentierten Sourcecode
verstehen kannst. Wo liegt da der Sinn?

Natürlich ist CAN als Fertiglösung einfacher zu handhaben und Unmengen
von Controllern haben Ihn gleich mehrfach implementiert.

Ich dachte eher, er könnte durch eine "Handanbindung" etwas lernen und 
verstehen, was ihm auch in Bezug auf CAN nützlich wäre.

Nochmal zur RS485. Natürlich ist Sie "Multimaster-Fähig".
Es geht hier die physikalische Schnittstelle. Man kann sogar Profibus DP
mit bestimmten RS485 Treiber (auch nicht isoliert) betreiben.
Geschwindigkeit geht über 50Mbit hinaus. Nodes mit über 256.

Wie man das exakte Timimg erzeugt, ist einem selbst überlassen.
Wie gesagt, die Lösung, die ich damals mit ATtiny2313 realisiert hatte,
lief im Standalone Betrieb mit ca. 920Kbit.
Die hier genannten Kriterien wurden alle erfüllt.

Was mich an CAN stört sind die 8Byte Datenlänge.
Er ist eben nicht für die Übertagung von Datenstrings entwickelt worden
sondern für I/O Abbildung.
Wenn man dann noch die CANopen Protokolle DS301/401.... fährt,
bleibt nur ein Teil für die Nutzdaten erhalten.

Es kommt eben immer darauf an, welche Anforderungen man an den Bus 
stellt.


Also Micha.
Oben sind Dir immer wieder Ratschläge gegeben worden, die Du aber nicht 
hören wolltest. Warum fragst Du uns dann, wenn Du Deinen eigenen Stiefel
ohnehin durchziehen willst.
Bist dann sauer, wenn Dir keiner zustimmt und noch mehr sauer, daß 
keiner
sich mit BASCOM beschäftigt und Dir ein Rundumsorglos Paket abliefert.

Dirk

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn man dann noch die CANopen Protokolle DS301/401....
> fährt, bleibt nur ein Teil für die Nutzdaten erhalten.

Fraglos. Nur - wenn man CAN in völlig eigenem Kontext verwendet, weil 
man kein Auto dranstöpselt sondern nur eigenen Kram, und daher den 
ganzen CANopen-Kram in den Wind schiesst, dann vereinfacht sich manches.

Ich übertrage beispielsweise den kompletten Inhalt eines Dataflash via 
CAN und verwende auch mal die unteren x Bits der EID als Teil der Daten. 
Grössenordnungsmässig bleibt mir nur die halbe Datenrate übrig. Na und? 
Mir ist nur wichtig ob es ausreicht, nicht wieviel Prozent irgendeiner 
Nominalzahl ich ausnutze. Für hohe Raten ist Ethernet besser und 
mittlerweise ja auch controllertauglich.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A.K. wrote:

> Ich übertrage beispielsweise den kompletten Inhalt eines Dataflash via
> CAN und verwende auch mal die unteren x Bits der EID als Teil der Daten.

Für eine Kommunikation zwischen 2 Teilnehmern ist das OK aber nicht wenn 
128
dranhängen, die alle bedient werden müssen. Dann ist der USB Stick und 
ein paar Meter Fußweg wohl besser geeignet.

> Grössenordnungsmässig bleibt mir nur die halbe Datenrate übrig. Na und?
> Mir ist nur wichtig ob es ausreicht, nicht wieviel Prozent irgendeiner
> Nominalzahl ich ausnutze. Für hohe Raten ist Ethernet besser und
> mittlerweise ja auch controllertauglich.

Ethernet steht aber für diesen Anwendungsfall kaum zur Debatte.
Für 500m Leitungslänge? und eine Sternförmige Verbindung zu 128 
Teilnehmern.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yep, Ethernet geht hier nicht, klar. Es kommt allerdings vor, dass 
beides parallel sinnvoll ist, wenn über das Netz verschiedenartige 
Anforderungen mit unterschiedlicher Kabelage auftreten. Das wäre 
beispielsweise der Fall, wenn man ein Hausnetz aufbaut, in dem 
weitgehend kurze Sensor/Aktuatorinformation fliesst, aber an ein paar 
enger liegenden Knotenpunkten (z.B. Logger <=> PC) grössere Datenmengen 
anfallen.

Aber wenn er mit 9600 auszukommen meint, liegt er 125Kbps CAN weit 
jenseits dessen. Ok, wenn sternförmig dann dank unsauberem Abschluss 
keine 500m, also vielleicht mal ~50Kbps probieren. Bleibt immer noch 
genug Luft.

Und man kann auch bei 128 Teilnehmern einen Teil der ID ausnutzen, wenn 
man mit 29bit-IDs arbeitet. Dann wird zwar auch der Frame länger, aber 
die Nutzrate steigt trotzdem.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K.

mit Sternförmig und 500m meinte ich natürlich nicht CAN sondern
Ethernet.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mein Schlußwort zu diesem Thema:

Ich will nicht davon überzeugt werden, das irgend ein Bus, sei es 
CAN-Bus, Profibus, SNAP oder ein anderer Bus besser ist. Das will ich ja 
gar nicht bezweifeln.

Fakt ist, ich habe RS422 Transceiver zu hause, die ich verbauen möchte.
Dazu brauche ich ein einfaches Protokoll, das sicher stellt, daß die 
Daten auch beim Slave ankommen. Und ein Slave soll sich auch beim Master 
melden können. Nicht mehr und nicht weniger.

Ich will kein Rad neu erfinden.

Was ich hier gesucht habe ist ein Paar Ideen, Protokoll-Ansätze, oder 
jemand, der vielleicht schon mal in der gleichen Situation war wie ich, 
der mir hier etwas weiter helfen kann.

Was mein Problem so halbwegs beschreibt ist das SNAP-Protokoll.

Aber nun gut. Ich werde mal schauen, wie ich weiter komme.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha R. wrote:
> Hier mein Schlußwort zu diesem Thema:

> Fakt ist, ich habe RS422 Transceiver zu hause, die ich verbauen möchte.

@Micha

Nimm mir das jetzt bitte nicht übel.

"Ich habe eine Armprothese daheim liegen aber mit fehlt ein Bein."

Suchst Du Deine Projekte nach den Bauteilen die Du rumliegen hast aus
oder anders herum?

Dirk

Autor: Macc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha,
ein Master-Slave protokol kann auch verwendet werden, um den Slave zu 
fragen, ob er was hat. Man erspart sich Vieles, wenn man anstelle eines 
Multimaster Aufbaus nur einen Master-Slave hat.

Autor: lektrikman1001 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha R. wrote:

Hier mein Schlußwort zu diesem Thema:

Ich will nicht davon überzeugt werden, das irgend ein Bus, sei es
CAN-Bus, Profibus, SNAP oder ein anderer Bus besser ist. Das will ich ja
gar nicht bezweifeln.


DAS SNAP VON HTH.COM IST EIN PROTOKOLL UND KEIN BUS!!!

Autor: Jürgen D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha,

ich habe bei mir in der gesamten Haustechnik ein RS485-Bus mit dem 
SNAP-Protokoll implementiert .... und das ganze ebenfalls mit BASCOM. 
Alles easy-doing!
Probier es einfach aus. Auf der Webseite von hth.com gibt es zwei Bascom 
Examples und das Tools Snaplab, welches zum Testen mit dem PC für die 
ersten Sachen echt super ist.

Ich habe bei mir 70 Module am Bus und keinerlei Probleme (Dimmer, 
Temperatursensoren, Schaltaktoren, Bewegungsmelder, DCF77-Empfänger, 
etc.). Das ganze läuft mit 19200 bit/s.

Grüße -- Jürgen

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Micha

Ich hab jetzt nicht die Ahnung von Programmierung, aber zumindest 
hardwareseitig hab ich viel mit RS422/RS485 zu tun, und kann dir sagen, 
dass es mit einer Kollisionserkennung nichts wird. Die Treiber sind so 
"stark", dass der (eigene) Empfänger nicht mal mitbekommt, ob da am 
anderen Ende der Leitung ein Anderer gerade eas tut.
Hier hilft dann bei Multimasterbetrieb nur eine Art token passing 
Verfahren o.ä.. und das wird (wie oben schon erwähnt) aufwändig.

Nimm mir´s nicht übel: aber ich denke du hast mit Feldbussystemen bisher 
nicht soviel zu tun gehabt.
Warum willst du dann gleich die ultimative Supermaschine bauen (wofür 
renomierte Firmen schon Jahre gebraucht haben..). Das endet nur mit 
Frust und die Platine landet irgendwann im Müll.

Fang doch erstmal klein an, also einfaches Protokoll mit 
Master-Slave-System. Das ganze zyklisch abfragen - fertig.
Das ist nicht so schwer und der erste Erfolg stellt sich schnell ein.
Wenn du dich erstmal eingearbeitet hast, und ein Händchen für die 
auftretenden Probleme hast, kannst du dich auch an größere Sachen 
machen.
Stellt sich mir abschließend noch die Frage, wofür man bis zu 256Byte im
Block und dann bei 9600...19200kbps braucht. Da wird´s bei 128 TLN schon 
schwierig mal einen "freien Platz" im Bus zu bekommen. Üblicherweise 
sollten nur Steuerbefehle mit ein paar Byte über den Bus gehen, dann 
ist´s mit der gegebenen Übertragungsrate auch ok.

Autor: Micha R. (michaavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gast,

vielen Dank für deine Teilnahme. Was du schreibst weiß ich zu schätzen.
Nun warum ich diesen Aufwand betreibe und warum bis zu 256 Byte über den 
Bus gehen sollen und warum Multimaster usw. möchte ich hier kurz 
erklären.

Grundsätzlich fängt meine Idee mit einem Hausbus an. Also Lichschalter 
usw. abzufragen, Licht einschalten und so.

Nun stelle dir bitte mal ganz hypotetisch vor, du hast volgenden 
Sachverhalt: 1 Zimmer, eine Lampe in der Mitte und 2 Lichtschalter, die 
an gegenüberliegenden Wänden befestigt sind. Und jeder Lichtschalter hat 
noch eine Signalleuchte eingebaut, die nur dann leuchtet, wenn das Licht 
nicht eingeschaltet ist.

Wenn ich nun einen Master habe (der ist in einem der beiden 
Lichtschalter untergebracht, nennen wir ihn Schalter 1) und einen Slave 
(im anderen Schalter, den nennen Wir Schalter 2), wie soll die 
Kommunikation von Statten gehen?

Mein erster Gedanke, der Master fragt zunächst den direkt 
angeschlossenen Schalter ab, gedrück oder nicht, und schaltet dann das 
Licht ein oder aus und und setzt dann die Signallampe im Schalter 
ebenso. Nun muß er den Schalter 2 übermitteln, daß die Signallampe ein 
oder auszuschalten ist.

Wird nun aber am Schalter 2 gedrückt, so schaltet der Controller dort 
seine Signallampe aus und Wartet darauf, daß sich der Master irgend wann 
meldet und anfrägt, ob sich etwas getan hat. Schalter 2 sagt nun Ja, 
Lampe Einschalten und der Master (Schalter 1) schaltet nun die Lampe ein 
und seine Signallampe ebenso aus.

Dieses Verfahren bedeutet relativ viel Datenverkehr auf dem Bus. Wenn 
nun 100 Teilnehmer (Mehrere Zimmer, Stockwerke usw) am Bus hängen, würde 
es unter Umständen relativ Lange dauern (vielleicht ein paar Sekunden), 
bis die Lampe an geht, wenn Schalter 2 gedrückt ist. Derjenige der dann 
drückt mein es ist eine Störung und so und drückt zug male usw.

Deshalb hatte ich die Idee mit einer Benachrichtigung. Die läuft dann 
folgendermaßen ab: Der Bus wird nur beansprucht, wenn auch Daten zu 
Transferieren sind. Im Falle des Schalter 2 sendet der Controller ein 
Event auf den Bus (wenn der frei ist) mit seiner eigenen Adresse. Der 
Master lauscht wie jeder andere Teilnehmer am Bus auch, wenn er nicht 
gerade sendet, was da für Daten transferiert werden. Deshalb bekommt er 
auch mit, Daß da ein Teilnehmer ein Event verschickt hat. Der Master 
prüft nun, ob die gesendete Slave-Adresse in seiner Liste steht, also ob 
er darauf antworten soll oder nicht. Trifft dies zu, so sendet der 
Master eine Bestätigung an den Slave, der dann weiß, seine Nachricht ist 
angekommen. So nun Baut der Master eine "richtige" Verbindung zum Slave 
auf, die der dann Quittiert. Jetzt weiß der Master, seine Verbindung 
steht. Er kann auch davon ausgehen, daß alle anderen Busteilnehmer 
dieses Signal erreicht haben. Ist so eine "ungestörte" Verbindung 
hergestellt, dann sind alle Teilnehmer still und Lauschen nur, außer die 
zwei, die eine Verbindung haben. Das Verbindung bleibt so lange, bis der 
Master die Verbindung wieder trennt und der beteiligte Slave die auch 
Quitieren muß.

Die Reaktionszeit des Schalters ist somit kürzer (in der Regel) weil der 
Bus eigentlich nicht benutzt wird, außer es drück mal gerade jemand 
einen Schalter.

Soweit meine Idee.

Warum 128 Teilnehmer.
Nun es ist ja nur die obere Grenze was RS422/485 kann. Es kann ja 
durchaus sein, daß dann ein weiteres Zimmer hinzu kommt, an den selben 
Bus, oder man möchte noch eine Heizungsregelung an den Bus anschließen. 
Da sind schnell einige Teilnehmer zusammen.

Warum Multimaster.

Ich stelle mir vor, in einem Raum ist ein kleines Bedienteil an der 
Wand, da kann man dann z. B. Raumtemperatur vorwählen und andere dinge 
Konfigurieren. So hätte man in dem Raum schon 2 Master und 1 Slave.
Kommt ein weiterer Raum hinzu mit der selben Konstellation, sind es 
schon 4 Master und 2 Slave. In einem solchen Fall würde auch 1 Master 
und 2 Slave pro Zimmer genügen. Wobei jeder Master nur die Slaves in dem 
zugehörigen Zimmer bedient.

Sicherlich kann man hier auch 2 Busse verwenden. Aber das macht wenig 
Sinn, wenn man Beispielsweise noch einen PC anschließbar machen möchte, 
der den vollen Zugriff auf den Bus hat, also alle Master und Slaves im 
Bus kennt und somit ansprechen kann.

Deswegen Multimaster, weil ich mit dem PC auf die Busteilnehmer 
zugreifen können möchte. Also von meinem Schreibtisch aus wenn es ich so 
wollte das Garagentor zumachen oder nachsehen, ob es offen ist. Bei 
getrennten Bussen müßte ich runter zum Schalter an der Garage und dort 
drücken. Darum geht es.

Warum 256 Byte Daten-Pakete?

Es ist nur mal so eine vorsichtige Grenze, weniger gehen auch (64 Byte 
oder 128). Der Grund liegt darin, daß der Schalter an der Garage ja auch 
einen Controller hat, über den er am Bus angeschlossen ist. Wenn ich nun 
merke, die Software ist fehlerhaft und müßte neu programmiert werden, so 
müßte ich zur Garage, den Schalter ausbauen, und in der Werkstatt den 
Controller neu Programmieren. Anschließend den Schalter an der Garage 
wieder einbauen. Die Großen Datenpakete sind eigentlich dazu gedacht, 
die neue Software per Netz in den Schalter der Garage zu übertragen. 
Wobei das kein Paket mit fester Größe ist, sondern variabel 1 bis 64 
oder 128 Byte.

So war die ganze Überlegung.

Stell dir vor, du verbaust mehrere Schalter im Haus, und dann stellst du 
fest, das die Software an allen Controllern upgedatet werden müßte, dann 
haste ganz schön Arbeit, alles auszubauen, neu zu programmieren und 
wieder einzubauen.

Wie einfach oder Kompliziert das Protokoll dann technisch wird, kann ich 
nicht abschätzen, aber mit Sicherheit fallen einem immer wieder 
Verbesserungen am Netz ein und das frustet dann auch, wenn man sich im 
Vorfeld nicht schon mal ein paar gedanken gemacht hat.

Der andere Punkt ist, ob ich überhaupt einen solchen Aufwand betreiben 
möchte in einer Mietwohnung und alle Stromeinheiten auszutauschen. 
Warscheinlich nicht! So stellt sich natürlich auch mir die Frage, wozu 
dann überhaupt bus?

Nun die Antwort ist relativ einfach. Das Protokoll stellt ja nur die 
Mittel bereit, im Bus zu kommunizieren. Was dann dran hängt ist ja 
eigentlich egal. Man könnte da ja auch an eine Steuerung von einem 
Fließband denken, und einen Prüfablauf mit mehreren Prüfapparaturen 
steuern. Ich habe keine Ahnung was sonst noch. Aber Sinnlos wäre es 
nicht, dieses Protokoll.

Außerdem ist es sehr reizvoll, sich darüber gedanken zu machen.

Mir kam da beispielsweise auch mal eine Idee, nicht nur Lichtschalter an 
den Bus zu hängen, sondern auch Steckdosen. Warum STeckdosen fragst du 
dich jetzt vielleicht. Im Hinterkopf der Komputer, der auch am Bus 
hängt, kann ja auf alle Teilnehmer zugreifen. So könnte vom 
Arbeitszimmer z.B. die Kaffemaschine in der Küche eingeschaltet werden. 
Oder Nacht könnten die Steckdosen abgeschlatet werden, an denen 
Standby-Geräte hängen. Boiler könnten morgens rechzeitig eingeschaltet 
werden, damit mal warmes wasser hat um sich morgens die Zähne zu Putzen. 
All solche Dinge. Es reizt schon sehr, da Zeit zu investieren. Man kann 
auch weiter spinnen und z.B. noch einen Leistungsmesser in die 
Steckdosen integrieren, so kann man den Stombedarf der eigenen Wohnung 
auf dem PC-Monitor anzeigen oder messen.

Und wenn man weiter spinnt, könnte man sogar in der Dusche einen Mischer 
istallieren, der auf Knopfdruck die Wassertemperatur auf die zuvor 
eingestellte Temperatur regelt.

Man kann sich hier richtig austoben, und der Fantasie sind kaum Grenzen 
gesetzt. - Wenn nicht das Protokoll so kompliziert wäre.

Naja kurz um, abgehakt habe ich die Sache nocht nicht, vielleicht 
verzweifle ich aber auch und laß es ergendwann bleiben.

Die Zeit wird es zeigen.

Micha.



Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

hier mal mein Vorschlag:

Bleib doch bei der Master - Slave Strucktur und zwar nach folgenden 
Aufbau

- Endgeräte sind immer Slaves
- im einem Zimmer gibt es nur einen Master der die Slaves abpollt
- in der ganzen Wohnung gibt es nur einen Master der die Zimmer abpollt

Wohnung --- Zimmer --- Geräte

Master --- Slaves / Master --- Slaves

So müsstest du eine relative kurze Reaktionszeit erhalten.

Protokoll:

Ich würde eins für transparente Daten nehmen, zb.:um Texte oder 
Flashdaten zu versenden und eins was Zustände abfragen kann.

In der Industrie wird für digitale Daten gerne MODBUS verwendet und ist 
recht gut händelbar. (Bitte kein ASCII MODUS!!!)
Leider ist MODBUS nur für Punkt zu Punkt-Verbindungen ausgelegt und kann 
nicht routen.
Wenn du dir virtuelle Abbilder der Slaves in den Master-Geräten 
erstellst dann könntest du auch mit MODBUS arbeiten.

Für transparente Daten könnte mann vielleicht 3964r vergewaltigen, das 
kann zwar auch nur P. zu P. aber dem ist fast egal was übertragen wird.
(PS: das ist ein Protokoll das mit händschake arbeitet, so kann zb. auch 
einer sagen das jetzt keine Verbindung aufgebaut werden darf)

Stephan

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Micha R.

Wie lange bist Du denn gesessen, um diesen Text zu schreiben?
Da wäre es besser gewesen, mal mit Deinem Sourcecode anzufangen und 
etwas
zu testen.

Du machst einen ganz entscheidenden Fehler. Du willst ohne größere 
Erfahrungen gleich in die Oberliga. Würdest Du Dich mal mit Bussystemen 
wie mit dem was Du beschrieben hast auskennen, würde Dir klar, daß Du 
hier mit 9600 oder 19200
garnicht erst anfangen brauchst.

Wenn dann die Anzahl der Slaves steigt, willst Du dann im Haus 
umherlaufen
und alle Busslaves updaten? Oder gleich ein Firmwareupdate über den Bus
zu allen Slaves einspielen?
Das ganze dann auch noch in BASCOM programmiert.

Ein Programmierer und seine Projekte werden nicht fertig geboren, 
sondern
wachsen. Fang doch mal mit einem kleinen Projekt an.
Die Verdrahtung kammst Du ja schon machen. Vielleicht auch mal 
Erfahrungen
mit dem Verhalten von ausgedehnten Bussystemen sammeln.

Bei Dir klingt das nun eben mal so "In der einen Hand hab ich BASCOM und 
in der anderen RS422 Treiber"
Die wirfst Du zusammen und abra kadabra .....

Hast Du zufällig 128 RS422 Treiber rumliegen. Glaube auch nicht, daß das 
ne
Rolle spielt, ob Du grad so ein paar Treiber zur Hand hast. Ein Haus 
derart zu automatisieren, was spielen da die paar RS422 Chips preislich 
noch für eine Rolle?

Übrigens: Es gibt RS485 Treiber die mehr als 256 nodes unterstützen.

Ich will Dir absolut nichts ausreden aber sei dann nicht enttäuscht, 
wenn
der Lösungsansatz gänzlich anders war.

Beginne am Anfang und steigere Dich. So läuft es immer.

Dirk

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also ehrlich, was soll denn der Blödsinn auf
Bascom herumzuhacken?
Ob Schleifen, Programmverzweigungen in C oder Basic
gekodet werden ist im Prinzip zunächst mal sowas von
Wurst.
Man muss ja auch nicht bedingungslos die Highlevelbefehle
von Bascom verwenden, es zwingt einen ja niemand dazu
und mitunter ist es auch sinnvoll direkt mit den Registern
zu werkeln und tut mir leid, aber ich sehe dann keinen
grundlegenden Unterschied mehr zwischen C und Bascom.
Im Übrigen lese ich hier im Forum nicht selten:
"Hilfe ich bekomm die LIBxy nicht zum Laufen" weil
irgendwelche Dumbos sich einen auf easy machen und sich
die Libs aus dem Netz zusammensaugen und sich wundern, dass
die nicht out of the Box laufen.

Zum RS485: Also es gibt gründe dafür den 485 zu verwenden,
zunächst mal ists monetär günstiger.
desweiteren ist hardwaremäßig die 485 voll kompatibel zu
Profibus, man kann also beispielsweise Busslaves zusammen-
schrauben für den Profibus. Klar, das Busprotokoll muss man halt
in Code umsetzen und auf dem µC laufen lassen. Das kost
Rechenleistung und macht Arbeit aber ist definitiv machbar.

Ich habe mir für ein Großprojekt n multimasterfähiges Protokoll
für die 485 selbst erarbeitet und es läuft störungsfrei schon
seit 2 Jahren durchgehend, aber tut mir leid, den Bascom-
Quellcode werd ich definitiv nicht rausrücken, keine Chance,
zumindest nicht, wenn jemand selbst überhaupt keinen Ansatz
macht irgendwas dazu beizutragen. Die "ich will ..." Masche
find ich zum k..... . In dem Forum wird Hilfe zur Selbsthilfe
geboten und dies schon seit langem und sehr kompetent.
Sich dann die Früchte der nächtelangen tüftelei mal einfach zu
zu krallen, sorry ich finde das dreist.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Mal so ganz am Rande, du hast RS422 Treiber. Kannst du denn die Ausgänge 
überhaupt abschalten?
Wenn ich soetwas machen würde gäbe es vermutlich nur einen Master, dafür 
aber eine recht hohe Datenrate(min 115K).Wenn du da mal einen Block mit 
256 Byte absetzen musst ist die "merkbare" Verzögerung recht gering.
Über Bascom halte ich mich mal zurück, bei mir wäre es sicher in ASM.
Waren aber nur mal so Gedanken zum reichlichen Text der Beiträge.

Viel Erfolg, Uwe

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.