Skip to main content
stst9184
stst9184
Associate III
January 8, 2013
Question

STMStudio maximum sample rate

  • January 8, 2013
  • 1 reply
  • 705 views
Posted on January 08, 2013 at 14:42

I have tried a STM Studio, yersteady downloaded. For sample rates less than 100ms are not shown all steps. Is it possible to show steps smaller than 100ms, how and how small they can be? I use an example delivered in a subdierctory 'softTrace' for Keil. I've just add a flag variable. The flag is set in an interrupt, in a main loop it just wait on it an clear it for a next step. After this modification I assume to see all steps. Modifications: 

/* in stm32f10x_it.c */
extern volatile uint16_t flag = 0; 
void TIM1_CC_IRQHandler(void)
{
// Clear the interrupt
TIM1->SR &= ~TIM_FLAG_CC1;
// Do a snapshot into data trace buffer
DumpTrace();
flag = 1;
}
/* in main.c */
....
extern volatile uint16_t flag; 
int main()
{
...
while(flag==0);
flag = 0;
}
...
}

    This topic has been closed for replies.

    1 reply

    S C
    S C
    ST Employee
    January 9, 2013
    Posted on January 09, 2013 at 17:52

    - select ''display all data'' in ''acquisition settings'' window

    - check the CPU frequency and timer period of the ''softTrace'' example. You may also move the call of Dumptrace into the main loop for investigating

    - ensure the variables you are displaying are really acquired in snapshot mode: in STMStudio

      version 3.1.1, a ''S'' icon in the first column of variables settings; clicking on the icon

      toggles the acquisition mode (direct or snapshot).

    In snapshot mode the sampling rate is defined at the application level (in ''softTrace'' example,

    it's the timer period defined in main). The theoretical maximum sampling rate would be reached by an application calling ''DumpTrace'' in the main loop, and doing nothing else. It depends on many contextual parameters (CPU freq, number of acquired variables ...). In STMStudio v3.1.1 the realtime timestamping (conversion from record ID to time date) depends on 2 parameters defined in dataAcq.c: SNP_TRC_TIMESTAMP_BASE_UNIT and SNP_TRC_TIMESTAMP_VALUE. A bad definition of these parameters can explain a time distorsion (labels on X-axis not fitting with the real time).

    If all is correct and with a usual CPU freq it is possible to be much better than 100ms.

     

    Then, by default the graphical interface under-samples these data for display; it is possible to

    enforce all acquired data to be displayed by selecting ''display all data'' in the ''acquisition

    settings'' window. In that case, all records stored in the target buffer will be displayed, but

    most probably the acquisition will spend more time in the ''overflow'' state [waiting for the host

    having consummed all records before continuing the acquisition]. Because displaying records takes more time than only storing them into the log file.

    Terms & ConditionsAccessibility statement