This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Finer control of Code Composer GUI's Backplane

So going off of: This wiki page, I was wondering if there is anyway to get more information and finer control out of the CCS information backplane. 

For starters, I'd like to be able to manually inititialize the underlying WS server without having to open up the GUI Composer app, and have the option of using html authoring tools outside of the Maquetta pane, as well as having the option of using a browser outside of CCS. 

I'd also like, if possible, more information on the timing and bandwidth capabilities of these things. It seems like there is an internal store of widgets to symbol to memory location, and I'm curious about how that functionally works over the JTAG connection. Is the JTAG able to grab memory without having to stop or insert instructions into the target CPU? What are the throughput considerations we should consider when looking at how much data to display, and could it effect the timing of the application, either interrupts or normal functions? 

I've looked into DSS for this, but it seems like the wrong tool for displaying the data. I think in theory I could write a java app on the DSS api and expose my own WS api, but that seems like a lot of duplicated effort. 

Thanks

  • david berger said:
    Is the JTAG able to grab memory without having to stop or insert instructions into the target CPU? What are the throughput considerations we should consider when looking at how much data to display, and could it effect the timing of the application, either interrupts or normal functions?

    From running a GUI Composer example with a JTAG connection it depends on the target device.

    If the target device supports "Real-time Debug" GUI Composer can access memory while the target CPU continues to run - see CCSv5-RealtimeDebug.pptx for details.

    If the target device doesn't support "Real-time Debug" you can enable "Halt the target before any debugger access (will impact servicing of interrupts)" under CCS Project Properties -> Debug -> Auto Run and Launch Options -> Realtime Options. However, that will cause the target CPU to stop when GUI Composer accesses memory over JTAG.

  • David,
    Separating WS from rest of the infrastructure is not feasible/possible at this point. We are using Jetty server which is integrated with Eclipse. We use Eclipse for basis of Code Composer Studio and GUI Composer. CCS and GUI Composer share very large portions of the software stack.

    In most cases if CCS can perform actions that you need with appropriate responsiveness/bandwidth then GC will be able to as well. As Chester mentioned performance/bandwidth limitations largely depend on device/emulator being used. Beyond JTAG there is an option of using serial communication. However, this requires target application to have a simple monitor that handles memory read/write requests. There are probably a lot more variables to consider in this case such as whether target application/system has room to allow a monitor to run. Higher data throughput would probably require more "room" in the system to handle this added load.

    I am speculating, but what you may be trying to do is to have a webserver running and allow remote browsers to connect to that webserver. This is possible with GC, however, it is disabled by default as it might be viewed as a security risk. We do not have any authentication support. Most modern browsers should work, we found chrome/firefox to work best. Older versions of IE do not have websocket support, thus they do not work.

    Regarding custom authoring tools. It is definitely possible. However, html/javascript knowledge would be necessary and you would need to develop javascript that binds widgets/objects that display data with json data that is coming from GC WS.

    Martin