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
  • Note: This was originally posted on 11th March 2010 at http://forums.arm.com

    Hi Slim,

    By using the GPIO signal itself as trigger for oscilloscope, depending on how you define the jitter, you can see the jitter as:
    Rising edge time = reference time + jitter_1;
    Falling edge time = reference time + 10 ms + jitter_2;

    The range of pulse width you measure is then 10 ms + (jitter_2 - jitter_1)

    If value of jitter_2 is often same as jitter_1, you can get very small measured jitter value. But in fact both jitter values e can be big but not shown in the oscilloscope because the tigger source contains the common mode jitter.

    Using a separated timing source for timing reference (e.g. a timer) can avoid this issue.

    regards,
    Joseph
Reply
  • Note: This was originally posted on 11th March 2010 at http://forums.arm.com

    Hi Slim,

    By using the GPIO signal itself as trigger for oscilloscope, depending on how you define the jitter, you can see the jitter as:
    Rising edge time = reference time + jitter_1;
    Falling edge time = reference time + 10 ms + jitter_2;

    The range of pulse width you measure is then 10 ms + (jitter_2 - jitter_1)

    If value of jitter_2 is often same as jitter_1, you can get very small measured jitter value. But in fact both jitter values e can be big but not shown in the oscilloscope because the tigger source contains the common mode jitter.

    Using a separated timing source for timing reference (e.g. a timer) can avoid this issue.

    regards,
    Joseph
Children
No data