SRCPD mit MFX und anderen Erweiterungen

Ich habe srcpd um einige Funktionen erweitert:

  • Portierung auf RaspberryPi
    • Alle Modelle
    • Möglichkeit DDL über SPI Bus anstelle RS232 auszugeben.
      Damit können alle Protokolle (Märklin Motorola, NMRA DDC, MFX) perfekt erzeugt, mit praktisch 0-CPU Last, ausgegeben werden.
    • S88 Bus immer über SPI (zusätzliche Hardware notwendig, siehe unten).
  • Schnellerer Lok-Refresh, „Fast“ Refresh für Lok mit neuen Kommandos.
  • Märklin MFX Protokoll (zusätzliche Hardware notwendig, siehe unten). Inkl. automatische Erkennung, Dekoderkonfiguration etc.
    Wird nur auf SPI Bus unterstützt!
    Ohne zusätzliche RDS Rückmeldehardware verwendbar, wenn man die Lok UID’s kennt.
  • Lok Stop Kommandos werden priorisiert behandelt und überholen andere Kommandos, auch der selben Lok.
    Von Stopkommandos überholte Fahrtkommandos einer Lok werden dann verworfen.
  • „MobileStation Mode“: Umschaltung MobileStation Ausgabe auf SRCPD für Schaltdekoderkommandos.
  • XBee Module als eigener SRCPD Bus.
  • S88 Bus mit 2v3 Filterung
  • Einmalige,  automatische  Boosterwiedereinschaltung, wenn dieser wegen einem Kurzschluss ausschaltet.
  • Korrektur Märklin Motorola Ausgabe für Schaltdekoder, so dass auch diejenigen der Firma LDT mit SRCPD funktionieren.
  • Watch-Dog für automatisches Power Off, falls der Client nicht mehr regelmässig mit dem SRCPD Server kommuniziert.
  • Booster „Sigg Mode“ (Booster werden über Impulse auf DTR & RTS ein- ausgeschaltet.

Update 05.01.20:
Unterstützung mehrerer  MCP23S17 (16-BIT I/O EXPANDERS WITH I2C & SPI INTERFACE) von Rüdiger Seidel.

Update 02.01.22:
Periodische Widerholung MFX F16-31.
Support für Raspberry PI OS bullseye.

Downloads:

44 Gedanken zu „SRCPD mit MFX und anderen Erweiterungen“

  1. Das ist ja phantastisch! Ich will gerne meine Anlage nach langer Zeit wieder in Betrieb nehmen. Ich habe vor einigen Jahren mit erddcd gearbeitet und habe damals rcsh entwickelt. Das ist lange her…
    Jetzt will ich gerne auf srcpd und rocrail wechseln. Mein RPi läuft, srcpd ist kompiliert. Jetzt scheitere ich an der Konfiguration. Die Dokumentation ist etwas knapp. Gibt es irgendwo ein Forum für dein Programm? Viele Referenzen auf deinen srcpd habe ich nicht gefunden. Vielleicht wäre es auch sinnvoll, es auf der Originalseite zum srcpd zu nennen.
    Meine Probleme mit der Konfiguration sind (ich habe mit der beiliegenden Datei gestartet):
    * Fehler: [bus 1] Warning: 0x1 is not valid port address for s88 device.
    * Wie schalte ich zwischen SPI und RS232 um?
    * Welche Pins werden für RS232 verwendet? (Der Schaltplan dokumentiert SPI, wenn ich es richtig sehe.)
    * (weitere Fragen kommen bestimmt)

    Danke für deine tolle Arbeit und danke für deine Hilfe!
    Peer

  2. Für den S88 Bus wird von meiner Implementierung auf dem RasPi prinzipiell nur noch SPI unterstützt. Die Fehlermeldung „is not valid port address for s88 device.“ kommt nur, wenn der S88 Bus über LPT Port angesprochen werden soll. Das ist aber auf dem PI eigentlich nie der Fall… Hast du auf dem Raspberry compiliert (und configure ausgeführt)?
    Bei dir muss etwas mit der Compilation falsch sein. „configure“ sollte eigentlich den RaspberryPI erkennen und „RASPBERRYPI“ setzen, damit wird in „ddl-s88.c“ für SPI compiliert.
    Für S88 Port über LPT (also alles NICHT RasPI) wird in der Konfiguration die LPT Basisadresse erwartet, bei mir die SPI Dev. Nummer 1 => /dev/spidev1.

    Für das Gleissignal (nicht S88) kann noch der serielle Port verwendet werden, dies ist im Schaltplan „Schema Booster Anschlusss an RaspberryPI“ mit gestrichelter Linie eingezeichnet.
    Aber: ich empfehle dringend, nur noch SPI zu verwenden:
    * MFX wird nur mit SPI unterstützt
    * Perfekte Nachbildung MM un DCC
    * Praktisch ohne CPU Last
    Umschaltung SPI – Seriell: durch entsprechenden Devicenamen in der Konfiguration (SPI: /dev/spidev0.0 oder seriell: /dev/ttyAMA0)

    Gruss Dani

    1. Ich habe configure aufgerufen. Ich habe es gerade noch einmal gemacht. Allerdings wird der Computer wohl nicht als RPi erkannt. Ich habe einen RPi3. Kann es sein, dass der nicht erkannt wird? In /cpu/procinfo wird ausgegeben: Hardware: BCM2835. Wenn ich es richtig sehe, wird aber nur auf BCM270x geprüft. Ich bin leider nicht fit in autoconf. Kannst du helfen?

      Außerdem würde mich die Verschaltung des Boosters interessieren. Ich verwende einen Booster nach Dr. König. Dort werden nur 4 Leitungen verwendet: DSR, DTR, TX und GND. Bei dir sind es 7 Leitungen. Kannst du mir die Aufgaben erklären? Muss ich alle Leitungen nutzen? (mfx ist derzeit noch kein Thema für mich.)

  3. Habe auch einen Pi 3, der meldet sich mit cpuinfo BCM270x.
    Aber scheinbar wurde ab irgend einer Kernelversion diese Ausgabe geändert… 🙁
    Habe deshalb configure.in (und damit configure, du musst nur autoconf aufrufen) angepasst: Raspberry Erkennung ist nun über /proc/device-tree/model realisiert.
    Hoffe, das bleibt stabil …
    Update steht bereit.

    Boosteranschluss: meine srcpd Implementierung beherrscht nach wie vor alle Anschlussmöglichkeiten des Orginals, Beschreibung siehe da. Zusätzlich ist nur der „siggmode“ hinzugekommen. Hier wird ein Booster mit einem Impuls auf DTR / RTS (oder beim PI der dafür verwendeten IO’s, siehe ddl.c) ein- ausgeschaltet.

    1. Danke! Alles, bestens. Das Programm läuft nun problemlos. Nun muss ich den Booster korrekt anschließen. Da gibt’s noch etwas zu basteln, sollte aber kein grundsätzliches Problem werden…

      Ich denke auch schon über den s88-Bus nach. Um möglichst schnell voranzukommen: Wäre es möglich mit nur einem Bus die Schaltung zu vereinfachen oder gar komplett auf sie zu verzichten? Wenn ich es richtig sehe, ist die Schaltung (vor allem) dafür notwendig, die zwei Busse voneinander zu separieren.

  4. Nach einiger Zeit muss ich mich wieder melden. Ich hatte bisher keinen Erfolg, srcpd einzusetzen. (Vorbemerkung: Ich bin zwangsweise auf einen RPi 2 umgestiegen.)

    Ich kann den Server starten. (Ich verwende die Ansteuerung über SPI.) Ich habe Strom auf dem Gleis (Wagenbeleuchtung funktioniert), kann aber nicht erfolgreich Befehle an die Loks schicken. Ich habe ein kleines Testprogramm (aufbauend in rcsh) geschrieben, das einfach alle Loks von 1 bis 200 auf eine bestimmte Geschwindigkeit setzt. Dabei startet eine Lok, stoppt dann aber auch wieder, ohne dass ich einen entsprechenden Befehl senden würde. Das wiederholt sich dann immer wieder. Komischerweise haben auch in einer Situation einzelne Weichen geschaltet, obwohl ich gar keine Befehle dafür gesendet habe.
    Ich habe übrigens bei der Ansteuerung des MAX2323 einen Inverter bestehend aus einem Transistor eingesetzt, um den Inverter-Chip einzusparen. Dass Signale am Gleis anliegen, kann ich übrigens auch auf einem (uralten) Oszi sehen. Warum lassen sich aber die Loks nicht steuern? Hast du eine Idee?

    Ich habe auch versucht, die serielle Schnittstelle statt SPi zu nutzen. Hier startet der Server allerdings nicht. Ich erhalte die Fehlermeldung „Error initializing device /dev/ttyAMA0 (reset custom divisor -3). Abort!“. Mit der Fehlermeldung kann ich nichts anfangen. Den agetty Prozess habe ich übrigens beendet.)

    Auf meine Frage mit der s88-Ansteuerung habe ich leider keine Antwort erhalten. Heißt das, mein Anliegen lässt sich nicht (einfach) umsetzen?

    Und noch eine Frage: Ist dieses Forum das geeignete und erwünschte Medium, um Fragen zu stellen?

    Vielen Dank für deine Hilfe!

    1. Ich bin gerade auf den Hinweis im Plan gestolpert: „Leider hängt der SPI CLK vom CPU Clock ab (was für ein saudummes Design…) -> sämtliche dynamischen CPU/GPU etc. Clocks auf dem PI ausschalten!“

      Wie macht man das? Was heißt ausgeschaltet? Sollte „force_turbo=1“ gesetzt sein? Damit wäre die Dynamik ausgeschaltet – allerdings immer die höchste Geschwindigkeit eingestellt. Ist das das Gewünschte?

  5. S88 über SPI:
    Geht nicht ohne die zusätzliche Schaltung (ich hatte zumindest keine Idee wie). Meine Schaltung ist für 2*S88 an einem SPI Port mit 2 select Leitungen. Dies kann natürlich für einen Bus vereinfacht werde.

    Lok Problem:
    Ja, ich denke das mit dem SPI Clock wird das Problem sein. Dieser ist beim RaspberryPI scheinbar direkt aus dem CPU Clock abgeleitet. Sobald dieser wegen wenig CPU Last reduziert wird stimmt natürlich dann nichts mehr.
    Ausschalten mit „force_turbo=1“. Raspberry läuft dann immer mit dem maximalen CPU Takt. Ist eigentlich kein Problem, ich habe dann jedoch den maximalen Takt bei mir noch mit core_freq=250 und arm_freq=500 reduziert.

    Fragen hier sind OK, per Mail daniel@s…. auch möglich.
    Wie Du siehst bist du der erste hier.
    Hier läuft eine Portierung meiner Software auf den BananaPI:
    https://www.stummiforum.de/viewtopic.php?p=1727122#p1727122

  6. Hallo tolle Forschung hier.
    Ich habe den srcpd 2.1.3 von sourceforge auf dem Raspi in Betrieb. Derzeit steuere ich ausschliesslich Viessman Decoder 5211 damit an, Rückmeldungen mit dem günstigen Port Expander MCP23S17 gemäß Bastelvorschlag hier:
    https://www.pcwelt.de/ratgeber/Modellbahnsteuerung_mit_dem_Raspberry_Pi-Guenstig_selber_machen-8937533.html
    Soweit alles bestens.
    Warum ich dann auf diese Seite gestossen bin, ist, dass der Viessmann Bahnübergang 5104 damit nicht angesteuert werden kann. Du schreibst, Dein srcpd kommt mit LDT Decodern klar, ich vermute wegen des verbesserten Timing, deshalb möchte ich die hier vorgestellte Version probieren und anstelle der Ausgabe über die serielle Schnittstelle die Ausgabe über SPI nutzen, das wäre in einem nächsten Schritt fix umgelötet.
    Zunächst hatte ich Schwierigkeiten diesen srcpd zu installieren, das liegt daran, dass ich einen Raspberry Pi B Plus Rev 1.2 habe und in den Dateien ddl.c und ddl_mfx.c im „Unsupported new RaspberryPi Board version“ rauskomme.
    Nachdem das auskommentiert war und der s88 Bus in der srcpd.config auskommentiert, läuft dieser srcpd nun auch bei mir, zunächst noch über die serielle Schnittstelle. Meine Weichen können angesteuert werden. Klasse.
    Wo finde ich denn den Define für meinen Raspberry? Da bin ich noch nicht fündig geworden. RPI_BPLUS_GPIO_xy könnte schon richtig sein. Da bräuchte ich mal einen Tip.
    Schonmal schönen Dank und Respekt für die Forschung.
    Dem Vorschlag das ganze dann wieder auf den offiziellen srcpd Seiten einzupflegen schliesse ich mich an.
    Viele Grüße,
    Rüdiger Seidel

    1. Hallo Rüdiger
      Eigentlich sollte der Raspberry durch „configure“ erkannt werden, dadurch werden dann auch die #define RASPBERRYPI in „config.h“ gesetzt.
      Die in „configure“ definierte Logik ist folgende:
      – $host in arm*-*-linux
      – /proc/cpuinfo enthält „BCM270“
      – /proc/cpuinfo enthält „BCM2708“ -> Raspberry PI 1
      – /proc/cpuinfo enthält „BCM2709“ -> Raspberry PI 2 / 3
      Bei PI1:
      – /proc/cpuinfo enthält 0002 oder 0003 -> Board Revesion 1, sonst Rev. 2

      Das alles ist in „configure.in“ definiert, wenn notwendig auch da anpassen.
      Durch „autoconf“ wird dann wieder ein „configure“ erstellt.
      Wenn es für deinen PI etwas anzupassen gibt, bitte Rückmeldung an mich, so dass ich das übernehmen kann.

      Gruss
      Dani

      1. Hallo Daniel,
        mittlerweile habe ich Deinen srcpd auf spi 0.0 umkonfiguriert und den 4093 Schmitt Trigger vor den Eingang des MAX2323 gesetzt. Damit kann ich nun endlich den digitalen Bahnübergang 5104 von Viessman betreiben. Ich schreib das hier für die Allgemeinheit, falls noch ein begeisterter srcpd Anwender das Problem haben sollte. Jetzt warte ich optimistisch auf die angekündigten Digitalsignale. Vielen Dank für Deine Mühe.
        Gruß,
        Rüdiger

        1. Hallo Rüdiger
          Es freut mich dass es bei Dir funktioniert.
          Ein Inverter (z.B. 4093) vor dem MAX232 ist für Betrieb über SPI (und MM Protokoll) zwingend notwendig und deshalb auch in meinem Schema für den Boosteranschluss enthalten.
          Gruss Dani

  7. Hi,

    I am trying to build the RDS feedback module. I have my own design… but based on the gleissbox, and I find your design much more elegant.

    I do not speak German, and most of my understanding of your design comes from the google translator (!).

    I am having problems to undesrtand and find the right current transformer, Could you please provide a reference ? (preferably to farnell).

    Thanks in advance,

    1. Hello Manolo
      One possibility for current transformator is Farnell 2526845 (Coilcraft CU8965-ALD).
      Primary side with one coil in serial connection in the power line from the booster to the track.

      Best regards
      Daniel

  8. Hi Dani,

    ich bin gerade dabei eine Platine fertig zu machen und in einen Eisenbahnwagon zu stecken. Ein Prototypen habe ich 2017 schon einmal erstellt: https://blog.io-expert.com/maerklin-4316-central jedoch enthielt dieser noch keine MFX Rückmeldung. Eine Frage zu der Schaltung: Ist der Verstärker IC1 an pin 21 wirklich benötigt? Falls ich den Übertrager in Serie zum Stunt-Widerstand der Treiberbrücke hänge, sollte es glaube ich auch funktionieren und erspart mir die Gleichrichter Dioden, oder?

    Viele Grüße
    Manuel

    1. Hallo Manuel
      IC1:
      Ja, der wird benötigt. Beim ermitteln der UID einer neuen Lok antwortet diese nur mit einem kurzen Signal. Dieses reicht dem RDS Chip nicht um zu synchronisieren und Daten zu liefern.
      Deshalb ist der Komperator IC1 vorhanden der die Information liefert, ob ein RDS signal anliegt. Ohne diesen habe ich keine Möglichkeit gefunden das beim UID auslesen angewandte Verfahren umzusetzen.

      Übertrager:
      Dieser sollte möglichst nicht mit dem Digitalsignal direkt „belastet“ werden da dessen Polaritätswechsel um Faktoren grösser wirken als das RDS Signal. Da ich ihn aussehalb des Boosters habe, habe ich das mit der Gleichrichterbrücke gemacht.
      Wenn Du ihn im Booster vor der Treiberbrücke, also in einem DC-Pfad, unterbringen kannst, dann kannst Du auf die Dioden verzichten (macht übrigens auch Märklin in der Mobile-Station so).

      Gruss
      Dani

  9. Hallo Dani,

    danke für die Antwort, genau so hätte ich mir das gedacht.

    Wie fragst Du denn das MFX Detektivs-Signal in der Software ab? Geht das über SPI MISO?

    Ich habe zu der MFX Rückmeldung nach dem Transformator auch noch eine ACK Detektor Schaltung mit implementiert. Der Transformator hängt nun im DC Pfad der Booster-Brücke (zwischen Brücke und GND). Ich hatte gehofft, dass SRCP neben dem Programmieren auch ein Verify von CVs kann. So wie ich sehe leider nicht. Ich überlege derzeit, ob ich SRCPD diesbzgl. noch anpasse. Hier zumindest die Schaltung: https://cloud.schreinerman.de/index.php/s/xCtnimb9y2YZya7

    Gruss
    Manuel

    1. Hallo Manuel
      Ja, MFX Dedektion wird über SPI MISO abgefragt. Nach dem entsprechenden SPI Transfer muss einfach an entsprechender Stelle im Eingangsbuffer gesucht werden.

      Betr. ACK bin ich nicht sicher ob ich dich richtig verstehe.
      Bei MFX gehen alle Rückmeldungen über RDS, also auch das auslesen der Konfigurationsdaten inkl. Verify (das auch geht).
      Wenn du DCC ACK meinst, dann ist nach dem Tarfo auch nicht so gut, da an dieser Stelle von der DCC ACK Stromerhöhung nur noch die positive / negative Flanke sichtbar ist.

      Gruss
      Dani

  10. Hallo Dani,

    genau das meinte ich: MFX Rückmeldung + DCC ACK Detektion.
    Ich habe das ganze bei mir etwas simuliert. Die Idee wäre, nur den Last-Wechsel des ACKs zu erkennen, das wäre zuverlässiger als das eigentliche ACK komplett zu erkennen. Es geht schliesslich nur um eine Bestätigung.

    Übrigens, ich habe einen kleinen Beitrag erstellt, in dem beschrieben wird, wie man einen Booster für etwa 7€ relativ simpel und klein aufbauen kann: https://blog.io-expert.com/simpler-mini-booster-fur-dll-srcpd-mit-max14870

    Viele Grüße
    Manuel

  11. Hallo,
    ich vesuche gerade Dein srcpd auf einem raspi 1 Model B Rev2.0
    mit dem letzten wheezy zu kompilieren:
    mcp-fb.h:47:21: fatal error: bcm2835.h: No such file or directory

    Offenbar erkennt autoconf die CPU falsch. Was soll ich tun?

    Gruss,

    Wolfgang

  12. Hello Daniel,

    i have some questions regarding your srcpd implementation & spi
    so i can use the srcpd interf. sending data thru rs232. The Pi i used is one of version 4B. I have been contacting David Rutti
    He advised you as the knowledge base. So i can compile the srcpd
    with an bcm2835 lib ( http://www.airspayce.com/mikem/bcm2835/ )
    But the inteface /dev/spidev0.* is not there , can you help me with this ?

  13. So einfach ist es nie, fuer pi 4 muss mann kernel source download , run make und dann ist es da anyspi.dtbo

    dann … kommt die magik.

    spi ausschalten im config.txt und hinzufugen :

    dtoverlay=anyspi:spi0-1
    dtoverlay=anyspi:spi1-1
    dtdebug=1

    neustart Pi4 und kontrolieren ob im /dev/ die spi interface da sind.

    So geht dass mit eine PI 4 und SRCPD_SIGG.
    Um Ihere Code zu bauen muss ihre configure geandert worden mit :

    if grep ‚Pi 4‘ /proc/device-tree/model >/dev/null 2>&1; then

    $as_echo „#define RASPBERRYPI_MODEL_2_3 1“ >>confdefs.h

    fi

    Auch muss die lib BCM2835 erst neu generiert und installiert sein.

    Spass wass…

  14. Hi Dani,

    Wenn ich jetzt nur Txd, Dsr und Gnd am Booster habe (alte Bogobit Version), sowie rail und Gnd als Ausgang …. Verwende ich von nur IC1_14 als Txd und IC2_13 als Dsr. Verbinde alle Gnd und lege als vcc 3.3v an. Klar noch 4093N plus die 100n…

    Oder kann/muss ich noch andere Ausgänge brücken oder mit rail verbinden. Mein Ziel ist es über SPI ein perfektes Signal für Märklin zu bekommen.

    Morgen kommen hoffentlich meine Bauteile von R***** und dann gehts ans Löten…
    Software ist schonmal auf dem PI drauf 😀

    Gruss Franz

    1. Hallo Franz
      Ja, im Minimum reicht es mit nur Tx und der Rückmeldung ob der Booster auf Go/Stop ist auf DSR.
      Den Rest kannst Du dann weglassen.
      Wenn Du MFX willst kommt natürlich noch die Schaltung für die MFX Rückmeldung hinzu.
      Und mit SPI Ausgabe werden alle Protokolle (Märklin Motorola, DCC, MFX) perfekt sauber ausgegeben!
      Gruss Dani

    1. Hallo Ralf
      Habe srcpd für Raspberry PI mit bullseye angepasst. Hat ein wenig länger gedauert, ich musste mir zuerst einen PI mit bullseye aufsetzen.
      Zumindest compiliert es nun darauf, allerdings bin ich mit meinem aktiv angesetzten System noch nicht auf bullseye, den Test ob es wirklich funktioniert müsstest Du machen.
      Gruss
      Dani

  15. Hallo zusammen,
    hat schon jemand erfolgreich seinen Decoder über srcpd programmiert? Mir will es einfach nicht gelingen, weder über den Motorola-Weg noch über DCC. Im Stummiforum gab es auch noch keine hilfreiche Rückmeldung.
    Verwendet habe ich den nmra-programmer und habe versucht, die Adresse, Beschleunigung und Bremsverzögerung zu setzen. Ein Programmiergleis habe ich nicht, das ist nach meinem Verständnis auch nicht notwendig. Weder POM noch direkte Programmierung waren erfolgreich.
    Ich bin für alle Hinweise dankbar.
    Gruß, Peer

  16. Hallo!

    ersteinmal vielen Dank für das update für Bullseye.

    Jedoch hab ich ein Problem, bei dem ich nicht weiter komme.
    ./configure läuft ohne Fehlermeldung auf dem PI 3+ durch, bis auf eine Meldung ganz am Schluss und make bringt dann folgende Meldung:

    Unsupported devices:

    Run ‚make‘ to continue.
    armv7l-unknown-linux-gnueabi
    pi@pi:~/srcpd $ make
    Making all in src
    make[1]: Verzeichnis »/home/pi/srcpd/src« wird betreten
    (CDPATH=“${ZSH_VERSION+.}:“ && cd .. && autoheader)
    /bin/bash: Zeile 1: autoheader: Kommando nicht gefunden.
    make[1]: *** [Makefile:411: config.h.in] Fehler 127
    make[1]: Verzeichnis »/home/pi/srcpd/src« wird verlassen
    make: *** [Makefile:440: all-recursive] Fehler 1
    pi@pi:~/srcpd $

    Was könnte denn hier die Lösung sein?

    Vielen Dank!
    grüße
    Micha

    1. Die „autotools“ müssen installiert sein, „autoheader“ wurde nicht gefunden. Das sollte alles sein:
      sudo apt install make cmake automake autoconf m4 libtool build-essential

  17. Hallo Daniel, ich versuche gerade SRCPD mit deiner mfx-Erweiterung auf meinem Pi3 Model B zu installieren und bekomme beim starten der Software die Meldung:
    [bus 1] Open SPI Device /dev/spidev1.0 fail!

    SPI ist aktiviert: pi@raspberrypi:~ $ ls /dev/spi*
    /dev/spidev0.0 /dev/spidev0.1

    Was könnte das sein ?
    Grüße
    Roland

    1. Hallo Roland
      Fehlermeldung ist, dass SPI1 nicht geöffnet werden konnte, Du hast aber nur SPI0 verfügbar.
      Kann es sein, dass in der Config Datei den S88 auf SPI1 aktiv hast? Wie sieht deine Config-Datei aus?
      Gruss Dani

      1. Hallo Daniel, ich benutze die unveränderte Datei:


        12345
        /var/run/srcpd.pid
        daemon
        daemon
        yes

        3

        1
        0
        50
        100
        18
        23
        0
        0

        yes
        3

        324
        255
        yes
        yes
        1021970
        no
        no
        no
        500000
        3
        no
        no
        0
        no
        yes

        no
        3
        /dev/spidev0.0

        1. In meiner srcpd.conf wird noch der S88 Bus auf spi1 aktiviert:
          bus
          ddl-s88
          ioport 1

          Bei dir gibt es kein spi1, siehe Ausgabe „ls /dev/spi*“.
          Nimme den S88 Bus mal ganz weg.
          Gruss Dani

  18. Hallo Daniel, hier das syslog ohne s88:

    Apr 11 09:46:13 raspberrypi kernel: [ 33.112035] cam-dummy-reg: disabling
    Apr 11 10:03:29 raspberrypi srcpd[1328]: [bus 0] Reading configuration for bus ’server‘
    Apr 11 10:03:29 raspberrypi srcpd[1328]: [bus 0] watchdog: yes
    Apr 11 10:03:29 raspberrypi srcpd[1328]: [bus 1] init GL: 255
    Apr 11 10:03:29 raspberrypi srcpd[1330]: Opening pid file ‚/var/run/srcpd.pid‘ failed: Permission denied (errno = 13)
    Apr 11 10:03:29 raspberrypi srcpd[1330]: srcpd V2.1.1; SRCP 0.8.4; SRCPOTHER 0.8.3
    Apr 11 10:03:29 raspberrypi srcpd[1330]: All threads started
    Apr 11 10:03:29 raspberrypi srcpd[1330]: [bus 1] tcflow() failed: Unknown error -1 (errno = -1).

  19. Dieses mal mit sudo:
    Apr 15 10:39:43 raspberrypi srcpd[1311]: [bus 0] Reading configuration for bus ’server‘
    Apr 15 10:39:43 raspberrypi srcpd[1311]: [bus 0] watchdog: yes
    Apr 15 10:39:43 raspberrypi srcpd[1311]: [bus 1] init GL: 255
    Apr 15 10:39:43 raspberrypi srcpd[1313]: srcpd V2.1.1; SRCP 0.8.4; SRCPOTHER 0.8.3
    Apr 15 10:39:43 raspberrypi srcpd[1313]: All threads started
    Apr 15 10:39:43 raspberrypi srcpd[1313]: [bus 0] usleep() failed: Interrupted system call (errno = 4)
    Apr 15 10:39:43 raspberrypi srcpd[1313]: [bus 0] usleep() failed: Interrupted system call (errno = 4)
    Apr 15 10:39:43 raspberrypi srcpd[1313]: [bus 0] usleep() failed: Interrupted system call (errno = 4)
    Apr 15 10:39:43 raspberrypi srcpd[1313]: [bus 0] usleep() failed: Interrupted system call (errno = 4)
    Apr 15 10:39:43 raspberrypi srcpd[1313]: [bus 1] tcflow() failed: Unknown error -1 (errno = -1).

Schreibe einen Kommentar zu Rüdiger Seidel Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht.

− two = 2