Hallo Michael,
Zitat von st-oldie
Hallo Gerd,
Zitat von bertr2d2
Ich denke, es gibt sehr viele Möglichkeiten einfach und preiswert GPIOs anzubinden.
Mit I2C Portextender hab ich etwas Erfahrung auf der Arbeit gesammelt. Dort setzen wir auch solche ICs ein, um Ausgänge wie z.B. Status LEDs und Eingänge wie (externe) Taster abzufragen. Da hab ich schon Treiber in Linux integriert um z.B. einen LED Treiber auf den I2C Portextender aufzusetzen. Die Inputs könnte man auch über das Button Subsystem von Linux einbinden. Ist zwar Overhead, wäre aber eine definierte Schnittstelle bei der dann egal ist, wie die Inputs eingebunden werden. Sowas hätte den Vorteil, daß die Taster auch gleichzeitig gedrückt werden können.
Ich kenne das Button-Substem nicht in der Tiefe, aber IMHO ist das Over-Kill. Wir wollen "nur" den Zustand einiger Ports wissen und nicht irgendwelche Software-Bussysteme (ubus, kbus oder dbus oder wie die Dinge alle heissen) füttern.
Zitat
Zitat von bertr2d2
P.S.: Dein BBB bietet viel mehr GPIOs. Die kannst Du natürlich auch nutzen 
Mir hat erst einmal eine getrennte Lösung vorgeschwebt. Ich mag es nicht, zuviel in einer Lösung zu integrieren. Wenn eine Lösung kaputt ist, dann sind es alle und oft sind die Einzelteile nicht so leistungsfähig. Aber dazu müßte ich auch etwas Hardwarebasteln und das kann ich nicht. Ich bin nur bis zum Löten gekommen, wenn es kein SMD ist. Die Lösung mit PIO2 ist schon ganz nett, aber mit hatte eigentlich vorgeschwebt, die Lösung direkt an den CAN Bus anzuschließen. Oder macht es Sinn das ganze wie eine zusätzliche PC Steuerung zu sehen? Welche Ports für eine Tasterabfrage benutzt werden, wollte ich erst mal offen lassen. Da soll Raum für verschiedene Lösungen bleiben. Mit wieviel Tastern müßte man denn bei einem GBS rechnen? Ich denke, die Zahl von GPIOs dürfte da auch limitierend sein. Wahrscheinlich auch der CANBuster mit den vorgestellten Spezifikationen.
Viele Fragen auf einmal: Fangen wir mal mit CAN und der theoreitsch max. Anzahl der Meldungen an:
Für CAN ist die Meldungs Länge (Ken Tindells Guaranteeing Message Latencies on Controller Area Network" 1st ICC'94)
1
2
3
4
5
6
7
8
9
10
(54 + 8n)/5 + 67 + 8n for EFF frames (29 bit CAN-ID) => (389 + 48n)/5
mit n = 8 (DLC ist 8 bei Events) sind das
(389 + 48*8)/5 = 155 Bits pro CAN Frame
bei 250kB
250.000 /155 / s = 1611 Meldungen pro Sekunde bzw 80 % ca. 1290 Meldungen pro Sekunde
Das ist ne ganze Menge, was über CAN-Bus geschaufelt werden kann. Also reicht CAN locker für große Installationen aus, wenn die Komponenten klug gewählt werden.
Der CAN-Buster hat "nur" 16 GPIOs, aber wird nahezu beliebig erweiterbar sein, d.h. an einem CAN Strang können 256 (entspricht 256*16 Ports = 4096 Ports) CAN-Buster hängen. Wem das nicht ausreicht, kann einen beliebigen Linux Rechner nehmen (z.B. 7 Euro OpenWRT Router) und den Monitor-Port des CAN-Busters nutzen (Stichwort SocketCAN bzw SLCAN) und einfach einen neuen Strang aufmachen.. Das dürfte für jede Größe an Modellbahn reichen.
Auch wenn ich CAN für gut halte, ist IMHO der RS485-Bus sogar noch geeigneter: Quasi genauso robust wie CAN aber jede MCU mit UART (z.B. PIC oder AVR) hat quasi einen RS485 Controller on Board bzw. kann einfach nachgebildet werden. Aber das ist ein anderes Thema ...
Für die Leute, die nicht selbst Löten können, besteht natürlich das Problem, an preiswerte, fertige Module zu kommen. S88 ist zwar verrufen aufgrund der Störanfälligkeit, aber immer noch die günstigste Lösung. Und bei sorgfältige Verkabelung auch robust. Darum habe ich ein S88 Bus vorgesehen.
Die von einigen auch gemutmaßte Langsamkeit des S88 ist schlicht humbug. Ja, es kann bei einem sehr langen S88 Strang lange dauern, diesen abzufragen, aber man braucht ja eh ein Entprell-Algorithmus, der Zeitintervalle nutzt. Und S88 ist so einfach gestrickt, das schafft eine Feld-Wald-Wiesen-MCU mit links in einem untergeordneten Task. BTW: Allzu viele S88 Komponenten sollte man an M*rklins CS2 S88 Bus nicht hängen: das braucht erhebliche CPU-Zeit, da Linux eher ungeeignet ist für solche Aufgaben. M*rklins Link S88 ist wirklich eine kluge Ergänzung: EIne kleine, eigene CPU erledigt das S88 Protokoll und sendet die Events über CAN.
Losgelöst vom verwendeten Bussystem (CAN, RS485, I2C) geht es letztendlich doch nur darum, viele Ports robust und preisgünstig abzufragen. Und diese möglichst noch ans LAN anzubinden. Mit der Verbindung zum Netzwerk entfällt dann auch eine Limitierung der Anzahl der Ports und man kann M*rklins "CAN-API" (CAN-Frame ins Ethernet verpackt) verwenden, wenn man möchte.
Was ein GBS (Gleisbild-Stellpult ?) typischer weise an GPIOs braucht, weiß ich nicht. Aber für so einen Fall ist ein Portextender geschaffen worden. Oder man verwendet eine RPi B+ (bietet reichlich GPIOs) für unter 30 Euro. Nur mit GPIO-Zuständen melden wäre der natürlich unterfordert.
Zitat
Sowas wie der Portextender dürfte da wohl die bessere Lösung sein.
Wenn ich an Deiner Stelle wäre (kein Löten möglich) würde ich M*rklins Link S88 verwenden und bei Bedarf um S88 Module erweitern. Ist nicht
ganz bei meinem Ziel (1Euro/Port), aber sicherlich robust und gibt es noch in 20 Jahren ...
Und der Link S88 ist Update-Fähig im Gegensatz zu den Konkurrenzsystemen.
Gruß
Gerd
P.S.: Ich habe zwei PI02 (I2C Portextender mit je 32 Ports) nachgebaut, wenn Du willst, kannst Du sie mir abkaufen. Löten macht mir nix, eher im Gegenteil, ich empfinde es entspannend 
)
bzw ISO1050
. Oder Link S88 ...
: !
