• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 53 subscribers
  • Views 1181 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

GUI composer refresh and target halt time

Tiago Monte
Prodigy 90 points
Other Parts Discussed in Thread: MSP-FET

Hi,

I'm making a very simple dashboard with GUI Composer. My hardware is an MSP430 device together with the latest model MSP-FET debugger (in JTAG) mode. On the software side I have latest CCS and GUI Composer versions. As the MSP430 doesn't support non-intrusive access I enabled the option "Halt the target before any debugger access".

1- I was able to change my GUI refresh time by binding a text box to the refresh time variable and I can indeed see that my widgets refresh rate is updated accordingly. Is there any relation between the GUI refresh time and the debugger "Continuous refresh interval"? The minimum debugger refresh interval is forced to 100 ms, can it be shorter for the GUI? Do they have to be aligned, meaning that if I set the debugger fresh to 500ms and GUI to 100ms only every 5th access is actually performed?

2- What is the target halt-time for 5 bytes readout from RAM? I don't need to read much data and also not that fast but I need to understand the possible impact of the halting time on my application.

Thanks

  • 0
    TI__Genius 15660 points

    Hello, 

    1. The two time outs are separate and independent. However, you are quite unlikely to be able to go below 100ms, regardless of whether you use debugger's continuous refresh or GUI Composer. GC and debugger use the same emulator/driver and SW sitting on top is quite similar. Also, those refresh intervals are not guaranteed to happen every 100ms for all items. As and example, if 5 bytes take 125 ms  (i.e. each byte read is 25ms), then last byte might never get updated as outstanding requests will get dropped.  

    It is quite difficult to come up with exact time. It depends on your MCU, emulator (in your case they are relatively fixed, but others that may be reading this read could use a different combination). It also depends on performance of your PC to a certain extent and how many other things your PC is doing. Probably the best suggestion that I can make is to enable GUI Composer logging and see what the timing is with your exact setup. Log will show target accesses and each row includes host (i.e. your PC) timestamp in ms. Thus there will be a bit of lag between what your CPU is doing and what shows in host log but it is probably relatively small. The log contains quite a bit of data, but it should be possible to figure out after some inspection as when a refresh cycle starts/ends. 

    http://processors.wiki.ti.com/index.php/GUI_Composer/Tracing

    If intrusiveness is a concern, then you may want to consider using UART to send/receive data. It does require you to include a small monitor that handles read/write requests, but it might be easier to ensure that your application is not impacted by target accesses. Also, if your GC app is predominantly receiving data, then there is an option of using streaming mode, where data is pushed by the target when it is ready rather than host asking for data and then receiving it. 

    This wiki topic contains information on program uart (i.e. host asks for data and then gets it back). There is an MSP430 examples

    http://processors.wiki.ti.com/index.php/ProgramModelUart_GuiComposer

    GUI Composer app for program uart is very, very similar to what you are doing. Main difference is the driver that is used. 

    Streaming mode would probably give you best performance as it is purely limited by how frequently your device can push data out and UART speed. However, it is more difficult to create a GC app as GUI Composer provides a "pipe" and then you have develop javascript functions to parse your stream of data and update individual widgets. A sample app is described in this topic

    http://processors.wiki.ti.com/index.php/Streaming_GuiComposer

    Martin