acassis opened a new pull request, #19113: URL: https://github.com/apache/nuttx/pull/19113
Summary Adapt AVR DA/DB family architecture code and breadxavr board to recent changes in NuttX (which prevent current code from building out-of-the-box.) Impact (patch 1) Amends commit f077c0321de which did not add board_late_initialize function to breadxavr board after commit 48db502daf9 changed BOARD_EARLY_INITIALIZE to default yes. This caused build failure with default configuration (the patch adds the function.) (patch 2) Amends commit dfd3426aa59 which is needed to support configuration with some or all signal-related functionality removed (the commit skipped this chip family.) To comply with commit 2d768c294ee3: (patch 3) Adds new configuration option that excludes default up_udelay function from the build. That allows creation of custom implementation (see the second commit description why weak attribute was found insufficient. Related mailing list discussion is https://lists.apache.org/thread/bd30lljl0kcknllrcv23gqzgg2wktq1q ) Skips static assertion of BOARD_LOOPSPERMSEC != -1 if the architecture declares that it is not using the value. (patches 4 and 5) Implement up_udelay function specific to AVR DA/DB family - one which does not use BOARD_LOOPSPERMSEC (unless configured to do so.) Users: currently unable to build AVR DA/DB in default configuration, will be able to do so with the patches. New implementation of up_udelay activates automatically. Users of other architectures are not affected. Build: - new configuration option ARCH_HAVE_UDELAY which prevents default up_udelay from building if set - new configuration option ARCH_HAVE_DYNAMIC_UDELAY that declares that custom implementation of up_udelay does not use BOARD_LOOPSPERMSEC. Both unset by default except AVR DA/DB. Documentation: updated, describes up_udelay behaviour for AVR DA/DB chip family Compatibility: no functional change except AVR DA/DB. New implementation of up_udelay for this chip family may behave differently in corner cases (very low clock speeds and/or long delays causing overflow during calculations etc.) Note that there are other custom implementations of up_udelay in the source tree and from testing it seems they too are affected by problem described in patch 3. No change was done for those (as the author of the series does not have means to test them.) Testing The first patch was simply tested by building breadxavr:nsh. Does not build without the patch, builds with it. Same for the second. The third patch was tested by building the code with and without it for breadxavr:nsh (identical binary by SHA256), rv32m1-vega:nsh (identical text section) and rv-virt:nsh (text section partially differs because of different ordering of functions in the binary, ostest passed though.) Patches four and five were tested by running it on hardware in multiple configurations and delay durations - application simply used printf to output "tick/tock" on serial port; timestamps are added on the PC side. Example output: I, [2026-03-06T10:32:35.965235 #59953] INFO -- : tick I, [2026-03-06T10:32:36.065227 #59953] INFO -- : tock I, [2026-03-06T10:32:36.166234 #59953] INFO -- : tick I, [2026-03-06T10:32:36.266215 #59953] INFO -- : tock I, [2026-03-06T10:32:36.368224 #59953] INFO -- : tick I, [2026-03-06T10:32:36.468156 #59953] INFO -- : tock I, [2026-03-06T10:32:36.568209 #59953] INFO -- : tick I, [2026-03-06T10:32:36.669204 #59953] INFO -- : tock I, [2026-03-06T10:32:36.769213 #59953] INFO -- : tick I, [2026-03-06T10:33:40.963365 #60055] INFO -- : tick I, [2026-03-06T10:33:41.464356 #60055] INFO -- : tock I, [2026-03-06T10:33:41.965337 #60055] INFO -- : tick I, [2026-03-06T10:33:42.466337 #60055] INFO -- : tock I, [2026-03-06T10:33:42.969307 #60055] INFO -- : tick I, [2026-03-06T10:33:43.470287 #60055] INFO -- : tock I, [2026-03-06T10:33:43.971281 #60055] INFO -- : tick I, [2026-03-06T10:33:44.474258 #60055] INFO -- : tock Documentation changes tested using make html. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
