We have been wondering for a long time about porting the “data” view on Developer Studio, and we couldn’t imagine any real use case (except for some instant debugging…)
Indeed, most of times, the data flow will need to be directed to either an application, or another device aiming to be driven by the Open AT application.
If you put DS as a client of this data flow, you won’t be able to see the exchanges made with this other application/device…
One more argument is that data flows can indeed be multiplexed with traces and AT commands on the same port when you use the ADL FCM service, but it is not compatible with the “Open Device” API, which is more powerful to get full and hard real-time access to the UART.
So what we think is that the good configuration should be:
- dedicate a target port to debugging (ideally the pure USB port; strongly recommended for data rate & reliability when compared to serial/USB converters)
- and dedicate other target port(s) to data exchanges with the other applications/devices
Doing the same, you’ll be able to address most of the use cases.
With DS 2.2.1, you can’t setup a connection with a device on a port with doesn’t handle AT commands, so you’ll need an external terminal program.
But with incoming new DS release, we’ve added a mode where you can simply open a “raw” connection, and exchange data in the TM console (so you won’t need a external program anymore to do basic string exchanges…)
It will remain the same TM console, so maybe not perfectly adapted to all “raw data” use cases (e.g. it only display characters in ASCII, and it handles only “command style” data emission, i.e. you need to validate any string output with the enter key before it is completely sent), but we expect it to be a good starting point, to let the community identify which feature is missing to address data use cases…