Hi Tomek, Unfortunately I believe it is build specific. ISR count and thread count will definitely affect it, and compiler optimization may as well according to Tim Hardisty's experience (there might be a way around in the implementation if we block the compiler from optimizing things?). I don't think that any of the busy-loop delays are really intended to be precise, so I'm not sure there's much that can be done about changing values depending on configuration besides warning users in the documentation. Timer-based delays should be used wherever possible instead. We can control the values in the NuttX defconfigs to make them as good as possible, but once the user starts changing options it's really a toss-up.
A check-list is a good idea, but I think for now we should be documenting some of these "hidden configuration options" on their own first, and then trying as much as possible to avoid these foot-guns by statically verifying values at compile time. That way the user will be forcibly made aware of things that will have unintended consequences and are then burdened to decide whether to read the docs to fix them properly or not. The check-list will probably have to be a long-term goal, since it highly depends on other variables like what architecture/chip is being used, what features are being used, etc. Before a check-list is made, I am of the opinion that we need to resolve other documentation issues first. Namely, all of the undocumented applications! Those are very valuable for testing, and in this case, for telling users how to solve the LOOPSPERMSEC issue! To summarize, I think the first steps are: 1. Resolving the board configurations that this change would break (I can do this atomically in the same commit, I just need people with those targets to help me come up with correct values for LOOPSPERMSEC) 2. Providing documentation for this specific configuration option (in addition to the calib_udelay docs) 3. Brainstorming any other configuration options that aren't straight-forward to make a list of things to fix 4. Compiling pre-flight checklist(s) for users to follow when making a firmware binary I think Sphinx lets us make global symbols for the CONFIG_* options, we can leverage that to document them like we do with the API symbols. Then it will be easy to reference them from other doc pages. That will also have to be long-term, there are tons of options (some with missing info in the Kconfig help text, too). Matteo On Fri, Sep 12, 2025 at 2:59 PM Tomek CEDRO <to...@cedro.info> wrote: > Thanks Matteo :-) > > My response as on GH :-) > > In this approach looks like we need to fix the boards where -1 (new > default) is used, just to pass build here and have correct timings on > these boards, then update the rest of the boards depending on what we > have at hand to fix their timings? :-) > > On the other hand we may keep this default and put some pressure / > attention to the proper timings calibration when using different > boards. I am wondering what impacts the value and if the differences > are big - is it build specific? For instance when using different > compiler, specific optimization level, many irqs, threads, etc. Or > this value is always correct once set no matter what build and > configuration is used? :-) > > I mean this 5000 default was probably set because any default may be > wrong when this value is not calibrated on a final firmware build? > People just did not know that (including me to be honest but I usually > change that value just not very precise measurement)? In that case we > may leave as-is and just add Pre-Flight-Check-List to the > documentation with list of important things to know / check / verify > when creating / building NuttX based projects? :-) > > Anyways this Pre-Flight-Check-List may be a nice a nice to add to the > documentation, it can be a table or bullet points with just short > sentence reminders on what is important before firmware launch? Each > reminder would be a hyperlink to a detailed description if someone > sees it for the first time? What do you think folks? :-) > > Thanks! :-) > Tomek > > > On Fri, Sep 12, 2025 at 8:38 PM Matteo Golin <matteo.go...@gmail.com> > wrote: > > > > Hello everyone, > > > > I have proposed a change wherein the default value > > for CONFIG_BOARD_LOOPSPERMSEC is no longer "5000" but instead "-1", such > > that it throws a compilation error if not changed. > > > > This is because most users do not know about this configuration value, > and > > wildly incorrect values may cause subtle timing issues. > > > > You can find the linked issue here: > > https://github.com/apache/nuttx/issues/17004 > > And the PR I made here: https://github.com/apache/nuttx/pull/17011 > > > > I need people with targets that are using the default to help us > determine > > the correct value with the `calib_udelay` example so that we can fix > > failing builds and make NuttX more stable for users using the pre-made > > defconfigs. > > > > Let me know what you think, > > Matteo > > > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
