EZR32 configurable oscillator source for timer about sub-iot-stack HOT 6 CLOSED

Hi Simon

Thanks!

You are right! Can you initiate a pull request?

Maarten

From: Simon Haines [mailto:[email protected]]
Sent: Tuesday, April 26, 2016 09:25
To: MOSAIC-LoPoW/dash7-ap-open-source-stack [email protected]
Subject: [MOSAIC-LoPoW/dash7-ap-open-source-stack] EZR32 configurable oscillator source for timer (#29)

The EZR32LG timer has the LFXO hard-coded as the oscillator source for the RTC. I am bringing up a platform that does not have an external low-frequency crystal. The startLfxoForRtc() function in ezr32lg_timer.c should use the HW_USE_LFXO macro definition in platform.h to select the oscillator source for the timer.

Additionally, the HW_USE_HFXO macro is used in the __ezr32lg_mcu_init() function to select the oscillator source for the MCU. The file ezr32lg_mcu.c does not include platform.h (nor does any of its includes) and so never sees the HW_USE_HFXO definition, and always defaults to the HFRCO. Should the hal/chips/ezr32/CMakeLists.txt file include configuration parameters for oscillator selection?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/29

from sub-iot-stack.

Yes, I will add the HW_USE_LFXO/HFXO options into hal/chips/ezr32/CMakeLists.txt and generate a hal/chips/ezr32/inc/chip.h file with the selected results (with the default to define these two macros). Unless you would prefer some other method?

from sub-iot-stack.

I will add Glenn to this discussion, he is the architect of the stack.
Glenn your opinion?

M

From: Simon Haines [mailto:[email protected]]
Sent: Tuesday, April 26, 2016 09:54
To: MOSAIC-LoPoW/dash7-ap-open-source-stack [email protected]
Cc: Weyn Maarten [email protected]; Comment [email protected]
Subject: Re: [MOSAIC-LoPoW/dash7-ap-open-source-stack] EZR32 configurable oscillator source for timer (#29)

Yes, I will add the HW_USE_LFXO/HFXO options into hal/chips/ezr32/CMakeLists.txt and generate a hal/chips/ezr32/inc/chip.h file with the selected results (with the default to define these two macros). Unless you would prefer some other method?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHubhttps://github.com//issues/29#issuecomment-214659309

from sub-iot-stack.

There is already a system in place to generate a header containing configuration parameters at the platform level, i think we can use this here as well.
See hal/platforms/EFM32GG_STK3700/CMakeLists.txt for an example, specifically the PLATFORM_PARAM, PLATFORM_OPTION and PLATFORM_HEADER_DEFINE
commands. This wil generate a platform_defs.h file in you build directory which contains those platform level config options. The chip implementation can then use these defines, based on the platform (board) used for building (ie platform having an external crystal or not).

from sub-iot-stack.

I assumed you wanted to keep /hal/chips/ decoupled from /hal/platforms/ as I couldn't find any existing dependency. By adding the dependency (including platform.h), there is no need to create any CMake configuration option--either the platform has a LFXO or it doesn't.

from sub-iot-stack.

You are correct, it does not need to be configurable on a platform level and can be hardcoded in platform.h. Thanks for the pull request!

from sub-iot-stack.