[EMAIL PROTECTED] wrote:
Andrew Lunn wrote:
Yes, I will use the SysTick for the real time clock source, moving
this to the architecture. So there will be no need to define this
in new variants and platforms. We probably should provide macros
for overriding though?!?
That is easy to do. The porting guide says the official interface is:
HAL_CLOCK_INITIALIZE( period )
HAL_CLOCK_RESET( vector, period )
HAL_CLOCK_READ( pvalue )
So you can include var_io.h or plf_io.h first and then do:
ifndef HAL_CLOCK_INITIALIZE( period )
#define HAL_CLOCK_INITIALIZE cyg_cortex_clock_init( (period))
#endif
etc...
Ok, moving the clock source to the architecture, we need a way to
define the frequency of the SysTick clock source, which is
implementation defined. Can we do this using a CDL interface,
requiring the cortex variants to provide the SysTick clock frequency?
Otherwise we'd have to move the clock functions back to the variant.
After some more investigation it looks like the SysTick is not THAT
usable as the source of the realtime clock. On the STM32, the SysTick
cannot be calibrated, and is by default calibrated for 1ms ticks (at
maximum system clock frequency). This can be enough for timeslicing but
it won't cut it delay_us. The luminary is obviously also pre-calibrated.
Do you still think SysTick is a good idea?
Simon
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
