[PATCH] examples/calib_udelay: add tool for calibrating CONFIG_BOARD_LOOPSPERMSEC

[Juha Niskanen (Haltian)]

Hi Greg,

Here is our tool for calibrating the delay loop for a new board. I thought we have sent this to you in past, but I guess not... sharing now in case this is useful to others as well.

Patch also fixes one undeclared variable in buttons example.

Best Regards,

   Juha

[patacongo]

Here is our tool for calibrating the delay loop for a new board. I thought we have sent this to you in past, but I guess not... sharing now in case this is useful to others as well.

Thanks! Committed.

This looks a little more rigorous than the technique that I use.  The is an RTOS option CONFIG_ARCH_CALIBRATION that just waits for 100 sec at boot up.  That is very painful to use (and perhaps I should remove it now that you have provided a real better tool).

But lately I have just been forcing a hard fault, then timing the rate of blinking.  I should be 2Hz.  Still a good quick'n'dirty way to calibrate.

Greg

[Juha Niskanen (Haltian)]

Hi Greg,

I did not notice CONFIG_ARCH_CALIBRATION exists. Perhaps apps/ is indeed a better place for rarely used features than duplicating calibration loop code for each chip architecture inside RTOS itself.

One problem with calib_udelay is that it currently needs CONFIG_LIBM and CONFIG_LIBC_FLOATINGPOINT. Maybe it should select those in its Kconfig - I forgot this from my patch - or be converted to use fixedmath.h?

Best Regards,

   Juha

---

From: nu...@googlegroups.com <nu...@googlegroups.com> on behalf of patacongo <spud...@gmail.com>
Sent: Tuesday, August 14, 2018 3:57:38 PM
To: NuttX
Subject: [nuttx] Re: [PATCH] examples/calib_udelay: add tool for calibrating CONFIG_BOARD_LOOPSPERMSEC

 

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[patacongo]

I did not notice CONFIG_ARCH_CALIBRATION exists. Perhaps apps/ is indeed a better place for rarely used features than duplicating calibration loop code for each chip architecture inside RTOS itself.

The manual technique... whether using CONFIG_ARCH_CALIBRATION or just forcing a hardfault is very time consuming.  It is an iterative processing involving modifying the LOOPSPERMSEC and  closing in on a good value.  Automating that is definitely an improvement.

One problem with calib_udelay is that it currently needs CONFIG_LIBM and CONFIG_LIBC_FLOATINGPOINT. Maybe it should select those in its Kconfig - I forgot this from my patch - or be converted to use fixedmath.h?

I added the selection of CONFIG_LIBC_FLOATINGPOINT in the Kconfig file, but not CONFIG_LIBM which enables the NuttX libm.  If you are using one of the newlib libm hacks you would not want that selected.

Greg