Hallo Richard,
Deine Frage versteh ich jetzt nicht ganz die Schaltung hab ich doch als jpg angehängt, ich sende Zeichen über den RS 485. (bzw. weiter oben meine Website zu dem Thema)
Mfg Jürgen
Druckbare Version
Hallo Richard,
Deine Frage versteh ich jetzt nicht ganz die Schaltung hab ich doch als jpg angehängt, ich sende Zeichen über den RS 485. (bzw. weiter oben meine Website zu dem Thema)
Mfg Jürgen
tjaha ... Du hast dann zwei Busmaster dran wenn ich das richtig verstanden habe ... da wirds schon deutlich komplexer. Du müsstest dann nämlich Deinen Mastern beibringen wann der jeweilige senden darf.
Damit hat Du ziemlich exakt die Schwachstelle bei der 485-kommunikation erwischt.
Mit nem einfachen Protokoll ... ich sende-du machst wird das dann nämlich nix.
Zum Einen müsstest du beim Aktor erfassen wenn ne Kollision stattfindet, sprich beide Master senden ... das geht noch recht einfach über das FE-Flag (framing error), Dann noch ne Checksumme verarbeiten für Dein Protokoll und natürlich n Acknowledge vom Slave verwerten beim Master, sprich der Slave müsste noch antworten (ja, ich hab den Befehl verstanden bzw. Ich hab den Befehl nicht verstanden) und dieses ACK auch beim Master verarbeiten um ggf. nochmals den Befehl zu senden ...
Im Idealfall müsstest Du den Mastern noch n Token geben, wann wer jetzt den Bus belegen darf ...
Alles in allem keine einfache geschichte an der sich schon viele die Zähne ausgebissen haben.
Ich meinte nicht die Schaltung, eher die Software. Du brauchst ja einZitat:
Zitat von Juergen151
Protokoll um den Bustreiber im richtigen Moment von Lesen auf
Schreiben umzuschalten. Siehe auch die Post von Vitis.
Gruß Richard
Hallo Vitis & Richard,
ja das mit dem Umschalten von Senden auf Empfangen hatte ich ganz vergessen, so ist es halt wenn man sich nur alle 6 Monate mit damit beschäftigt.
Ein Protokoll wollte ich unbedingt vermeiden um das Ganze nicht unnötig kompliziert zu machen, mit einem Sender + einem Empfänger hats ja bisher auch wunderbar funktioniert.
Ich hab mir den Code des Senders jetzt schon mal angesehen und abgeändert für Umschaltung Senden/Empfangen, bin aber noch nicht dazu gekommen das ganze zu probieren.
Ich meine aber es sollte funktionieren, wenn man davon ausgeht das verschiedene Taster nicht gleichzeitig gedrückt werden, obwohl wenn man bedenkt wie kurz diese Zeiten sind wird man das wohl kaum schaffen genau gleichzeitig zu drücken.
Wie seht Ihr das ist das so lauffähig ?
Mfg Jürgen
Code:'Sensor
$regfile = "attiny2313.dat"
$crystal = 3579545
$baud = 4800
Portb = &B11111111
Portd.2 = 0
$hwstack = 32
$swstack = 10
$framesize = 40
Config Print = Portd.2 , Mode = Set
Config Pind.2 = Output
Config Debounce = 30
Waitms 300
Do
Debounce Pinb.0 , 0 , Schalter1 , Sub
Debounce Pinb.1 , 0 , Schalter2 , Sub
Debounce Pinb.2 , 0 , Schalter3 , Sub
Debounce Pinb.3 , 0 , Schalter4 , Sub
Debounce Pinb.4 , 0 , Schalter5 , Sub
Debounce Pinb.5 , 0 , Schalter6 , Sub
Debounce Pinb.6 , 0 , Schalter7 , Sub
Debounce Pinb.7 , 0 , Schalter8 , Sub
Loop
Schalter1:
Portd.2 = 1
Waitms 50
Print "!10";
Waitms 50
Portd.2 = 0
Waitms 50
Return
Schalter2:
Portd.2 = 1
Waitms 50
Print "!11";
Waitms 50
Portd.2 = 0
Waitms 50
Return
Schalter3:
Portd.2 = 1
Waitms 50
Print "!12";
Waitms 50
Portd.2 = 0
Waitms 50
Return
Schalter4:
Portd.2 = 1
Waitms 50
Print "!13";
Waitms 50
Portd.2 = 0
Waitms 50
Return
Schalter5:
Portd.2 = 1
Waitms 50
Print "!14";
Waitms 50
Portd.2 = 0
Waitms 50
Return
Schalter6:
Portd.2 = 1
Waitms 50
Print "!15";
Waitms 50
Portd.2 = 0
Waitms 50
Return
Schalter7:
Portd.2 = 1
Waitms 50
Print "!16";
Waitms 50
Portd.2 = 0
Waitms 50
Return
Schalter8:
Portd.2 = 1
Waitms 50
Print "!17";
Waitms 50
Portd.2 = 0
Waitms 50
Return
End
Hallo Vitis, Richard,
ich habs nun ausführlich getestet, vergesst meinen Code vom letzten Posting, es ist wohl tatsächlich so wenn ein Dritter Bus-Teilnehmer dran ist gehts nicht ohne Software-Protokoll, ich war bisher immer der Meinung das der RS485 Chip dies bereits hardwaremäßig tut.
Wie schwierig ist es wohl das Protokoll in meinen biherigen Code einzufügen ? Geht das überhaupt mit Bascom ? Vitis vielleicht kannst Du das mal probieren, wäre nett ! Oder gerne auch ein anderer Bascom-Experte !
Mfg Jürgen
moin min
Grht relativ einfach. Alle Teilnehmer empfangen per IRQ, damit
nebenbei auch aqndere Aufgaben möglich sind.Dann sendet der
Master eine Auffrderung z.B. in der Art..
: Start.
#ID = Adresse des Slaves
> = für Sendeauforderung
< = für Leseaufforderung
xyz = Anzahl der folgenden Daten oder Befehls Bytes
CRC Checksumme
$00 = nack senden wenn CRC OK
.................................................. ...
CRC nicht Ok nach ? Zeit goto start
Else
xyz Daten vom Slave empfangen und verarbeiten.
Für den IRQ Empfang und auch CRC bilden/auswerten
gibt es in Bascom Befehle musst mal die Beispiele
unter samples durchsuchen und oder in der Hilfe
nach on interrupt und CRC suchen. Alle Empfangen alles,
inorieren aber alles wenn #ID nicht passt bis ein $00
kommt. Dann geht es von vorne los.
Also auch die Slaves müssen beim Antworten immer erst
ein #ID senden damit die Daten an der richtigen Stelle
ausgewertet werden, die Routine ist quasie bei allen gleich.
Die jeweilige ID sollte im EE.Prom liegen (achtung, die erste
EE-prom Speicherstelle kann beim Rest oder Einschalten
verloren gehen) also besser eine höhere wählen.
Viel Spass, Richard
Wenn DU ne Hardwarelösung willst solltest Du Dir mal die CAN-Bus Bausteine anschauen, die machen sowas, bei 485 muss man sich um sowas selber kümmern. RS485 beschreibt nur die elektrische Seite der Übertragung, sonst nix.
Die Umwandlung Deines Codes ist sogar noch verhältnismäßig überschaubar.
Zum Einen solltest Du Dir mal das UCSRA Register anschauen, bzw. das TXC-Flag, damit kann man recht elegant die Umschaltung von Senden auf Empfangen lösen ohne Wait Befehle.
Dann noch CRC (gibts auch als Bascom Befehl) und n Array als Overlay über Deinen Sende- / Empfangsstring.
Dann noch das FE-Flag für den Empfang und n Ack vom Slave als Antwort bei verstandenem Befehl, bzw. Nack. Dann noch n Timeout beim Master für Befehle die ins Leere gegangen sind und gut ist.
G***** davon wollte ich jetzt nicht auch noch anfangen, CAN ist zuwarZitat:
Zitat von Vitis
etwas super feines aber nicht umsonst kaum im Hobby Bereich zu
finden....recht kompliziert. Weshalb Amtel auch AVR`s mit Hardware
CAN zur Verfügung stellt. Was die jetzt kosten? Aber wenn jemand seine
Wohnung komplett inklusive Musikübertragung Verkabeln will.....
Der sollte sich überlegen ob sich das nicht doch rechnet.
Da CAN aus dem Automobielbereich stammt und z.B. auch Sicherheits-
Bereiche wie ABS u.s.w. abdeckt. Sind Preislich kaum Grenzen gesetzt.
Gruß Richard
nee, da hast Du mich falsch verstanden, da gibts
entsprechende Bausteine dafür, z.B.
MCP2515
http://www.datasheetcatalog.org/data...7dqexxwhcy.pdf
Hmm, wenn ich mir so Threads (auch in anderen Foren) darüber anschaueZitat:
Zitat von Vitis
hatte ich den Eindruck das auch mit den IC`s etliche Probleme aufgetreten
sind?
Ich hatte einmal weil mir die Adressierung und Prioritäten verwaltung
so gut gefallen hat etwas ähnlichen aufgebaut. Einfach die TXD/RXD
noch auf 2 zusäzliche Pin`s gelegt und damit überprüft ob das gerade
gesendete Byte von einen Anderen Teilnehmer über schrieben worden ist.
Dazu muss die Datenleitung natürlich über einen Pullup an + Liegen
und mittels OC geschaltet werden. Sonst brennt etwas weg....
Allerdings ward das damals ein PIC und in Assembler realisiert.
Gruß Richard