Requesting Supplemental TargetInfo.h info...

11 posts / 0 new
Last post
Steve Stearns
Offline
Last seen: 3 weeks 4 days ago
Joined: 05/09/2017 - 10:14am
Requesting Supplemental TargetInfo.h info...

Greetings,

I'm bringing AWE up on a new  32FL4 target (using STEM32L496_Discovery IAR project as a model) and I'd like to understand the usage and constraints on the following symbol definitions (from the TargetInfo.h) (as defined, they *might* be appropriate for my target, or might *not* how am I to know?):

#define VER_DAY 10
#define VER_MONTH 5
#define VER_YEAR 17

#define CORE_ID 0
#define CORE_SPEED 80e6f
#define SAMPLE_SPEED 80e6f
 

One comment in the code mentions that the VER info "must match" but it's not clear to *what* it must match.  Another comment in the code says CORE_ID is 100, but it's not.  And nowhere can I find to what CORE_SPEED and SAMPLE_SPEED are supposed to correspond.

All clarifications are appreciated.

Thanks!

Steve.

Chris Perry
Offline
Last seen: 1 month 3 weeks ago
Joined: 07/16/2017 - 9:45am

The comment in the code that CORE_ID is 100 is spurious and should be ignored or removed.
CORE_SPEED is the processor tick rate in Hz
SAMPLE_SPEED is the profiling clock in Hz and is typically the same as the CORE_SPEED but doesn't have to be.

Also, ignore the comment that version must match. That comment is also spurious.

Steve Stearns
Offline
Last seen: 3 weeks 4 days ago
Joined: 05/09/2017 - 10:14am

Thanks Chris,

So...  What date is the VER supposed to represent?  My code?  Or some whatever I want server to display?  Random is ok?  What's the intended purpose?

Steve.

Chris Perry
Offline
Last seen: 1 month 3 weeks ago
Joined: 07/16/2017 - 9:45am

The Version information is basically a unique identifier using the date whose primary purpose is to identify a revision of the firmware  and display in the AWE_Server info pane.

Steve Stearns
Offline
Last seen: 3 weeks 4 days ago
Joined: 05/09/2017 - 10:14am

Thanks for being responsive to my presumably ignorant questions.  I still don't understand *which* tick frequency the  CORE_SPEED/SAMPLE_SPEED values are supposed to correspond.  The value of 527983 Hz (80e6f) in the STM32L496 discovery doesn't seem to match anything I've found so far.  The call to the platform and framwork tick functions are in a superloop (running who knows how fast...) and the value returned by awe_pltGetCycleCount() appears to be in milliseconds.  The same function in our STM32F429 port runs much faster and the value reported by AWE server, in the F429 case, for the Profile Clock Rate is 168 MHz.  Can you add some clarity to my confusion and give me direction on how to make this all correspond as intended by DSP Concepts?

Steve.

Chris Perry
Offline
Last seen: 1 month 3 weeks ago
Joined: 07/16/2017 - 9:45am

Looking at the data sheet for the STM32L496 the maximum frequency for the processor is 80 MHz (80,000,000 Hz). For the STM32F429 I believe the maximum frequency ia 168 MHz. As you have noticed the comments in the code need scrubbing. awe_pltGetCycleCount returns the processor tick count (not milliseconds, so ignore the comment).

 

Steve Stearns
Offline
Last seen: 3 weeks 4 days ago
Joined: 05/09/2017 - 10:14am

Ok.  In my port I'll make awe_pltGetCycleCount correspond to timer ticks at the processor running frequency and set CORE_SPEED/SAMPLE_SPEED to match in Hertz.

btw:  Unless I've totally missing the mark, this is not what is being done in the STM32L496_Discovery code.  The comments are correct in that the code for awe_pltGetCycleCount is returning counts in milliseconds (it uses HAL_GetTick as the timer source).  And this does not match the value being set for CORE_SPEED/SAMPLE_SPEED.  However, I didn't check if 527983 Hz being set does match that actual processor speed as configured by that code.

Thanks again for your help.

Steve.

Chris Perry
Offline
Last seen: 1 month 3 weeks ago
Joined: 07/16/2017 - 9:45am

nReloadValue is the number of ticks in 1 millisecond. HAL_GetTick() returns elapsed milliseconds. This millisecond value is converted into ticks and then additional ticks (nReloadValue - nCycles) are added in to have a value in ticks (not milliseconds as the variable in the code implies).

Steve Stearns
Offline
Last seen: 3 weeks 4 days ago
Joined: 05/09/2017 - 10:14am

Oh...  I totally missed that.

I appreciate the patience!

Thanks,

Steve.

Steve Stearns
Offline
Last seen: 3 weeks 4 days ago
Joined: 05/09/2017 - 10:14am

Regarding the NO_THREADS_SUPPORTED symbol defined in TargetInfo.h.  Am I correct in assuming that it should be defined to be the max number of layouts that will be pumped? I've inferred this from the STM32L496 _Discovery where it's defined to be 2. There are correspondingly awe_pump calls for two different priority layouts.  A related assumption is that our use of RTOS threads for lower priority awe objectives (tuning etc.) have nothing to do with the value to which NO_THREAD_SUPPORTED is set. 

Do I have this correct?

Steve.

Chris Perry
Offline
Last seen: 1 month 3 weeks ago
Joined: 07/16/2017 - 9:45am

Yes, your understanding is correct.