| Re: [tcf-dev] TCF pending commands |
|
Hi Eugene, we moved our target flashing routine from “Processes.start” to the File System Service. Writing to a virtual file will cause the chip to be flashed now. But,
as you described, there is still no progress bar when launching a new debug session. Is it possible to update the progress monitor on the Eclipse side? I think there are other
remote-systems like ours that also have a slow connection and slow flash memory. It’s really strange if there is no response during launch of an application on such systems. I still wish we could also make usage of the “P” status messages in the File System service. Maybe as a future feature? Best regards, Michael From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Eugene Tarassov Hi Michael, > 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. Yes, it should work. > 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? “File System” does not use “P” messages, because writing a file is done by multiple “write” commands, like 4KB per command. No need for “P” message – progress
bar can be updated on each reply of “write”. > 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? We now have two options for launching: a basic and generic “Target Communication Framework” launch configuration; and “Target Explorer” – a framework that allows
to develop highly customized and elaborated target management and launch configuration UI. As for “Target Communication Framework” launch, it downloads a file if both “Local File Path” and “Remote File Path” are non-empty. It skips downloading if
either of them is empty. Currently, it does not show downloading progress, but we can fix it if necessary. Regards, Eugene From:
tcf-dev-bounces@xxxxxxxxxxx
[mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael Rentschler 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
|