Specification / Feature List for New Target Management?

[awneil]

@daav

Will be hopefully fixed with new Target Management.
Switch Workspace usually fails - #3 by awneil

Do you have a specification or feature list for the new Target Management?

Would seem like a good idea to review that before you go ahead and implement it, only to have people say “we don’t like that…” or “what happened to ?”

[daav]

Here is a sneak peek of the new Target Management feature list.

Functional scope includes at least the current Target Management’s one, i.e.:

• Serial port configuration + open/close
• AT commands console
• Target information tree
• Traces view
• Download capability

Following new features will be integrated:

• Backtraces decoding, with direct link to the source code editor for known functions in the backtraces
• Simultaneous connections to several ports
• New concepts for the target connection’s states:
  –> “Nominal” mode is now named “production mode”: this is the default UART state
  –> “Debug” mode is now named “development mode”: this mode allows Developer Studio to gets traces, backtraces, etc… from the module.
• When Developer Studio starts working with a target in development mode, it will set it as a “sticky” state (i.e. still enabled over a module reset)
• [TBC] Heap memory status: heap memory snapshot, with blocks addresses, size, and name of the function which has allocated it.
• [TBC] Tasks status: application tasks states snapshot, with state (as defined in the ADL execution context API) and call stack consumption (current/max)

(TBC stands for To Be Confirmed: integration will depend on the project advancement)

Improvements coming from the withdrawal of Selima

• Serial port opened only on demand, and not more immediately at Developer Studio opening
• Target Management support under Linux (except for RTE)
• No more brutal crashes, or missed “restart”/“switch workspace” operations
• Faster connection setup
• Better AT commands performances in production mode

Modified graphical interface (see picture below)

• New “Devices” view allowing to control the serial ports connections
• New views for new services (Backtraces decoding, Heap memory status, Tasks Status)
• All service views by default “pinned” to the selected “master” connection in the Device view
• But capability to instantiate several times a service view in order to bind it to another port

Any comment welcome!

[awneil]

@daav

[*] Backtraces decoding, with direct link to the source code editor for known functions in the backtraces

Excellent.
This needs to include the facility to import backtraces captured from devices “in the field”.

[*] Simultaneous connections to several ports

Does that mean simultansously “managing” several target devices; eg, several Fastracks?

[*] When Developer Studio starts working with a target in development mode, it will set it as a “sticky” state (i.e. still enabled over a module reset)

ie, DevStudio will automatically detect when the target restarts, and re-establish the “development mode” comms?
So, in TMT terms, we don’t have to re-do “Init Target” each time the target restarts?

withdrawal of Selima

Presumably this will mean that TMT will no longer be usable?

Will there be some equivalent “light-weight” interface for, say, field debugging - without the need for a full Dev Studio, project, etc?

Modified graphical interface (see picture below)

One big advantage of TMT is that it can be run on a separate screen - so I have DevStudio on one screen, and TMT+TE on another.
Will it still be possible to have the “source” view on one screen, and the “debug” view on another?

[awneil]

The timestamp format in the screenshot uses up a huge amount of screen real-estate!

There needs to be options to control that!

[daav]

This needs to include the facility to import backtraces captured from devices “in the field”.

Obviously, target is to reach same backtrace decoding capability than TMT.

Does that mean simultansously “managing” several target devices; eg, several Fastracks?

Yes, and getting traces from them (TMT wasn’t able to do that).

ie, DevStudio will automatically detect when the target restarts, and re-establish the “development mode” comms?

Actually, there is no reset detection: the development mode persistence is saved on the device (i.e. the device stays in development mode even if not connected to DevStudio; it will have to be explicitely set to production mode to resume “normal behaviour”).
This may be an important change in your developer habits, but in our opinion it’s the best way to guarantee it always works:

• No way to implement a 100% reliable reset detection mechanism
• If the target starts in development mode, you’re absolutelly sure that all traces are sent from the beginning, without any doubt around “Have I enabled the traces quickly enough to get them all?”

So, in TMT terms, we don’t have to re-do “Init Target” each time the target restarts?

Exactly, this is the point of the feature. Among other things, it enables to collect traces in long-terms scenarios including target resets.

Presumably this will mean that TMT will no longer be usable?

Not at the same time and on the same port than DevStudio (like you can do it with current DevStudio versions). But if you close (or don’t open) DevStudio connection, you still can use TMT on the target, or even use DevStudio on one port, and TMT on one other.

Will there be some equivalent “light-weight” interface for, say, field debugging - without the need for a full Dev Studio, project, etc?

We are indeed studying this possibility, since it doesn’t make sense to use the full-over-600MB-with-all-toolchains-IDE just to collect traces. The software architecture is ready for that, and we’ll probably submit you the first beta in this format.

Will it still be possible to have the “source” view on one screen, and the “debug” view on another?

IIRC, I told you about using the Eclipse Window > New Window menu. Unfortunately, this feature is not working with current Target Management implementation, but we’ll take care of making it full functional with the new one.

The timestamp format in the screenshot uses up a huge amount of screen real-estate! There needs to be options to control that!

We’ll provide an option to hide/show the timestamp column.
Any suggestion about the timestamp format?

[awneil]

@I

This needs to include the facility to import backtraces captured from devices “in the field”

@daav

Obviously, target is to reach same backtrace decoding capability than TMT.

Don’t set you goals too low - there are definitely things in TMT/TE which could be improved!

@I

Does that mean simultansously “managing” several target devices; eg, several Fastracks?

@daav

Yes, and getting traces from them (TMT wasn’t able to do that).

Excellent!

@daav

if you close (or don’t open) DevStudio connection, you still can use TMT on the target

Good.

@I

Will there be some equivalent “light-weight” interface for, say, field debugging - without the need for a full Dev Studio, project, etc?

@daav

We are indeed studying this possibility, since it doesn’t make sense to use the full-over-600MB-with-all-toolchains-IDE just to collect traces. The software architecture is ready for that, and we’ll probably submit you the first beta in this format.

Great.
Even better if the interface could be made “Open” so that we could build custom Trace capture/logging devices or applications…

@I

Will it still be possible to have the “source” view on one screen, and the “debug” view on another?

@daav

IIRC, I told you about using the Eclipse Window > New Window menu.

Oh yes - I think you did!

@daav

Unfortunately, this feature is not working with current Target Management implementation

I guess that’s why I never used it - and, hence, forgot about it!

@daav

We’ll provide an option to hide/show the timestamp column.

It needs not just a hide/show option, but also a format option.

@daav

Any suggestion about the timestamp format?

Options to provide:

1. Same as current TMT (ie, just run-time seconds & decimals);
2. “Unix Time” seconds & (optional) decimals;
3. hh:mm:ss[.sss]
4. [yy]yy-MM-dd hh:mm:ss[.sss]

Maybe provide a “format builder” like Excel, et al…

[awneil]

@daav

[*] AT commands console

I think one of the problems with the current “console” is that it’s an extra layer of unknowns in trying to communicate with the device (I think the same applies to the “Expresso” tool?).

There are enough “unknowns” alread - especially for beginners - in just getting a serial connection to a modem; eg,

• Correct port
• Correct cable
• Correct setup
• etc…

What is needed is something really minimal just to show that the device is properly connected - without any extra processing, distractions, fancy processing, etc, etc,…

One thing that I find invaluable for this is to have mimic “lights” to show the activity on the actual port lines; eg,

See: antronics.co.uk/downloads/comled.htm

[awneil]

@daav

Actually, there is no reset detection: the development mode persistence is saved on the device

Presumably, that will require a device firmware update?

(i.e. the device stays in development mode even if not connected to DevStudio; it will have to be explicitely set to production mode to resume “normal behaviour”).
This may be an important change in your developer habits

Indeed - it would need to be very clearly documented!

There would need to be a way (AT Command) to escape - in case a device is “accidentally” left in “development mode” after it’s removed from DevStudio…
This probably also needs to be accessible remotely/programmatically?

but in our opinion it’s the best way to guarantee it always works:

• No way to implement a 100% reliable reset detection mechanism
• If the target starts in development mode, you’re absolutelly sure that all traces are sent from the beginning, without any doubt around “Have I enabled the traces quickly enough to get them all?”

Yes, that sounds good; particularly when debugging via USB - where TMT always misses the initial traces due to the time required for the USB to start.

@I

So, in TMT terms, we don’t have to re-do “Init Target” each time the target restarts?

@daav

Exactly, this is the point of the feature. Among other things, it enables to collect traces in long-terms scenarios including target resets.

Yes - that was a real limitation of TMT!

[daav]

@awneil

(about backtrace decoding) Don’t set you goals too low - there are definitely things in TMT/TE which could be improved!

OK, I reformulate: Obviously, target is to reach at least same backtrace decoding capability than TMT.

@awneil

(about light-weight application) Even better if the interface could be made “Open” so that we could build custom Trace capture/logging devices or applications…

As the current one, new Target Management implementation will be open-source. Now (and you would say that it’s not a surprise), it’s not properly documented. However it would be a basis to start looking on how to customize or implement a new UI on top of Target Management API.

@awneil

(about traces timestamp formating) Options to provide:

• Same as current TMT (ie, just run-time seconds & decimals);
• “Unix Time” seconds & (optional) decimals;
• hh:mm:ss[.sss]
• [yy]yy-MM-dd hh:mm:ss[.sss]

This is loged; thanks for the suggestions

@awneil

(about the AT console) I think one of the problems with the current “console” is that it’s an extra layer of unknowns in trying to communicate with the device (I think the same applies to the “Expresso” tool?).

You’re right, but we need to have a high level access to AT commands in order to implement some other Target Management features. And you’re also right we need a simpler way to easily diagnose what is going wrong when trying to connect to the device.
Actually, we plan to make behave the DevStudio differently according to the device mode:

• Development mode: we will have an AT console similar to the existing one
• Production mode: a reduced set of functionalities (i.e. AT commands and download), and the AT command console will be as simple as possible in this case, directly plugged on RX and TX serial signals, without any additional layer.

Thanks also for the suggestion about the signals activation “leds”, this can be indeed usefull.

@awneil

(about “development mode persistence”) Presumably, that will require a device firmware update?
There would need to be a way (AT Command) to escape - in case a device is “accidentally” left in “development mode” after it’s removed from DevStudio…

Yes, we are indeed going to add a new AT command in the firmware, allowing to control that.
This means that:

• This development mode persistence feature will be available only if you’ve upgraded your firmware to the right version (currently targetted: Software Suite 2.34)
• It will be possible to disable “manually” the persisting development mode

[awneil]

@daav

As the current one, new Target Management implementation will be open-source.

I didn’t realise that the current one was open source!

Where should I look for the source?

[daav]

@awneil

Where should I look for the source?

Actually it is open source from Eclipse plug-ins development environment.
You have to first download a raw Eclipse SDK (http://www.eclipse.org/downloads/, and download “Eclipse Classic” package)
Then, follow the install instruction from the release note (http://www.wavecom.com/releasenotes/m2mstudio/1.1.2) and choose the feature proposing the Developer studio source code + runtime.
Once installed, you will be able to import in your workspace any of the DevStudio Eclipse plug-ins:

• Open the Plug-ins view
• Select the desired plug-in
• Choose right-click > Import as > Source project

And from there, you have to read Java

[awneil]

@daav

And from there, you have to read Java

I thought you might say that…

BTW: does that smiley work for you?
It doesn’t work here - see: Smilies broken!

[daav]

@awneil

BTW: does that smiley work for you?

No, it’s indeed broken since the forum migration at sierrawireless.com

[awneil]

Just remembered another bug in the current Trace view: handling of the “%p” format…

[daav]

@awneil

Just remembered another bug in the current Trace view: handling of the “%p” format…

Yes, this one is logged and planned for fix in this release.

[awneil]

Another one (an improvement required over TMT):

TMT names its trace log files in the form Tracen_ddMMMyyyy.txt; eg,

Trace0_28Jun2010.txt
Trace0_29Jun2010.txt
Trace1_17Jun2010.txt
Trace1_25Jun2010.txt

This is not good because, as you see, the names do not sort into a sensible order!

I think a far better name format would be something like: yyyy-mm-dd_Trace-nn.txt

Thus the above would become:

2010-06-17_Trace-01.txt
2010-06-25_Trace-01.txt
2010-06-28_Trace-00.txt
2010-06-29_Trace-00.txt

Note the use of 2-digit month to ensure that alphabetic & numeric sorting give the same result;

Similarly, always 2 digits for the trace number (maybe 3 - incase anyone takes >100 traces in a day?)

[daav]

Thanks for the very good suggestion; now added to the backlog

[awneil]

@daav

Yes, we are indeed going to add a new AT command in the firmware, allowing to control that.
This means that:

• This development mode persistence feature will be available only if you’ve upgraded your firmware to the right version (currently targetted: Software Suite 2.34)
• It will be possible to disable “manually” the persisting development mode

There needs to be a way for the Application to tell that “development mode” is on - so that it can report this if a device “accidentally” gets into the field with the mode left on…

[awneil]

TMT has a bug with ‘&’ (ampersand symbol) in Traces: it causes the next character to be underlined, and the ‘&’ is not displayed (ie, it’s doing what Windows does with menu definitions).

[daav]

@awneil

There needs to be a way for the Application to tell that “development mode” is on - so that it can report this if a device “accidentally” gets into the field with the mode left on…

Do you mean the embedded application?
Isn’t the AT command enough for this case?

@awneil

TMT has a bug with ‘&’ (ampersand symbol) in Traces: it causes the next character to be underlined, and the ‘&’ is not displayed (ie, it’s doing what Windows does with menu definitions).

Maybe I’m wrong, but I think this is already behaving correctly in the current Target Management traces view (‘&’ printed as ‘&’, not as ‘_’)