Highspeed Komunikation zwischen PC und externem IO-Adapter

Moin moin.

RS485 ist als Bus selber gut, nur muß man dann selber für ein
Reibungslos arbeitendes Protokoll sorgen (programmieren).
Dazu gehört schon ein wenig Erfahrung in solchen Dingen.
Bei Software CAN selber "gestrickt" ist es das gleiche Problem.

Der Ursprungsposter scheint aber eher keine bis sehr wenig
Programmiererfahrung zu besizen. Deshalb mein Forschlag
als Mastercontroller* einen AVR mit intregeirten Hardware CAN
Bus zu nehmen, da ist das Protokoll schon vorhanden und man
kann die Schnitstelle ähnlich wie RS232 Ansprechen. Das erspart
sehr viel Arbeit, Hirmschmalz, Debuggen u.s.w.!

* Der Kontroller der zwischen PC und CAN BUS Hängt.

Alle anderen Bus Teilnemer sind keine µC sondern normale
CAN Bus Bausteine wie z.B. I/O Treiber, Display, Tastatur und
was es sonst noch alles gibt. Da muß man halt mal nach
Can Bausteinen suchen, es gibt da quasi alles was man so brauchen
kann.

Bus Reichweiten weit über 1000m sind kein Problem und Datenraten
sind je nach Bauteile Auswahl (PREIS) ganz erheblich. Im KFZ wird
über CAN auch Video übertragen......

Für diese Eisenbahnsteuerung kommt noch hinzu das jedem Ereigniss
eine Priorität 11111110....11111100 zugeortnet werden kann. Die
mit dem niedrigsten Wert hat Vorrang und überschreibt auch während
ein anderer Teilnehmer sendet dessen Daten. Quasie Echtzeit, der
Teilnehmer dessen Daten überschrieben wurden merkt das und sendet
seine Daten halt solange noch einmal bis sie nicht überschrieben
gesendet wurden.Es geht also nichts verloren. :-)

Das muß "nicht" selber programmiert werden, das ist hardware mäßig in
Can Chips enthalten! Teurere Exenplare (MIL Bereich) bemerken sogar
wenn sie selber durch Defeckt den Bus blokieren und schalten sich
ab. :-)

Für die Schienensensoren mit OP u.s.w., es gibt Can Bus Bausteine
mit Differenz Eingängen, damit sollte die ganze Analogmimik entfallen
können und was nicht gebraucht (vorhanden) ist kann auch nicht ausfallen
oder Ärger bereiten.

Klar ist aber, ohne sich da Intensiv Einzulesen, Datenblätter studieren,
Schlau machen was es alles für Bauteile gibt, geht es auch beim CAN Bus
natürlich nicht!

Dafür bekommt man aber einen extrem sicheren Bus, ein super Protokoll
mit tollen Möglichkeiten und letztendlich durch die vielen möglichen
Bus Teilnemer spart man haufenweise zusätzliche Hardware die nict
mehr Ärger machen kann. Dafür sind die Teile je nach Anforderung
(MIL Bereich) ......etwas teurer als son TTL 7400 Gatter.

Ich hoffe etwas Licht in die Urteilsfindung gebracht zu haben. :-)

Gruß Richard

hm das klingt allerdings interessant! aber die preislichen vorstellungen würden mich wirklich mal interessieren, zumal auch beim CAN irgendwann die grenzen erreicht sind mit der kommunikation und reaktionsgeschwingikeit, wenn ein zentraler baustein/computer sämtliche logik übernehmen soll ... ich bezweifle ein wenig, dass ein (1) ATCAN da alleine zurechtkommt ... ich denke zumindest dass die verteilte lösung einen effiziensvorteil hat, die kommunikation dient dann nurnoch der synchronisierung mit dem PC aber ich lasse mich gerne eines besseren belehren

Hallo,

das mit dem, das ich wenig programmiererfahrung habe lass ich nicht auf mir sitzen, bin zwar kein Profi, aber ein bisschen kann ich es auch.
Aktuell läuft ja die Anlage schon, aber halt nicht so, das Fehler nicht auftreten können. Die bereitstellung der Fahrspannug erfolg aktuell bereits mit hilfe von µCs.
Desweiteren sind in meiner Werkstatt schon ein Funkwecker entstanden, der sich per IR-Fernbedienung einstellen lässt/abstellen. Dann wurde hier und dort noch ein µC programmiert, damit man nicht jedes mal in den Keller rennen muss, um zu sehen ob die Waschmaschine fertig ist, oder festzustellen, dass das Warmwasser im Tank zum duschen doch nicht reicht und die Heizung erst angschaltet werden muss.

Dann wurden für mein zweites Hobby, die Wasserraketen, zahlreiche µCs programmiert, u.a. eine neue Firmware für meinen Höhenmesser.

Also von keiner bis wenig programmiererfahrung würde ich hier nicht sprechen.

Das mit dem CAN kling schon ganz gut, wenn man aber ins Internet schaut, wird von 40m bei 1MBit/s gesprochen und bei 125kBit von maximal 500m. Und keien 1000m
Das würde aber auf das RS485 zutreffen, dort wird von 1,2km gesprochen. Gut, so viel gibt es bei der Modellbahn nicht. Vielleicht ein Bus, über die ganze Anlage von maximal 50m, das ist aber schon sehr viel.

Wenn ich das ganze so gestallten würde, wie es Richard vorschlug, alles mit CAN bausteinen zu machen, wäre mir ja wenig geholfen, ich müsste immernoch mit 4MB/s in den PC rein.
Aber wir sind ja schon so weit, dass es ein paar externen µCs gibt, die grundlegende Aufgaben lösen, damit nicht so viel in den PC geschaufelt werden muss. Die Frage ist nur wie man das macht.

Gruß
Michael

Zitat:

---

Zitat von Michael 123

Hallo,

das mit dem, das ich wenig programmiererfahrung habe lass ich nicht auf mir sitzen, bin zwar kein Profi, aber ein bisschen kann ich es auch.
Aktuell läuft ja die Anlage schon, aber halt nicht so, das Fehler nicht auftreten können. Die bereitstellung der Fahrspannug erfolg aktuell bereits mit hilfe von µCs.

---

Moin moin.

Sorry, da habe ich Dich mit denem Vater verwechselt?

Ich habe hier irgendwo ein Buch vom "Vater des Can Bus" werde
es mal raussuchen, die Leitungslänge ist allemal der von rs485 und
auch ähnlich bis besser schnell.

Wie Du 4 Mbit zum PC übertragen willst/kannst? Mein PC kann
über rs232 max 128.000 Byte übertregen, bei 1 Start, 8 Daten
und 1 Stopp Bit also 10 x 128.000 Bit/s = 1.280000 Bit/s das ist
weit weniger als 4 MBit/s. Du mußt einen verdammt schnellen PC
besitzen. :-)

Wo kommen die vielen Daten eigentlich zustande? Hast Du 4.000000
Sensoren an der Bahn welche alle zur selben Zeit Daten senden
wollen/müssen? Oder überträgst Du jedesmal ein ganzes Byte wo
ein einzelnes Bit für Sensor an/aus genügen würde? OK, ein par
Adress Bits (welcher Sensor) braucht es auch noch, trotzdem
kann mann durch geschiktes Codieren Code Sparen!

Letztendlich muß ja nicht zwangsläufig ALLES so schnell gesendet
werden, der normale "Verkehr" kann über langsamesPolling laufen,
wichtige Ereignisse dürfen das dann in Echtzeit "Überschreiben" und
4 Mbit "wichtig" wird so eine Modell Eisenbahn kaum jede Sekunde
bringen...

Ich habe vergessen zu erwähnen das man beim Can Bus Polling
und (Echtzeit/IRQ Übertragung) mischen kann.

Gruß Richard

Ps.: Ein Onkel von mir hatte vor ca. 30 Jahren eine etwa 100m²
Modellbahn mit einer etwa 3 x 7 m großen Gleisanzeige gebaut
auf der alle Züge optisch verfolgt werden konnten. Die Anlage
war mehrere Jahre in Diepholz ausgestellt und ist irgenwann nach
den USA verscherbelt worden. Alles ganz ohne Computer von
Hand verdratet!

Gruß Richard

Zitat:

---

Wie Du 4 Mbit zum PC übertragen willst/kannst? Mein PC kann
über rs232 max 128.000 Byte übertregen, bei 1 Start, 8 Daten
und 1 Stopp Bit also 10 x 128.000 Bit/s = 1.280000 Bit/s das ist
weit weniger als 4 MBit/s. Du musst einen verdammt schnellen PC
besitzen. Freudig

---

DEN rechner möchte ich sehen!

1 start + 8 daten + 1 stop = 10bit pro byte, mal 128kByte/s
1.28MBaud ... unmöglich .. (standard)windoof schafft ja kaum die 512KBaud ohne zicken!

2Mbit schaff ich mit Ethernet und normalen atmel ... mit nem fpga komm ich wenns gut läuft auf 10-12Mbit ...

zu dem was er gesagt hat wegen der sensoren es ging dabei um zeitkritische probleme ... aber wnen etwas wirklich zeitkritisch ist, würde ich die reaktion nicht einem PC überlassen,
der eventuell genau in dem moment die prio des threads ins nirvana schiesst weil er meint er müsste mal eben nach updates suchen ...
ein CAN als unterbau schient mir persönlich garnicht so verkehrt, aber ein einzelner controller der die logik der ganzen bahnplatte regeln soll find cih auch shcon wieder ein bisschen viel ... eine unterverteilung mittels mehrerer µC ist da schon effektiver ... leider schraubt sich genau DANN der preis pro controller durch den zusätzlichen CAN aufwand in die höhe so sehe ich das zumindest, ich will hier bloß keinen streit ausbrechen lassen, ich sehe im moment einfach den aufwand beim CAN größer ... obwohl das prioritäts-handling natürlich die verwendung von steuerleitungen beim RS485 unnötig machen würde, auch nicht zu verachten!