Open Asbelos opened 3 years ago
If this were built in by a user, then the WiThrottle and <T id 1|0> commands would continue to operate but the define/delete versions would be denied.
Sensors also behave slightly differently as well... If JMRI is using sensors then they still have to be continuously polled, whereas TPL does not need this overhead.
So... We have I suggest, 3 different types of CS build
If We do implement this... can we avoid the hassle of rewriting the old eeprom code and just leave it as-is?
@Asbelos I haven't really done any work on the Command Station side of things before, but the way I see it, JMRI poses a major problem for adding new features as it requires DCC++ to work a specific way. I could be wrong, but I am wondering if it would be better off in the long run if someone could add a new 'driver' in JMRI, specific to Command Station EX, allowing more freedom development wise.
On the TPL side of things, am I right in saying that the scripts are compiled in with the command station then uploaded to the Arduino? Even if this is so, it could be all right to define the turnouts in the script, as most people would only add turnouts to their layout very occasionally. Also, as TPL is very much abstracted from C++, do you think it would be possible to have an interpreter that runs on a PC and sends commands over serial for testing purposes? Once the script had been finalized, it could then be compiled.
As I said, I don't know a huge amount about Command Station or TPL so these suggestions may be no good, but I thought I would say them just incase they were helpful in any way.
I tend to agree with your points about JMRI although I am not familiar with the code this would involve.The idea of debugging Tpl on a pc is viable but would involve a fair bit of code. On 18 Nov 2020 19:40, Matt notifications@github.com wrote: @Asbelos I haven't really done any work on the Command Station side of things before, but the way I see it, JMRI poses a major problem for adding new features as it requires DCC++ to work a specific way. I could be wrong, but I am wondering if it would be better off in the long run if someone could add a new 'driver' in JMRI, specific to Command Station EX, allowing more freedom development wise. On the TPL side of things, am I right in saying that the scripts are compiled in with the command station then uploaded to the Arduino? Even if this is so, it could be all right to define the turnouts in the script, as most people would only add turnouts to their layout very occasionally. Also, as TPL is very much abstracted from C++, do you think it would be possible to have an interpreter that runs on a PC and sends commands over serial for testing purposes? Once the script had been finalized, it could then be compiled. As I said, I don't know a huge amount about Command Station or TPL so these suggestions may be no good, but I thought I would say them just incase they were helpful in any way.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
@Asbelos I am happy to have a go at writing the PC application once a full command list is made. I was intending to do this anyway at some point as I wanted to support TPL execution over Wifi on TrainLink. I also don't know much about JMRI, but if I have some free time I will have a little look to see if anything can be done.
I suggest taking a look at this doc that has the list... but beware things can change a bit as we progress the development. https://github.com/DCC-EX/CommandStation-EX/blob/TPL/docs/TPL%20Introduction.pdf On 18 Nov 2020 20:25, Matt notifications@github.com wrote: @Asbelos I am happy to have a go at writing the PC application once a full command list is made. I was intending to do this anyway at some point as I wanted to support TPL execution over Wifi on TrainLink. I also don't know much about JMRI, but if I have some free time I will have a little look to see if anything can be done.
@Asbelos thanks for that!
TPL requires access to the layout control hardware (turnouts sensors, outputs, signals) and is not compatible with the JMRI way of defining this externally and downloading it at run time... Quite apart from the fact that this severely limits the layout complexity and quickly overflows the EEPROM.
Current TPL code expects a LAYOUT ENDLAYOUT block containing definitions of hardware devices. This information is stored in progmem and only the current status is mapped into bits in a fixed byte array which can be readily stored in eeprom.
It seems to me that it would be entirely reasonable to allow this layout definition in a non-TPL build - as an alternative to the JMRI methods which are fundamentally incompatible with TPL.