| Re: [tcf-dev] TCF pending commands |
|
Hi Eugene, thank you for your quick reply. We also thought about implement FW-flashing as a separate service. In this case it makes no sense to create a new definition.
Instead we can use the “File System”-Service and start the flash process whenever a firmware image file (of a specific name) gets written to the remote system root folder.
I guess this service will support “P” messages and the client side RSE will be able to display a progress bar, since writing files typically will consume time on the
target? But even if we are able to flash the application through the RSE prior to launching the build, we don’t want to separate this steps. During development this
steps will have to be repeated many, many times. It would be much more user friendly to combine them in one action. I think this is the typical use case for any environment,
not only ours. I noticed there is some remote path inside the TCF launch configuration. I believe to remember, some time ago there was also a checkbox option to omit downloading the application file to the targets remote path prior to starting the debug session? (“Skip download to target path” inside the “TCF Remote Application” launch
configuration) Such a feature (downloading, not skipping :) would perfectly fit to our needs. Whenever a TCF debug session will be launched, first the file will be copied
to the remote system path through the “File System” service and finally the “Process.start” command will be executed. Was there a reason to drop this feature or does it still
exist in the new TCF? I am just wondering because the “skip” option disappeared. Best regards, Michael From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Eugene Tarassov Hi Michael, ‘P’ messages are supported by the framework, but not used by standard services – there was no need for that. Normally, others implement flash programming as
a separate custom service. When you design a custom service, you can use ‘P’ messages to report progress. Using “Process.start” might be not a very good idea, because the command is not designed to be long running operation, and changing existing commands
is difficult - we are committed to maintain backward compatibility of the protocol. With a custom service, you would have full control over commands behavior, and you could easily add Eclipse UI to give user feedback. > It seems the documentation is somehow incomplete or outdated. Please, file Bugzillas when you see gaps or outdated info in the documentation. Bugzilla is the best way to communicate issues found in both docs and code.
Reporting an issue is a form of contribution, and we greatly appreciate contributions to the project
J Regards, Eugene From:
tcf-dev-bounces@xxxxxxxxxxx
[mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael Rentschler Hi list, I’ve some question regarding the TCF command results: In the documentation section I’ve found the TCF specification file that defines result packets starting with the letter ‘P’ to postpone the command completion
(or to return a pending result). There is no additional information specifying the mentioned “progress data”. Is this feature implemented for the TCF Eclipse client side? Is there a place where
I can get more information about this feature? As far as I know, the C agent example does not make use of such a command response. The problem I must solve: whenever an application gets loaded through the “Processes::start” command then my agent starts flashing the binary to the target
device. Since flashing is very slow on my target, this may take minutes. In the meantime the Eclipse IDE should be able to give user feedback (update the progress bar). BTW: It seems the documentation is somehow incomplete or outdated. Are there plans to update the documentation, at least those parts that are not supposed to
change anymore? I am sure there are enough other things to do, but a good documentation may be indispensable for a new evolving protocol like TCF. Best regards, Michael
|