I noticed, thanks. To reply to the comments and feedback in the PR:
1. The discussion about AVR_LINUXGCC_TOOLCHAIN_IS_GCC - my overall goal
was to minimize changes for boards and AVR families I am not using (and
have no experience with them and, most importantly, cannot test.)
Setting DEBUG_OPT_UNUSED_SECTIONS to No in all defconfigs is something
that did not occur to me. Using the indirection with
AVR_LINUXGCC_TOOLCHAIN_IS_GCC still looks safer - even with
DEBUG_OPT_UNUSED_SECTIONS being disabled, setting ARCH_TOOLCHAIN_GCC and
ARCH_TOOLCHAIN_GNU in turn may still have some side effects. But if the
consensus is to drop AVR_LINUXGCC_TOOLCHAIN_IS_GCC, select
ARCH_TOOLCHAIN_GCC directly and alter existing defconfigs, I can prepare
new version of the series which will do that instead.
2. Build instructions etc. - I noticed Alan C. Assis already said he
will create some documentation but I can prepare something as well (so
other people are not burdened with it.) If you want me to, I'll just
need to know where to put that - to the board Documentation directory?
(Documentation/platforms/avr/avrdx/boards/breadxavr/index.rst)
Also - is it appropriate to prepare more default configurations? I
didn't want to pollute the configuration list with a bunch of
breadxavr:nsh, breadxavr:buttons etc. But if that is not seen as a
problem, I can try to make a few to pair with patches that add some
hardware support
On 2025-05-06 19:16, Tomek CEDRO wrote:
Alan just posted the PR with your AVR updates :-)
https://github.com/apache/nuttx/pull/16323
Thank you! :-)
Tomek
On Tue, May 6, 2025 at 2:37 AM Tomek CEDRO <to...@cedro.info> wrote:
Okay, git clone works from that location, I pushed the PR but Alan is
working on this one too so he takes over, thanks for your
contributions KR!
Two remarks:
1. Please remember to git commit -s.
2. Please remember to mark what hardware was the code tested on.
https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md
Thank you! :-)
Tomek
On Mon, May 5, 2025 at 7:47 PM <kr....@kerogit.eu> wrote:
>
> Hi, it's just /nuttx.git without the /apache part.
>
> On 2025-05-05 17:46, Tomek CEDRO wrote:
> > Is server broken? I get 403 on https://git.kerogit.eu/apache/nuttx.git
> > and anything else in kerogit.eu domain :-(
> > Tomek
> >
> > On Sun, May 4, 2025 at 4:44 PM <kr....@kerogit.eu> wrote:
> >>
> >> Hello,
> >>
> >> new version of the patch series is posted in the git repository, the
> >> branch is named avrdx_rfc2 and starts at avr_fixes_rfc2 (everything up
> >> to and including avr_fixes_rfc2 is already merged.)
> >>
> >> Here are the changes from previous version:
> >>
> >> 1. some formatting and typo fixes in various documents
> >>
> >> 2. as discussed above, some mixed-case constants were preserved (_bm
> >> and
> >> _bp suffix) and some removed. Patch for the nxstyle tool that
> >> facilitates this exception is added to the series. Non-permitted
> >> constants with mixed-case letters are no longer used in their form
> >> from
> >> library io.h file, instead there are new files within NuttX source
> >> tree
> >> that provide all-uppercase constant names.
> >>
> >> 3. nxstyle cannot deal with the exceptions properly and come constants
> >> with _bm suffix in their name were still flagged as incorrect. That is
> >> worked around by various code shuffling, assigning into temporary
> >> variables etc. Most places where this was needed to be done are marked
> >> with comment along the lines of "this will make nxstyle happpy." The
> >> code seems less readable this way but after trying to make heads or
> >> tails of the nxstyle source code, this is the only solution I can
> >> provide on my own.
> >>
> >> 4. after dealing with this, I found that there were some mixed-case
> >> warnings still left - I missed them because of the quantity of others.
> >> Specifically, it was the type USART_t, a data type which facilitates
> >> access to a peripheral I/O registers for USART. (Other peripherals
> >> have
> >> their types named in the same way.) I changed this one into
> >> avrdx_usart_t and redefined it in the NuttX source as well.
> >>
> >> There should be no checkpatch errors left.
> >>
> >> From what I tested, the code compiles to a binary identical to
> >> previous
> >> version of the patch series.
> >>
> >> Any comments and reviews are appreciated.
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
