-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karl Robinsod <karl.robin...@gmail.com> wrote:
> Hi
>
> I have been working with the LPC1768 and I found some code I
> don't fully understand
>
> core_cm3.c
>
> static inline uint32_t SysTick_Config(uint32_t n_ticks)
> {
> ....
> systick_set_reload(n_ticks);
> systick_set_clocksource(true);
> systick_interrupt_enable();
> systick_counter_enable();
>
> return 0;
> }
I found that in libopencmsis/core_cm3.h
I don't know why you don't get a compiler warning there, and yes,
the code is bogus. Tthe definition is
systick_set_clocksource(uint8_t clocksource)
Passing "true" is never going to do anything intelligent. You
should be use one of the defines for it, see for instance
systick_set_frequency in
https://github.com/libopencm3/libopencm3/blob/master/lib/cm3/systick.c#L82-L101
> I see the implementation looks like this:
>
> void systick_set_clocksource(uint8_t clocksource)
> {
> STK_CSR = (STK_CSR & ~STK_CSR_CLKSOURCE) |
> (clocksource & STK_CSR_CLKSOURCE);
> }
>
> STK_CSR_CLKSOURCE is ultimately defined as (1 << 2). I don't
> understand how '(1 << 2) & true' is meaningful.
>
> I found this because passing true to systick_set_reload()
> caused Systick to behave incorrectly. I think this is probably
> better (systick works)
>
> void systick_set_clocksource(uint8_t clocksource)
> {
> STK_CSR = (STK_CSR & ~STK_CSR_CLKSOURCE) |
> (clocksource ? STK_CSR_CLKSOURCE : 0);
> }
The existing implementation would keep working if more systick
sources turn up, but yes, when there's only a single clock
source, your definition is possibly better. It doesn't fix the
problem that "systick_set_clocksource(true)" is still totally
meaningless, so an implementation change that makes that work is
kinda irrelevant.
I believe that libopencmsis code should be changed to do a
"systick_set_clocksource(STK_CSR_CLKSOURCE_AHB)" instead. If that
fixes your problems, I'll happily merge that.
The whole opencmsis situation is relatively unclear to me though,
I believe it was brought in to help EFM32 parts work with some
binary blobs they had, but for most people, I'm not aware of any
reason to use it at all.
Sincerely,
Karl P
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJWWEg3AAoJEBmotQ/U1cr27OAP/RqENpyNik5eykmnu+GiBGKW
fc21UWmxETF+wJEyDAMebPx9tzfkUkWqBsj4/M77JgPgFUGGW4weCsTVAfcvsyxR
sNa9R48KIqsMSte9mwGKzzKe0v/0E8cM3z9YUVo95wEsggfDcSpdCAD8dcZBEfVL
XUokH/bVcDW3dbNqJ+2wbhlaf2WkneZVX7HZ4TGoMUH/WJ5BKWnbRnJruBVy8TD+
Hlv/q4xXk3izpKp/34KwXm6Fe9gcz8lZcTb2WodxqVXKJ43imb3bVCUJM1tlCIwt
X3pixYwSSQ9R3CMwaKOGN50jw6hCv+vFm7mbLDHZm/ylNyUQp/hZhxO21UfEuVsk
OLqTcU+zV+fbcXOQhrf0bCpj0hT89J3Jf5GQwB/na5iK0PC7/beJkt4+PwXBislc
YWTsOqGk+ARIG7GkxOLcC0tStLQOEnEgX+//jCAdkXVO49Ok9GoDITQnJzQCHs3b
BiNG1rGNi7rbo8W2yhCpB31Z8q2115qNP0LUCNjeMjn26e1KTXJKaWM5vq6v7yRL
awdy3GLILdikIUJnOkf/558r5Yq4rAi4PROeN5kYsczH6ptX/KBvF+YQBAkq8ytA
iNg4W/BzruT+ZX+Dwj8RlKRbxiVSi5JyjQ42ICCgc+/P3g1O9jL9BLuCdQ4RGkHX
Ek/SpUEQXvvFQu9Doj7s
=YwbH
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
