Menu
▾
▴
srcpd-devel
|
From: Guido S. <gui...@ba...> - 2012-10-24 19:09:23
Attachments:
signature.asc
|
Hello all,
as winter time is aproaching, which means more in house activitiy, I
would like to propose a new srcpd release.
The current NEWS file only lists these lines:
Fixed Bugs
o Fix Lenz GA address handling (bug introduced in version 2.0.11).
New Features
o Support for up to 28 GL functions in Lenz module.
But I am not sure if those describe all what happened since the last
release. Can someone contribute more information?
Guido
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
|
|
From: Matthias T. <mt...@we...> - 2012-10-24 19:44:07
|
Re-Hi, > But I am not sure if those describe all what happened since the last > release. Can someone contribute more information? For the loconet module I've made some minor improvements for the device handling (flow control etc) to work with usb2serial adapters. I remember some changes for Open-BSD portability as well. Matthias |
|
From: Guido S. <gui...@ba...> - 2012-10-28 09:33:47
Attachments:
signature.asc
|
Am Wed, 24. Oct 2012 um 21:43:58 +0200 schrieb Matthias Trute: Hello Matthias, > > But I am not sure if those describe all what happened since the last > > release. Can someone contribute more information? > For the loconet module I've made some minor improvements for the > device handling (flow control etc) to work with usb2serial adapters. > I remember some changes for Open-BSD portability as well. this is added tho the NEWS file. I have meanwhile changed the getaddrinfo() usage in the Loconet module to check all available addresses. It should just work, but may be you could do a quick check. Guido -- http://www.bayernline.de/~gscholz/ http://www.lug-burghausen.org/ |
|
From: André S. <an...@me...> - 2012-10-24 19:56:14
|
Hi Guido, nice to see you back with srcpd development! > But I am not sure if those describe all what happened since the last > release. Can someone contribute more information? I think I put some comments to the "ChangeLog" file. If I go through the SVN log then I see: DDL: - allow 28 speed steps for DCC Intellibox: - read initial power state from IB on startup - enabled functions F17 - F28 (OpenDCC) - fixed baud rate negotiation common: - added missing TERM GA function - send info message for SET SM, INIT SM, TERM SM - reject INIT GL if device is locked Best regards, André |
|
From: <sr...@ro...> - 2012-10-25 07:43:46
|
Hi Guido, concerning the DDL code, I remember, that early this year the 0.8 protocol compatibility was broken (it now expects NMRA protocol 1 to 5 instead of the defined 1 and 2 - there was some long discussion about this). Torsten announced to re-work this, but I don't think that this has happened yet. So from the DDL module a release is currently not useful. Joerg |
|
From: <vog...@gm...> - 2012-10-25 08:11:28
|
Hello all, Joerg, you are right. Sorry, i found no time to correct this issue. At the moment, i cannot see a chance to solve it in the near future. Has anybody else capabilities to do this? Torsten Am 25.10.2012 09:01, schrieb sr...@ro...: > Hi Guido, > concerning the DDL code, I remember, that early this year the 0.8 > protocol compatibility was broken (it now expects NMRA protocol 1 to 5 > instead of the defined 1 and 2 - there was some long discussion about > this). > Torsten announced to re-work this, but I don't think that this has > happened yet. So from the DDL module a release is currently not useful. > Joerg |
|
From: Guido S. <gui...@ba...> - 2012-10-28 09:57:45
Attachments:
signature.asc
|
Am Thu, 25. Oct 2012 um 09:01:39 +0200 schrieb sr...@ro...: > Hi Guido, Hello Jörg, > concerning the DDL code, I remember, that early this year the 0.8 protocol > compatibility was broken (it now expects NMRA protocol 1 to 5 instead of the > defined 1 and 2 - there was some long discussion about this). > Torsten announced to re-work this, but I don't think that this has happened yet. Hm yes, I weakly remember. > So from the DDL module a release is currently not useful. We could put the curent state by side to a branch and publish the code of the last version (2.1.1) again. Guido -- http://www.bayernline.de/~gscholz/ http://www.lug-burghausen.org/ |
|
From: Guido S. <gui...@ba...> - 2012-10-28 09:50:52
Attachments:
signature.asc
|
Am Wed, 24. Oct 2012 um 21:52:39 +0200 schrieb André Schenk: > Hi Guido, Hello André, > I think I put some comments to the "ChangeLog" file. > > If I go through the SVN log then I see: > > DDL: > - allow 28 speed steps for DCC > > Intellibox: > - read initial power state from IB on startup > - enabled functions F17 - F28 (OpenDCC) > - fixed baud rate negotiation > > common: > - added missing TERM GA function > - send info message for SET SM, INIT SM, TERM SM > - reject INIT GL if device is locked that is done also. Concerning the "fixed baud rate negotiation" issue I would like to propose to switch P50X mode off instead of extending the baud rate names by a leading "X". What about this idea? By the way I found the config file generator http://srcpd.sourceforge.net/srcpd/cfg/ stil makes configuration files where general bus options precede bus specific options: <bus> <general_option>...</general_option> <intellibox> <special_option>...</special_option> </intellibox> </bus> In this case bus specific default values will overwrite general options set before (like "auto_speed_detection"). The right sequence is this one: <bus> <intellibox> <special_option>...</special_option> </intellibox> <general_option>...</general_option> </bus> This could have also contributed to the bug reported in the opendcc forum. FYI: I have just improved the firmware version check to print readable output. Guido -- http://www.bayernline.de/~gscholz/ http://www.lug-burghausen.org/ |
|
From: André S. <an...@me...> - 2012-10-29 08:06:03
|
Hi Guido, > that is done also. Concerning the "fixed baud rate negotiation" issue > I > would like to propose to switch P50X mode off instead of extending > the > baud rate names by a leading "X". What about this idea? Just do it. ;-) > By the way I > found the config file generator > http://srcpd.sourceforge.net/srcpd/cfg/ > stil makes configuration files where general bus options precede bus > specific options: > <bus> > <general_option>...</general_option> > <intellibox> > <special_option>...</special_option> > </intellibox> > </bus> Without a deeper knowledge of the code I would understand this as - take the general options first - If there are bus specific options then overwrite the general options with the bus specific ones. This sounds correct to me. Best regards, André |
|
From: Guido S. <gui...@ba...> - 2012-10-29 18:13:17
Attachments:
signature.asc
|
Am Mon, 29. Oct 2012 um 09:01:28 +0100 schrieb André Schenk: > Hi Guido, Hello André, > > <bus> > > <general_option>...</general_option> > > <intellibox> > > <special_option>...</special_option> > > </intellibox> > > </bus> > Without a deeper knowledge of the code I would understand this as > > - take the general options first > - If there are bus specific options then overwrite the general options > with the bus specific ones. > > This sounds correct to me. Yes and no. Setting up a brand new srcpd.conf I had some trouble concerning the flag "auto_speed_detection", which is a "general option". I found it makes a difference if it is set before or after the bus-type tag: 1) [from config file generator] <bus> <general_option>...</general_option> <intellibox> </intellibox> </bus> 2) <bus> <intellibox> </intellibox> <general_option>...</general_option> </bus> In case 1 the flag was simply ignored because here the general option is overwritten by default values which are set during bus-setup in "read[Cc]onfig_DEVICE". May be it is time now to change the file format to something more robust like this: <bus type=intellibox> <general_option>...</general_option> <specific_option>...</specific_option> </bus> Bus option parameters would then be sequence independent. I remember there was a similar issue concerning ddl-s88 some years ago. Guido -- http://www.bayernline.de/~gscholz/ http://www.lug-burghausen.org/ |
|
From: Guido S. <gui...@ba...> - 2012-11-02 16:59:59
Attachments:
signature.asc
|
Am Mon, 29. Oct 2012 um 19:13:04 +0100 schrieb Guido Scholz:
Hallo all,
> May be it is time now to change the file format to something more robust
> like this:
> <bus type=intellibox>
> <general_option>...</general_option>
> <specific_option>...</specific_option>
> </bus>
I have created a branch named "bus-type" implementing this feature
now. It reads config files like this:
<?xml version="1.0"?>
<srcpd version="2.1.0">
<bus type="server">
<tcp-port>4303</tcp-port>
<pid-file>/var/run/srcpd.pid</pid-file>
<username>nobody</username>
<groupname>nogroup</groupname>
<verbosity>2</verbosity>
</bus>
<bus type="intellibox">
<number_fb>1</number_fb>
<number_ga>300</number_ga>
<number_gl>300</number_gl>
<fb_delay_time_0>0</fb_delay_time_0>
<pause_between_commands>0</pause_between_commands>
<auto_power_on>yes</auto_power_on>
<verbosity>4</verbosity>
<device>/dev/ttyUSB0</device>
<speed>19200</speed>
<auto_speed_detection>no</auto_speed_detection>
</bus>
</srcpd>
Even if this looks pretty smart now, I am not really pleased with the
result because there are two nasty side effects:
1) The bus options are scanned twice, first time by bus initialization
(bus specific options), second time at the general options routine.
This is of course not economical.
2) As both option routines do not know anything about parameters of
the other routine I had to drop the "unknown tag" warnings. So
currently there are no warnings if a misspelled tag occurs, which
is not first choise for manually edited xml-files (or xml-files at
all).
As a result of these "errors" I would propose to remove the general
options completely and support them as bus specific options instead.
Are there other ideas?
Guido
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
|
|
From: Matthias T. <mt...@we...> - 2012-10-29 18:35:55
|
Hi, > Setting up a brand new srcpd.conf I had some trouble concerning the flag > "auto_speed_detection", which is a "general option". I found it makes a > difference if it is set before or after the bus-type tag: > > 1) [from config file generator] > <bus> > <general_option>...</general_option> > <intellibox> > </intellibox> > </bus> > > 2) > <bus> > <intellibox> > </intellibox> > <general_option>...</general_option> > </bus> > > In case 1 the flag was simply ignored because here the general option is > overwritten by default values which are set during bus-setup in > "read[Cc]onfig_DEVICE". > > May be it is time now to change the file format to something more robust > like this: > > <bus type=intellibox> > <general_option>...</general_option> > <specific_option>...</specific_option> > </bus> There are only a few general options at all device verbosity use_watchdog restore_device_settings auto_power_on speed auto_speed_detection (? why is this not an option for speed?) esp the device settings are commonly used (except for auto_speed, which does not makes sense for at least the marklin 6051 interface). On the other hand, there are now very different methods for a device, that makes it troublesome to integrate serial lines, CAN devices, ethernet targets (with and without IP) into one settings schema. If a redesign of the config file is really needed (which I seriously doubt currently, the name collision can easily avoided by renaming the affected tag), the above names are good candidates as well. They are not well-choosen (mea culpa). Thinking about it, it may be a good strategy to drop all tags except verbosity and watchdog from the general settings and move all other stuff into the bus specific sections. auto_power_on can easily be deleted, a smart startup script can do that as well. Just my 2c Matthias |
|
From: Guido S. <gui...@ba...> - 2012-10-29 22:20:38
Attachments:
signature.asc
|
Am Mon, 29. Oct 2012 um 19:35:45 +0100 schrieb Matthias Trute: > Hi, Hello Matthias, > There are only a few general options at all > > device > verbosity > use_watchdog > restore_device_settings > auto_power_on > speed > auto_speed_detection (? why is this not an option for speed?) because this would mix up two different meanings in one variable. > esp the device settings are commonly used (except for auto_speed, > which does not makes sense for at least the marklin 6051 interface). > On the other hand, there are now very different methods for a device, > that makes it troublesome to integrate serial lines, CAN devices, > ethernet targets (with and without IP) into one settings schema. You are quite right, but the real root cause for this trouble is not to have the different options for different devices but the variable evaluation of "general" options and "module specific" options. The implementation of the config file layout is just erroneous. The sequence of options for a specific bus should not result in different server behavior respectively ignoring one option or not. To remove or rename one or another option will not change this error. If we chose my proposed layout, all options will be on the same level, independent if they are general or specific and in what sequence they are listed. The transition to this new file format is not really pleasant for users used to the old format. That is quite clear. Guido -- http://www.bayernline.de/~gscholz/ http://www.lug-burghausen.org/ |
|
From: Guido S. <gui...@ba...> - 2012-11-02 17:42:33
Attachments:
signature.asc
|
Am Mon, 29. Oct 2012 um 19:35:45 +0100 schrieb Matthias Trute: Hello Matthias, > device > verbosity > use_watchdog > restore_device_settings > auto_power_on > speed > auto_speed_detection (? why is this not an option for speed?) > > esp the device settings are commonly used (except for auto_speed, > which does not makes sense for at least the marklin 6051 interface). > On the other hand, there are now very different methods for a device, > that makes it troublesome to integrate serial lines, CAN devices, > ethernet targets (with and without IP) into one settings schema. > > If a redesign of the config file is really needed (which I seriously > doubt currently, the name collision can easily avoided by renaming the > affected tag), the above names are good candidates as well. They are > not well-choosen (mea culpa). Thinking about it, it may be a good > strategy to drop all tags except verbosity and watchdog from the > general settings and move all other stuff into the bus specific > sections. auto_power_on can easily be deleted, a smart startup script > can do that as well. concerning an options naming scheme I would like to keep the xml-node-tree flat and simple, like this: device_type = network device_host = 127.0.0.1 device_port = 0815 Renaming taken into account: restore_device_settings -> device_restore_settings sync-time-from-loconet -> loconet_sync_time loconet-id -> loconet_id Guido -- http://www.bayernline.de/~gscholz/ http://www.lug-burghausen.org/ |
|
From: Matthias T. <mt...@we...> - 2012-11-04 14:37:47
|
Hi, > concerning an options naming scheme I would like to keep the > xml-node-tree flat and simple, like this: > > device_type = network > device_host = 127.0.0.1 > device_port = 0815 This way you combine a flat formal structure with a deeply nested non-formal structure. I cannot see any advantage here (to be polite). The flat design looks like a legacy windows ini file in XML syntax. Some of the "nasty side effect you've already addressed. I very much prefer the structured (non-flat) approach. The device node could be restructured to look like <device> <rs232 speed="9600" restore-on-exit="true" os-device-name="com7" ../> <parport io="0x30e"/> <usb vendor="0xdead" id="0xbeef" serial="1234"/> <net ip="1.2.3.4" tcp="4303" reconnect="true"/> </device> etc pp. Turning the (e.g.) <ddl> node definitions into <bus type="ddl"> is something that would make things more difficult to handle (IMHO). Matthias |
