On 13/03/17 23:01, Karl Palsson wrote:
> So, you should be able to configure the timer to actually output
> something, and otuput at the wrong speed because a write was too early
> right?
The behaviour in this case is unspecified, but yes, I would guess that's
the most likely thing to happen. W
Matthew Lai wrote:
> Code:
>
> -
>
> #include
> #include
>
> int main(void)
> {
> rcc_periph_clock_enable(RCC_TIM3);
> timer_set_period(TIM3, 1);
> return 0;
> }
>
> --
Thank you Matthew, that is excellent.
--Chuck
On Mon, Mar 13, 2017 at 1:58 PM, Matthew Lai wrote:
> Code:
>
> -
>
> #include
> #include
>
> int main(void)
> {
> rcc_periph_clock_enable(RCC_TIM3);
> timer_set_p
Code:
-
#include
#include
int main(void)
{
rcc_periph_clock_enable(RCC_TIM3);
timer_set_period(TIM3, 1);
return 0;
}
-
Using defaul
Matthew,
I'm really grateful you brought up the warning you read in the F7 manual.
Clearly if someone tried to read or write a register and it wasn't ready
the system would hard fault and that would be bad.
I have reviewed the code and the warning in the datasheet and believe it is
impossible to
Chuck, I'm not sure why you feel that way, but having disagreements and
discussions about technical aspects of a project is usually a good thing.
I am also not sure how I am not being helpful by pointing out something
on the errata sheets that would be a potential source of bugs, some ways
it
Matthew, it feels like you are trying to create an argument here.
If you want to be helpful, and this is actually a problem given the way
libopencm3 is built, then *reproduce the problem* with libopencm3. You can
use any combination of compiler flags you want, you just can't change the
source insi
On 03/13/2017 01:25 PM, Karl Palsson wrote:
> Matthew Lai wrote:
>
>>> I would ignore it. There's very few places where it will really matter,
>>> and the people who will need it, will be handling it themselves anyway, not
>>> using high level helper functions.
>> It would mean things like:
>>
Matthew Lai wrote:
> >
> > I would ignore it. There's very few places where it will really matter,
> > and the people who will need it, will be handling it themselves anyway, not
> > using high level helper functions.
> It would mean things like:
> rcc_periph_clock_enable(RCC_TIM3);
> timer_s
On 13/03/17 11:44, Karl Palsson wrote:
> Matthew Lai wrote:
>> Oops, looks like I only replied to Chuck.
>>
>> --
>>
>> When compiling with optimizations, I would expect
>> rcc_periph_clock_enable() to be inlined even at -Os s
Matthew Lai wrote:
> Oops, looks like I only replied to Chuck.
>
> --
>
> When compiling with optimizations, I would expect
> rcc_periph_clock_enable() to be inlined even at -Os since
> function body (one instruction after
Oops, looks like I only replied to Chuck.
--
When compiling with optimizations, I would expect
rcc_periph_clock_enable() to be inlined even at -Os since function body
(one instruction after constant propagation) is smaller
2 AHB cycles are generally essentially one instruction so a delay is
somewhat pointless, there are 4 AHB cycles consumed when returning from the
call to rcc_periph_clock_enable(). This limitation would be hit if you were
to pipeline the clock enable and the first register write in sequence so
somet
13 matches
Mail list logo
