Highspeed Komunikation zwischen PC und externem IO-Adapter

[Ceos]

genau @ thomas

ich würde auch versuchen das problem zu unterteilen! nimm einfach mehrere µCs die möglichst viele interrupteingänge haben, diese eingänge verbindest dann mit deinen meldern (die ja wohl hoffentlich ein sauberes signal ausgeben ... ich vermute mal reedkontakte ... dann bitte mit tiefpass).

jeder controller hat dann eine primäre und eine sekundäre aufgabe, primär ist die reaktion auf die meldung zu reagieren (weiche stellen, zug anhalten what ever) und sekundär sollte er das ereignis an den PC melden ...

dafür mal ein beispiel 1 großer master mit datenbus und 8 interruptleitungen, daran 8 slaves die auch am bus hängen und zur unterverteilung dienen


wenns um ausgänge geht hast du beliebig viele anschlussmöglichkeiten an den bus, du musst dir nur ein schlüssiges addressierungssystem ausdenken

so ala

empfangsadresse = 0x07 01 10

07 8ter hauptverteiler
01 2ter unterverteiler 
10 17ter ausgabecontroller

deine einganbecontroller und verteiler bekommen dann IMMER adressen von 0 - 7 (entsprechend der interruptleitung an der sie hängen) und die ausgabecontroller bekommen dann immer adressen darüber bis 255

die adresse wird dann immer so aufgelöst, dass zunächst das LSB auf den bus gelegt wird, auf bestätigung gewartet wird und dann der rest gesendet wird, der entsprechende verteiler schneidet dann sein byte ab und sendet den nächsten block, bis es beim schlussendlichen empfänger ankommt

[markusj]

Ich denke auch, dass du an dieser Stelle am besten anfängst du delegieren.
Einzelne µCs können mittels Interrupts etc. zeitnah reagieren, du musst das ganze dann "nur" noch an einen Bus häkeln und vernetzen.

mfG
Markus

[Michael 123]

Hallo,

das ganze hört sich zwar ganz gut an, aber mein Dad ist in Sachen µCs eine absolute Niete.
Darum sollte das ganze so viel wie möglich "analoges" enthalten. Digitales in Form von Und/Oder etc. Gattern ist auch drin, aber nix zum Programmieren.
Es reicht schon der µC, der aus USB die Signale für die Anlage macht.

Für jeden Block ein µC zu nutzen ist eher schlecht, da ja jeder Block eine Art "Trafo" ist, der die Fahrspannug bereitstellt. Somit wäre dies auch noch eine schlechte eigenschaft, da ja irgendwie die Daten an den nächsten Block übergeben werden müssten. Gut, das ginge per UART. Und wie kommt es vom vorherigen rein? Gut, es bit µCs, die haben zwei UARTs. Aber wie kommt die Meldung nun an den PC? Habe noch keine AtMega gefunden, der drei UARTs hat. Software UART ist auch eher negativ, da ich bis jetzt noch keine laufende Lösung gefunden habe. Zumindest für Bascom noch nicht.

So eine Idee wäre es doch auf den LPT Port zu gehen.
Dazu müsste ich aber erst wissen, was die maximale Frequenz ist, mit der man den LPT abtasten kann. Tante Google gibt dazu nix her, zumindest habe ich nix gefunden, dafür aber einen USP->LPT-Adatper, der einen echten LPT Darstellt, und nicht dies Pseudo dinger, die es für 1€ auf Ebay gibt.

gruß
Michael

[Richard]

Moin moin.

Bei der Anzahl von Sensoren ist "Polling" nicht wirklich optimal.
Da währen z.B. CAN Bus Bausteine besser geeignet, die gibt es
auch mit 16..32.. (?) Eingängen und lassen sich SO programmieren
das nur dann der Bus benutzt/belastet wird wenn ein Ereigniss
eingetreten ist. Es werden ja sicherlich nicht alle xyz Sensor wirklich
gleichzeitig auslösen.

Wenn ein Ereignes aufgetreten ist und der Bus belegt ist, wird das
gesendet solald der Bus wieder frei ist. Es kann auch festgelegt
werden welches Signal Vorrang hat und alle anderen Signale müssen
dann warten.

Der Can Bus wird im Auto z.B. für ABS, ESP und andere Sicherheits
kritischen Aufgaben eingesetzt und "Antischlupf" bei 250 km/h sollte
für eine Modelleisenbahn allemal schnell genug sein.

Can Bus per Software und AVR ist allerdings noch nicht wirklich
gelungen, das Protokoll ist halt etwas schwierig. Es gibt aber AVR`s
wo das schon intregiert ist und dann sollte es auch mit der CAN
Hardware ab der Can Bus Ebene klappen. Der PC sollte nur Bedingungen
An den AVR senden, für Aktion/Reacktion muß der AVR sorgen.
Ein normaler PC ist dafür einfach zu langsam, außer man umgeht die
API`s und greift mittels Assembler direckt selber auf die Harte Ware
ein, aber die Zeiten sind ja "abgelaufen".

Gruß Richard

[christian_u]

Du kannst das USB AVR Lab dafür nehmen, dein Problem teilt sich mit der Sensorik enorm herunter da ja nicht ständig von den Sonsoren etwas kommt das zum PC muss. Mit dem lab kannst du den AVR der darauf ist mit einer eigenen Firmware versorgen so das du die Sensoren ständig abtasten kannst auch mit 1Mbit/s und nur Daten zum PC schickst wenn wirklich was sinvolles dabei ist. Zum PC kannst du dann Daten mit max. 7kb/s schicken.

http://www.ullihome.de/index.php/Hauptseite#USB_AVR-Lab

[Vitis]

man nehme differenziellen Datenbus und schleife durch von einem zum nächsten node, einfach parallel ... halbduplex in 2-draht oder vollduplex in 4-draht technik.
dann noch n sinnvolles protokoll

[Felix G]

Also bei einer derartigen Anlage würde ich ebenfalls ganz stark zu mehreren per CAN vernetzten Controllern tendieren...

Wenn man das richtig macht lässt sich z.B. auch eine Anlage realisieren die Plug&Play mäßig erweiterbar ist. Wenn dann neue Meldestellen benötigt würden könnte man diese einfach ggf. zusammen mit einem weiteren Controller (falls die vorhandenen keine freien Eingänge mehr haben) einbauen, an den CAN-Bus anschließen, und die Signale würden nach dem Einschalten sofort am PC zur Verfügung stehen, ohne daß dafür eine Konfiguration nötig wäre.

Nur muss man dafür eben erstmal die Hardware und Software entwickelt haben bevor sich überhaupt irgendwas tut

[Michael 123]

Hallo,

noch mal danke für die Antworten.

Es scheint mir, als würde es sinnvoll sein, was man aus eueren Antworten ziehen kann, mehrer Prozessoren dort einzusetzen.

Über PN bekam ich einen Tipp, das jeder µC das gleiche OS haben soll. Aber über den PC mit einer Art Software versehen werden kann, die ihn spezielle Aufgaben erledigen lassen kann. Die Software wird dann in den EEProm gespeichert. Somit gibt es nur eine Art von µC, aber jeder kann spezielle Aufgaben lösen.

Das ganze dann über den von euch vorgeschlagenen CAN Bus vernetzt. Warum eigneltich nicht I2C?

Mein PC hätte dann also nur noch die Aufgabe für die Komunikation zu sorgen, die Daten zwar zu bekommen, aber nicht mehr Auswerten zu müssen. Er bekommt die Daten, zeigt sie nur noch an.
Auch müsste er dann noch sagen, dass die Geschwindigkeit der Lok XY jetzt nicht mehr als Maximum 50 sondern 100 hat. Mehr würde der PC ja nicht mehr machen oder?


So, da ja jetzt so viele hier schrieben, und es vielleicht sinnvoll wäre, ein paar weitere Infos hier zu schrieben, hätte nie gedacht, dass es hier soweit käme, dachte eher an eine Finale Lösung die hier gepostet würde, so nach dem Motta: Friss oder Stirb.
Also es geht wie schon beschrieben um eine Modellbahnsteuerung.

Aber nicht nach dem Motto: Ah der Zug ist dort, dann muss ich die Weiche a, b, d stellen, nein vielmehr geht es darum, genau zu wissen, wo welcher Zug gerade ist. Sprich der Zug wird von Block zu Block auf der Anlage fahren, aber der PC weiß jederzeit genau wo er jetzt ist, aufgrund der Besetzmelder. Somit ist es dann auch möglich zu wissen das jetzt im Schattenbahnhof, den man ja normal nicht sieht, zu sagen, ich hole jetzt die Dampflock XY raus. Und nicht den ICE.
Dazu kann man dann noch Parameter wie maximale Geschwindigket, Bremsverhalten etc. unterbringen.
Vor allem wird es dann interessant, wenn man sogenannte NoGos fahren will. Z.B. wenn man eine E-Lock hat, die man aber auf eine Nebenstrecke schicken will, die aber keine Oberleitung hat. Da würde dann der PC sofort sagen: Nö, das geht nicht.
Auch könnte man dann sagen, dass für Güterzüge es verboten ist im Bahnhof an einem Bahnsteiggleis zu halten.

Bis jetzt läuft die Anlage per einfachen Stellpult, was das ganze nicht unterstützt. Jetzt muss ich mehr oder weniger noch selbst denken, dass mir sowas nicht passiert. Die Anlage ist schon komplett "umgerüstet", so dass ich nur noch die Besetzmelder an den PC anschließen müsste.

Oben hat mal jemand geschrieben, das die Besetzmelder (BSM) aus Reedkontakten besteht. Das stimmt nicht. Es wird über 2 Dioden ein Spannugsabfahl auf einen AC-Optokoppler (für jeder Fahrrichtung eine "LED" und 2 Dioden) gegeben. Vom Transistorausgang geht es auf einen OP, der mir das Signal auf 0V bei keinem Zug und 5V bei Zug verstärkt.
Dann geht es, noch meiner aktuellen Vorstellung auf ein Schieberegister, das vom PC angesteuert wird.
Die Besetztmelder funktionieren störungsfrei, das habe ich bereits getestet. Auch die Bereitstellung der Fahrspannug geht super, da gibt es keien Probleme.

Gruß
Michael

[Ceos]

I2C hat ne verhältnismäßig winzige reichweite ... mehr als 1-2m kann man damit kaum effektiv überbrücken ... lieber RS485 ... (meine meinung) ist relativ sicher gegen EMI und man muss sich nicht mit den CAN protkollen rumschlagen (wenn man nicht gleich einen fertigen CAN controller nimmt wo man nur noch daten reinschaufeln muss oder ne lib) das protkoll muss man sich aber selber bauen

das mit den redkontakten war ich, ich dachte dass du mit den magneten in den loks arbeitest, weil das die günstigste lösung ist ^^ aber wenn du schon was vernünftiges hast brauchst dir da keine gedanken machen, dann kannste auch gemütlich die leitung an die interruptleitungen klemmen

[Vitis]

I2C geht sehrwohl auch weit über 30m ... hab sowas bei mir laufen, kommt aber auch stark auf den Bustakt, Terminierung, Topologie an. Bei den geforderten Übertragungsraten daher eher ungünstig.
Das Nächste ist der "Funkenflug" bei den Lokomotiven, wenn die über die Gleise rattern ... ein Fest für jeden Elektroniker die Störungen auszufiltern,
deutlich geringer ist die Störung bei Verwendung eines differentiellen Busses
wie rs485 oder CAN ... ich arbeite auch lieber auf 485, aber das ist
Geschmackssache ... Bei CAN hat man halt weniger Ärger mit den
Kollisionen, bei 485 ist man freier im Protokoll.