You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(80) |
Feb
(10) |
Mar
|
Apr
(13) |
May
|
Jun
|
Jul
|
Aug
(22) |
Sep
(37) |
Oct
(27) |
Nov
(20) |
Dec
(2) |
2004 |
Jan
(20) |
Feb
(35) |
Mar
(17) |
Apr
(15) |
May
(44) |
Jun
(9) |
Jul
(14) |
Aug
(4) |
Sep
(1) |
Oct
(17) |
Nov
(23) |
Dec
(5) |
2005 |
Jan
(13) |
Feb
(4) |
Mar
(49) |
Apr
(30) |
May
(13) |
Jun
(24) |
Jul
(26) |
Aug
(13) |
Sep
(3) |
Oct
(38) |
Nov
(19) |
Dec
(68) |
2006 |
Jan
(14) |
Feb
(6) |
Mar
(12) |
Apr
(4) |
May
(16) |
Jun
(49) |
Jul
(40) |
Aug
(8) |
Sep
(2) |
Oct
(4) |
Nov
(16) |
Dec
(42) |
2007 |
Jan
(65) |
Feb
(36) |
Mar
(18) |
Apr
(70) |
May
(2) |
Jun
|
Jul
(9) |
Aug
(13) |
Sep
(13) |
Oct
(33) |
Nov
(173) |
Dec
(116) |
2008 |
Jan
(217) |
Feb
(5) |
Mar
(22) |
Apr
(1) |
May
|
Jun
(7) |
Jul
(4) |
Aug
(30) |
Sep
(6) |
Oct
(8) |
Nov
(17) |
Dec
(15) |
2009 |
Jan
(117) |
Feb
(2) |
Mar
(1) |
Apr
(24) |
May
(18) |
Jun
(30) |
Jul
(13) |
Aug
(51) |
Sep
(2) |
Oct
(5) |
Nov
(10) |
Dec
(47) |
2010 |
Jan
(9) |
Feb
(35) |
Mar
(84) |
Apr
|
May
(2) |
Jun
(8) |
Jul
(6) |
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(3) |
Dec
(24) |
2011 |
Jan
(7) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(10) |
Aug
(26) |
Sep
|
Oct
(12) |
Nov
(2) |
Dec
(4) |
2012 |
Jan
(38) |
Feb
(28) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(60) |
Nov
(13) |
Dec
|
2013 |
Jan
(32) |
Feb
(1) |
Mar
(16) |
Apr
(4) |
May
(7) |
Jun
(6) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
2014 |
Jan
(110) |
Feb
(38) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
(1) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
(2) |
Mar
(11) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
(26) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(13) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(46) |
Apr
(22) |
May
(12) |
Jun
(12) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
(5) |
Feb
(8) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Wolfgang B. <wol...@we...> - 2020-06-08 19:02:18
|
Danke, ja das is in der Tat eine delta. Da muesste man wohl umruesten (Motor und Decoder). Die andere Lok hat aber einen 60902-decoder und eine Telexkupplung an F2. Trotzdem gelingt es mir nicht, die anzusteuern. Vielleicht habt Ihr einen Tipp? Ich habe versucht: init 1 gl 45 M 5 28 2 set 1 gl 45 1 3 14 0 1 Mit F1 (hier 0) kann ich das Licht steuern. F2 hat keine Wirkung. Ist M5 das richtige Protokoll? Ist M 5(mit space richtig) Danke, Wolfgang |
From: <da...@ru...> - 2020-06-08 08:16:16
|
Hi all > I found it out by myself. I have to use /dev/ttyS0 instead of > /dev/ttyAMA0. I am not too well into the Raspberry pi layout so I > cannot tell the reason, usually, you have to use ttyAMA0 to make use > of the rs-232 uart. By the way, I have found a German description what is going on here for those who are interested <https://forum-raspberrypi.de/forum/thread/30190-konfiguration-der-gpio-mit-raspbian-jessie-und-raspberry-pi-3/> Best regards David |
From: Harald B. <hab...@kt...> - 2020-06-08 07:42:07
|
Hab da was gefunden (ok, ganz schreckliche Frames, aber Information drin): http://www.web-hgh.de/p01_45239b.htm http://www.web-hgh.de/p03_maedel_dec_66031.htm Grüße, Harald. |
From: Josef Z. <Jo...@we...> - 2020-06-08 06:46:12
|
<html> <head> <meta name="viewport" content="width=device-width"> <meta http-equiv="Content-Type" content="text/vnd.ui.insecure+html;charset=utf-8"> </head> <body style="overflow-wrap:break-word; word-break: break-word;"><div class="mail_android_message" style="line-height: 1; padding: 0.5em">Hallo Wolfgang<br/>Das ist wohl eine Delta Lok. Funktionen kennt Delta nicht, die sind hart verdrahtet. Telex wird i.d.R. über doppelte Fahrtrichtungsbefehle geschaltet. Licht brennt entweder immer oder nur bei Fahrt.<br/><br/>Grüße <br/>Josef Zinkernagel</div><div class="mail_android_quote" style="line-height: 1; padding: 0.3em"><html><body>Am 07.06.20, 20:47 schrieb Wolfgang Buesser <wol...@we...>:</body></html><blockquote class="gmail_quote" style="margin: 0.8ex 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Hallo, <br> <br> ich steuere jetzt zum ersten Mal Maerklin-Lokomotiven im M1-Format und <br> srcpd. <br> <br> Ich habe hier eine LOK mit einem DIP-8 Decoder. Da kann ich die <br> Geschwindigkeit und die Fahrtrichtung steuern und das Licht ueber F1 <br> ein-und aus-schalten. <br> <br> Ich habe eine zweite Lok mit einem DIP-4 Decoder und Telexkupplung. <br> Da kann ich zwar auch Fahrtrichtung und Speed steuern, aber das Licht <br> brennt immer und die Telexkupplung ist auf merkwuerdige Weise <br> fahrtrichtungsabhaengig. <br> <br> Kann mir irgendjemand einen Tipp geben wie ich da Licht und Telex <br> richtig ansteuere? <br> <br> Danke, <br> <br> Wolfgang <br> <br> <br> <br> _______________________________________________ <br> Srcpd-devel mailing list <br> Src...@li... <br> <a href="https://lists.sourceforge.net/lists/listinfo/srcpd-devel">https://lists.sourceforge.net/lists/listinfo/srcpd-devel</a> <br> </blockquote></div></body> </html> |
From: Wolfgang B. <wol...@we...> - 2020-06-07 18:47:10
|
Hallo, ich steuere jetzt zum ersten Mal Maerklin-Lokomotiven im M1-Format und srcpd. Ich habe hier eine LOK mit einem DIP-8 Decoder. Da kann ich die Geschwindigkeit und die Fahrtrichtung steuern und das Licht ueber F1 ein-und aus-schalten. Ich habe eine zweite Lok mit einem DIP-4 Decoder und Telexkupplung. Da kann ich zwar auch Fahrtrichtung und Speed steuern, aber das Licht brennt immer und die Telexkupplung ist auf merkwuerdige Weise fahrtrichtungsabhaengig. Kann mir irgendjemand einen Tipp geben wie ich da Licht und Telex richtig ansteuere? Danke, Wolfgang |
From: David R. <da...@ru...> - 2020-06-05 23:34:28
|
Heureka! I found it out by myself. I have to use /dev/ttyS0 instead of /dev/ttyAMA0. I am not too well into the Raspberry pi layout so I cannot tell the reason, usually, you have to use ttyAMA0 to make use of the rs-232 uart. Anyway, I am happy that the locos can now be controlled with srcpd 2.1.5. David > [...] > srcpd: [bus 1] usleep() failed: Interrupted system call (errno = 4) > srcpd: [bus 0] usleep() failed: Interrupted system call (errno = 4) > srcpd: [bus 1] Refresh cycle started. > srcpd: [bus 1] 1 ioctl() failed: Inappropriate ioctl for device > (errno = 23) > [...] > David |
From: David R. <da...@ru...> - 2020-06-05 20:50:19
|
Dear all The issue still exists on 2.1.5 release. Have set both logging options to 6. Here is /var/log/syslog: Jun 5 22:46:18 jimknopf srcpd[4991]: srcpd V2.1.5; SRCP 0.8.4; SRCPOTHER 0.8.3 Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 0] init_bus 0 Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 1] DDL init with debug level 5 Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 1] DDL init done Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 0] Time thread created. Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 0] Starting 1 bus interface threads. Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 0] Starting interface thread number 1 (type = 1). Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 0] Thread on bus 1 is woken up Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 0] Netservice thread for port 4303 created. Jun 5 22:46:18 jimknopf srcpd[4991]: All threads started Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 1] DDL bus started (device = /dev/ttyAMA0). Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 1] Refresh cycle started. Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 0] usleep() failed: Interrupted system call (errno = 4) Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 0] Changed to group nogroup Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 1] usleep() failed: Interrupted system call (errno = 4) Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 0] usleep() failed: Interrupted system call (errno = 4) Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 0] Changed to user nobody Jun 5 22:46:18 jimknopf srcpd[4991]: [bus 1] ioctl() failed: Inappropriate ioctl for device (errno = 25) Do you have any ideas? Regards David |
From: <da...@ru...> - 2020-06-05 09:11:23
|
Dear all > due to some recent feedback of Denis Fateyev and some other > investigations the source code could be improved further. So time for > new release. Thank you Guido and all other involved for the new version. This just reminds me that I tried yesterday to generate a DDL signal with the 2.1.4 release on a Raspberry Pi 3 on Raspbian buster without success. The 2.1.4 release compiles normally but when I start srcpd, there is no signal on track. /var/log/syslog says: [...] srcpd: [bus 1] usleep() failed: Interrupted system call (errno = 4) srcpd: [bus 0] usleep() failed: Interrupted system call (errno = 4) srcpd: [bus 1] Refresh cycle started. srcpd: [bus 1] 1 ioctl() failed: Inappropriate ioctl for device (errno = 23) [...] I could send detailled log files if needed this evening. Best regards David srcpd.conf: <?xml version="1.0"?> <srcpd version="2.1.0"> <!-- generated by srcpd web config generator version 1.4 --> <!-- save this file as srcpd.conf --> <bus> <server> <tcp-port>4303</tcp-port> <pid-file>/var/run/srcpd.pid</pid-file> <username>nobody</username> <groupname>nogroup</groupname> </server> <verbosity>2</verbosity> </bus> <bus> <auto_power_on>yes</auto_power_on> <verbosity>4</verbosity> <device>/dev/ttyAMA0</device> <ddl> <number_ga>0</number_ga> <number_gl>81</number_gl> <enable_maerklin>no</enable_maerklin> <enable_nmradcc>yes</enable_nmradcc> <enable_ringindicator_checking>no</enable_ringindicator_checking> <enable_checkshort_checking>no</enable_checkshort_checking> <inverse_dsr_handling>no</inverse_dsr_handling> <shortcut_failure_delay>0</shortcut_failure_delay> <nmradcc_translation_routine>3</nmradcc_translation_routine> <improve_nmradcc_timing>no</improve_nmradcc_timing> <enable_usleep_patch>no</enable_usleep_patch> <usleep_usec>250</usleep_usec> </ddl> </bus> </srcpd> |
From: Guido S. <gui...@gm...> - 2020-06-05 08:16:06
|
Dear all, due to some recent feedback of Denis Fateyev and some other investigations the source code could be improved further. So time for new release. Here are the release notes: srcpd-2.1.5 (2020-06-05) Fixed Bugs o Revert timing problem fix (r1743) New Features o Adjust handling of extern variables to comply to gcc-10 linker General Changes o Simplify time difference calculation o Convert encoding of some German text files to utf-8 o Small internal cleanups Please find the source code files at the usual place: https://sourceforge.net/projects/srcpd/files/srcpd/2.1.5/ Guido -- http://wie-im-flug.net/ http://www.lug-burghausen.org/ |
From: Guido S. <gui...@gm...> - 2020-06-05 07:47:15
|
Am Wed, 03. Jun 2020 um 06:30:07 +0600 schrieb Denis Fateyev: > Hello Guido, Hi Denis, > OK, I have patched the configure script in terms that it disables "ddl-s88" > support conditionally on-the-fly. > It doesn't fit for general use — just allows me to build the sources under > various architectures without modifying configure options. > For general use, it's better to disable "ddl-s88" with configure features — > like you mentioned in the man-file. > > > > I just have solved this "extern" variable declaration issues. Can you > > check the svn repository if it fits for you? > > > > Looks good for now. I haven't spotted any new build errors. > > > Now, there are some other suggestions: > > 1) Under "ppc64le" arch: > > ----- > gcc -D_REENTRANT -DSYSCONFDIR=\"/etc\" -DHAVE_CONFIG_H -I. > -I/usr/include/libxml2 -O2 -g -pipe -Wall -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions > -fstack-protector-strong -grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fcommon -m64 -mcpu=power8 > -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection > -pthread -c -o srcpd.o srcpd.c > In file included from /usr/include/bits/termios.h:76, > from /usr/include/termios.h:39, > from config-srcpd.h:30, > from srcp-command.c:12: > srcp-time.h:16:16: error: expected '{' before numeric constant > 16 | typedef struct _VTIME > | ^~~~~~ > ----- > This typedef declaration conflicts with another global struct which is > already defined. > Build log example: > https://kojipkgs.fedoraproject.org//work/tasks/530/45330530/build.log > > I have changed the declaration this way to avoid conflicts: > > --- a/src/srcp-time.h > +++ b/src/srcp-time.h > @@ -13,7 +13,7 @@ > #include <sys/time.h> > > /* time value */ > -typedef struct _VTIME > +typedef struct VTIMEDEF > { > int day; > int hour; > > — and it went well under all architectures. You could consider renaming it, > too. > > 2) German man-files and readme files are presented in Latin1 encoding — not > a real issue, but a little bit frustrating to read them in the modern > Unicode console: > ----- > .SH BESCHREIBUNG > .PP > Dieses Handbuch ist nicht vollst�ndig. F�r weitere Informationen > besuchen Sie bitte die Internetseite des Projektes unter > http://srcpd.sourceforge.net/. > ----- > > You could consider recoding them to UTF8 as the most compatible option, > e.g. using the following snippet: > ----- > for file in ./man/de/srcpd.* ./DESIGN ./README; do > iconv -f latin1 -t utf8 < $file > $file.new > mv -f $file.new $file > done > ----- > > 3) https://sourceforge.net/p/srcpd/code/1754/ > > Die ioperm() Funktion selbst ist+typischerweise nur auf i386 Hardware verfügbar. > > Nicht nur x86, sondern auch auf amd64 (x86_64) verfügbar. > Alles in allem, wie es früher bemerkt wurde, die beste Lösung wäre den > "ddl-s88" den anderen Architekturen anzupassen (wenn es möglich ist). thanks for your input, changes are applied. Release 2.1.5 is out now. https://sourceforge.net/projects/srcpd/files/srcpd/2.1.5/ Guido -- http://wie-im-flug.net/ http://www.lug-burghausen.org/ |
From: Guido S. <gui...@gm...> - 2020-05-28 14:39:09
|
Am Sun, 24. May 2020 um 04:09:29 +0600 schrieb Denis Fateyev: > Hello all, Hi Denis, > I have recently noticed that a new "srcpd" version 2.1.4 has been released, > thanks for that. But there are some issues with it under recent Fedora and > RHEL which I'd like to report: > 1) New version builds fail on these architectures which don't have > "sys/io.h" in glibc headers ported ("aarch64", "ppc64", "armv7", "s390x"): [...] > More detailed build log you could see here: > https://kojipkgs.fedoraproject.org//work/tasks/7639/44877639/build.log > Earlier, this wasn't an issue because this check was present, but didn't > cause a fatal interrupt like in the new version. In fact, the new version > can be built under "x86_64" and "x86" only. > The best solution would be to adapt configure scripts to other > architectures; regarding this topic I recommend ito use the configure features the package provides already. The ddl-s88 module uses the ioperm() function wich is not available on all systems. So consequently you can just disable this module for those architectures. See ./configure -- help for more details. > 2) "DDLS88" isn't compatible with architectures different from "x86_64" and > "x86". Currently, we exclude it from the build with a patch — but would be > better to adapt it for other arches; OK, so any idea how to implement this? > 3) The new version cannot be built with GCC 10+: [...] > The reason is that srcpd headers miss "extern" declarations, so when GCC10 > switched to "-fno-common" by default — it caused compile issues. > The current workaround is to use "-fcommon" forcefully, but declarations > are needed to be fixed in srcpd anyway. > You can find additional information here: > https://gcc.gnu.org/gcc-10/porting_to.html I just have solved this "extern" variable declaration issues. Can you check the svn repository if it fits for you? Guido -- http://wie-im-flug.net/ http://www.lug-burghausen.org/ |
From: Harald B. <hab...@kt...> - 2020-05-03 20:00:28
|
The SPI stuff seems to have been branched off around 2010. Then it's not clear if any patches from the trunk were ported in later. So I think the approach would be to take the old srcpd from 2010 where it was branched (Revision numbers look intact) and look at the context diff to srcpd-SPI. Then look how that patch applies to todays srcpd and how to resolve the conflicts. I think the translation and comment style is peanuts compared to that. Harald. |
From: Guido S. <gui...@gm...> - 2020-05-03 17:37:45
|
Am Sun, 03. May 2020 um 13:11:07 +0200 schrieb Wolfgang Buesser: > Hello, Hi Wolfgang, > have you considered merging with what is presented on > http://siggsoftware.ch/wordpress/category/modellbahn/ > I consider the approach of generating the DDL-signal on raspi via the > SPI-interface quite attractive. And this solution is somewhat 'hidden' > in the web. on principle yes, but a merge needs a lot of clean-up work. All German comments must be translated, C++ comment style must be tranfered to C comment style ... If you have some time please send a patch. Guido -- http://wie-im-flug.net/ http://www.lug-burghausen.org/ |
From: Wolfgang B. <wol...@we...> - 2020-05-03 11:16:49
|
Hello, have you considered merging with what is presented on http://siggsoftware.ch/wordpress/category/modellbahn/ I consider the approach of generating the DDL-signal on raspi via the SPI-interface quite attractive. And this solution is somewhat 'hidden' in the web. Kind regards, Wolfgang On Sun, 2020-05-03 at 10:48 +0200, Guido Scholz wrote: > Dear all, > to meet the currently increased interest regarding srcpd I just made > a > step forward and released the 2.1.4 version. This wraps up some fixes > and improvements being committed to the svn repository some time ago. > > Here are the release notes: > > srcpd-2.1.4 (2020-05-03) > Fixed Bugs > o Prevent direction inversion for emergency halt > o Fix Motorola code 246 (patch by Siegfried Grob) > o Add routines to cleanup used mutexes etc. properly > o Fix use of NUM_MODULES counter in configure.ac to be usable > with > non bash shells (patch by Sebastian Reitenbach) > > New Features > o Use 103 INFO message for extended BiDiB GL information > o Add xz option to make dist target > > General Changes > o Some internal code cleanup > o C99 compliant C compiler required > o Disable 100 INFO message triggered by INIT GL > > > Please find the source code files at the usual place: > > https://sourceforge.net/projects/srcpd/files/srcpd/2.1.4/ > > > Guido > > _______________________________________________ > Srcpd-devel mailing list > Src...@li... > https://lists.sourceforge.net/lists/listinfo/srcpd-devel -- |
From: Guido S. <gui...@gm...> - 2020-05-03 09:12:49
|
Dear all, to meet the currently increased interest regarding srcpd I just made a step forward and released the 2.1.4 version. This wraps up some fixes and improvements being committed to the svn repository some time ago. Here are the release notes: srcpd-2.1.4 (2020-05-03) Fixed Bugs o Prevent direction inversion for emergency halt o Fix Motorola code 246 (patch by Siegfried Grob) o Add routines to cleanup used mutexes etc. properly o Fix use of NUM_MODULES counter in configure.ac to be usable with non bash shells (patch by Sebastian Reitenbach) New Features o Use 103 INFO message for extended BiDiB GL information o Add xz option to make dist target General Changes o Some internal code cleanup o C99 compliant C compiler required o Disable 100 INFO message triggered by INIT GL Please find the source code files at the usual place: https://sourceforge.net/projects/srcpd/files/srcpd/2.1.4/ Guido -- http://wie-im-flug.net/ http://www.lug-burghausen.org/ |
From: Jos W. <jos...@ou...> - 2020-05-01 19:43:54
|
Hello Steamers, So i got it working !!!! changed overlays and kernel compilations for PI 4 Delta BR81 is running on the track with spi interface Jos Op 01-05-20 19:43 heeft Wolfgang Buesser <wol...@we...> geschreven: Danke fuer die Hinweise! Wie gesagt: Daniel Sigg macht S88 ueber SPI1 auf dem raspi. Ich weiss (noch) nicht mit welcher Datenrate. Da ich aber mit diesen Signalen eh nicht auf den bus will, sondern nur zu einem arduino, der (per Bitbanging) S88 emuliert und Daten sendet, die er zu vor per CAN eingesammelt hat, sollte die Datenrate kein Problem sein (hoffe ich). Wolfgang On Fri, 2020-05-01 at 18:47 +0200, Hans-Heinrich Müller wrote: > S88 über GPIO geht nur mit Bitbanging und belastet bei vielen > Rückmeldern > die CPU erheblich. SPI kann das per Hardware und belastet die CPU > dabei so > gut wie gar nicht. Bei 512 Kontakten habe ich 50% vs. 2% gemessen. > > Wichtig: SPI1 hat nicht den vollen Funktionsumfang wie SPI0. > Unterschiede > sind z.B. > - kein DMA (braucht man für DDL über SPI) > - nur SPI Mode 0 und 2 > - Minimale Taktfrequenz 30,5 kHz, d.h. 32,8 uSec Taktbreite und damit > vermutlich zu schnell. > > Schönen Gruß > Hans-Heinrich > > > -----Ursprüngliche Nachricht----- > Von: Harald Barth <hab...@kt...> > Gesendet: Freitag, 1. Mai 2020 18:01 > An: src...@li...; wol...@we... > Betreff: Re: [Srcpd-devel] S88 mit dem raspi > > > dass hier der S88 offenbar ueber SPI1 geht. > > Leider habe ich die entsprechenden Pins nicht auf meinem > > alten Raspi. > > Zwar kann ich eigentlich nix über S88 aber ich glaube nicht dass dazu > Pins nötig sind welche SPI können, sondern ich glaube man kann auch > GPIO pins nehmen die nix besonderes können. > > Grüße, > Harald. > > > _______________________________________________ > Srcpd-devel mailing list > Src...@li... > https://lists.sourceforge.net/lists/listinfo/srcpd-devel > _______________________________________________ Srcpd-devel mailing list Src...@li... https://lists.sourceforge.net/lists/listinfo/srcpd-devel |
From: Wolfgang B. <wol...@we...> - 2020-05-01 17:43:26
|
Danke fuer die Hinweise! Wie gesagt: Daniel Sigg macht S88 ueber SPI1 auf dem raspi. Ich weiss (noch) nicht mit welcher Datenrate. Da ich aber mit diesen Signalen eh nicht auf den bus will, sondern nur zu einem arduino, der (per Bitbanging) S88 emuliert und Daten sendet, die er zu vor per CAN eingesammelt hat, sollte die Datenrate kein Problem sein (hoffe ich). Wolfgang On Fri, 2020-05-01 at 18:47 +0200, Hans-Heinrich Müller wrote: > S88 über GPIO geht nur mit Bitbanging und belastet bei vielen > Rückmeldern > die CPU erheblich. SPI kann das per Hardware und belastet die CPU > dabei so > gut wie gar nicht. Bei 512 Kontakten habe ich 50% vs. 2% gemessen. > > Wichtig: SPI1 hat nicht den vollen Funktionsumfang wie SPI0. > Unterschiede > sind z.B. > - kein DMA (braucht man für DDL über SPI) > - nur SPI Mode 0 und 2 > - Minimale Taktfrequenz 30,5 kHz, d.h. 32,8 uSec Taktbreite und damit > vermutlich zu schnell. > > Schönen Gruß > Hans-Heinrich > > > -----Ursprüngliche Nachricht----- > Von: Harald Barth <hab...@kt...> > Gesendet: Freitag, 1. Mai 2020 18:01 > An: src...@li...; wol...@we... > Betreff: Re: [Srcpd-devel] S88 mit dem raspi > > > dass hier der S88 offenbar ueber SPI1 geht. > > Leider habe ich die entsprechenden Pins nicht auf meinem > > alten Raspi. > > Zwar kann ich eigentlich nix über S88 aber ich glaube nicht dass dazu > Pins nötig sind welche SPI können, sondern ich glaube man kann auch > GPIO pins nehmen die nix besonderes können. > > Grüße, > Harald. > > > _______________________________________________ > Srcpd-devel mailing list > Src...@li... > https://lists.sourceforge.net/lists/listinfo/srcpd-devel > |
From: Hans-Heinrich M. <hh...@hh...> - 2020-05-01 17:10:26
|
S88 über GPIO geht nur mit Bitbanging und belastet bei vielen Rückmeldern die CPU erheblich. SPI kann das per Hardware und belastet die CPU dabei so gut wie gar nicht. Bei 512 Kontakten habe ich 50% vs. 2% gemessen. Wichtig: SPI1 hat nicht den vollen Funktionsumfang wie SPI0. Unterschiede sind z.B. - kein DMA (braucht man für DDL über SPI) - nur SPI Mode 0 und 2 - Minimale Taktfrequenz 30,5 kHz, d.h. 32,8 uSec Taktbreite und damit vermutlich zu schnell. Schönen Gruß Hans-Heinrich -----Ursprüngliche Nachricht----- Von: Harald Barth <hab...@kt...> Gesendet: Freitag, 1. Mai 2020 18:01 An: src...@li...; wol...@we... Betreff: Re: [Srcpd-devel] S88 mit dem raspi > dass hier der S88 offenbar ueber SPI1 geht. > Leider habe ich die entsprechenden Pins nicht auf meinem > alten Raspi. Zwar kann ich eigentlich nix über S88 aber ich glaube nicht dass dazu Pins nötig sind welche SPI können, sondern ich glaube man kann auch GPIO pins nehmen die nix besonderes können. Grüße, Harald. _______________________________________________ Srcpd-devel mailing list Src...@li... https://lists.sourceforge.net/lists/listinfo/srcpd-devel |
From: Harald B. <hab...@kt...> - 2020-05-01 16:00:53
|
> dass hier der S88 offenbar ueber SPI1 geht. > Leider habe ich die entsprechenden Pins nicht auf meinem > alten Raspi. Zwar kann ich eigentlich nix über S88 aber ich glaube nicht dass dazu Pins nötig sind welche SPI können, sondern ich glaube man kann auch GPIO pins nehmen die nix besonderes können. Grüße, Harald. |
From: Harald B. <hab...@kt...> - 2020-05-01 15:41:42
|
Da musst du wahrscheinlich selber ein wenig programmieren, aber nicht so viel wenn du zuerst mal das da durchliest: http://www.s88udp.de/ Allerdings muss man das Ganze in /* Loop forever */ while ( 1 ) { int oldvalue, newvalue; (...) /* get sensor data */ (...) } zu einem eigenen Thread umbauen, sonst blockieren wir ja alles andere was srcpd machen soll(te). Danach sollte es aber auch kein Problem selber was zu schreiben um die Daten anstelle vom parport von den GPIO pins reinzubekommen. Dann braucht man sich auch nicht um Beerware vs GPL kümmern. Grüße, Harald. |
From: Wolfgang B. <wol...@we...> - 2020-05-01 15:25:12
|
danke! Das ist eine Moeglichkeit. Ich habe gerade auf http://siggsoftware.ch/wordpress/category/modellbahn/ gesehen, dass hier der S88 offenbar ueber SPI1 geht. Leider habe ich die entsprechenden Pins nicht auf meinem alten Raspi. Jetzt muss ich mich entscheiden: Eigentlich will ich den S88 nicht nutzen, weil das kein richtiger Bus - sondern eher eine Daisy-Chain ist. Ich moechte die Rueckmeldung ueber CAN machen. Die CAN-hardware mit MCP2515 benoetigt aber ein SPI-Interface am raspi. Da ich SPI0 schon fuer DDL nutze, und mir nicht klar war, dass die neueren raspis auch ein SPI1 haben, dachte ich, ich benutze S88 zur Kommunikation mit einem ardunio, der dann seinerseits auf CAN umsetzt. Da aber der S88 auf dem raspi offenbar auch ueber SPI1 geht, macht es vielleicht mehr Sinn, gleich ein CAN-Rueckmelde-System fuer srcpd zu kodieren. Was meinst Du? Wolfgang On Fri, 2020-05-01 at 17:08 +0200, Harald Barth wrote: > Da musst du wahrscheinlich selber ein wenig programmieren, aber nicht > so viel wenn du zuerst mal das da durchliest: http://www.s88udp.de/ > > Allerdings muss man das Ganze in > > /* Loop forever */ > while ( 1 ) { > int oldvalue, newvalue; > (...) > /* get sensor data */ > (...) > } > > zu einem eigenen Thread umbauen, sonst blockieren wir ja alles andere > was srcpd machen soll(te). Danach sollte es aber auch kein Problem > selber was zu schreiben um die Daten anstelle vom parport von den > GPIO > pins reinzubekommen. Dann braucht man sich auch nicht um Beerware vs > GPL kümmern. > > Grüße, > Harald. -- |
From: Wolfgang B. <wol...@we...> - 2020-05-01 14:40:40
|
Hallo, nhacdem das mit dem DDL-M1 so gut klappt, moechte ich jetzt den Rueckmeldebus S88 auf dem raspi (srcpd_050120) ausprobieren. Mein Problem: Das Readme spricht nur vom parallel-port. Was bedeutet das fuer den raspberry-pi? Welche pins werden genutzt? Danke, Wolfgang |
From: Jos W. <jos...@ou...> - 2020-04-27 16:35:45
|
Hi Manfred, I have some comments seen where the gpio clock freq. is have the old rasp. That’s why I try to use the spi interface where also some issues are around the bcm2835 and spi https://github.com/raspberrypi/linux/issues/3381 Regards, Jos Van: maevelhe <mae...@gm...> Beantwoorden - Aan: "src...@li..." <src...@li...> Datum: maandag 27 april 2020 om 17:27 Aan: "src...@li..." <src...@li...> Onderwerp: Re: [Srcpd-devel] issue regarding installation on Raspberry Pi 4 using /dev/spidev.0.0 Hi Jos, since I work with Raspberry Zero, I cannot comment on Raspberry 4. But in general I would expect that srcpd 2.1.3 should work properly on all Raspberries when using the serial interface. In your first posting I have seen that /dev/ttyS0 was configured. For my Raspi I had to configure the device /dev/ttyAMA0. And the pulse length of 50 usec, which you mentioned, seems not OK from my point of view. So I would suggest to check the interface on your Raspi. Can you power on/off your booster via SRCP ? Regard, Manfred |
From: maevelhe <mae...@gm...> - 2020-04-27 15:27:27
|
Hi Jos, since I work with Raspberry Zero, I cannot comment on Raspberry 4. But in general I would expect that srcpd 2.1.3 should work properly on all Raspberries when using the serial interface. In your first posting I have seen that /dev/ttyS0 was configured. For my Raspi I had to configure the device /dev/ttyAMA0. And the pulse length of 50 usec, which you mentioned, seems not OK from my point of view. So I would suggest to check the interface on your Raspi. Can you power on/off your booster via SRCP ? Regard, Manfred |
From: David R. <da...@ru...> - 2020-04-26 19:35:01
|
Hi Jos I am using srcpd on a Raspberry Pi 2 B, so I cannot comment if it should work on a recent RPi4 model. It's correct that you need bcm2835 header files. I suggest that you write to Daniel Sigg or better use commenting function on siggsoftware.ch / modellbahn. He seems helping as I got already valuable input to get srcpd working. I wish good luck David |