This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NEW on Cortex-M3 STM32F103B IAR

Note: This was originally posted on 29th January 2010 at http://forums.arm.com

Hi everyone,

I recently got an Arm cortex m3 microcontroller (stm32f103B). I'm interested in programming in C. I received some software with the kit I bought (IAR workbench kickstart) but i find all of these a little confusing to use. Reading the book "the definitive guide to arm cortex m3",
i found that's describing assembly instructions,

I ask, if there is an other guide wich describes C instructions?

Parents

slim bahri over 12 years ago

Note: This was originally posted on 11th March 2010 at http://forums.arm.com

Hi Slim,

Thanks for the update.

The measurement you have done is interesting.

There are a few things you might need to look at:
- Are the two tests carried out in the same setup?
(same clock frequency, same peripheral clock frequency,
same wait state configuration, same OS tick frequency).
- I guess you measured the duration of the pulse in the GPIO.
Since both rising and falling edge of the pulse can be affected by jitter, the result might not be accurate.
Ideally you should use a constant timing source which is synchronous to the processor clock
and divided to the same test loop frequency to drive the trigger input of the oscilloscope.
I know that might not be possible with the current setup, but it might worth mention in your paper.
Using on chip timer measurment is one good way to solve this problem.
- Other jitter source - e.g. Potential jitter from on chip PLL

Regarding measurement of context switching time:
Develop two tasks, one toggle a GPIO pin and the other task toggle another pin.
You can then see the gap between the activities of the two tasks with an oscilloscope.
Of course, there could be some timing inaccuracy because it depends on the length of the toggling loop, the access time of the GPIO registers, and which instruction it stop at most often during context switching.

Unfortunately I don't have any STM32 board so can't develop test code for it.
You can try post your question on this to STM32 forum
[url="https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/AllItems.aspx"]my.st.com/.../url]
Maybe someone will be able help you there.

regards,
Joseph

1- For each OS we have to do:
two tests (on-chip timer and GPIO probes on osciloscope)
the two tests are carried out in the same setup

(the clock frequency of stm32F103B is 72Mhz, so we work with 2 waitstates,
the same os tick frequency).

2- I have measured the pulse in GPIO (170,7 ns at max) with 100Mhz MTX3352 oscilloscope
so we will substract the GPIO pulse time in pair (set/reset)
from the latency duration (170,2 * 2), isn't it?

3- I don't undestand the following item:

"Ideally you should use a constant timing source which is synchronous to the processor clock
and divided to the same test loop frequency to drive the trigger input of the oscilloscope.
I know that might not be possible with the current setup, but it might worth mention in your paper."

---> you can explain with pseudo code or diagram for example.

4- I'm developping some charts to do a benchmark tool for both freertos and µcos2 seperatly (view attached file) /* comment*/

Slim
Cancel
Vote up 0 Vote down

Cancel

Reply

slim bahri over 12 years ago

Note: This was originally posted on 11th March 2010 at http://forums.arm.com

Hi Slim,

Thanks for the update.

The measurement you have done is interesting.

There are a few things you might need to look at:
- Are the two tests carried out in the same setup?
(same clock frequency, same peripheral clock frequency,
same wait state configuration, same OS tick frequency).
- I guess you measured the duration of the pulse in the GPIO.
Since both rising and falling edge of the pulse can be affected by jitter, the result might not be accurate.
Ideally you should use a constant timing source which is synchronous to the processor clock
and divided to the same test loop frequency to drive the trigger input of the oscilloscope.
I know that might not be possible with the current setup, but it might worth mention in your paper.
Using on chip timer measurment is one good way to solve this problem.
- Other jitter source - e.g. Potential jitter from on chip PLL

Regarding measurement of context switching time:
Develop two tasks, one toggle a GPIO pin and the other task toggle another pin.
You can then see the gap between the activities of the two tasks with an oscilloscope.
Of course, there could be some timing inaccuracy because it depends on the length of the toggling loop, the access time of the GPIO registers, and which instruction it stop at most often during context switching.

Unfortunately I don't have any STM32 board so can't develop test code for it.
You can try post your question on this to STM32 forum
[url="https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/AllItems.aspx"]my.st.com/.../url]
Maybe someone will be able help you there.

regards,
Joseph

1- For each OS we have to do:
two tests (on-chip timer and GPIO probes on osciloscope)
the two tests are carried out in the same setup

(the clock frequency of stm32F103B is 72Mhz, so we work with 2 waitstates,
the same os tick frequency).

2- I have measured the pulse in GPIO (170,7 ns at max) with 100Mhz MTX3352 oscilloscope
so we will substract the GPIO pulse time in pair (set/reset)
from the latency duration (170,2 * 2), isn't it?

3- I don't undestand the following item:

"Ideally you should use a constant timing source which is synchronous to the processor clock
and divided to the same test loop frequency to drive the trigger input of the oscilloscope.
I know that might not be possible with the current setup, but it might worth mention in your paper."

---> you can explain with pseudo code or diagram for example.

4- I'm developping some charts to do a benchmark tool for both freertos and µcos2 seperatly (view attached file) /* comment*/

Slim
Cancel
Vote up 0 Vote down

Cancel

Children

No data