Hallo Rainer,
[quote="Rainer Müller" post_id=1684643 time=1493832425 user_id=1332]
Hallo Gerd,
Zitat
Ich habe mal einen Blick in den Code des modifizierten SRCPD von (Herrn) Sigg geworfen. Aufgrund eines Fehlers des RPi Chips muss da wieder einiges abgefangen werden. Zudem muss man dafür Sorgen, das immer genügend Daten über DMA dem SPI zur Verfügung stehen. Ob das mit dem BPi auch so möglich ist (DMA für SPI), weiß ich momentan nicht. Für eine externe MCU wäre die Erzeugung des Signals ein Klacks und lastet den Chip bei weitem nicht aus. Praktischer Weise lässt man die MCU gleich noch ein paar andere Protokolle mit machen, wie S88, Loconet, RS485 etc. pp.
da ich was ähnliches langfristig geplant hatte, habe ich den Code von Herrn Sigg sowie den dtcltiny - SRCP Model Train Controller auf meinem alten Raspberry Pi1 compiliert und ohne spezielle Beschaltung getestet. Das Signal sah gut aus, allerdings gab es auch einige Merkwürdigkeiten, teilweise durch das Basis-DDL verursacht, die sich aber lösen lassen sollten.
Ich habe aber das Problem, dass ich den SPI für einen CAN mit MCP2515 nutzen wollte, und das geht mit Sigg zusammen nicht. Lösungen wären, am RPi über den in den seriellen Modus schaltbaren PWM-Ausgang zu gehen, oder wegen der als nicht leistungsfähig bekannten CAN-Lösung mit MCP2515 auf einen Banana Pi mit Sigg-SW umzusteigen. Notfalls ist ein angepasster SPI-Treiber nötig ...
[/quote]Ich habe nach längerer Zeit mal wieder CAN mit MCP2515 auf einem RPi 3 einem Lasttest unterzogen. Ich bin positiv überrascht - die Stabilität und Performance ist wesentlich besser geworden. Trotz ordentlich Last (50% bei 1 MBaud - doppelt so viel wie theoretisch bei M*rklin mit 250kBaud) konnte ich keine Hänger oder verlorene CAN-Frames feststellen. Werde den Test aber nochmal mit einem modifizierten CANBuster wieder holen.
Somit wäre CAN auf dem RPi IMHO erst mal kein KO-Kriterium mehr. Aber der RPi bietet ansonsten leider nur eine sehr begrenzte Anzahl weiterer Schnittstellen (insbesondere UART) - abgesehen von USB.
Als ideale Maschine sehe ich immer noch die BeagleBones (BBB oder BBG) mit ihren dedizierten Realtime-Kernen (PRUSS) an. Da wäre das Gleissignal und noch ein paar andere Schnittstellen sehr gut umsetzbar. Die Beaglebones bieten zudem eine Vielzahl von Schnittstellen (incl. CAN) an. Nur die Verbreitung ist nicht so hoch, wie das beim Raspberry Pi ist.
Zitat
Zitat
BTW: Auch deshalb habe ich den UART rausgeführt um ein wenig damit zu experimentieren. Das Gleis-Signal muss ja nicht zwangsläufig extern zugeführt werden, sondern kann auch durch den PIC16F1705 generiert werden. Und über den I2C wäre es möglich, ein RDS Chip anzubinden. Sozusagen die Vorstufe zu einem eigenen GFP.
Der PIC16F1705 hat mit seinen 1024 Bytes RAM etwas wenig Platz für einen Refreshbuffer, aber seine Peripherals sind toll. Mit dem kann man den DCC-Railcom-Freunden entgegenkommen, indem man ihn nebenbei zur Erzeugung der Austastlücke abordnet.
Da hast Du natürlich recht - der PIC16F1705 kann kein vollwertiger GFP werden. Das RAM alleine ist zu knapp, wie Du schon zutreffend angemerkt hast. Aber als reiner Gleissignalgenrator, der seine Kommandos über UART bekommt, sehr gut geeignet. Die Intelligenz, wenn man das so sagen kann, käme vom Rechner, bevorzugt Linux-SBC ala RPi, BPi, BBB etc. pp.
Zitat
Irgendwie bin ich immer noch auf der Linie, das Digitalsignal zentral zu erzeugen und an identische Booster synchron zu verteilen, aber vielleicht kann man das bei der BTN8962-Endstufe ja vergessen.
Momentan bevorzuge ich eine Endstufe (IBT-2 bzw. BTN8962), da diese mehr Leistung bietet, als ich wahrscheinlich jemals brauchen werde.
Gruß
Gerd
Mit dem hier vorgestellten Booster nicht, aber durchaus mit einer Kombination aus 
deshalb nehme ich lieber eine THT-Platine mit komplettem Bauteilesatz... 
