wes3 commented on pull request #2441: URL: https://github.com/apache/mynewt-core/pull/2441#issuecomment-747480588
@ncasaril and @kasjer I was looking over the changes and I was thinking the same thing regarding settling time. The code to request the hfxo just turns it on and leaves without waiting for it to settle as you say and I was thinking of the implications of that. I think I modeled this code after some code I saw in an SDK from nordic. The idea was to check to see if the clock was started; if so do nothing. If not, clear the started event, turn on the clock, and wait for it to settle. I figured it would be pretty catastrophic if we never see EVENTS_HFCLKSTARTED so that is why it just loops forever and lets the watchdog fire. Yes, that assumes there is a watchdog running :-) There is an errata for the chip that states you could see that event erroneously if the clock takes longer than 400 usecs to settle btw so that would have to be handled differently. So I guess we just need to decide if we care about using a timer or the radio before the clock settles. I would suspect most settling times for most boards to be in the hundreds of usecs so probably not an issue but who knows? I guess if we were being very cautious and "more correct" (bad term) we would move the code that waits for settling into hfxo_request if the clock is not on. So some thoughts on what we could do if we wanted: 1) Make sure on startup that the HFXO is off. This is to deal with any bootloaders that may have turned it on. 2) In HFXO request, wait to settle if the reference count is zero. 3) Related to 2, if all things are working properly, the HFXO should be off if the reference count is zero. Not sure if we care about that case and want to add an assert there for debug (a debug assert that can get compiled out) but this is not critical. If both of you feel that there really is no need to wait for it to settle I am fine with the code the way it is. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
