Hello,

I prepared new version of the series, it's available in branch named avrdx_flmap_v2 (and also attached.)

The changes are based on the feedback both from the mailing list and from PR:

1) the #endif alignment was fixed. Checkpatch doesn't complain about assembly files unfortunately and I missed this one as well.

2) since no one was happy with the naming of the new configuration options, they are renamed to what xiaoxiang781216 suggested, ie.

- AVR_HAVE_FLMAP to denote chip with memory-mapping support
- AVR_HAVE_BOARD_FLMAP to denote board with linker script that responds to configuration values set by the user

I did not rename AVR_HAS_RAMPZ for the time being, the patch series would then affect AtMega family as well. Now it only affects AVR DA/DB and I don't want to broaden the scope.

As for the HAVE/HAS discussion on GitHub, I think it depends on the view of the speaker - AVR (architecture - singular) has but AVR (chips - plural) have. I am not native speaker though.

I have been using AVR_HAS_something for configuration options because it matches AVR_HAS_MEMX_PTR which was present in the code before I started working on it (as opposed to - unless I missed something - no AVR_HAVE_something.) If AVR_HAVE is preferable for new code, I don't have any problem with that but I would rather avoid renaming the existing options to prevent needless (IMO) code churn.

Feel free to let me know if there's something else to work out.

Attachment: 0001-boards-avr-avrdx-breadxavr-fix-path-in-license-heade.patch.gz
Description: application/gzip

Attachment: 0002-Documentation-platforms-avr-document-options-of-keep.patch.gz
Description: application/gzip

Attachment: 0003-arch-avr-avrdx-do-not-copy-const-variables-into-RAM.patch.gz
Description: application/gzip

Attachment: 0004-arch-avr-avrdx-avrdx_serial-make-uart_ops_s-structur.patch.gz
Description: application/gzip

Reply via email to