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.
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.
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.
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?
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
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?
>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.
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.
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!
Hier in Anhang habe ich mal den Ansatz des Protokolls gepostet. Vielleicht willst du dir das mal anschauen!
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.
Danke für den Link, da steht aber nichts drin, was ich nicht schon weiß. Hast du noch einen Vorschlag?
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.
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
Eine sinnvolle Kollisionserkennung wirst du in Bascom nicht hin bekommen -> Löse das Problem also in Hardware.
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
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.
@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
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.
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
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
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
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.
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.
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.
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?
Micha, ich hab was : http://www.ibrtses.com/embedded/shortmsgprotocol.html Das Protokol ist eigentlich multimasterfaehig wurde aber immer nur als master slave eingesetzt.
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?
hi rene, ich schau mir das mal an, danke für den Hinweis.
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
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.
> 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.
@AK das Datenpacket ist passend fuer Multimaster, die Statusmaschine nicht ganz.
Hat jemand Interesse mit mir soetwas zu Programmieren? Ja, dann bitte melden!
Im wesentlich muss man nur zuruecklesen was man gesendet hat und vergleichen.
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
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?"
Deinen Lamborghini kannste auch behalten. Wenn du nichts konstruktives beisteuern kannst, bist du hier falsch!
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
>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.
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
@ 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
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
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
> 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.
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.
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.
@A.K. mit Sternförmig und 500m meinte ich natürlich nicht CAN sondern Ethernet.
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.
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
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.
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!!!
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
@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.
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.
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
@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
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.