Hallo, ich arbeite schon etwas länger mit den AVR Controllern (Mega 8/32 usw) und programmiere diese in Bascom. Inzwischen kann ich Bascom recht gut, auch weil ich mir letztens ein Fachbuch gekauft habe. Jetz möchte ich mich so langsam an das Vernetzen der AVRs wagen. (Für Hausbus etc) Schade nur, dass im Fachbuch kein Wort darüber verloren wird, wie man mehrere AVRs verbindet. Nur 2 AVR über RS232 bzw. UART zu verbinden ist ja schnuckelig einfach. Nur eben nicht das, was man für ein Netzwerk mit sagen wir mal 20 AVRs geeignet ist. Ein wenig Googeln und es kommen verschiedene Methoden zum Einsatz. Funk über RFM12 Module. Scheint aufwändig zu sein und wird dann nur in einem Raum funktionieren. Über mehrer Stockwerke mit Beton sicher nicht. Fällt also flach. RS485 - Billige und wenige Komponenten. Dafür aber keine Zentrale Sternverteilung möglich, da alle Controller an einem Strang sein müssen. Protokoll muss selber definiert werden CAN - Protokoll schon vorhanden, anscheinend Sternverteilung möglich, bischen mehr und teurere Komponenten als RS485. Problem. Ich suche mich schon seit Stunden "dumm und deppert" obwohl ich eigentlich schlauer werden will. Über CAN findet man relativ wenig mit Bascom. RS485, da sieht es schon etwas besser aus aber Code und Protokoll, Buskollisionen usw. Alles nicht so einfach zu verstehn und da hilft es mir nicht, wenn einer ein Projekt damit gemacht hat, mir den Quellcode gibt und ich dann den RS485 Code aus dem 5000 Zeilen Programm rausfinden soll, welches zudem nicht kommentiert ist. Ich sucher eher nach einem kurzen und knappen Code, der nur die RS485 Routine samt Protokoll enthält. Möglichst kommentiert, warum jetz dieser und jener Befehl verwendet wird. Sagen wir mal so als einfaches Anfängerprojekt. Ein Master und 2 Slaves. Jeweils Atmega 8 oder was auch immer. Max485 Controller an jeden AVR und schon kann es losgehen. Den ersten AVR beschalten wir mit ein, zwei Tastern und einem LCD. Den ersten Slave ebenfalls mit einem Taster und einer Led und an den zweiten Slave ein LM335 Temperatursensor. Dann soll der Master nach Tastendruck z.B. an Slave 1 Senden "Schalte Led ein". Druck auf Taster 2 sendet an Slave 2 "Gib mir Temperatur", dann Sendet Slave 2 die Temperatur an den Master. Jetzt soll der Master auch noch prüfen ob an Slave 1 der Taster gedrückt ist. In diesem Beispiel wäre so ziemlich alles wichtige zum Verständnis mit Rs485 oder einer anderen Technik drin. Zustand abfragen und einem Controller Anweisungen geben. Nur so etwas habe ich im Netz nicht gefunden. Also wenn sich damit jemand auskennt, könnte er so einen Code (In Bascom) erstellen inkl. Schaltplan? Ich denke damit wäre nicht nur ich glücklich.
Hi Du schreibst, das du bereits mit AVR's unter Bascom gearbeitet hast und wünscht dir, das dir jemand einen Code sowie die Schaltpläne liefert... Mir riecht das stark nach: "Kann mir mal jemand meine Arbeit machen ?" Ok, gehen wir mal davon aus, du sprichst die Wahrheit und eine RS 232 Verbindung zwischen 2 Controllern ist für dich kein Problem. Dann denk doch mal nach, wie du mehrere Controller ganz einfach vernetzen kannst. Du betrachtest die RxD und TxD- Leitungen einfach als Ring. Nun schleifst du deine µC's alle in diesen Ring. Also, von TxD geht's auf RxD, bis alle Controller verbunden sind. Nun definierst du ein Protokoll. Z.B. Quelle, Ziel, Daten Quelle ist der sendende µC, Ziel der angesprochen werden soll. Nun sendest du z.B con Controller "0", von mir aus der Basiscontroller, an den µC mit Nr.6 Das Telegramm erreicht zuerst den µC 2. Der stellt fest "is nix für mich und schickt es wieder raus. Der Nächste ist vielleicht µC mit Nummer 7. Auch der schleift das Telegramm einfach durch. Irgendwann erhält µC Nr.6 das Telegramm, bearbeitet die Daten und gibt Rückmeldung an die Quelle. Nschteil ist eine rel. lange Laufzeit, da ein solches Ringtelegramm ja immer erst empfangen und ausgewertet werden muß. Trotzdem ist diese Art vorzugehen bei nicht zeitkritischen Anwendungen gar nicht so schlecht, da auch die Verkabelung sich in Grenzen hält. Auch müssen die Controller nicht der Reihe nach in der Kette stehen, sondern es reicht, wenn jeder µC eine Nr. besitzt. Diese kann Bspw. im EEProm liegen. Die Empfangs- und Senderoutinen sind alle gleich zu halten. Das erspart auch Programmierarbeit. Du siehst, nicht alles steht in Büchern, manches darf man sich ruhig auch mal ausdenken. Obwohl, solch eine Vorgehensart ist nix neues.... Gruß oldmax
Ich will nicht das mir jemand die Arbeit macht. Ich will ja lernen. Oder habe ich geschrieben "Entwickelt mir mal jemand einen kompletten Hausbus (ca. 20 Controller) mit folgenen Funktionionen..." Ich habe um ein Beispiel gebeten wie so etwas funktioniert, anhand von einem Master und 2 Slaves die einfache Dinge austauschen. Und wenn ich das dann verstanden habe, kann ich es ja SELBER auf mein geplantes Controllernetzwerk bzw Hausbus umsetzen. Dein beschriebenes "Protokoll" ist irgendwie auch nicht das richtige. Wenn der Befehl erst durch 20 Controller durchgejagt werden muss um dann nach einer halben Ewigkeit am Zielcontroller zu sein (geschweige denn, dass die anderen Controller hier den kompletten Datenstrom auswerten müssen und dann weitersenden und so Rechenleitung verschenkt wird), dann nenne ich das nicht sehr optimal. Und ein RS485 Netz wird sicher nicht mit Print, Input usw. richtig gut funktionieren. (Was ich sonst immer bei RS232 verwendet habe) Deswegen ja die Frage, ob da nicht jemand ein kleines Tutorial schreiben könnte. Damit man sowas von Grund auf vertehen kann und wie es richtig funktioniert.
Florian schrieb: > Dein beschriebenes "Protokoll" ist irgendwie auch nicht das richtige. > Wenn der Befehl erst durch 20 Controller durchgejagt werden muss um dann > nach einer halben Ewigkeit am Zielcontroller zu sein (geschweige denn, > dass die anderen Controller hier den kompletten Datenstrom auswerten > müssen und dann weitersenden und so Rechenleitung verschenkt wird), dann > nenne ich das nicht sehr optimal. Dann denk dir halt was anderes aus. Erlaubt ist was gefällt. > Und ein RS485 Netz wird sicher nicht mit Print, Input usw. richtig gut > funktionieren. (Was ich sonst immer bei RS232 verwendet habe) Öhm. Wenn du derartige Dinge machst, kannst du dir die simplen Standardfunktionen höchst wahrscheinlich alle abschminken. Da musst du dann selber rann, anstatt alles einer vorgefertigten Print Funktion zu überlassen.
Hallo. Also RS485 ist ansich relativ einfach. Du kannst den Print-Befehl dafür auch benutzen. UM ein RS485-Netzwerk aufzubauen, brauchst du Buscontroller wie zum Beispiel den MAX485. AN den wird die Betriebsspannung angeschlossen, zwei adern für den Bus und RxD, TxD und Richtungswahl. Danach ist nur der Unterschied, dass dui bevor du etwas sendest den 'Richtungswahl' PIn auf high ziehen musst und das wars auch schon. Um dies am anderen Controller zu empfangen, empfehle ich dir den Interrupt. AVRs haben einen hardware empfangspuffer den du dann abfragen kannst. UDR ist das register.
Das ist doch mal eine Antwort. Von den "Vollprofis" bekommt man immer nur: Denk dirs selber aus wir machen hier garnix. Und Bascom ist fürn Schrott lern C. So interpretier ich zumindest die beiden ersten Antworten und das ist nicht wirklich hilfreich. Und wenn es eben halt nicht mit Print usw. funktioniert, dann erklärts mir doch bitte wie es denn sonst geht. Wenn ihr mir nur sagt: Ne so funktionierts nicht, dann weiß ich zwar dass es so nciht funktioniert aber nicht wie es denn sonst funktioniert. Zurück zum Thema: Also ich brauch schonmal Buscontroller. Gut wie der angeschlossen wird weiß ich jetzt auch. Im Datenblatt konnte ich dann auch sehen wie mehrere angeschlossen werden an einem Bus inkl. einer Terminierung. Hardwareseite also geklärt. Softwareseitig bin ich immernoch auf dem Holzpfad. Ich habe viel gelesen und bin noch mehr verwirrt. Von Protokollen ist die rede, Buskolissionen, Checksummen usw. Und da bräuchte ich eben ein gut kommentiertes Beispiel, wie so ein Protokoll aussieht und in Bascom umgesetzt ist.
Hi >Ich habe viel gelesen und bin noch mehr verwirrt. Von Protokollen ist >die rede, Buskolissionen, Checksummen usw. Und da bräuchte ich eben ein >gut kommentiertes Beispiel, wie so ein Protokoll aussieht und in Bascom >umgesetzt ist. Wenn du nur einen Master hast geht das ganze relativ einfach. AVRs mit einer Hardware-Uart besitzen einen 'Multi-processor Communication Mode'. Der ist genau dafür gemacht. Allerdings weiß ich nicht, ob der von BASCOM direkt unterstützt wird. Aber man kann ja die Register auch direkt ansprechen. Also auchkeine Hürde. Lies das mal im Datenblatt nach. MfG Spess
Hi >Dein beschriebenes "Protokoll" ist irgendwie auch nicht das richtige. >Wenn der Befehl erst durch 20 Controller durchgejagt werden muss um dann >nach einer halben Ewigkeit am Zielcontroller zu sein (geschweige denn, >dass die anderen Controller hier den kompletten Datenstrom auswerten >müssen und dann weitersenden und so Rechenleitung verschenkt wird), dann >nenne ich das nicht sehr optimal. Abgesehen von weiteren Inhalten deiner Antwort will ich mal nur auf diesen Teil Bezug nehmen. Bevor du hier Lautstark dein "Nicht Wissen" verkündest, nur mal ein Beispiel, was Zeit betrifft. 1. Ein solcher Aufbau ist Leitungstechnisch völlig einfach zu realisieren. Du brauchst noch nicht einmal unbedingt einen RS232- Umsetzer. 2. Wennn du das erste gesendete zeichen für die Zieladresse nimmst, braucht auch nur 1 Zeichen ausgewertet werden, ob das Telegramm für den empfangenen Controller relevant ist. 3. Zeit. Wenn du mit einer Baudrate von 19600 sendest, und 10 Bit pro Information hast (Datenbits, Stoppbits) sind immerhin bei Ziel+ Quelle+8Byte Nutzdaten 1960 Byte pro Sekunde beim 1. Controller. Wenn du 20 ansprichst und der letzte bekommt die Info, dann braucht die Info grob 1/80 Sekunden. Selbst wenn du nur 1 Zehntel Sekunde Reaktionszeit hättest, ich wüßte nicht, was im Haus eine höhere Real-Time-Anforderung braucht. Manchmal sind Tipps nicht gleich zu verwerfen. Es gibt andere, schnellere Verfahren. Sicher. Aber sind diese Hardwaremäßig auch so einfach realisierbar ? Die Software und die Auswerteroutinen dürften sich gar nicht so sehr unterscheiden. >Das ist doch mal eine Antwort. >Von den "Vollprofis" bekommt man immer nur: Denk dirs selber aus wir >machen hier garnix. Und Bascom ist fürn Schrott lern C. So interpretier >ich zumindest die beiden ersten Antworten und das ist nicht wirklich >hilfreich. Dennoch, du sprichst davon, Erfahrungen mit der Kommunikation in Basic von Controller zu Controller zu haben. Da war diese Info gar nicht die eines hochnäsigen "Experten" und keiner hat auch nur ansatzweise über Basic gelästert. Wenn du dir da selber Minderwertigkeitsgefühle hinein interpretieren willst, bitte. Da ich aber nicht in Basic schreibe (ich kann es nicht !) kann ich nur auf Prinzipien verweisen. Ein Telegramm, um in jedem Zimmer alle Temperaturen bspw. im Haus abzufragen könnte wie folgt aufgebaut sein: Ziel = 255 = alle Controller oder Ziel =7 = Controller 7 Quelle = eigene ID 8 Byte Nutzdaten = 5 Raumtemperaturen + 2 Statusbytes Eingang + 1 Statusbyte Ausgang Das Ganze empfängst du per Interrupt und packst es in einen Ringpuffer. Dann wertest du das erste Byte aus und erkennst Selbst bearbeiten oder selbst bearbeiten und weiterreichen oder nur weiterreichen Ich kann dir sagen, das ich schätze, es ist in Basic vielleicht einfacher umzusetzen als in Assembler. Wenn ich in meinem Haus so etwas vorhätte, dann würden mir die einfachen Verkabelungen sehr entgegenkommen und ich bin jederzeit in der Lage, einen Controller irgendwo einzuschleifen. Die Nummern müssen nämlich nicht in der Reihe liegen, sondern es können überall "freie" Nummern zwischengeschaltet werden. Wo bitteschön ist bei diesem Prinzip das Agrument "völliger Quatsch" oder mit deinen Worten "suboptimal" angebracht ? Gruß oldmax
@oldmax Schönes Konzept, weil einfach und übersichtlich. Wenn der jeweilige Master den von ihm erzeugten Ist-Buszustand wieder einliest und mit dem Soll-Buszustand vergleicht, lassen sich auch Störungsroutinen einfach realisieren.
Jaaa ... RS485 hat schon n paar Stolpersteine eingebaut und es kommt auch stark auf die Komplexität der Aufgabe an wie es realisiert werden kann. Zunächst mal kannst Du die Bascomfunktionen wie Print und Input verwenden. Über Config Print kannst Du auch die Richtungsumschaltung des 485-Bausteins aktivieren, dann kannst DU einfach per Print die Daten raus senden. Daraus kannst Du Dir dann n einfaches Protokoll mit Texten und Zahlen, also Strings zimmern ... der Nachteil, die Auswertung ist mitunter haarig und geht auf die Reechenleistung weil Strings ausgewertet werden müssen, zum Anderen wird bei Print dann der µC im Programmablauf dort gestoppt bis alle Zeichen übertragen sind. Eine solche Message könnte z.B. so aussehen: 20,1,a,1023 ... 20 = Empfänger, 1 = Sender, a= Parameter A, 1024 = Parameterwert Der Empfänger muss dann den String mindestens bis zum ersten "," einlesen um zu sehen ob er gemeint ist ... bei Empfang per Input muss er sogar den ganzen String empfangen bis zum CR-LF am Ende. Derweil hängt das Programm im Input fest. Bei einfachen Anwendungen kann das sogar schon reichen, kritischer wirds wenn da noch andere Funktionen vom µC ausgeführt werden sollen. Dann geht man hin und lässt diesen per Interrupt empfangen und reiht die Daten hintereinander auf in einem String oder Array. Der Interrupt heißt dann URXC und wird bei jedem empfangenen Zeichen ausgelöst. So hat man den Programmstillstand im Input schonmal umschifft ... aber der µC muss halt auch wissen wann ein Paket komplett empfangen wurde. Dafür gibt es im Prinzip zwei Techniken. Entweder Dein Paket hat eine festgelegte Länge, die entweder bei jedem Paket mit übertragen wird oder Du sagst, wenn x Millisekunden nix übertragen wurde ist das Paket komplett und wertest dann aus. Letzteres kann z.B. mit einem Timer realisiert werden, der bei einem URXC Interrupt zurückgesetzt wird und bei Überlauf eben n Flag setzt. Beim Senden per Print hast Du ja wie gesagt das Problem, dass während der Ausführung das Programm im Print stehen bleibt bis alles übertragen ist. Auch hier gibt es eine Methode um das zu verhindern, den UTXC-Interrupt. Er funktioniert wie der Empfangsinterrupt nur in die andere Richtung, wird ausgelöst wenn ein Zeichen gesendet ist. Man geht dann einfach hin, schreibt seine zu sendende Message in ein Array oder String, scchickt das erste Zeichen auf das UDR-Register und los gehts. Ist das Zeichen raus, wird der Interrupt ausgelöst, man schiebt das nächste Zeichen ins UDR usw. bis eben die ganze Message raus ist, dann stoppt man, indem man einfach kein Zeichen sendet. Wenn man mehrere Slaves am Bus hat kann es dann irgendwann schon eng werden mit dem Timing, die Baudrate hängt stark von der Bustopologie und den Kabeln ab, sodass hier Grenzen gesetzt sind. Dann wird es u.U. notwendig ein kürzeres Protokoll zu verwenden, die Bytes sinnvoller zu nutzen. Das erste Beispiel war 11 Byte lang, man könnte es aber auch anders formulieren: &H14 &H01 &H41 &Hff &Hff ... das sind dann noch 5 Bytes, also nur weniger als die Hälfte der Daten mit dem gleichen Inhalt und schneller zu verarbeiten, da keine Stringauswertung vorgenommen werden muss. Dann haben wir ja noch Störungen immer und überall um uns herum, die eben auch abgefangen werden sollten. In der Übertragung macht man es meist so, dass am Ende der Message ne Prüfsumme angehängt wird, CRC8 CRC16 etc.. Schau mal in die Bascomhilfe rein, da sind die erwähnt. Die Protokollauswertung kann dann so gemacht werden: erstes Byte empfange, bin ich als Slave gemeint? Ja, dann empfange weiter bis alles da ist, dann rechne die Prüfsumme nach, stimmt die mit der übertragenen überein, ok, führe aus und gib OK zurück. Wenn nicht ok, schick dem Sender ein "wie bitte?" zurück, damit der nochmal den Befehl sendet. Störungen / Kollisionen können auch u.U. schon bei dem Empfang der Bytes festgestellt werden indem man den Frame-Error abfragt. Das ist ein Flag, den der µC setzt wenn die Bits nicht ins Format z.B. 8n1 passen ... auch dann sollte der µC ein "wie bitte" zurück senden an den Master. Auch beim Master kann es Probleme geben ... wird das Datenpaket so verstümmelt, dass kein Slave sich angesprochen fühlt so sollte er seine Anfrage irgendwann wiederholen oder bei 2-3-maliger Wiederholung eben weiter machen im Text ... Du siehst schon, das kann man in die Abstraktion treiben bist zum erbrechen ... kommt halt drauf an was Du brauchst.
ps: @oldmax Das von Dir beschriebene Verfahren unterscheidet sich vom Protokoll her garnicht von einem RS485 und reicht auch in den meisten Fällen aus ... ich sehe nur einen Knackpunkt. Fällt einer der Slaves in der Kette ... warum auch immer ... aus, ist ggf. der ganze Strang, minimum aber bis zu dem Slave tot. Ist schon weniger günstig wenn evtl. die Rolladensteuerung die Grätsche macht und dafür dann Lichttaster und Raumtemperatur auch weg sind.
Wer mit RS485 und Bascom ein Bus-System aufbauen möchte, dem sei mal empfohlen, sich mit "Modbus" vertraut zu machen Das ist kein neuartiges Bussystem sondern ein recht komfortables Protokoll auf der Basis von RS485. Die LIB in Bascom ist leider nur für Modbus-Master tauglich, aber man kann damit wenigstens die Checksumme generieren
Komisch, alle reden bei dem Thema nur von Protokollen und den logischen Schichten. Das hat doch mir rs 485/422 erst mal nix zu tun. Hier sind die elektrischen Eigenschaften erst mal wichtig und differenzieren. Somit ist RS484/422 erst mal kein Protokoll sondern definiert in der ISO Schicht die untersten Ebenen, hier Differenzspannungschnittstelle. Ich empfehle an dieser Stelle mal die viel gescholtene Elektor. Hier werkelt seit ca. 1 1/2 Jahren jemand ( ein ganzes Team mittlerweile von durchaus bekannten Fachleuten) an einem freien Hausbusprotokoll auf Basis RS485. Das ist ausgereift, sehr durchdacht, einfach und basiert auch auf Bascom Routinen mit Beispielen etc.. Die Programmierung erfolgt aber auch in C oder in beliebig anderen Sprachen. Auch Hostanwendungen und Testprogramme unter Windows existieren. Back to the roots
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.