Highspeed Komunikation zwischen PC und externem IO-Adapter

Hallo,

für ein neues Projekt brauch ich jetzt eine Möglichkeit 32 I/O Pins möglichst schnell zu schalten.

Die Schaltfrequenz sollte 1 Mhz betragen. Für jeden I/O Pin. Nach Möglichkeit sollten die I/O Pins das Signal parallel und nicht ein pseudo parallel sein. Also wirklich gleichzeitig schalten. Und nicht irgendwie nacheinander, wie bei schieberegistern.

Da ich hierfür warscheinlich USB nehmen muss, da der seriall Port das auf keine Fall und der LPT warscheinlich nur sehr beding packen würde, würde sich dort ein µC anbeiten. Nur ist die Frage welcher? Ein AtMegaxxx geht warscheinlich auch nicht, da er nie und nimmer die Frequenzen mitmacht. Er muss ja das USB-Protokoll mitmachen, und gleichzeitig die 32 I/O Pins schalten.

Das ganze soll in einem VB-Programm ausgewertet werden können.
Das Programm schickt z.B. 4 1Byte Packete an den Controller, der dann das Signal ausgibt.

Am genialsten wäre es, wenn man den Controller auch noch mit ein paar kleinen Rotinen versehen könnte. Nach dem Motto: Wenn Eingang 1 1ms an war, dann Schalte sofort Ausgang 3 aus. Oder wenn vom PC ein 5tes 1Byte Packet kommt, dann Schalte Ausgang 5, 6, 10 und 32 an/aus. Aber das wäre nur wunderbar, und ist kein muss.

Insgesammt werden 32 I/Os benötigt, wie die genau verteilt sind weiß ich noch nicht, kommt halt auf den Speed an :-)

Ich hoffe ihr könnt mir bei der Suche / Realisierung helfen.

Ach ja, Programmieren kann ich eigentlich nur in Bascom, anderes, wie C, hatte ich mal versucht zu lernen, blieb aber daran stecken, das es neu ist :-)

gruß
Michael

analysiere nochmal deine eigenen ansprüche, erwartest du, dass du echte und perfekte 1Mhz allein mit dem PC versenden kannst ? der arbeitet selbst nichtmal in echtzeit die programme ab, also wird allein das schon schwer die kommunikation über USB ist da auch nur ein trugschluss, ein FTDI ist nichts weiter als nen virtueller COM port und der geht am PC genausoschnell wie ein echter ^^

erklär nochmal genau was du willst und welche bedingunen du vorliegen hast, dann kann man dir vielleicht mit einem anderen lösungsweg helfen

Naja, theoretisch könntest du über Schieberegister und ein gemeinsam angesteuertes Latch-Signal tatsächlich 32 simultan schaltende Ausgänge bekommen - direkt mit dem AVR schalten ist nicht drinne, das gibt bestenfalls 8 Pins (ein Port) je Taktzyklus (+Wert Laden etc.) her.

mfG
Markus

ftdi kann 1mbit.
Schau dir deine anforderungen nochmal genau an. Vielleicht sagst du auch, wofür du das brauchst?

Windows kann aber kein 1mbit

und er brauch 4mbit bei 32 I/Os 4byte pro schaltvorgang

Ceos, nochmal zurück ins Bett und mit dem richtigen Bein aufstehen ;)
4 Byte / Schaltvorgang machen 32 Bit / Schaltvorgang und bei einer Frequenz von 1 Mhz sind dass 4 MByte/s bzw. 32 MBit/s
Wohlgemerkt, in SI-Einheiten, nicht in MiBytes

mfG
Markus

40 Mbit sogar wenn man von UART/COM protokoll ausgeht hast ja recht ^^

Hallo,

danke schon mal für die Antworten.

Es geht dabei um eine Modellbahnsteuerung.

An die 32 I/O Leitungen werden Schieberegister angschlossen. Ein paar für input ein paar für Output.
Da es auf der Modellbahn um bewegte abläufe geht, ist eine schnelle Reaktion auf best. Ereignisse erfoderlich. Wenn man sich vorstellt, das ein Zug mit 0,5m/s fährt. Naja, das ist Vorbildgeschwindigkeit, wenn jetzt die Kinder meiner Schwester kommen, dann erhöt sich das ganze schon mal auf 1-2m/s.
Gehen wir mal auf 2m/s aus. Die kürzeste Meldestelle ist 10cm lang. Das bedeutet, das der Zug/Lok dort gerade mal 1/20s darauf ist. Sprich ich müsste alle 50ms messen. Um auf Nummer sicher zu gehen alle 25ms. So da es aber nicht nur eine Melde stelle gibt, sondern auf meiner Anlage bereits 80, müssen alle 0,3ms die Kontakte abgefragt werden. Das wären immerhin 3000Hz. Da aber das ganze bei mir nur eine Probestrecke ist, und später mal auf die Anlage von meinem Vater übertragen werden soll, und er allein schon im Schattenbahnhof mal eben diese 80 Kontakte verbrät, die ganze Anlage wird dann so ca. 4000 Kontakte haben. Das wäre das 50 fache. Also auch die 50fache Frequenz. Das macht dann 150000Hz. Hee? Ich hatte dort doch was von 750kHz ausgerechnet und nicht 150kHz.

Es gibt aber dann auch noch die Ausgabe, dort werden, kann man fast sagen alle 4 Besetzmelder ein neuer Block. Pro Block werden 8bit für die Fahrspannug und 1bit für die Fahrrichtung benötigt. Für meine Anlage also 20 an der Zahl.
Das würde dann 20x(8bit+1bit)=180bit machen. Diese wieder alle 25ms. Macht dann 7200bit/s. Also 7,2kHz. Für meinen Dad wieder das 50fache. Macht dann 360kHz.
Da waren es 1,08Mhz.

Ich muss mich da wohl verrechnet haben.

Das ganze ist auch noch 1Leitung. Ich hatte es für 5 Leitungen berechnet. Muss mir wohl ein Fehler unterlaufen sein. Sorry. Brauch dann keine 1Mhz sondern ein bisschen :-) weniger.

Trotzdem bräuchte ich eure Hilfe, da mein PC keine LPT Port und keine COM Port mehr hat.

mfg
Michael

com1 kanst du dir über adapter machen. ich würd aber nicht die ganze bahn anlage über ein µC laufen lassen sondern bissel verteilen

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

Code:

---

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

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

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

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

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

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

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

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

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

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.

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!