Considering upgrading from AS 4 to AS 6. Any issues?

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

I'm thinking of finally upgrading from AS 4 to AS 6 for my ATTiny and Xmega development. I've been holding off since there were a number of problems with AS 5 and, initially, AS 6. I haven't been keeping up so I thought I'd see if there was anything I should be aware of beyond what's listed in the Known Issues section of the release notes. I use AVR One and ICCAVR. Thanks.

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

AS6 is much stable than AS5. I think, it should be fine to upgrade to AS6. For safety, take the backup of your projects before converting into AS6 projects.
After converting the projects, you can work on your projects without any issue.

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

Ideal case for me would be to try it for a while in a virtual environment like vmware or virtual box so that you can keep working with both versions and make the transition in the main OS when you feel comfortable .

Alex

"For every effect there is a root cause. Find and address the root cause rather than try to fix the effect, as there is no end to the latter."
Author Unknown

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

You can easily run AS4 and AS6 on the same machine. The only "issue" is that each has their preferred firmware for Atmel devices such as AVRISPmkII, Dragon, JTAGICEmkII, etc. So if you use one of these you may see Studio asking you to change the firmware each time you switch between using AS4 and AS6.

AS6 is definitely "stable" now and apart from answering questions in the AS4 forum I find myself only using AS6 now.

Also there used to be problems with Atmel's build of the avr-gcc compiler but the one now in AS6 SP2 is good enough that it's a good alternative to WinAVR. You get to move from 4.3.3 to 4.6.2 by using it too.

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

One important thing to note: importing an AS4 project into AS6 should retain the old toolchain settings, so you'll still be building with WinAVR. If you want to uninstall WinAVR later and/or use the much newer toolchain, you'll need to set the project's toolchain selection to "Native". See this new video explaining the procedure:

https://www.youtube.com/watch?v=...

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

In the case you use the C compiler, read the release notes of respective GCC release series, in particular about caveats.

And read the Atmel release notes (if they exists) and what they changed in addition and on additional caveats.

Thus you want to read the release notes for 4.4, 4.5 and 4.6, and maybe also the bug lists on open problems.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
In the case you use the C compiler, read the release notes of respective GCC release series, in particular about caveats.

And read the Atmel release notes (if they exists) and what they changed in addition and on additional caveats.

Thus you want to read the release notes for 4.4, 4.5 and 4.6, and maybe also the bug lists on open problems.

In particular, there was a thread on this forum last year about a problem performing signed 16bit * 16bit = 32bit multiplication, for example:

long __attribute__((noinline,noclone))
test (int a, int b)
{
    return (long) a * b;
}

int main (void)
{
   if (test (1, -32768) != -32768L)
     abort()
   return 0;
} 

Compiling this code with optimization -O2 exposed the bug.

Atmel's toolchain was omitting a required sign extension step while computing the inner and outer products. The bug occurs in the libgcc.a routine __mulhisi3.

I've checked Atmel's open source repository for their flavour of the 8-bit GNU toolchain - both toolchain versions 3.4.1 and 3.4.1.830. The defective sign extension bug is present in the gcc-fixedpoint-2-4-2010.patch file incorporated in both of these toolchains.

To the best of my knowledge, the latest and greatest version of the Atmel toolchain included with Atmel Studio 6 SP2 is version 3.4.1.830. Therefore, I am afraid that you cannot trust the latest and greatest version of Atmel Studio (or any previous version of Atmel/AVR Studio 5.x and 6.x, for that matter) to perform signed 16bit * 16bit = 32bit multiplication.

I'm actually in the middle of re-evaluating the current status of the Atmel toolchain in this respect before giving a recommendation to my employer about whether or not it is safe for us to migrate from Studio4/WinAVR to Studio6.

My initial tests show that the bug is, indeed, still present in Atmel Studio 6 SP2.