On Thu, Apr 22, 2021 at 8:02 AM Sebastian Huber
wrote:
>
> On 22/04/2021 14:17, Robin Müller wrote:
>
> > It worked for me. Can you specify that? The overflow check would have
> > to be implemented by an upper layer, right?
> > I can adapt my former patch using the tick solution to do the
> > mult
On 22/04/2021 14:17, Robin Müller wrote:
It worked for me. Can you specify that? The overflow check would have
to be implemented by an upper layer, right?
I can adapt my former patch using the tick solution to do the
multiplication first if this is better.
If you call HAL_GetTick() when the clo
It worked for me. Can you specify that? The overflow check would have to be
implemented by an upper layer, right?
I can adapt my former patch using the tick solution to do the
multiplication first if this is better.
Kind Regards
Robin
On Wed, 21 Apr 2021 at 20:25, Sebastian Huber <
sebastian.hu..
On 21/04/2021 19:30, Sebastian Huber wrote:
On 21/04/2021 11:00, Robin Müller wrote:
Okay, good to know. Do you think it's okay if my simpler
implementation is used completely?
Another option would be to use the simple function for the oscillator
init functions (sth like a private HAL_GetTick
On 21/04/2021 11:00, Robin Müller wrote:
Okay, good to know. Do you think it's okay if my simpler
implementation is used completely?
Another option would be to use the simple function for the oscillator
init functions (sth like a private HAL_GetTick_OscInit function).
But maybe you have a bett
Okay, good to know. Do you think it's okay if my simpler implementation is
used completely?
Another option would be to use the simple function for the oscillator init
functions (sth like a private HAL_GetTick_OscInit function).
But maybe you have a better idea.
Kind Regards
Robin
On Tue, 20 Apr
On 20/04/2021 19:45, Robin Müller wrote:
Hmm, do you have an idea how to fix this cleanly? Was this the reason
the implementation returned 0?
Yes.
This was not an issue with the other implementation:
(rtems_clock_get_ticks_since_boot() * 1000) /
rtems_clock_get_ticks_per_second();
This fun
Hmm, do you have an idea how to fix this cleanly? Was this the reason the
implementation returned 0?
This was not an issue with the other implementation:
(rtems_clock_get_ticks_since_boot() * 1000) /
rtems_clock_get_ticks_per_second();
Kind Regards
Robin
On Tue, 20 Apr 2021 at 19:31, Robin Mülle
Yes, I tried to switch oscillator and clock init in the start hook, but
that did not appear to solve the issue.
Kind Regards
Robin
On Tue, 20 Apr 2021 at 19:24, Robin Müller
wrote:
> This is really odd.. THe function is already called in the start up hook
> function init_oscillator() before ini
On 20/04/2021 19:09, Robin Müller wrote:
Okay, there is some issue with the rtems function to get the uptime
nanoseconds.. The call appears to crash for some reason.
Is this function called before the clock driver is initialized?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178
Okay, there is some issue with the rtems function to get the uptime
nanoseconds.. The call appears to crash for some reason.
Kind Regards
Robin
On Tue, 20 Apr 2021 at 18:31, Robin Mueller
wrote:
> This now uses rtems_clock_get_uptime_nanoseconds
> to calculate the uptime ticks in milliseconds.
This now uses rtems_clock_get_uptime_nanoseconds
to calculate the uptime ticks in milliseconds.
---
bsps/arm/stm32h7/start/bspstart.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/bsps/arm/stm32h7/start/bspstart.c
b/bsps/arm/stm32h7/start/bspstart.c
index 2fc8133cca..7ae3
12 matches
Mail list logo
