WinAVR20100701 first impressions

Go To Last Post
57 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, Atmel does not call it this way, but I now will.

Downloaded the bundle from http://distribute.atmel.no/tools... (a whopping 265MB) .

I am not interested in the diluted stuff, so I haven't install it as intended. It is a normal zip, thanks heavens, so instead I found the fairly standard WinAVR installation within it, under as4e-ide\plugins\com.atmel.avr.toolchains.win32.x86_3.0.0.201007011157\os\win32\. Unzipped to a suitable directory (say, WinAVR20100701).

Running [WinAVR20100701]/bin/avr-gcc.exe on a .c source ends with cc1.exe complaining of missing libgmp-3.dll. This .dll is in [WinAVR20100701]/bin/ (whereas cc1.exe is in [WinAVR20100701]/libexec/gcc/avr/4.4.3/). Okay I did not properly install, paths are missing - added a path to [WinAVR20100701]/bin/, but that did not help. I am not good in the Win path games, so I gave up and simply copied libgmp-3.dll (and libmpfr-1.dll which also appears to be needed) into [WinAVR20100701]/libexec/gcc/avr/4.4.3/ . That did the trick - now it appears I can compile.

--version gives

avr-gcc (atmel-201007011147CEST-(mingw32_special)) 4.4.3 

and avr-libc is of course 1.7.0.

I played a bit compiling simple examples I have here and everything appears to work.

Enjoy!

JW

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

And the first bug report:

Trying to set target to -mmcu=atmega2561 (or 2560) results in linker complaining of duplicate __vectors and __bad_interrupt in the respective crt file:

c:\wek\StationMaster\SML\tmp>"c:\Program Files\Atmel\AVRTools\WinAVRBeta\bin\avr
-gcc" k.c -Os -DF_CPU=14745600UL -mmcu=atmega2560 -Wa,-adhlns=k.lst -Wl,-Map=k.m
ap,--cref -o k.elf k1.c
c:/program files/atmel/avrtools/winavrbeta/bin/../lib/gcc/avr/4.4.3/../../../../
avr/lib/avr6/crtm2560.o: In function `__vectors':
/home/tools/hudson/workspace/avr8-gnu-toolchain/src/avr-libc/crt1/gcrt1.S:52: mu
ltiple definition of `__vectors'
c:/program files/atmel/avrtools/winavrbeta/bin/../lib/gcc/avr/4.4.3/../../../../
avr/lib/avr6/crtm2560.o:/home/tools/hudson/workspace/avr8-gnu-toolchain/src/avr-
libc/crt1/gcrt1.S:52: first defined here
c:/program files/atmel/avrtools/winavrbeta/bin/../lib/gcc/avr/4.4.3/../../../../
avr/lib/avr6/crtm2560.o: In function `__vectors':
/home/tools/hudson/workspace/avr8-gnu-toolchain/src/avr-libc/crt1/gcrt1.S:52: mu
ltiple definition of `__bad_interrupt'
c:/program files/atmel/avrtools/winavrbeta/bin/../lib/gcc/avr/4.4.3/../../../../
avr/lib/avr6/crtm2560.o:/home/tools/hudson/workspace/avr8-gnu-toolchain/src/avr-
libc/crt1/gcrt1.S:52: first defined here

JW

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

Jan,

By your own admission "I did not properly install" so are you really surprised if you get library conflicts etc?

BTW as previous WinAVRs have shown it is NEVER a good idea to install WinAVR into a directory with spaces in the pathname - I'm afraid "Program Files" does.

Cliff

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

clawson wrote:
By your own admission "I did not properly install" so are you really surprised if you get library conflicts etc?

If you look at that zip, there is in fact no installation - you apparently should simply unzip it and run. So I did nothing wrong.

I guess if you run it through eclipse it will perform some path magic or run cc1 directly avoiding the "driver" avr-gcc program (thus covering the dll/path problem); but I doubt it would tweak the crt files. I believe that's a genuine bug - other targets link just fine. If anybody is willing to pull out the whole shebang, I would be grateful if (s)he would report back on this issue.

clawson wrote:
BTW as previous WinAVRs have shown it is NEVER a good idea to install WinAVR into a directory with spaces in the pathname - I'm afraid "Program Files" does.

Not knowing it is a problem I merrily install all WinAVRs under Program Files/something. I expect some tweaking with escaped spaces or putting the path into doublequotes, but so far everything worked. I admit it is not the best situation but I believe none of the problems I described above are caused by this.

JW

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

Quote:

but so far everything worked.

Ah then I think the problem must actually be in Studio (which I'm guessing you of all people don't use as an IDE ;-)). I think it's auto-generated Makefiles sometimes include a path to tools or something but don't quote delimit it so things tend to stop at the "Program "

I'll pull this distribution and have a "play" later.

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

wek wrote:
I guess if you run it through eclipse it will perform some path magic or run cc1 directly avoiding the "driver" avr-gcc program (thus covering the dll/path problem); but I doubt it would tweak the crt files. I believe that's a genuine bug - other targets link just fine. If anybody is willing to pull out the whole shebang, I would be grateful if (s)he would report back on this issue.

AVR32 Studio will as you've guessed determine the full path of the toolchain binaries and use this for the internal builder. When using the makefile builder, the various utilities has to be in the system path.

Note that the builds announced is of pre-release quality. This is in particular true for the 8-bit toolchain which is only a part of AVR32 Studio because as of the upcoming release the toolchains will be released together.

Note that simply unzipping AVR32 Studio and running the executable is a completely valid way of using the application. The only modifications we need to do to the operating system is to add USB drivers for Windows and udev rules to Linux.

The missing DLL is a bug.

Last Edited: Fri. Jul 2, 2010 - 11:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

torkildr wrote:
AVR32 Studio will as you've guessed determine the full path of the toolchain binaries and use this for the internal builder. When using the makefile builder, the various utilities has to be in the system path.

I see; however, I guess I am not the only one who will want to use the bare toolchain stripped of the ballast.

torkildr wrote:
Note that the builds announced is of pre-release quality. This is in particular true for the 8-bit toolchain which is only a part of AVR32 Studio because as of the upcoming release the toolchains will be released together.

I know. I am not complaining.

JW

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

wek wrote:

I see; however, I guess I am not the only one who will want to use the bare toolchain stripped of the ballast.

Toolchains will (also) be released separately as soon as they are ready.

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

torkildr wrote:
wek wrote:

I see; however, I guess I am not the only one who will want to use the bare toolchain stripped of the ballast.

Toolchains will (also) be released separately as soon as they are ready.

Looking forward to it :-)

Jan

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

As for the linking error: appears to be bug in avr-gcc (the driver program). When invoking avr-ld directly, it links just fine. It appears that the driver invokes the linker with listing crtm2560.o (crtm2561.o) twice.

m128 and m8 appear unaffected, I did not try other targets.

The workaround is to link through direct invocation of the linker.

JW

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

I did an overwrite of the winavr toolchain folder with the beta atmel gcc 4.4.3 and it works in avrstudio.
I found that the delay function the don't work as it should but they are: delay _delay_ms() makes 4times shorter delay and the _delay_us() ~30% longer delay!

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

Quote:

I found that the delay function the don't work as it should but they are: delay _delay_ms() makes 4times shorter delay and the _delay_us() ~30% longer delay!

Sounds like you are using them wrong then - there is a very minimal error in their use (esp. _us at the bottom end of its range) but it's in the order of a fraction of a percent - not 30%. Were you perhaps passing a variable as the delay length (the manual tells you this is verbooten) or did you maybe not have the optimiser switched on? (again the manual warns against this)

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

DieCore wrote:
I did an overwrite of the winavr toolchain folder with the beta atmel gcc 4.4.3 and it works in avrstudio.
I found that the delay function the don't work as it should but they are: delay _delay_ms() makes 4times shorter delay
This is indeed a bug in , __builtin_avr_delay_cycles() is called incorrectly with the number of loops rather than number of cycles (the former is 4x smaller as there are 4 cycles per delay loop).

I suspect the other one will be similar but have no time to investigate it further at this moment.

Thanks for letting know.

JW

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

Apologies to DieCore - wonder who was behind the addition of the _builtin_delay_cycles() support? It's not clear from the online CVS or the Savannha bug tracker (except that the work was committed by Joerg - but I'm not convinced it was instigated by him)

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

That's not that important now. The real question is, who is going to post a bug report?

JW

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

I added a bug report for the delay routines:
https://savannah.nongnu.org/bugs/index.php?30363

I included (but didn't test) a proposed fix.
The reason I didn't test it yet, is I want to get positive feedback from the developers on how to round the cycle counts, at which point I'll fully test it and even update the doxygen documentation.

--- bill

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

Well, a couple of cycles goes into the function invocation (more precisely, into the registers loading) anyway, so I'd be not really that concerned about the rounding...

... but the documentation might perhaps say something about providing a delay of *at least* xxx us/ms, so that the users won't expect absolute precision.

JW

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

wek wrote:
Well, a couple of cycles goes into the function invocation (more precisely, into the registers loading) anyway, so I'd be not really that concerned about the rounding...

... but the documentation might perhaps say something about providing a delay of *at least* xxx us/ms, so that the users won't expect absolute precision.

JW

I don't believe your comment on the the additional overhead of register setup is correct for the new code which is using much different inline cycle wasting delay code and does not use the basic delay loops.

What I have seen when using the new __builtin_delay_cycles()
or Hans Heinrich's delay_x project code which eventually uses his own internal delay_cycle() routine,
is the actual final number of cycles delayed, should be *exactly* the number of cycles requested. They use all sorts of various "do nothing" instructions that are all accounted for to ensure that the final number of cycles is exactly the number of cycles requested.
At this point Han's code seems to generate slightly smaller delay_cycle code due to using different instructions to get the delays than the compiler __builtin_delay_cycles() function.
Funny huh? How often does that happen? Usually the
compiler uses the best instructions possible.

Converting from "wall clock time" to MPU clock cycles always involves having to round the requested delay to a cycle boundary and how that cycle rounding is done can be a very big deal.
In certain situations, it can be the difference between the code that uses these delay functions working and not working.

IMHO one of the biggest uses for these types of inline busy/spinloop delay functions is for hardware setup timing delays as there is no other alternative.

Hardware setup type delays usually need a delay of "at least as long" as a certain amount of time. i.e. longer is ok but shorter runs the risk of violating the timing enough to where there is a malfunction.

Typically for other uses of these delay routines, the
rounding direction is not critical. So my assumption was that in the absence of being able to specify how the rounding works, rounding up makes the most sense as it makes the functions usable for low level hardware setup time delays.

I do totally agree that the documentation needs to reflect how the code does its delays.
In fact, I believe more people would have been concerned with the previous code that used the basic delay loops if it had been documented how it really worked.

So if the avrlib C developers agree on moving the delay routines forward with delays of "at least as long" as requested, I'll be happy to update and expand the doxygen documentation to reflect this and even provide specific examples including certain "gotchyas" to watch out for.

--- bill

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

Jan,

How did you find the distro linked in the first post? I just tried to download it but get a not found error so I'm wondering if there's a newer version - but how to find it?

Cliff

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

Ah that explains it - it's moved on from build 688 to 702

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

And it's probably not the final release number yet.

But any feedback is useful.

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

I've followed the above directions and can run avr-gcc --version and get the appropriate results indicated above. I've added the new 20100709 folder to the windows path instead of 20100110. But when I open AvrStudio, it still only sees 20100110.

I renamed 20100110 to XXX20100110 then reopened AS4. It then says that it can't find WinAVR. If I then tell the project to use the 20100709 folder, it will not sucessfully compile the project.

Has anyone else gotten AS4 to use the newer WinAVR version. The latest beta suggests it's version 20100709 but --version shows AVR_Toolchain_3.0_201007081300

Jim M., Rank amateur AVR guy.

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

AS4 "finds" WinAVR by a key it puts in the registry. My money is on th fact that this beta release does not set that registry key - hence AS4 will not fid it automatically.

However it's pretty easy to switch GCC versions for a project in Studio. Under Project-ConfigOptions go to the 5th tab - "Custom options" and you'll see the bottom two fields in the dialog allow you to set a path to avr-gcc.exe and make.exe - just untick the "use WinAVR" box then point these two at the right place - the rest of the toolchain will be found relative to these.

The other way might be to rename the old "WinAVR" out of the way then use the MS-DOS command MKLINK to make a WinDOS style softlink from the existing WinAVR to where the new toolchain is located. For example:

C:\>ren WinAVR-20100110 oldWinAVR-20100110

C:\>mklink /D WinAVR-20100110 D:\downloads
symbolic link created for WinAVR-20100110 <<===>> D:\downloads

C:\>dir \WinAVR-20100110\*.txt
 Volume in drive C is ACER
 Volume Serial Number is C6B0-75D7

 Directory of C:\WinAVR-20100110

05/05/2009  16:08             1,022 3.txt
29/07/2010  10:50             2,990 adc.txt
08/05/2009  11:07             3,879 apr.c.txt
27/07/2009  11:49             5,506 asm (2).txt
05/08/2009  10:13             1,516 ccpexample.txt
21/05/2009  16:00             2,509 Compiler.txt
04/08/2009  10:39             1,286 Example for CCP.txt
28/04/2009  08:59               974 filter.txt
18/06/2010  18:28            10,557 Firmware_1_0.txt
28/04/2009  09:08             7,419 interrupt.txt
16/05/2009  16:18             3,345 new test.txt
07/05/2009  14:30             4,851 New Text Document.txt
12/05/2009  14:08             1,217 problem.txt
15/04/2009  09:32            70,057 RFR09.txt
26/05/2009  12:05             2,342 RTC_arrows.txt
16/05/2009  15:11             5,210 SHT11sensor.txt
26/08/2010  17:06            48,991 SMain_Forum.lss.txt
26/08/2010  16:47            38,206 SMain_Forum.lst.txt
01/06/2009  15:36             1,697 st_kh.txt
05/06/2009  13:16             3,424 test.txt
23/04/2010  16:56            21,839 Text Document.txt
              21 File(s)        238,837 bytes

In that I have replaced the previous \WinAVR20100110 with my D:\downloads directory (as the DIR output demonstrates). Also:

C:\>dir winav* /ad
 Volume in drive C is ACER
 Volume Serial Number is C6B0-75D7

 Directory of C:\

31/08/2010  13:19         WinAVR-20100110 [D:\downloads]

PS just use:

RD Symlink_name

to delete a symlink to a directory.

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

Thanks. I'll give that a try.
One thing is that the "new" WinAVR doesn't have a "utils" directory. The make.exe file in the int bin folder, not utils/bin.
I try a few things later.

Jim M., Rank amateur AVR guy.

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

Quote:

One thing is that the "new" WinAVR

As it's an alpha release I'm waiting until at least they get to beta before looking at it - there's already been too many horror stories about its code generation to consider using it seriously. And there haven't been too many new AVR model releases since 20100110 so you aren't really missing out on anything by using it.

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

clawson wrote:
Quote:

One thing is that the "new" WinAVR

As it's an alpha release I'm waiting until at least they get to beta before looking at it - there's already been too many horror stories about its code generation to consider using it seriously. And there haven't been too many new AVR model releases since 20100110 so you aren't really missing out on anything by using it.

You're probably right. Sometimes beta is bad enough. Alpha is scary some times. 20100110 has been working fine for me thus far. I was just hoping to get the Tiny10 files.

Jim M., Rank amateur AVR guy.

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

I woud not have thought avr-gcc woud ever support Tiny10 (and t4/5/9). It needs the entire code generation model changed to only use 16 rather than 32 registers so is not just a case of "add this months new AVRs" like almost all previous model additions to the toolchain.

Where have you read that avr-gcc has or ever will have support for the brain-dead tinys? Given their flash size I'd have thought most users would be using Asm not C and for those that want C I know CV supports them (because it's designed to constrain register usage) and I think maybe IAR will.

Edit: this from October 2009:

http://www.mail-archive.com/avr-...

Edit2: seems IAR does have support:

http://www.iar.com/website1/1.0....

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

I thought I read that the Tiny10 would be supported in the release after 20100110. Also, there's a Tiny10 folder in the 20100709 toolchain referred to earlier.

Jim M., Rank amateur AVR guy.

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

By default AS4 uses 20100110 on my machine.
I created a new GCC project for the Tiny10. For this project I changed the paths to the avr-gcc and make exe files in the project config.
Pasted in the new c file the c code from CV (with a few changes) and hit F7.

Build started 31.8.2010 at 11:53:37
avr-gcc  -mmcu=attiny10 -Wall -gdwarf-2 -std=gnu99      -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT JM-PhD-C1_Tiny10.o -MF dep/JM-PhD-C1_Tiny10.o.d  -c  ../JM-PhD-C1_Tiny10.c
avr-gcc -mmcu=attiny10 -Wl,-Map=JM-PhD-C1_Tiny10.map JM-PhD-C1_Tiny10.o     -o JM-PhD-C1_Tiny10.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  JM-PhD-C1_Tiny10.elf JM-PhD-C1_Tiny10.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex JM-PhD-C1_Tiny10.elf JM-PhD-C1_Tiny10.eep || exit 0
avr-objdump -h -S JM-PhD-C1_Tiny10.elf > JM-PhD-C1_Tiny10.lss

AVR Memory Usage
----------------
Device: attiny10

Program:     514 bytes (50.2% Full)
(.text + .data + .bootloader)

Data:          0 bytes (0.0% Full)
(.data + .bss + .noinit)


Build succeeded with 0 Warnings...

Jim M., Rank amateur AVR guy.

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

Learn something new every day.

I guess that as Atmel have taken on the official maintenance of the toolchain they would have to include support for even the brain-dead AVRs

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

Hmmm... Maybe we will finally get rid of the R1 for the Zero register headache.

Regards,
Steve A.

The Board helps those that help themselves.

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

clawson wrote:
Learn something new every day.

I guess that as Atmel have taken on the official maintenance of the toolchain they would have to include support for even the brain-dead AVRs

One would hope so. It's their product, they SHOULD support it with something other than "learn assembly".
Over all I'm pretty pleased.

Jim M., Rank amateur AVR guy.

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

Quote:

It's their product,

No it isn't - the copyright of GNU software is held by the Free Software Foundation isn't it?

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

clawson wrote:
Quote:

It's their product,

No it isn't - the copyright of GNU software is held by the Free Software Foundation isn't it?

Oh, I meant the Tiny10 is their product. If they've taken over management of WinAVR then they should support their own chips.

Jim M., Rank amateur AVR guy.

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

Koshchi wrote:
Hmmm... Maybe we will finally get rid of the R1 for the Zero register headache.
Why is it a headache, Steve? Is it less efficient than "creating" an ad-hoc zero register whenever needed?

Jan

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

I did not mean "get rid of the zero register", I meant "get rid of the requirement to use R1 for the zero register".

Regards,
Steve A.

The Board helps those that help themselves.

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

Quote:

Maybe we will finally get rid of the R1 for the Zero register headache.

Wouldn't that create a "everybody rebuild your libraries!" pain in the behind?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:
Quote:

Maybe we will finally get rid of the R1 for the Zero register headache.

Wouldn't that create a "everybody rebuild your libraries!" pain in the behind?
Well it surely would be fun enough, but I still miss the cause of the headache.

If Steve wants to retain a dedicated zero register, why is R1 a wrong one? Because it gets in way of mul-s and spm? I can't think of other reason - all registers below R16 were created equal (except of the above), weren't they? Or does he suggest to use one of the precious R16+ regusters? What would be the benefit of that?

Jan

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

Quote:
Because it gets in way of mul-s and spm

Regards,
Steve A.

The Board helps those that help themselves.

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

Hi All,

Let's see if I can address the latest spate of issues above.

1. I'll look into how AVR Studio 4 finds the AVR Toolchain. That looks like it could be a problem for people.

2. Yes, the version string looks very different. This is not WinAVR, it is a different product, with a different version scheme.

3. Yes, it will contain limited C language support for the ATtiny10 family (ATtiny10/4/5/9/20/40). "Limited" in this sense means that there is no support yet from avr-libc. You don't get C standard library functions for these chips yet. However, we have plans for avr-libc support in the future. And, believe it or not, we have had customer requests for C language support for ATtiny10 family, specifically for ATtiny40 which has a bit bigger sized flash. I'm a bit surprised about it myself. But, it is what it is.

4. Yes, R1 as a zero constant is a big pain. That register was selected as part of the ABI a long, long time ago before the MUL instructions were added to the instruction set. Hindsight is always 20/20. So, in retrospect, that register should not have been chosen. But the AVR port of GCC was put together by outside volunteers who didn't know Atmel's chip road map. I have it on our todo list to *eventually* change the ABI to be more efficient. I stress the word "eventually" because it is a very big task as it changes binutils, gcc, avr-libc, and it will break backwards compatibility. If we do this, then I want to make sure that it is actually a win on creating smaller code size. I don't yet have a timeline for this particular project, as we have quite a backlog of higher priority items to get to first. However, I am hoping that perhaps we could start working on this sometime in late 2011. But don't hold me to it.

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

Newest Beta shows 20100914. Just FYI.

Jim M., Rank amateur AVR guy.

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

Anybody sampled the "official" issue of "AVR Toolchain"?

I gave it a shot but am disappointed by the mess.

Bloated (installator is 91MB of download, inflates during install to 220M if you omit the AVR32 tools (otherwise it's over 300M): unnecessary lengthy changelogs and other files. Documentation split to (at least) 2 separate directories. The installator has the same version number in its name than the current version on the beta site ("3.0.0.240"), date stamps of files are 09/09/2010 (I did not download and install the file from beta site but JimmyM reported 20100914 in the post above), avr-gcc --version writes "AVR_Toolchain_3.0_149".

I did not investigate further.

JW

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

wek wrote:

I gave it a shot but am disappointed by the mess.
I am most annoyed by the name.

I can already imagine the hundreds of questions in the future, when people ask here where to find the AVR gcc compiler. Because people will have a hard time to figure out that the "AVR Toolchain Installer Software" is the compiler (and some more stuff).

What is wrong with just calling that thing the "AVR[8|32] GCC Compiler for Windows" or the "AVR[8|32] GCC Compiler for AVR Studio"? (select 8 or 32 as needed)

I don't think that people will be surprised to get an installer when they download Windows software. I don't think one needs to tell people that they get software when they download software. I don't think "toolchain", while technically correct, is the best way to indicate a compiler. And I think telling them which compiler it is (gcc) isn't too dumb an idea.

Stealing Proteus doesn't make you an engineer.

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

Partially, I agree.

Actually, I'd call it WinAVR.

It took some time to push through that THIS is the name for gcc-and-stuff-for-AVRs, and they now are going to drop it.

I can't imagine the dumbest idea why Atmel wants to drop a well-known name.

JW

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

Quote:

I can't imagine the dumbest idea why Atmel wants to drop a well-known name.

That's why you're not paid to be a marketing executive ;-)

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

Okay, second impression, this time it's a real engineering dumbness rather than marketing decision - the installer added the installation path to the system PATH variable (and who knows where else) WITHOUT warning, notification, not even giving a choice to refuse or change it... And, what's even worse, it added its path BEFORE the existing paths!

A true M$-style "we know better what you want".

Found out the hard way. Yes, I AM p***d off now.

JW

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

Sigh! This does not bode well..

Quote:
what's even worse, it added its path BEFORE the existing paths!

The usual strategy. Either put it there and you are sure that this stuff will be seen correctly, or place it last and risk being shadowed by something else. An "us-or-them" approach.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:
Sigh! This does not bode well..

Quote:
what's even worse, it added its path BEFORE the existing paths!

The usual strategy. Either put it there and you are sure that this stuff will be seen correctly, or place it last and risk being shadowed by something else. An "us-or-them" approach.
This is half-okay, if the expeced "audience" is non-technical.

However, for us, at least the option to refuse the system variables modification is mandatory. I would say it would be far better if there would be NO installer at all: a zip file plus comprehensive instructions ARE better.

JW

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

Quote:

I would say it would be far better if there would be NO installer at al

Not sure about that. It depends on what AVR Studio 5 will look like. The IDE Atmel designs/chooses for it :wink: might not be so easy to set up, and in order to not plague us with long and tedious setups I for one would like to have the integration into Ecl..., errr..., the IDE, to be done for me. Maybe this will be done by the IDE install, but for many it would be preferrable to have Studio 5 and the successor of WinAVR to be installed in one go.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

I don't give a *** about IDEs - they are 49% crap and 49% marketing (as you have guessed by now, the rest is the useful part of them). Being mostly a toy for those who merrily call themselves "freaks", I don't care how the "IDE" will be installed.

I do care how the real tools are installed, as tools are here to do real work.

JW

PS.

Earlier in this thread, torkildr wrote:
Toolchains will (also) be released separately as soon as they are ready.

Pages