Once I’ve got my code building in the Open-AT perspective I switch to Target Management to Connect;
Then I have to switch back to Open-AT to run;
Then I have to switch back to Target Management again to see the result!
Once I’ve got my code building in the Open-AT perspective I switch to Target Management to Connect;
Then I have to switch back to Open-AT to run;
Then I have to switch back to Target Management again to see the result!
Hiya,
You should only have to connect once when you initially open M2M studio.
However, you will have to refresh the Taget Info Window if you want to change Trace setup after you have rebooted the target device.
ciao, Dave
Yes, that is true.
But it is still a very cumbersome way to do such an absolutely basic and essential thing!
This does seem to be a common flaw throughout M2MStudio (maybe Eclipse in general) - they really haven’t thought about the “workflow”
Hiya,
Yep, I agree.
I think it’s better than the old method of automatically connecting and hanging the PC if the COM port or target device wasn’t present…
ciao, Dave
In Eclipse, you can display any view in any perspective.
By using the Window > Show view > Other > Remote Shell menu in the Open AT perspective, you will be able to have the shell and your code in the same perspective…
But then it will get so cramped that you can hardly see anything worthwhile in any of the views!
Which brings me to the question of multiple monitors: viewtopic.php?f=78&t=3476
And another thing:
Once it’s connected, it pops up a dialogue to say “Connected” - which you have to manually dismiss by clicking OK!
That really is an unnecessary annoyance: it doesn’t do that at the end of a build - even with errors - so why here?
Surely, a message in the status bar would be sufficient?!
This point has been fixed in the next release: the “confirmation” dialog has been removed.
About the “complicated” workflow around Target Management, please be sure that we are aware about all these issues and behaviours; we plan a Target Management strong update in a future release.
Thanks
Another one:
If I press the ‘Run’ buton (in the Open-AT perspective) when the target is not connected, it just says, “Target Not Detected”.
In this case, the reason is obvious - it’s not connected - so it should offer to connect automatically.
It should also offer a ‘Help’ button with tips to diagnose the problem.
Also, the ‘Download’ button should be available in the Open-AT perspective; ie, without first having to switch to the Target Management perspective.
Will be fixed in next release: launching a Run session will automatically try to connect to the target (with the currently configured settings)… and by the way it won’t display anymore the “Target Connected” message
Please can you elaborate on why you need the download button, since when you launch a Run session, it actually downloads the application…?
Because I might want to just do a download without switching to the Target Management perspective.
Specifically, at the moment, this is because I need to use the external TMT.
BTW: any chance of getting the downloader fixed in TMT: viewtopic.php?f=78&t=3500&p=13621&hilit=tmt+xmodem#p13621
Or just the necessary source or specifications released…
Well, I guess the real need is to have a target management (workflow + features) robust and satisfactory enough not to make you going back to TMT
One again, please be sure that target management refactoring is in the top group of the priorities list. We prefer re-study the target management completely rather than providing “workarounds” like download buttons in the Open AT perspective, or improve the download in old TMT.
We will probably make polls on the forum to determine the use cases and provide the most appropriate solutions.
By the way, to fill your immediate need, you can download a .dwl file from the right-click menu in the project explorer. You will still have the constraint to connect the target from the target management perspective before, but it is maybe a satisfactory workaround for you.
Thanks.
Well, I guess the real need is to have a target management (workflow + features) robust and satisfactory enough not to make you going back to TMT
Yes, that is very necessary!
But I think there may well be times when an external tool is necessary or preferable.
eg, for a “soak” test of a batch of units, using a simple tool like TMT just to log traces could be preferable to having to do a complete SDK+M2MStudio installation on each test station…
One again, please be sure that target management refactoring is in the top group of the priorities list.
By the way, to fill your immediate need, you can download a .dwl file from the right-click menu in the project explorer.
I’ll give it a try…
By the way, to fill your immediate need, you can download a .dwl file from the right-click menu in the project explorer. You will still have the constraint to connect the target from the target management perspective before
Yes, this works - but it is still cumbersome to have to switch to ‘Target Management’ in ordet to connect, then switch back to ‘Open AT’ to do the actual download.
Still present in Studio 1.1.1 - wasn’t this going to be streamlined so that, if you tried to download before connecting, it would pop-up a prompt that would allow you to connect and carry straight on with the download…?
i guess it’s not what you mean, but when i start M2M studio, write some code and press the ‘run’ button, it automatically connects and uploads the application.
i guess it’s not what you mean, but when i start M2M studio, write some code and press the ‘run’ button, it automatically connects and uploads the application.
You’re right - it’s not what I meant! 8)
So it looks like they’ve fixed the process when using the ‘run’ button, but have omitted to apply the same fix to the right-click download…
So it looks like they’ve fixed the process when using the ‘run’ button, but have omitted to apply the same fix to the right-click download…
Indeed. We will take care of that in 1.2
Thanks.