| Re: [tcf-dev] TCF pending commands |
|
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
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. |