Announcing AVR-LIBC3

Go To Last Post
32 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Everyone,

 

AVR-LIBC hasn't seen any activity in a subjective age.  Bug Reports and Patches get posted to the official AVR-LIBC repository and no action gets done.  Nothing.  No rejections, no consideration, nothing.

 

I wanted xmega3 devices to be in AVR-LIBC, there is a patch for that.  There are other patches too, like a delay routine for attiny.

 

SO, I have converted the entire SVN history from the official AVR-LIBC to git.  I have applied 6 long outstanding patches, the oldest dating from July 2017.  It adds support for 26 processors, fixes definitions for ATmega324PA and other issues. I have called the fork AVR-LIBC3 because I don't want any confusion with AVR-LIBC which is the official version and its last release was V2, unmaintained as it is.  If anyone has any bugs they want fixed in AVR-LIBC or wants to benefit from having a maintained source tree of AVR-LIBC, feel free to clone and push merge requests. There are a few Patches I haven't applied, because they don't apply cleanly.  like new/delete support for C++.  There are numerous issues in the bug tracker, some with patches.  I haven't even begun to look at those.

Bringing AVR-LIBC up to include all the work that people have done, but the maintainers have neglected, is a big task.

 

Feel under no obligation to use this, but if you want modern tools, with support for modern versions of GCC, actively maintaining AVR-LIBC is going to be necessary.

 

Source is here: https://github.com/stevenj/avr-libc3

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

strontiumdog wrote:

I wanted xmega3 devices to be in AVR-LIBC, there is a patch for that.

For all of my knowledge, that patch had been accepted and integrated and is working properly (same for GCC and Binutils additions).

 

If you want to build avr-libc from source, use SVN trunk instead of the latest official release.  There is no heavy development, hance any additions are maintenance bits.

 

To add native support for ATmega4809 et al., you'll need to add a compiler addition to handle the different PM_FLASH_OFFSETs amongs the avrxmega3 devices (extension to specs files generation).

 

IMO it does not make much sense to start more avr-libc forks and diffuse development even more.

 

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So ... which version of avr-libc do I get when I download the "Atmel Toolchain for Mac" (or Atmel Studio, for that matter.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:

strontiumdog wrote:

I wanted xmega3 devices to be in AVR-LIBC, there is a patch for that.

For all of my knowledge, that patch had been accepted and integrated and is working properly (same for GCC and Binutils additions).

Incorrect.

Quote:

If you want to build avr-libc from source, use SVN trunk instead of the latest official release.  There is no heavy development, hance any additions are maintenance bits.

What do you think I based my fork on?  I said explicitly

strontiumdog wrote:
I have converted the entire SVN history from the official AVR-LIBC to git.
There is no heavy development because no one is paying any attention to feature additions and bug fixes.  A one off comment and then no action for over a year is not even light development, its dead.

Quote:

To add native support for ATmega4809 et al., you'll need to add a compiler addition to handle the different PM_FLASH_OFFSETs amongs the avrxmega3 devices (extension to specs files generation).

You are correct, GCC 9.1 has no support for ATmega808/809/1608/1609/3208/3209/4808/4809.

I have no intention of adding to GCC.  However if GCC added support for ATmega4809 I would happily accept patches to avr-libc3 to support it.  Can the same be said for avr-libc? 

Quote:

IMO it does not make much sense to start more avr-libc forks and diffuse development even more.

I couldn't disagree more.  git and github have proven beyond all reasonable doubt that forking is good for a project.  The concept of private forks, where people add the features THEY need, and can use themselves, with easy reintegration upstream is very powerful and encourages development.  If i did nothing more than migrate the source tree (which I did), then the effort is worthwhile, in my opinion.

 

The fact is the last update made to the SVN source of avr-libc was 1 year and 2 weeks ago.  The one before that was 22 months and 3 weeks ago.  The last time the maintainer did an update was 2 years and 1 month ago.  They don't even bother to do the annual changelog rotation any more.  Its stuck on 2017.

 

The project is dead, and thinking it isn't is just wishful thinking.  It should be a development priority of avr-libc to fully support the latest released avr-gcc.  Thats version 9.1.  avr-libc doesn't even fully support 8.3, so clearly there is no development priority at all.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

So ... which version of avr-libc do I get when I download the "Atmel Toolchain for Mac" (or Atmel Studio, for that matter.)

 

 

No idea.  But, if you are using a pre-built toolchain by Microchip, i would use whatever avr-libc they bundle.  I would not advocate mixing and matching.

My main purpose in creating this fork is to have a maintained version of avr-libc which tracks the latest gcc release. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

strontiumdog wrote:

SprinterSB wrote:

strontiumdog wrote:

I wanted xmega3 devices to be in AVR-LIBC, there is a patch for that.

For all of my knowledge, that patch had been accepted and integrated and is working properly (same for GCC and Binutils additions).

Incorrect.


I see avrxmega3 support added as SVN 2544 (patch #9400).

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
strontiumdog wrote:

SprinterSB wrote:

strontiumdog wrote:

I wanted xmega3 devices to be in AVR-LIBC, there is a patch for that.

For all of my knowledge, that patch had been accepted and integrated and is working properly (same for GCC and Binutils additions).

Incorrect.

I see avrxmega3 support added as SVN 2544 (patch #9400).

 

2544 adds a few defs, necessary for building multilib for xmega3 but doesn't have any device files whatsoever.

2548 defines an xmega3 variant of  eeprom_is_ready()  but doesn't have any device files whatsoever.

 

Thats the sum total of committed xmega3 support in avr-libc.  Which amounts to no practical xmega3 support.  You certainly can't use avr-libc with an xmega3 with those two minor patches alone.  To claim otherwise is disingenuous.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


When I look at 2544 I see:

 

Certainly seems to suggest extensive changes to support X3.

 

BTW would it surprise you to learn that "SprinterSB" and Georg-Johan Lay (shown in this change) are one and the same person? I rather suspect he may know what changes he has made to device support in the compiler as for the last few years he's been the one who's done almost all the (non Atmel) maintenance on avr-gcc and AVR-LibC ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

BTW would it surprise you to learn that "SprinterSB" and Georg-Johan Lay (shown in this change) are one and the same person? I rather suspect he may know what changes he has made to device support in the compiler as for the last few years he's been the one who's done almost all the (non Atmel) maintenance on avr-gcc and AVR-LibC ;-)

Is that some kind of attempt to intimidate or shame me?  I honestly want to know, because I don't care about personalities,  I don't see how its relevant. I care about what the code does or doesn't do.  Its functionality is plain, on it's face.

 

clawson wrote:

When I look at 2544 I see:

2017-07-05  Georg-Johann Lay <avr@gjlay.de>
         
                    patch #9400: Add multilib support for avrxmega3 + avrxmega3/short-calls.
                    * configure.ac (CHECK_AVR_DEVICE): Add one for avrxmega3.
                    (AM_CONDITIONAL): Add one for HAS_avrxmega3.
                    (AC_CONFIG_FILES): Add avr/lib/avrxmega3/Makefile,
                    avr/lib/avrxmega3/short-calls/Makefile.
                    * devtools/gen-avr-lib-tree.sh (CFLAGS_SHORT_CALLS): New.
                    (AVRXMEGA3_DEV_INFO): New.
                    (AVRXMEGA3SC_DEV_INFO): New.
                    (AVR_ARH_INFO): Add entries avrxmega3, avrxmega3/short-calls.
                    * include/avr/pgmspace.h (__AVR_HAVE_RAMPD__): Fix comment.

 

Certainly seems to suggest extensive changes to support X3.

 

 

The changelog accurately reflects the changes made, and I don't understand how anyone can think that they suggest "extensive changes to support X3".  I also don't understand why anyone making that claim wouldn't also look at the actual patch in question to determine if it does or does not in reality constitute "extensive changes to support X3".  The changes are minor.  To hopefully put an end to the lie that Patch 2544 is extensive support for xmega3, here it is, in its entirety:

 

diff --git a/avr-libc/ChangeLog b/avr-libc/ChangeLog
index ff7030aa..b8a83d33 100644
--- a/avr-libc/ChangeLog
+++ b/avr-libc/ChangeLog
@@ -1,3 +1,16 @@
+2017-07-05  Georg-Johann Lay <avr@gjlay.de>
+
+       patch #9400: Add multilib support for avrxmega3 + avrxmega3/short-calls.
+       * configure.ac (CHECK_AVR_DEVICE): Add one for avrxmega3.
+       (AM_CONDITIONAL): Add one for HAS_avrxmega3.
+       (AC_CONFIG_FILES): Add avr/lib/avrxmega3/Makefile,
+       avr/lib/avrxmega3/short-calls/Makefile.
+       * devtools/gen-avr-lib-tree.sh (CFLAGS_SHORT_CALLS): New.
+       (AVRXMEGA3_DEV_INFO): New.
+       (AVRXMEGA3SC_DEV_INFO): New.
+       (AVR_ARH_INFO): Add entries avrxmega3, avrxmega3/short-calls.
+       * include/avr/pgmspace.h (__AVR_HAVE_RAMPD__): Fix comment.
+
 2017-06-16  Joerg Wunsch <j.gnu@uriah.heep.sax.de>

        * doc/api/faq.dox (faq_reg_usage): Document differences for
diff --git a/avr-libc/NEWS b/avr-libc/NEWS
index 9b6d2233..ab9f1394 100644
--- a/avr-libc/NEWS
+++ b/avr-libc/NEWS
@@ -32,6 +32,7 @@
   [#8536] Fix a typo within <stdio.h>
   [#8649] small documentation fixes in
   [#9187] [AVR_TINY]: Support 16-bit xtoa functons and more string functions.
+  [#9400] Add avrxmega3 multilibs

 * Other changes:

diff --git a/avr-libc/configure.ac b/avr-libc/configure.ac
index dd868eeb..ab4903a5 100644
--- a/avr-libc/configure.ac
+++ b/avr-libc/configure.ac
@@ -1124,6 +1124,11 @@ CHECK_AVR_DEVICE(atxmega32e5)
 AM_CONDITIONAL(HAS_atxmega32e5, test "x$HAS_atxmega32e5" = "xyes")

+# avrxmega3
+CHECK_AVR_DEVICE(avrxmega3)
+AM_CONDITIONAL(HAS_avrxmega3, test "x$HAS_avrxmega3" = "xyes")
+
+
 # avrxmega4
 CHECK_AVR_DEVICE(avrxmega4)
 AM_CONDITIONAL(HAS_avrxmega4, test "x$HAS_avrxmega4" = "xyes")
@@ -1571,6 +1576,16 @@ AC_CONFIG_FILES([
diff --git a/avr-libc/ChangeLog b/avr-libc/ChangeLog
diff --git a/avr-libc/ChangeLog b/avr-libc/ChangeLog
diff --git a/avr-libc/ChangeLog b/avr-libc/ChangeLog
index ff7030aa..b8a83d33 100644
--- a/avr-libc/ChangeLog
+++ b/avr-libc/ChangeLog
@@ -1,3 +1,16 @@
+2017-07-05  Georg-Johann Lay <avr@gjlay.de>
+
+       patch #9400: Add multilib support for avrxmega3 + avrxmega3/short-calls.
+       * configure.ac (CHECK_AVR_DEVICE): Add one for avrxmega3.
+       (AM_CONDITIONAL): Add one for HAS_avrxmega3.
+       (AC_CONFIG_FILES): Add avr/lib/avrxmega3/Makefile,
+       avr/lib/avrxmega3/short-calls/Makefile.
+       * devtools/gen-avr-lib-tree.sh (CFLAGS_SHORT_CALLS): New.
+       (AVRXMEGA3_DEV_INFO): New.
+       (AVRXMEGA3SC_DEV_INFO): New.
+       (AVR_ARH_INFO): Add entries avrxmega3, avrxmega3/short-calls.
+       * include/avr/pgmspace.h (__AVR_HAVE_RAMPD__): Fix comment.
+
 2017-06-16  Joerg Wunsch <j.gnu@uriah.heep.sax.de>

        * doc/api/faq.dox (faq_reg_usage): Document differences for
diff --git a/avr-libc/NEWS b/avr-libc/NEWS
index 9b6d2233..ab9f1394 100644
--- a/avr-libc/NEWS
+++ b/avr-libc/NEWS
@@ -32,6 +32,7 @@
   [#8536] Fix a typo within <stdio.h>
   [#8649] small documentation fixes in
   [#9187] [AVR_TINY]: Support 16-bit xtoa functons and more string functions.
+  [#9400] Add avrxmega3 multilibs

 * Other changes:

diff --git a/avr-libc/configure.ac b/avr-libc/configure.ac
index dd868eeb..ab4903a5 100644
--- a/avr-libc/configure.ac
+++ b/avr-libc/configure.ac
@@ -1124,6 +1124,11 @@ CHECK_AVR_DEVICE(atxmega32e5)
 AM_CONDITIONAL(HAS_atxmega32e5, test "x$HAS_atxmega32e5" = "xyes")

+# avrxmega3
+CHECK_AVR_DEVICE(avrxmega3)
+AM_CONDITIONAL(HAS_avrxmega3, test "x$HAS_avrxmega3" = "xyes")
+
+
 # avrxmega4
 CHECK_AVR_DEVICE(avrxmega4)
 AM_CONDITIONAL(HAS_avrxmega4, test "x$HAS_avrxmega4" = "xyes")
@@ -1571,6 +1576,16 @@ AC_CONFIG_FILES([
        avr/lib/avrxmega2/atxmega32e5/Makefile
 ])

+# avrxmega3
+AC_CONFIG_FILES([
+       avr/lib/avrxmega3/Makefile
+])
+
+# avrxmega3/short-calls
+AC_CONFIG_FILES([
+       avr/lib/avrxmega3/short-calls/Makefile
+])
+
 # avrxmega4
 AC_CONFIG_FILES([
steven@steven-ge40:/opt/AVR/avr-libc/avr-libc3$ git diff 86bae6991f99c660cc93c0e6d0ae7a9a0aa5cd1d~ 86bae6991f99c660cc93c0e6d0ae7a9a0aa5cd1d > d
steven@steven-ge40:/opt/AVR/avr-libc/avr-libc3$ cat d
diff --git a/avr-libc/ChangeLog b/avr-libc/ChangeLog
index ff7030aa..b8a83d33 100644
--- a/avr-libc/ChangeLog
+++ b/avr-libc/ChangeLog
@@ -1,3 +1,16 @@
+2017-07-05  Georg-Johann Lay <avr@gjlay.de>
+
+	patch #9400: Add multilib support for avrxmega3 + avrxmega3/short-calls.
+	* configure.ac (CHECK_AVR_DEVICE): Add one for avrxmega3.
+	(AM_CONDITIONAL): Add one for HAS_avrxmega3.
+	(AC_CONFIG_FILES): Add avr/lib/avrxmega3/Makefile,
+	avr/lib/avrxmega3/short-calls/Makefile.
+	* devtools/gen-avr-lib-tree.sh (CFLAGS_SHORT_CALLS): New.
+	(AVRXMEGA3_DEV_INFO): New.
+	(AVRXMEGA3SC_DEV_INFO): New.
+	(AVR_ARH_INFO): Add entries avrxmega3, avrxmega3/short-calls.
+	* include/avr/pgmspace.h (__AVR_HAVE_RAMPD__): Fix comment.
+
 2017-06-16  Joerg Wunsch <j.gnu@uriah.heep.sax.de>

 	* doc/api/faq.dox (faq_reg_usage): Document differences for
diff --git a/avr-libc/NEWS b/avr-libc/NEWS
index 9b6d2233..ab9f1394 100644
--- a/avr-libc/NEWS
+++ b/avr-libc/NEWS
@@ -32,6 +32,7 @@
   [#8536] Fix a typo within <stdio.h>
   [#8649] small documentation fixes in
   [#9187] [AVR_TINY]: Support 16-bit xtoa functons and more string functions.
+  [#9400] Add avrxmega3 multilibs

 * Other changes:

diff --git a/avr-libc/configure.ac b/avr-libc/configure.ac
index dd868eeb..ab4903a5 100644
--- a/avr-libc/configure.ac
+++ b/avr-libc/configure.ac
@@ -1124,6 +1124,11 @@ CHECK_AVR_DEVICE(atxmega32e5)
 AM_CONDITIONAL(HAS_atxmega32e5, test "x$HAS_atxmega32e5" = "xyes")

+# avrxmega3
+CHECK_AVR_DEVICE(avrxmega3)
+AM_CONDITIONAL(HAS_avrxmega3, test "x$HAS_avrxmega3" = "xyes")
+
+
 # avrxmega4
 CHECK_AVR_DEVICE(avrxmega4)
 AM_CONDITIONAL(HAS_avrxmega4, test "x$HAS_avrxmega4" = "xyes")
@@ -1571,6 +1576,16 @@ AC_CONFIG_FILES([
 	avr/lib/avrxmega2/atxmega32e5/Makefile
 ])

+# avrxmega3
+AC_CONFIG_FILES([
+	avr/lib/avrxmega3/Makefile
+])
+
+# avrxmega3/short-calls
+AC_CONFIG_FILES([
+	avr/lib/avrxmega3/short-calls/Makefile
+])
+
 # avrxmega4
 AC_CONFIG_FILES([
 	avr/lib/avrxmega4/Makefile
diff --git a/avr-libc/devtools/gen-avr-lib-tree.sh b/avr-libc/devtools/gen-avr-lib-tree.sh
index 73fff8a4..02f7dc13 100755
--- a/avr-libc/devtools/gen-avr-lib-tree.sh
+++ b/avr-libc/devtools/gen-avr-lib-tree.sh
@@ -47,6 +47,7 @@ PATH=/usr/xpg4/bin:$PATH

 CFLAGS_SPACE="-mcall-prologues -Os"
 CFLAGS_TINY_STACK="-msp8 -mcall-prologues -Os"
+CFLAGS_SHORT_CALLS="-mshort-calls -mcall-prologues -Os"
 CFLAGS_BIG_MEMORY='-Os $(FNO_JUMP_TABLES)'
 CFLAGS_SPEED="-Os"

@@ -302,6 +303,12 @@ atxmega32d4:crtx32d4.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
 atxmega32e5:crtx32e5.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS}\
 "

+AVRXMEGA3_DEV_INFO="\
+"
+
+AVRXMEGA3SC_DEV_INFO="\
+"
+
 AVRXMEGA4_DEV_INFO="\
 atxmega64a3:crtx64a3.o:${DEV_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
 atxmega64a3u:crtx64a3u.o:${DEV_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
@@ -371,6 +378,8 @@ avr5::AVR5_DEV_INFO:${LIB_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
 avr51::AVR51_DEV_INFO:${LIB_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
 avr6::AVR6_DEV_INFO:${LIB_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
 avrxmega2::AVRXMEGA2_DEV_INFO:${LIB_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
+avrxmega3::AVRXMEGA3_DEV_INFO:${LIB_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
+avrxmega3:short-calls:AVRXMEGA3SC_DEV_INFO:${LIB_DEFS}:${CFLAGS_SHORT_CALLS}:${DEV_ASFLAGS};\
 avrxmega4::AVRXMEGA4_DEV_INFO:${LIB_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
 avrxmega5::AVRXMEGA5_DEV_INFO:${LIB_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
 avrxmega6::AVRXMEGA6_DEV_INFO:${LIB_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
diff --git a/avr-libc/include/avr/pgmspace.h b/avr-libc/include/avr/pgmspace.h
index 54d40f3f..f406865d 100644
--- a/avr-libc/include/avr/pgmspace.h
+++ b/avr-libc/include/avr/pgmspace.h
@@ -892,8 +892,8 @@ typedef uint64_t  prog_uint64_t __attribute__((__progmem__,deprecated("prog_uint
 }))

 /*
-Check for architectures that implement RAMPD (avrxmega3, avrxmega5,
-avrxmega7) as they need to save/restore RAMPZ for ELPM macros so it does
+Check for architectures that implement RAMPD (avrxmega5, avrxmega7)
+as they need to save/restore RAMPZ for ELPM macros so it does
 not interfere with data accesses.
 */
 #if defined (__AVR_HAVE_RAMPD__)

 

That is not "extensive support for avr xmega3.  At best it can be described as getting some boiler plate build code in order.

 

Patch #9543 by comparison which has sat neglected by the avr-libc maintainers for over six months is 16 Megabytes large.  THAT is EXTENSIVE support for AVR XMEGA3.  And it is NOT in avr-libc, and it seems no amount of begging will change that any time soon.  Net result, avr-libc does not support the features offered by mainline avr-gcc.  The feature disparity alone between avr-gcc and avr-libc creates the demand that it be forked and this whole conversation has proven to me that such a fork is desperately needed.   

 

I am honestly at a loss as to why this is such an issue. Patch 2544 is all well and good, it is what it is, and it is necessary.  But it isn't extensive support for xmega3, and by itself will not let anyone build working code with avr-gcc for the newer attinys that gcc supports.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

strontiumdog wrote:
Is that some kind of attempt to intimidate or shame me? 
Err no - are you perhaps a little over-sensitive? I was pointing out that if anyone knows Georg-Johan will as it's largely thanks to him we have such a good compiler these days.

Last Edited: Thu. Jul 18, 2019 - 11:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

strontiumdog wrote:
Is that some kind of attempt to intimidate or shame me? 
Err no - are you perhaps a little over-sensitive? I was pointing out that if anyone knows Georg-Johan will as it's largely thanks to him we have such a good compiler these days.

 

Ok, my mistake, seems that I was being over-sensitive.

 

I do not dispute his work, or it's value. In this case, however, the existing level of support for xmega3 is being overstated, its plain from the diff, anyone can see it.    But there does seem to be a resistance to new people wanting to improve the code and address its deficiencies.  And there is definitely no path to getting code merged into avr-libc upstream.  Certainly not one with any transparency.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As far as device support is concerned, the respective files were available but copyrighted. I will not propose patches containing copyrighted content (whoever hosts libc or whatever project). I am no advocat or legal expert and if Microchip prohibits improving tools that support their chips, then I respect that policy.
.
And neither do I want to re-invent wheels...
.
Device packs to augment X3 support are available, and my X3 extensions are the basis that they can be used as the multilib structure changed (and avr-libc does not support GCC multilib info like -print-multi-lib).

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
As far as device support is concerned, the respective files were available but copyrighted. I will not propose patches containing copyrighted content (whoever hosts libc or whatever project). I am no advocat or legal expert and if Microchip prohibits improving tools that support their chips, then I respect that policy. . And neither do I want to re-invent wheels... . Device packs to augment X3 support are available, and my X3 extensions are the basis that they can be used as the multilib structure changed (and avr-libc does not support GCC multilib info like -print-multi-lib).

 

So, the solution is NOT to include Atmel/Microchip code in avr-libc?  But force end users to include exactly the same files/code themselves, manually, in their programs?

 

In any event, the device support files from patch 9543 are autogenerated, and do not come from the packs.  They do not contain atmel/microchip copyrights.

However, even if they did there is no problem.  The atmel packs have the following license (taken from iotn816.h in my installed version of xc8):

 * Copyright (C) 2018 Atmel Corporation, a wholly owned subsidiary of Microchip Technology Inc.
 * All rights reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *   http://www.apache.org/licenses/LICENSE-2.0
 *

The apache license is compatible with the Modified BSD License, and is non restrictive.  In fact it grants more rights than the Modified BSD License, by giving patent rights.

 

Atmel/Microchip would have no basis legally or morally to prevent that code being included in avr-libc.  Microchip did not prohibit improving tools that support their chips by making files available under the apache2 license, they explicitly allowed it when they chose a license that says:

 

each Contributor hereby grants to You a perpetual, 
worldwide, non-exclusive, no-charge, royalty-free, 
irrevocable copyright license to reproduce, prepare 
Derivative Works of, publicly display, publicly perform, 
sublicense, and distribute the Work and such Derivative 
Works in Source or Object form.

 

All of that said, the maintainers of avr-libc are free to include and exclude whatever they like, for whatever reason they like, and I have no problem with that. It is, after all, their project to do with as they please.  I on the other hand have no such constraints.  If gcc ended up with Atmega4809 support and the most expedient way to get avr-libc3 to match that support that was to use apache licensed files from microchip, i would include them in a heartbeat, and without a second thought.  But thats just me.  I will also happily bring forward to my fork any changes made in the upstream avr-libc project.  I am just under no illusions that I have any means of getting any patches included into avr-libc, nor will i waste any effort trying. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Patch #9543 by comparison which has sat neglected by the avr-libc maintainers for over six months is 16 Megabytes large.  THAT is EXTENSIVE support for AVR XMEGA3.

 

I guess.  Did you notice whether there is anything "real" in there, or is it just  (mostly?) ~30 instances of program-generated .S and .h files generated from the Atmel XML, and the makefile/etc additions necessary to create them?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

Patch #9543 by comparison which has sat neglected by the avr-libc maintainers for over six months is 16 Megabytes large.  THAT is EXTENSIVE support for AVR XMEGA3.

 

I guess.  Did you notice whether there is anything "real" in there, or is it just  (mostly?) ~30 instances of program-generated .S and .h files generated from the Atmel XML, and the makefile/etc additions necessary to create them?

 

 

You are correct that the vast majority of bulk is autogenerated .S and .h files.  As is to be expected. 

 

In addition there is xmega3 versions of _PROTECTED_WRITE_SPM and changes to support eeprom on those devices and the necessary build system changes.

 

However, the largest most substantial part of the patch is the addition of devtools/gen-ioheader-atdf-avr8x.py

It is the workhorse which creates header files from atmel/microchip distributed .atdf files.  That is quite a large contribution (712 lines of python code) and makes the rest of it possible.  It will be a great utility to create headers for future processors as/if they gain support by avr-gcc.

 

Or to enhance the existing files while retaining full backwards compatibility.  For example, I write a LOT in assembler.  Sure I use C too, but I drop to assembler often as the need arises.  The standard headers have all these great enums for field values like:

/* SDA Hold Time select */
typedef enum TWI_SDAHOLD_enum
{
    TWI_SDAHOLD_OFF_gc = (0x00<<2),  /* SDA hold time off */
    TWI_SDAHOLD_50NS_gc = (0x01<<2),  /* Typical 50ns hold time */
    TWI_SDAHOLD_300NS_gc = (0x02<<2),  /* Typical 300ns hold time */
    TWI_SDAHOLD_500NS_gc = (0x03<<2),  /* Typical 500ns hold time */
} TWI_SDAHOLD_t;

But in assembler you don't have those constants all you get is this:

 

#define TWI_SDAHOLD_gm  0x0C  /* SDA Hold Time group mask. */
#define TWI_SDAHOLD_gp  2  /* SDA Hold Time group position. */
#define TWI_SDAHOLD0_bm  (1<<2)  /* SDA Hold Time bit 0 mask. */
#define TWI_SDAHOLD0_bp  2  /* SDA Hold Time bit 0 position. */
#define TWI_SDAHOLD1_bm  (1<<3)  /* SDA Hold Time bit 1 mask. */
#define TWI_SDAHOLD1_bp  3  /* SDA Hold Time bit 1 position. */

which is annoying and means I have to do a lot of copy pasting to my own headers to supplement the fact that field value definitions are missing when i build a .S file.  Not only is it tedious, its error prone.

 

But with the autogenerator, i can actually produce a section protected by a

#if defined (__ASSEMBLER__)

that is just all of these field values, represented as #defines instead of as an enum, so that they are equally and consistently usable from either C or Assembler.  Something the current headers sorely lack, in my opinion.

 

It is actually the thing i am working on now.  The next major patch will be to add these definitions for assembly compilations to the standard files.  Once I get it working for the xmega3 attinys I will explore the issues (if any) of doing the same for the rest of the devices.  The only concern I have at the moment of doing that is if older device headers match the definitions from .atdf files of those devices, or were they manually generated.  I know the xmega3 files are auto-generated and so I can be assured a new auto generated file won't clobber any manual addition. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the largest most substantial part of the patch is the addition of devtools/gen-ioheader-atdf-avr8x.py

It is the workhorse which creates header files from atmel/microchip distributed .atdf files.   It will be a great utility to create headers for future processors as/if they gain support by avr-gcc.

Ah.  I haven't even considered writing asm for any XMega parts, so it had not occurred to me that the new "higher-level" structure definitions used there would be problematic.
(It should have - I ran into a similar problem creating https://github.com/WestfW/Minima... - but that was more of an academic exercise, and I just "slightly automated it with EMACS keyboard macros.)

 

Will your program work with ARM-standard CMSIS XML description as well (um, '.SVD' files, I guess)?  My impression is that they're very similar to the .ATDF files, and ... if ever there were an architecture with "weak" assembly language support, it's those ARMs...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I haven't even considered writing asm for any XMega parts,

I have wink but I'm a REAL freak! I have a product that I have made a couple of thousands off written in ASM, it was much easier to do it that way for me.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

Will your program work with ARM-standard CMSIS XML description as well (um, '.SVD' files, I guess)?  My impression is that they're very similar to the .ATDF files, and ... if ever there were an architecture with "weak" assembly language support, it's those ARMs...

 

Just to clarify, the patch that contains the autogenerator was:

Written by Balint Cristian <cristian dot balint at gmail dot com>

I just took his patch, reviewed it and applied it and found it worked for me.  Which is what catalysed me to fork avr-libc for my own purposes.

 

As to will it work, sadly NO.  Both are XML hardware descriptions, but both have totally different schemas.  However you could use it as the basis for a .SVD parser.

 

js wrote:

I haven't even considered writing asm for any XMega parts,

I have wink but I'm a REAL freak! I have a product that I have made a couple of thousands off written in ASM, it was much easier to do it that way for me.

The xmega3's are actually pretty nice to code for in assembler.  They are only tiny's in name, the CPU is fully featured, unlike the reduced core attinys.  If the logic is straight forward, asm is no harder than C.  But if i was using a dynamically allocated B-Tree, i would use C.  Just depends on the logic, how important it be small/fast and how complex it is.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just pushed a new devtool to my avr-libc3 project.  Its an updated version of gen-ioheader-atdf-avr8x.py now called gen-ioheader-atdf.py  it is no longer restricted to xmega3 attiny and can generate headers for all devices found in an atpack.

 

In fact, to run it, you give it a source directory, and it will scan each and every atpack it finds, and generate headers for all devices contained within.  The goal is to allow easy updates of device headers when microchip release a new pack.  The program will eventually do more than generate headers.  It is also planned to automatically generate automake.am files for the io include directories so that maintenance of these numerous files is eased.

 

One significant enhancement over the existing header generator, is that it also generates defines equivalent to the device enum's for assembler use.

 

Its still a work in progress, currently all files are just dumped to the terminal as they are generated.  This makes it easy to test.  but its not how it will be ultimately.  One thing i discovered is there are numerous files which contain conflicting definitions, so i check for that and emit warnings if a #define would be emitted with the same name, but a different value.  So far I haven't been able to work out from the .atdf file any way to determine the difference between them.  Currently you get the first, and subsequent definitions are suppressed.

 

The end goal is for device headers for all devices to be generated automatically, the current device headers which are unlikely to be compatible will be retained and a define on the command line will let you choose the old (and for me unmaintained) legacy headers, or the new fully autogenerated headers.  At least for the handful of files i have looked at in detail no definitions seem missing for the older devices, although they likely have different names.  The advantage is however that everything will be consistent across all files, and an improvement in the header generation will be applied to all devices equally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

strontiumdog,  By your last post it looks like avr-libc3 should support mega4809, right?   The README.md file indicates the package only provides updates for tinys.  Can you confirm?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW wrote:

strontiumdog,  By your last post it looks like avr-libc3 should support mega4809, right?   The README.md file indicates the package only provides updates for tinys.  Can you confirm?

 

SprinterSB wrote:
Quote:

To add native support for ATmega4809 et al., you'll need to add a compiler addition to handle the different PM_FLASH_OFFSETs amongs the avrxmega3 devices (extension to specs files generation).

 

The answer is, Yes and No.  The current avr-libc3 does not support mega4809.  BUT i am working now on a new generator for io headers from microchip distributed .atdf files.  Once that is complete, there will be headers for the ATmega4809, etc in avr-libc3.  avr-libc3 will at that point have headers for EVERY atmel AVR chip that Microchip document via the .atdf files, auto-generated.  The existing manually created io headers will still be there but will be marked legacy and you can choose at build time if you want the old headers or the new ones (because they may not be 100% compatible with the manually created old io files).  The aim is to have every io header consistent with each other.

 

However, as SprinterSB says, thats only part of the problem.  There would also need to be support for them in GCC.  Currently GCC 9.1 doesn't know anything about ATmega4809.  It may be that the only thing needed is specs files, in which case, I could extract the specs directly from the .atpack files to redistribute with avr-libc3, OR i could auto generate new ones.  If it requires some actual internals of GCC to be modified, then that's beyond the scope of what I am working on.

 

Hope that answers the question.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just pushed some updates to my avr-libc3 project.

 

I have been working on a generator for io headers, so that every io header is generated from the microchip distributed .atdf files.

It seems to work and I have added it to my repo: https://github.com/stevenj/avr-libc3/blob/master/devtools/gen-ioheader-atdf.py

 

Its a python3 program, and it only needs the lxml library in addition to standard python3 libraries.

 

It may be useful to some outside of header generation, because it will automatically contact the microchip servers and download the very latest .atpack files for 8 bit AVR devices.  So it is a very easy way to stay up-to-date on those.  It has command line options to control this, and also inhibit header generation, so it could be used purely to get the latest atpack files if one wanted. 

 

I also pushed all of the IO headers i generate along with a modification to how io headers work in general.

I moved ALL existing io*.h files (except the base io.h) to <avr/legacyio/>  and created a legacyio.h file which has the enormous #if defined table to find these files.  It is a maintenance nightmare.  Firstly the io files have no regular naming, they just look "something" like the device name.  Secondly there is no way to autogenerate the names, hence making the monstrous #if defined table necessary.

 

I don't do that.  If you wanted those, they are still available, but AVR_LIBC_LEGACY_IO needs to be defined to 1 (and currently it is by default).

If it is 0 or not defined, then the name is generated from the __AVR_DEV_LIB_NAME__ definition that gcc 9.1 supplies for ALL targets it knows about.  The benefit is all io headers now have the name of the chip they define ("atmega32u4.h" for example)  which is a lot easier to remember and can be automatically generated.

Auto-generated headers is all well and good, but sometimes something is missing.  To facilitate manually adding to the headers i created a extraio directory.  it would contain files with the same names as in the io directory ("attiny816.h", etc) and manual extra definitions can be placed here, they will only get included if __AVR_EXTRA_IO__ is defined.  Otherwise they are ignored.

 

All this refactoring of the headers is currently untested, its just a first push.  It probably won't build because i am at least missing a Makefile.am file from the new io subdirectory.  That said, i am posting it now so if anyone has any feedback or suggestions, i can work on it while i work out the kinks in this.

 

Full repo at https://github.com/stevenj/avr-libc3

 

I forgot to mention, my generation includes more information that the headers provided by Microchip.

  1. I have a assembler section which has #defines for everything defined as a enum for C.  Allowing the same named definitions to be used in inline ASM as well as C.
  2. I generate full port pin definitions, so that PORTA0 or PA0 will work as expected for all devices.
  3. I compact IO structures, so you don't have tons of "reserved" 8 bit registers, wherever they are contiguous they are represented as a reserved array, which makes the structures a lot more readable.
    Example for ATxmega128d3, this:

    /* Event System */
    typedef struct EVSYS_struct
    {
        register8_t CH0MUX;  /* Event Channel 0 Multiplexer */
        register8_t CH1MUX;  /* Event Channel 1 Multiplexer */
        register8_t CH2MUX;  /* Event Channel 2 Multiplexer */
        register8_t CH3MUX;  /* Event Channel 3 Multiplexer */
        register8_t reserved_0x04;
        register8_t reserved_0x05;
        register8_t reserved_0x06;
        register8_t reserved_0x07;
        register8_t CH0CTRL;  /* Channel 0 Control Register */
        register8_t CH1CTRL;  /* Channel 1 Control Register */
        register8_t CH2CTRL;  /* Channel 2 Control Register */
        register8_t CH3CTRL;  /* Channel 3 Control Register */
        register8_t reserved_0x0C;
        register8_t reserved_0x0D;
        register8_t reserved_0x0E;
        register8_t reserved_0x0F;
        register8_t STROBE;  /* Event Strobe */
        register8_t DATA;  /* Event Data */
    } EVSYS_t;
    

    became:
     

    typedef struct EVSYS_struct
    {
        register8_t CH0MUX;      /* Event Channel 0 Multiplexer */
        register8_t CH1MUX;      /* Event Channel 1 Multiplexer */
        register8_t CH2MUX;      /* Event Channel 2 Multiplexer */
        register8_t CH3MUX;      /* Event Channel 3 Multiplexer */
        register8_t rsv_0x04[4]; /* RESERVED REGISTER BLOCK */
        register8_t CH0CTRL;     /* Channel 0 Control Register */
        register8_t CH1CTRL;     /* Channel 1 Control Register */
        register8_t CH2CTRL;     /* Channel 2 Control Register */
        register8_t CH3CTRL;     /* Channel 3 Control Register */
        register8_t rsv_0x0C[4]; /* RESERVED REGISTER BLOCK */
        register8_t STROBE;      /* Event Strobe */
        register8_t DATA;        /* Event Data */
    } EVSYS_t;
    

     

  4. my generator is fussy about emitting equal width columns of data which makes the files easier to read (i think)
  5. Not every field in the atdfs is defined, a lot are missing.  To help with using bitfields i detect these and emit things like this:
    #define TWI_SLAVE_ADDRMASK_ADDRMASK_gc(x) ((x<<1) & 0xFE)
    #define TC0_CTRLFCLR_CMD_gc(x) ((x<<2) & 0x0C)
    #define TC1_CTRLFCLR_CMD_gc(x) ((x<<2) & 0x0C)
    

    Which should make storing values into these fields a bit less tedious and error prone.

Last Edited: Sat. Aug 10, 2019 - 08:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a hint, instead of parsing the html on the pack server, there's a index.idx file on the root that follows the Keil CMSIS spec which is a bit safer to parse... (At least it won't break the next time we're changing the html page).

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the work.  I'm not sure I got everything above, but I have used the previous version to translate the atdf to avr/iom*.h files.

I have put together my own sh script to run the converter on each atdf file in the pack.   I use the following to match atdf name to .h name.

It misses a couple (ATmega16HVBREVB.atdf and ATmega32HVBREVB.atdf).

for dev in $devs; do
  file=$devs_dir/$dev/device-specs/specs-$dev
  x=`awk '/D__AVR_DEV_LIB_NAME/ {
  	if ($1 != "#") { sub("-D__AVR_","",$1); sub("__","",$1); print $1 }
	}' $file`
  y=`awk '/D__AVR_DEV_LIB_NAME/ { 
  	if ($1 != "#") { split($2,f2,"="); print f2[2] }}' $file`
  z=`awk '/D__AVR_DEV_LIB_NAME/ { 
  	if ($1 != "#") { split($3,f3,"="); print f3[2] }}' $file`
  if [ -f $pack_dir/atdf/${x}.atdf ]; then
    $gen_iom $pack_dir/atdf/${x}.atdf > $dest_dir/include/avr/io${z}.h;
  else
    echo "not found: ${x}.atdf"
  fi
done

The file io.h will include the right stuff for me.  I'm compiling C and assembly for mega4809 with gcc 8.3.0.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:
Just a hint, instead of parsing the html on the pack server, there's a index.idx file on the root that follows the Keil CMSIS spec which is a bit safer to parse... (At least it won't break the next time we're changing the html page).

 

Thanks for the hint. 

 

My parsing is a bit simplistic, i don't really parse the html, I just do a regex lookup in the page text for 'data-link="(.*atpack)"'.  Which produces a list of files with .atpack extensions, and I then use string matching to determine if its AVR 8 bit data, or something else.  It seems to work for now.  But yes, if the token changed from 'data-link=""' OR the file name pattern changed, it would certainly break.

 

I looked at the index.idx file.  I don't see any links to .atpack files.  The closest I get is

<pdsc url="packs.download.microchip.com" name="Microchip.ATmega_DFP.pdsc" version="2.0.12" atmel:name="ATmega_DFP" atmel:name.gz="Microchip.ATmega_DFP.pdsc.gz">

From that information I could manufacture a atpack file link as:

url + name (striped of pdsc extension) + version + ".atpack"

 

Is that reliable?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jupp, that's reliable. See https://www.keil.com/pack/doc/CMSIS/Pack/html/packIndexFile.html for the details.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW wrote:

Thanks for the work.  I'm not sure I got everything above, but I have used the previous version to translate the atdf to avr/iom*.h files.

 

 

Well, i am trying to keep things simple for the generator and reduce or eliminate busy work maintenance.  So, I am relying on the __AVR_DEV_LIB_NAME__ to supply the actual device name, and then making sure the io headers match it.  It means I no longer need to manually maintain a very large set of #if defined/#include preprocessor directives.  My ultimate goal is just regenerate the io headers, job done.   If __AVR_DEV_LIB_NAME__ is defined appropriately the header will be found.  gcc 9.1 does define it for all the devices it currently knows about (which isn't mega4809).

 

Including the attiny files I added manually earlier, in avr-libc3 there are 267 io headers.  I am currently generating 272 io headers.  I don't want to have to go into io.h and work out what those 5 extra headers are, work out what gcc defines for them, and then add those #if define and #include lines.  So i just use __AVR_DEV_LIB_NAME__ which will always find the correct header, if it exists.

 

PS. I am not using mega4809 and don't have any to test with, BUT, how did you get gcc 8.3 to work with mega4809, SprinterSB mentioned something above, is it just that gcc needs the appropriate spec file?  Or did you need to do something else?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What you need from the tools is core support, which is avrxmega3, or if it doesn't support that then avrxmega2 will do with potential minor performance loss.
.
The rest is sugar around it: feed the right options into the tools (or use a specs file for convenience), device header (or write home-brew SFR defs for the ones you need), crt (or -nostartfiles and cook-up your own), devicelib (or -nodevicelib if you don't need one, or ad-hoc code). That's it.
.
avr-libc comes with the required multilib-variants, except in the case when you are ambitious and want double64 and / or long-double64 variant(s). In that unlikely case, you need avr-libc extensions and dynamic (at configure-time) multilib adjustment, for some of which there are patches, for others there's just issues that point out what's needed.
.
The specs file that the compiler generates for ATmega4809 is backwards compatible, but asserts that avr-libc and binutils support the core.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

strontiumdog wrote:

PS. I am not using mega4809 and don't have any to test with, BUT, how did you get gcc 8.3 to work with mega4809, SprinterSB mentioned something above, is it just that gcc needs the appropriate spec file?  Or did you need to do something else?

 

Oops.  I guess I never responded.

1) I copied the include,  lib files  and spec files from the device pack to /opt/avr. 

2) I modified the spec files to find the right stuff.

3) I used -mcpu=atmega4809 -B/opt/local/avr/packs/1.3.300/ where that directory looks like

$ ls /opt/local/avr/packs/1.3.300
atdf/  device-specs/  include/	lib/

I did post everything in a thread a while ago.  I don't want to look for it now.   Here is the script to update the specs:

 

#!/bin/sh
#
# pack-xfer -
#
# Transfer files from microchip dev-pack to local install.
# This will tweak includes to allow use with assembler and tweak dev-spec
# files to be able to find the crt and lib files.
# What about includes?

# v190825a - MattRW

# gen_iom is avr-lib3/devtools/gen-ioheader-atdf-avr8x.py
# It generates iom1234.h files from atdf files with hooks
# for allowing use in assembly code.  That's good news.
gen_iom=/opt/local/bin/gen-iom

# Define source and target directories.
pack_dir=/var/tmp/mwette/atmel_DFP-1.3.300
dest_dir=/opt/local/avr/packs/1.3.300
echo $#
if [ $# -eq 2 ]; then
    pack_dir=$1
    dest_dir=$2
elif [ $# -eq 1 ]; then
    pack_dir=`pwd`
    dest_dir=$1
else
    echo 'usage: pack-xfer <src-dir> <dest-dir>'
    echo '       pack-xfer <dest-dir>'
    exit 1
fi
if [ ! -d $pack_dir/gcc/dev ]; then
    echo "*** bad pack src: $pack_dir"
    exit 1
fi

# Generate list of devices.
devs_dir=$pack_dir/gcc/dev
devs=`(cd $devs_dir; ls)`


# Start building destination.
mkdir -p $dest_dir


# Install include files.
mkdir -p $dest_dir/include
(cd $pack_dir/include; tar cf - . ) | (cd $dest_dir/include; tar xf -)
for dev in $devs; do
  file=$devs_dir/$dev/device-specs/specs-$dev
  aname=`awk '/D__AVR_DEV_LIB_NAME/ {
	 if ($1 != "#") { sub("-D__AVR_","",$1); sub("__","",$1); print $1 }
	 }' $file`
  lname=`awk '/D__AVR_DEV_LIB_NAME/ { 
	 if ($1 != "#") { split($3,f,"="); print f[2] }}' $file`
  if [ -f $pack_dir/atdf/${aname}.atdf ]; then
    $gen_iom $pack_dir/atdf/${aname}.atdf > $dest_dir/include/avr/io${lname}.h;
  else
    echo "not found: ${aname}.atdf"
  fi
done


# Install device-spec files.
# *asm_gccisr:
#         %{!mno-gas-isr-prologues: -mgcc-isr}
tweak_spec () {
    file=$1
    dev=$2
    mcu=`sed -n -e 's/\t-mmcu=//p' $file`
    ed -s $file >/dev/null << EOF
/\*avrlibc_startfile:/
+1
d
i
	$dest_dir/lib/crt$dev.o%s
.
/^%rename link
i
%rename asm old_asm

*asm:
	%(old_asm) -mgcc-isr

.
/\*link:
+1
a
 -L$dest_dir/$mcu
.
-1
j
wq
EOF
}

for dev in $devs; do
  file=$devs_dir/$dev/device-specs/specs-$dev
  temp=/tmp/$file.$$
  cp $file /tmp/$temp
  tweak_spec $temp $dev
  rm /tmp/$temp
done


# Install lib files.
mkdir -p $dest_dir/lib
for dev in $devs; do
  for dir in `ls $devs_dir/$dev`; do
    case $dir in 
      device-specs) ;;
      *) (cd $devs_dir/$dev; tar cf - $dir) | (cd $dest_dir/lib; tar xf -) ;;
    esac
  done
done

# --- last line ---

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

here is the other thread: gcc-libc-atmega4809

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Matt, there's no need to rename the asm spec. You can just add asm_gccisr as indicated by the comment. That spec is part of the asm spec, cf specs.h in the avr backend of GCC.
.
This is not the case for older versions, hence asm_gccisr will have no effect there.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
Hi Matt, there's no need to rename the asm spec. You can just add asm_gccisr as indicated by the comment. That spec is part of the asm spec, cf specs.h in the avr backend of GCC. . This is not the case for older versions, hence asm_gccisr will have no effect there.

 

Yup.  I should go back and clean that up.