Hello,
I would like to submit some patches that catch AVR architecture (DA/DB
family) up to recent changes in the NuttX. (Currently, the code does not
build with default configuration.)
First patch amends commit dfd3426aa59 and fixes build failure with
default configurations. As far as I was told, authors of that commit
work with older code base so they likely did not have the DA/DB family
in their source tree and so they did not fix it. I simply duplicated
their change. After this change, build succeeds.
Following patches are response to commit 2d768c294ee3 which requires
boards to configure value of LOOPSPERMSEC (and triggers a build-time
assertion if not.) This is somewhat problematic for AVR DA/DB family
because there is no single correct value of LOOPSPERMSEC - the CPU
frequency is configurable both in Kconfig and during runtime.
This means that the board can have LOOPSPERMSEC set in its defconfig but
the value is going to be wrong, unless the user chooses corresponding
CPU frequency (and sticks with it.) The third and fourth patch,
therefore adds architecure-specific up_udelay function which calculates
required number of loops in runtime based on current clock source and
prescaler.
While creating this function, I discovered that while compiled, it is
not linked into the resulting binary - the default implementation marked
as weak is used instead. According to a short mailing list discussion,
it seems to have something to do with the way NuttX is linked (using
static libraries.) See more in [1]. For this reason, second patch adds a
configuration option that disables building default up_udelay
implementation if the architecture enables this option to declare that
it provides its own version.
As usual - I do not have a GitHub account so - if the patches seem
useful and the problem with LOOPSPERMSEC can be solved this way - I
would like to ask someone with one to create a pull request. The series
is available in a git repository nuttx.git at git.kerogit.eu accessible
through HTTP/S. (Trying to prevent bot traffic by not posting the URL in
machine-readable form.) The relevant branch is called
avrdx_adapt_20260306
If it comes to it, this is the description for the pull request:
==================
Summary
Adapt AVR DA/DB family architecture code and breadxavr board to recent
changes in NuttX (which prevent current code from building.)
Impact
(patch 1) 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 2) 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 )
(patches 3 and 4) Implements up_udelay function specific to AVR DA/DB
family - one which does not use BOARD_LOOPSPERMSEC (unless configured to
do so.)
Skips static assertion of BOARD_LOOPSPERMSEC != -1 if the architecture
declares that it is not using the value.
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 2. 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.
The seconds 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.)
Third and fourth patch was 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: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
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
Documentation changes tested using make html
==================
Any feedback will is appreciated
[1] https://lists.apache.org/thread/bd30lljl0kcknllrcv23gqzgg2wktq1q
