What utility programs are missing from the Atmel Toolchain?

Go To Last Post
75 posts / 0 new

Pages

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

Hi All,

I know that some of you have commented that there are certain unix utility programs that are missing from the Atmel Toolchain compared to WinAVR.

From what I can tell so far, these are missing:
- bash
- sed
- gawk

What else is missing?

Thanks! :)

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

Batman and Robin will soon come up with more names... :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Aren't there a lot? WinAVR includes a pretty complete unix-like working environment. "bison" and "m4" come to mind as actually being relevant. And "which", which is useful for figuring it out...

(Hmm. I have a pretty virgin windows+AVS+WinAVR system, so I can get all the files in WinAVR\...\utils\bin\, and run a "which xxx" on them in an AS6 "command prompt" window (nice idea, BTW. I like not having the "normal" paths messed with!) Since AVS is ahead of WinAVR in the path, anything that shows up as being from WinAVR is something that WASN'T in the AS6 paths. So that's this list:)

C:\WinAVR-20100110\utils\bin\ansi2knr.exe
C:\WinAVR-20100110\utils\bin\bc.exe
C:\WinAVR-20100110\utils\bin\bison.exe
C:\WinAVR-20100110\utils\bin\bunzip2.exe
C:\WinAVR-20100110\utils\bin\bzcat.exe
C:\WinAVR-20100110\utils\bin\bzip2.exe
C:\WinAVR-20100110\utils\bin\cmp.exe
C:\WinAVR-20100110\utils\bin\compress.exe
C:\WinAVR-20100110\utils\bin\dc.exe
C:\WinAVR-20100110\utils\bin\diff.exe
C:\WinAVR-20100110\utils\bin\diff3.exe
C:\WinAVR-20100110\utils\bin\egrep.exe
C:\WinAVR-20100110\utils\bin\fgrep.exe
C:\WinAVR-20100110\utils\bin\find.exe
C:\WinAVR-20100110\utils\bin\flex.exe
C:\WinAVR-20100110\utils\bin\fromdos.exe
C:\WinAVR-20100110\utils\bin\fsplit.exe
C:\WinAVR-20100110\utils\bin\gawk.exe
C:\WinAVR-20100110\utils\bin\gclip.exe
C:\WinAVR-20100110\utils\bin\gplay.exe
C:\WinAVR-20100110\utils\bin\grep.exe
C:\WinAVR-20100110\utils\bin\gsar.exe
C:\WinAVR-20100110\utils\bin\gunzip.exe
C:\WinAVR-20100110\utils\bin\gzip.exe
C:\WinAVR-20100110\utils\bin\indent.exe
C:\WinAVR-20100110\utils\bin\info.exe
C:\WinAVR-20100110\utils\bin\infokey.exe
C:\WinAVR-20100110\utils\bin\install-info.exe
C:\WinAVR-20100110\utils\bin\jwhois.exe
C:\WinAVR-20100110\utils\bin\less.exe
C:\WinAVR-20100110\utils\bin\m4.exe
C:\WinAVR-20100110\utils\bin\makeinfo.exe
C:\WinAVR-20100110\utils\bin\makemsg.exe
C:\WinAVR-20100110\utils\bin\man.exe
C:\WinAVR-20100110\utils\bin\mount.exe
C:\WinAVR-20100110\utils\bin\mvdir.exe
C:\WinAVR-20100110\utils\bin\patch.exe
C:\WinAVR-20100110\utils\bin\pclip.exe
C:\WinAVR-20100110\utils\bin\ps.exe
C:\WinAVR-20100110\utils\bin\rman.exe
C:\WinAVR-20100110\utils\bin\sdiff.exe
C:\WinAVR-20100110\utils\bin\sed.exe
C:\WinAVR-20100110\utils\bin\sh.exe
C:\WinAVR-20100110\utils\bin\shar.exe
C:\WinAVR-20100110\utils\bin\stego.exe
C:\WinAVR-20100110\utils\bin\tar.exe
C:\WinAVR-20100110\utils\bin\texindex.exe
C:\WinAVR-20100110\utils\bin\todos.exe
C:\WinAVR-20100110\utils\bin\type.exe
C:\WinAVR-20100110\utils\bin\unshar.exe
C:\WinAVR-20100110\utils\bin\uudecode.exe
C:\WinAVR-20100110\utils\bin\uuencode.exe
C:\WinAVR-20100110\utils\bin\wget.exe
C:\WinAVR-20100110\utils\bin\which.exe
C:\WinAVR-20100110\utils\bin\xargs.exe
C:\WinAVR-20100110\utils\bin\zcat.exe
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is "Atmel Toolchain"?

JW

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

@EW

I use this , and is quite satisfied (the few times i boot into XP)
http://gnuwin32.sourceforge.net/
http://unxutils.sourceforge.net/

The most important part of these utils , as opposed to older "Non win32" utils.
Is the support for long filenames , and the "Non Cygwin".

/Bingo

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

Eric,

I'm kind of surprised you don't own a "diff" tool. Could I recommend kdiff3 for cross platform work. If sticking to Windows then things like Beyond Compare and Araxis Merge are better.

Cliff

PS I just tried kdiff3 and the result was the same as westfw's above.

PPS Oh sweet irony - one of the things that WinAVR provides that Toolchain doesn't is diff.exe:

E:\WinAVR-20100110\utils\bin>diff . c: | grep "Only in \." | grep exe
Only in .: AvrCalc.exe
Only in .: ansi2knr.exe
Only in .: basename.exe
Only in .: bc.exe
Only in .: bison.exe
Only in .: bunzip2.exe
Only in .: bzcat.exe
Only in .: bzip2.exe
Only in .: cat.exe
Only in .: chgrp.exe
Only in .: chmod.exe
Only in .: chown.exe
Only in .: cksum.exe
Only in .: cmp.exe
Only in .: comm.exe
Only in .: compress.exe
Only in .: cp.exe
Only in .: csplit.exe
Only in .: cut.exe
Only in .: date.exe
Only in .: dc.exe
Only in .: dd.exe
Only in .: df.exe
Only in .: diff.exe
Only in .: diff3.exe
Only in .: dircolors.exe
Only in .: dirname.exe
Only in .: du.exe
Only in .: echo.exe
Only in .: egrep.exe
Only in .: env.exe
Only in .: expand.exe
Only in .: expr.exe
Only in .: factor.exe
Only in .: false.exe
Only in .: fgrep.exe
Only in .: find.exe
Only in .: find.exe.txt
Only in .: flex.exe
Only in .: fmt.exe
Only in .: fold.exe
Only in .: fromdos.exe
Only in .: fsplit.exe
Only in .: gawk.exe
Only in .: gclip.exe
Only in .: gplay.exe
Only in .: grep.exe
Only in .: gsar.exe
Only in .: gunzip.exe
Only in .: gzip.exe
Only in .: head.exe
Only in .: id.exe
Only in .: indent.exe
Only in .: info.exe
Only in .: infokey.exe
Only in .: install-info.exe
Only in .: install.exe
Only in .: join.exe
Only in .: jwhois.exe
Only in .: less.exe
Only in .: ln.exe
Only in .: logname.exe
Only in .: ls.exe
Only in .: m4.exe
Only in .: make.exe
Only in .: make.exe.old
Only in .: makeinfo.exe
Only in .: makemsg.exe
Only in .: man.exe
Only in .: md5sum.exe
Only in .: mkdir.exe
Only in .: mkfifo.exe
Only in .: mknod.exe
Only in .: mount.exe
Only in .: mv.exe
Only in .: mvdir.exe
Only in .: nl.exe
Only in .: od.exe
Only in .: paste.exe
Only in .: patch.exe
Only in .: pathchk.exe
Only in .: pclip.exe
Only in .: pr.exe
Only in .: printenv.exe
Only in .: printf.exe
Only in .: ps.exe
Only in .: pwd.exe
Only in .: rm.exe
Only in .: rman.exe
Only in .: rmdir.exe
Only in .: sdiff.exe
Only in .: sed.exe
Only in .: seq.exe
Only in .: sh.exe
Only in .: shar.exe
Only in .: sleep.exe
Only in .: sort.exe
Only in .: split.exe
Only in .: stego.exe
Only in .: su.exe
Only in .: sum.exe
Only in .: sync.exe
Only in .: tac.exe
Only in .: tail.exe
Only in .: tar.exe
Only in .: tee.exe
Only in .: test.exe
Only in .: texindex.exe
Only in .: todos.exe
Only in .: touch.exe
Only in .: tr.exe
Only in .: true.exe
Only in .: type.exe
Only in .: uname.exe
Only in .: unexpand.exe
Only in .: uniq.exe
Only in .: unshar.exe
Only in .: uudecode.exe
Only in .: uuencode.exe
Only in .: wc.exe
Only in .: wget.exe
Only in .: which.exe
Only in .: whoami.exe
Only in .: xargs.exe
Only in .: yes.exe
Only in .: zcat.exe

(my copy is "tainted" as I've copied things like avrcalc.exe there too)

PPPS: BTW second the recommendation for gnuwin32 - I sort of assumed that's where all the WinAVR "goodies" came from in the first place?

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

Hi All,

Thanks for the feedback.

For the record, yes, I do own a diff tool, several in fact. I thought that perhaps someone already had a list compiled, so I thought I'd ask here first. My machine is not always in a "pristine" installation state, due the different things I'm working on.

Yes, I'm very familiar with the gnuwin32 project. In fact I have one of the oldest Feature Requests for that project, asking for a bash shell for Windows:
http://sourceforge.net/tracker/?...
I submitted this item over 7 years ago!

I'm also familiar with the unxutils project. In fact, that is the one that I use in WinAVR.

I would prefer to get everything from the gnuwin32 project, as that seems to be a very active project.

The kicker in all of these utilities has always been the bash shell, which is really required for make. I ended up redistributing the mingw version of bash, but it requires one of their DLLs (IIRC). I'd love to have a statically linked bash that will work with GNU Make that I can easily redistribute.

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

EW wrote:
I'd love to have a statically linked bash that will work with GNU Make that I can easily redistribute.

Just use linux :wink:

/Bingo

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

Quote:
Just use linux

1. Ouch...

2. Does not make much sense in the conrtext of AVR/Atmel Studio.. :twisted:

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

Bingo600 wrote:
EW wrote:
I'd love to have a statically linked bash that will work with GNU Make that I can easily redistribute.

Just use linux :wink:

/Bingo

Let me rephrase:
I'd love to have a statically linked bash that will work with GNU Make that I can easily redistribute on Windows in WinAVR and the Atmel Toolchain.

There.

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

westfw wrote:

C:\WinAVR-20100110\utils\bin\ansi2knr.exe
C:\WinAVR-20100110\utils\bin\bc.exe
C:\WinAVR-20100110\utils\bin\bison.exe
C:\WinAVR-20100110\utils\bin\bunzip2.exe
C:\WinAVR-20100110\utils\bin\bzcat.exe
C:\WinAVR-20100110\utils\bin\bzip2.exe
C:\WinAVR-20100110\utils\bin\cmp.exe
C:\WinAVR-20100110\utils\bin\compress.exe
C:\WinAVR-20100110\utils\bin\dc.exe
C:\WinAVR-20100110\utils\bin\diff.exe
C:\WinAVR-20100110\utils\bin\diff3.exe
C:\WinAVR-20100110\utils\bin\egrep.exe
C:\WinAVR-20100110\utils\bin\fgrep.exe
C:\WinAVR-20100110\utils\bin\find.exe
C:\WinAVR-20100110\utils\bin\flex.exe
C:\WinAVR-20100110\utils\bin\fromdos.exe
C:\WinAVR-20100110\utils\bin\fsplit.exe
C:\WinAVR-20100110\utils\bin\gawk.exe
C:\WinAVR-20100110\utils\bin\gclip.exe
C:\WinAVR-20100110\utils\bin\gplay.exe
C:\WinAVR-20100110\utils\bin\grep.exe
C:\WinAVR-20100110\utils\bin\gsar.exe
C:\WinAVR-20100110\utils\bin\gunzip.exe
C:\WinAVR-20100110\utils\bin\gzip.exe
C:\WinAVR-20100110\utils\bin\indent.exe
C:\WinAVR-20100110\utils\bin\info.exe
C:\WinAVR-20100110\utils\bin\infokey.exe
C:\WinAVR-20100110\utils\bin\install-info.exe
C:\WinAVR-20100110\utils\bin\jwhois.exe
C:\WinAVR-20100110\utils\bin\less.exe
C:\WinAVR-20100110\utils\bin\m4.exe
C:\WinAVR-20100110\utils\bin\makeinfo.exe
C:\WinAVR-20100110\utils\bin\makemsg.exe
C:\WinAVR-20100110\utils\bin\man.exe
C:\WinAVR-20100110\utils\bin\mount.exe
C:\WinAVR-20100110\utils\bin\mvdir.exe
C:\WinAVR-20100110\utils\bin\patch.exe
C:\WinAVR-20100110\utils\bin\pclip.exe
C:\WinAVR-20100110\utils\bin\ps.exe
C:\WinAVR-20100110\utils\bin\rman.exe
C:\WinAVR-20100110\utils\bin\sdiff.exe
C:\WinAVR-20100110\utils\bin\sed.exe
C:\WinAVR-20100110\utils\bin\sh.exe
C:\WinAVR-20100110\utils\bin\shar.exe
C:\WinAVR-20100110\utils\bin\stego.exe
C:\WinAVR-20100110\utils\bin\tar.exe
C:\WinAVR-20100110\utils\bin\texindex.exe
C:\WinAVR-20100110\utils\bin\todos.exe
C:\WinAVR-20100110\utils\bin\type.exe
C:\WinAVR-20100110\utils\bin\unshar.exe
C:\WinAVR-20100110\utils\bin\uudecode.exe
C:\WinAVR-20100110\utils\bin\uuencode.exe
C:\WinAVR-20100110\utils\bin\wget.exe
C:\WinAVR-20100110\utils\bin\which.exe
C:\WinAVR-20100110\utils\bin\xargs.exe
C:\WinAVR-20100110\utils\bin\zcat.exe

There are a number of programs in the above list, that I would say are not *really* required for a toolchain, and some that really should be.

For example, NOT required:
stego
uudecode
uuencode
mount
bc

Should be required:
diff
grep
find
man
bison
flex
wget
sed
gawk
todos
fromdos
*zip
mvdir
etc. ...

I'm sure there are others that could be categorized in both lists.

What would be your choices for those lists?

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

Quote:

in WinAVR and the Atmel Toolchain

Both? Interesting ;-)

A Google suggests that anything purporting to be "bash on Windows" all appears to originally derive from MSys - I guess they did such a good job that no one saw the need to reinvent the wheel?

Dependency viewer shows that what sh.exe is using from msys-1.0.dll are actually a lot of pretty standard libc functions so I imagine if the intention were simply to simplify the DLL one could reimplement a "cut down" one with minimal functionality?

BTW presumably the sh.exe in Msys is open source - could it not be built to statically link anyway?

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

Quote:
Both? Interesting :wink:

[Humming on "I Heard It Though The Grapevine", alternating between the Gladys, Pips, Gaye and Creedence versions.]
Great song, interesting new rumor-fodder! :wink:

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

Honestly while I'd love to have all the nice Unix tools without having to use a funky Cygwin shell, the most important thing is that we can compile using the WinAVR makefile template. There's a billion trillion projects out there who can't/won't switch to IDE based projects for cross-platform reasons, and they're currently semi-screwed by the lack of sh, mv, rm, rmdir, sed, find, gawk etc. in the Atmel toolchain. Just allowing the cross-platform WinAVR makefile to compile with the new toolchain will allow everyone to drop the old WinAVR releases immediately.

- Dean :twisted:

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

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

Quote:

Just allowing the cross-platform WinAVR makefile to compile with the new toolchain will allow everyone to drop the old WinAVR releases immediately.

Once the other faults in Toolchain are all cleared. How's its tiny 4/5/9/10 support getting on by the way? Ready for human consumption yet?

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

Quote:

Once the other faults in Toolchain are all cleared. How's its tiny 4/5/9/10 support getting on by the way? Ready for human consumption yet?

Has the Atmel toolchain got any faults in the latest release that WinAVR does not, not counting new part support? I think the lack of stripped binaries was fixed, so while I haven't looked too closely I think it's only some new parts that are broken.

The toolchain team is autonomous to the other teams, so they release on their own cycle. I've no idea when the next big release is, but I hope they fix up any remaining issues.

- Dean :twisted:

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

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

Quote:

Has the Atmel toolchain got any faults in the latest release that WinAVR does not, not counting new part support? I think the lack of stripped binaries was fixed, so while I haven't looked too closely I think it's only some new parts that are broken.

It's YOUR beta test - you tell me? How are the test results going? You corrected the big one (ELPM in CRT) but that exposed how little care was made in preparing the build so what other dark faults lurk? Presumably there's a publically accessible Bugzilla for it where one can check what has been found/fixed and gain confidence that the build team really do know the right way round to sit on a lavatory (with apologies to Rowan Atkinson: http://www.simplythefatheroftheb... ).

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

abcminiuser wrote:
Quote:

Once the other faults in Toolchain are all cleared. How's its tiny 4/5/9/10 support getting on by the way? Ready for human consumption yet?

Has the Atmel toolchain got any faults in the latest release that WinAVR does not, not counting new part support? I think the lack of stripped binaries was fixed, so while I haven't looked too closely I think it's only some new parts that are broken.

The toolchain team is autonomous to the other teams, so they release on their own cycle. I've no idea when the next big release is, but I hope they fix up any remaining issues.

- Dean :twisted:

I reported a Tiny10 err in my avr-gcc 4.5.1 TC , related to "Builtin delay_ms" , it was detected by Snigelen. And was triggered if the Speed was .. I think lower than 3Mhz

https://www.avrfreaks.net/index.p...

Atmel verified & accepted the bug.
And deep silence since then.

Recently i saw this , and i guess Cliff would know something about that opcode thingy.

https://www.avrfreaks.net/index.p...

/Bingo

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

Nobody answered me and it appears everybody knows what Eric is talking about, so let me guess: are you all talking about the so called AtmelStudio6?

Or is there a sane size standalone package under "Atmel Toolchain" name around?

I hate to come to the last sentence of the joke.

JW

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

Quote:

Or is there a sane size standalone package under "Atmel Toolchain" name around?

Atmel releases "Atmel Studio", which is a huge world-wide multi-team joint effort - however each individual component is build by standalone teams. It includes:

Atmel Studio Shell - Atmel Tools
Debugger Backend - Atmel Tools
Device Simulator - Atmel Tools
QTouch Library - Atmel Touch Team
QTouch Composer - Atmel Touch Team
ARM Compiler - Atmel ARM Toolchain Team
AVR Compiler - Atmel AVR Toolchain Team
ASF - Atmel Applications Team (me!)
Part Descriptions - Atmel Device Team

And probably a bunch of bits and pieces I'm forgetting. However, some of these bundled components are available standalone - ASF, and the toolchains in particular. You can grab the latest Atmel AVR Toolchain here:

http://www.atmel.com/tools/ATMEL...

Which is basically like WinAVR, except it doesn't have the Unix utilities currently for WinAVR makefile support.

- Dean :twisted:

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

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

abcminiuser wrote:
You can grab the latest Atmel AVR Toolchain here:

http://www.atmel.com/tools/ATMEL...

linked page wrote:
updated June 2011

Dean,

With due respect, you really want us to comment on an issue almost one year old?

Besides, I've already /grabbed/ a (slightly) newer one since then (and don't think it is worth commenting, either). It just highlights how deeply disordered Atmel's web now is, if even an insider can't access rudimentary information on it. Every "new technology" introduced in the last few months made it only worse - not that surprisingly, lack of structure and content can't be made up by "technologies" and "features", however tempting it is.

JW

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

EW wrote:

There are a number of programs in the above list, that I would say are not *really* required for a toolchain, and some that really should be.

For example, NOT required:
stego
uudecode
uuencode
mount
bc

Should be required:
diff
grep
find
man
bison
flex
wget
sed
gawk
todos
fromdos
*zip
mvdir
etc. ...

The bzip2 stuff is rarely needed. There are better tools for windows, like 7-zip.

man does not make sense without having some man pages to display. And it requires a formatter like nroff

bison/flex only makes sense if they have been hacked for AVR code generation. Like sizeof(int) == 2 observed, generated code reduced in size to fit in AVRs.

wget? Nice, but not really needed for building code.

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

Quote:

With due respect, you really want us to comment on an issue almost one year old?

The website doesn't always carry the latest versions of everything, I've no idea why.

Quote:

Besides, I've already /grabbed/ a (slightly) newer one since then (and don't think it is worth commenting, either). It just highlights how deeply disordered Atmel's web now is, if even an insider can't access rudimentary information on it.

Frankly I haven't looked into it much - I just use whatever's packaged within Studio, and report bugs. I can check the internal issue management system and find out who is responsible for it/what the status is, but I haven't had a pressing reason to do so. There's enough to worry about within my own department that I haven't spent much time "joy-riding" around the internal systems to find out everything about everything. It's a big company!

- Dean :twisted:

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

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

asf-test wrote:
EW wrote:

There are a number of programs in the above list, that I would say are not *really* required for a toolchain, and some that really should be.

For example, NOT required:
stego
uudecode
uuencode
mount
bc

Should be required:
diff
grep
find
man
bison
flex
wget
sed
gawk
todos
fromdos
*zip
mvdir
etc. ...

The bzip2 stuff is rarely needed. There are better tools for windows, like 7-zip.

man does not make sense without having some man pages to display. And it requires a formatter like nroff

bison/flex only makes sense if they have been hacked for AVR code generation. Like sizeof(int) == 2 observed, generated code reduced in size to fit in AVRs.

wget? Nice, but not really needed for building code.

I think the tools were meant for the HOST not the TARGET.

/Bingo

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

Quote:

wget? Nice, but not really needed for building code.

As someone who uses the wget that happened to come with WinAVR for almost everything I retrieve from HTTP or FTP *please* do not drop this from any proposed package. (same goes for wput).

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

abcminiuser wrote:
Frankly I haven't looked into it much - I just use whatever's packaged within Studio, and report bugs.
Frankly, I am not interested in Studio at all. I don't use it and, after reading numerous reports on it here, don't intend to waste time with it (I don't think any IDE is worth the hassle btw.).

What I am seeking is a WinAVR replacement with the native code memory access (courtesy of tireless effort of Georg-Johann Lay). My motivation to look at interim releases is to help to kill out the bugs, as the huge company you said Atmel is, apparently struggles to provide the quality the few unpaid enthusiasts were able to produce with WinAVR previously. I do understand the possible reasons for this not to blame anybody, but from my egoistic point of view I don't care of the reasons, I just want the thing.

If it helps to locate the person within Atmel who can issue a recent "Toolchain", I was promised a previous release by torkildr and one later by Ole a.k.a. OKB (although he apparently is not directly the person who can do that). Btw, note what he said in

Also, frankly, I don't care about the reasons why your web is in disorder. I just noted it repeatedly, as it repeatedly gets into my way when I try to find an appropriate device for a new project, for example, or searching for any other information I might need for my work. You can take it as an attack on your script kidd^H^H^H^H^H^H^H^H^H^H^Hweb developers, if you want.

JW

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

abcminiuser wrote:
Has the Atmel toolchain got any faults in the latest release that WinAVR does not, not counting new part support?
You mean bugs like GCC's PR52474?

This was introduced by a patch. Unfortunately, there is no avr-atmel-gcc bugtracker. At least I could not find one -- if it cannot be found it is non-existent ;-) and instead of refering to bug tracker+number, people link again and again from avrfreaks threads to thread... merely impossible to follow, find reduced test cases, tool versions, command options, etc.

It's not really possible to compare WinAVR against avr-atmel-gcc as the first is 4.3 and the latter is 4.5.

Anyway, I think you know GCC bugzilla and how to find known and fixed bugs like PR46779, PR39633 or PR42240. Notice that not all affected versions are fixed and the known fixes are not backported for reasons we know.

abcminiuser wrote:
Atmel releases "Atmel Studio", which is a huge world-wide multi-team joint effort - however each individual component is build by standalone teams.
That's only Atmel inards that users won't notice. What users will notice, however, is the result -- no matter how it was produced.

"Atmel Toolchain" will have to catch up with quality and stability of WinAVR.

From forum post a major user annojance appears to be debugging optimized code like var in:

void foo (void)
{
   int var = 0;
}

Debug formats like DWARF-4 will ship the information, so the question is: Do the deguggers support DWARF-4 or at least DWARF-3?

And will there be barrier free access to the sources like here?

http://distribute.atmel.no/tools...

avrfreaks does not support Opera. Profile inactive.

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

Speaking about utilities - what about Mfile (+ the tcl/tk stuff needed to run it)?

I understand that the IDE aims to replace it, but if you mean seriously to produce a WinAVR replacement, it would be fit to have it there. IMHO.

JW

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

SprinterSB wrote:
Unfortunately, there is no avr-atmel-gcc bugtracker.
You probably have not noticed this announcement (it's a sticky post in top of the AS5/AS6 sub-forum).

I am not sure it is good to have yet another tracker for the whole toolchain, even if I know you have a different view on this. Eric was trying to maintain a "cumulative" list, but apparently gave up years ago (so I am lazy to look up the link right now).

JW

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

Quote:
There are a number of programs [WestfW's] list, that I would say are not *really* required for a toolchain

Agreed. I meant it to be an unedited, uncommented, list.

Quote:
I don't think any IDE is worth the hassle

Yeah. I keep thinking that the Arduino pre-processing should all be re-written in elisp...

Is there such a thing as a sub-package manager for a super-package (like WinAVR, or AVRStudio.) It seems like that sort of thing might be useful. For example, you mentioned MFile, which I'd never heard of and isn't part of WinAVR itself (as far as I can tell), but it seems like it'd be nice to be able to say "avryum install mfile" and get a "known-compatible" version.

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

Quote:
You probably have not noticed this announcement (it's a sticky post in top of the AS5/AS6 sub-forum).

That is the Atmel Studio 6 bug tracker. As Dean has pointed out above, the Toolchain is done by a separate team, not the Studio team. It is likely that they do not use that tracker, if they use any.

Quote:
The website doesn't always carry the latest versions of everything, I've no idea why.

Simply: Because it is not considered important enough.

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

westfw wrote:
For example, you mentioned MFile, which I'd never heard of and isn't part of WinAVR itself (as far as I can tell)
We might have a different notion of "itself", but AFAIK Mfile has always been part of WinAVR as a package which facilitates development with AVRs. As well as avrdude, avarice and a couple of other lightweight but useful tools.

westfw wrote:
but it seems like it'd be nice to be able to say "avryum install mfile" and get a "known-compatible" version.
It's a neat idea indeed, but given the state of things, I don't believe it will ever happen.

JW

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

JohanEkdahl wrote:
Quote:
You probably have not noticed this announcement (it's a sticky post in top of the AS5/AS6 sub-forum).

That is the Atmel Studio 6 bug tracker. As Dean has pointed out above, the Toolchain is done by a separate team, not the Studio team.

I know, but we don't have anything better. I believe if I would submit a "genuine toolchain" bug there, it would propagate to the "appropriate team" in one way or other. Eventually, I believe, given enough such bug reports, a qualitative change might happen too.

Actually, it's about time to centralize the efforts around the available devtools. I wonder how long would it take.

JohanEkdahl wrote:
Quote:
The website doesn't always carry the latest versions of everything, I've no idea why.

Simply: Because it is not considered important enough.
In contrast with the javoid [self-censored] there which is apparently deemed much more important.

JW

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

wek wrote:
SprinterSB wrote:
Unfortunately, there is no avr-atmel-gcc bugtracker.
You probably have not noticed this announcement (it's a sticky post in top of the AS5/AS6 sub-forum).
That says it's a tracker for the "Beta release of Atmel Studio 6".
Quote:
I am not sure it is good to have yet another tracker for the whole toolchain, even if I know you have a different view on this.
I don't have a different view. I think that having /one/ place to report bugs of all kind (AS4, AS5, AS6, toolchain, ARM, AVR, AVR32, ...) is the easieast and most obvious way for the user. Most users using a GUI are not even aware that AS is not a compiler or that there is somethink like a "linker".

What I am confused about is that the tracker does not list components (except "AVR Studio 6 beta" in Product "Atmel Studio 6"). Operating Systems and Hardware are /Target/ OSes and Hardware, not Host. And it's not possible to specify a version.

As there are obviously Atmel employees around here: What is the right way to report bugs like, e.g.:

PR46779: This is a bug known in the base version. It this worth a bug report for the Atmel toolchain? Or is the intended place GCC bugzilla? And the bug won't be fixed in AS and instead fixed automatically as AS moves to newer GCC base version?

PR52474: This is a bug present in some AS distributions but not in the original avr-gcc from FSF. What is the right place to report it?

From what I read (I don't use AS) I'd guess there is more than one "Atmel avr toolchain 4.5.1" floating around, but it's hard to know what version, where are the respective sources, patches, ChangeLogs, etc.

The more barriers there are, the less support/help/collaboration from users or community will be...

I don't use AS, never did, never will. But at the moment it's even impossible to direct a user who is seeking help with a (known) bug to respective Atmel tracker and say "hey, it's a known issue and maybe already fixed, look at tracker XYZ bug number ABC" for more details and what versions come with a fix. Or "It's a Atmel issue, file a bug at XYZ so that the developers can fix it and other users are aware of the bug(fix)"

It's no shame if there are bugs. The software is very complex and there will be bugs.

It's inevitable to know what bugs are there and to have an easy overview and accessible tracker, what versions are affected, if there are work-arounds; both for developers /and/ the useres!

avrfreaks does not support Opera. Profile inactive.

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

We have an internal issue management system that is non-public, which has all the correct differentiations. Put all your bugs in the AS6 tracker for now and they will be triaged and sent to the correct teams.

SprinterSB. could you PM me an email you use so that I can put you in direct touch with the Toolchain team? I think that would help get things sorted out more quickly.

- Dean :twisted:

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

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

You find an up to date bug list at http://www.mikrocontroller.net/a...

It's mostly avr-gcc centric.

If you like to contact via email, you can use (forwarding) address "gjl at gcc dot gnu dot org".

Eric is aware of the list and of kind, priority and severeness of (open) bugs.

avrfreaks does not support Opera. Profile inactive.

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

EW wrote:
Hi All,

I know that some of you have commented that there are certain unix utility programs that are missing from the Atmel Toolchain compared to WinAVR.

From what I can tell so far, these are missing:
- bash
- sed
- gawk

What else is missing?

Thanks! :)

Personally, I'm heavily invested in SRecord. I use it for various automated post-processing activities after my builds. (Such as attaching checksums to the compiler's output.)

I currently use the Atmel toolchain bundled with AVR Studio 5.1 for compiling, and then I depend on WinAVR to provide access to SRecord. It'd be nice if SRecord (or something that provides equivalent functionality) was included as part of the Atmel Toolchain.

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

I found this thread while searching for info regarding sh.exe present in WinAVR, but missing in shellUtils bundled with Atmel Studio 6.1.

Does anyone know if this will be added in the future?
The GnuWin32 FAQ justifies it's absence from CoreUtils:
http://gnuwin32.sourceforge.net/...

Can anyone recommend the best / smallest download alternative? MINGW appears daunting for just one utility...

Better yet, will sh.exe be added to Atmel Studio?

Thanks in advance,
Pieter

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

Quote:
Better yet, will sh.exe be added to Atmel Studio?

About as likely as them adding avrdude!

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

pieterc wrote:
...MINGW appears daunting for just one utility...
Why the aversion to MinGW? It takes up less than a 1GB of hard drive space.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

Quote:
It takes up less than a 1GB

Is that supposed to be sarcasm? All of WinAVR was less than 300M in its last release...

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

westfw wrote:
Quote:
It takes up less than a 1GB

Is that supposed to be sarcasm? All of WinAVR was less than 300M in its last release...

No. MinGW, which includes MSYS, weighs in at 956MB.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

In fact:

E:\WinAVR-20100110\utils\bin>dir sh.exe
 Volume in drive E is VBOX_windows
 Volume Serial Number is 0000-FC03

 Directory of E:\WinAVR-20100110\utils\bin

19/01/2010  18:10           476,672 sh.exe

If it's only the shell interpreter you want - you don't need an entire OS/compiler/baggage/and/all if you just need "sh".

It seems to me that gnuwin32 - the exact same source Eric used for the utilities in WinAVR - is probably the most that is required.

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

I think Eric packaged GnuWin32 CoreUtils with ATmel Studio 6:
http://gnuwin32.sourceforge.net/...

Unfortunately it is missing sh.exe. In Makefiles there is a problem that if a source file is missing (or the path is wrong), then make spits out an obtuse error message, so I used Dean Camera's check in his LUFA Makefile:
check:
@echo
@echo $(MSG_CHECK)
@for f in $(SRC) $(CPPSRC) $(ASRC); do \
if [ ! -f $$f ]; then \
echo "$$f ERROR! File not found"; \
exit 1; \
fi; \
echo $$f OK; \
done
@echo

The problem is that it uses sh.exe. Now I have to tell users of my Makefile to download WinAVR or MSYS to get the missing sh.exe.

I was hoping that there would be an easier solution for the average user.

Regards,
Pieter

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

Quote:

I think Eric packaged GnuWin32 CoreUtils with ATmel Studio 6:

Not Eric - for some strange reason Atmel wouldn't let Eric have anything to do with the open source toolchain in AS6 (well, this thread is about as close as he got). Eric no longer works for Atmel. (related?).

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

Quote:

I think Eric packaged GnuWin32 CoreUtils

AS you see, coreutlils does not contain any shell, only the shell utils. Not sure where our source of coreutils is, but I know that they are not from any prepackaged source (e.g. we have compiled it ourselves).

Quote:

so I used Dean Camera's check in his LUFA Makefile:

I think dean has rewritten his makefiles a bit. Look at his github repo for them.

Quote:

... download WinAVR or MSYS to get the missing sh.exe.

All users of windows should have a version of msys, cygwin or gnuwin32... Its a must have :)

PS:
No, I cant say much about reasons for the current state of things, but that last time I tried to find out of it I hit a wall of politics.

:: 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

Quote:

I think dean has rewritten his makefiles a bit.

Well he's done a wee bit more than that - he's added a LUFA extension to AS6 which creates AS6 projects with AS6 Makefiles. If it were me I'd just use that if you want to "play" with LUFA inside AS6.

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

But they don't contain the makefiles, the plugin uses the xml schema from ASF.

:: 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

Quote:

But they don't contain the makefiles, the plugin uses the xml schema from ASF.

Are you saying that if you create a LUFA project from the extension and then build it that it does not create Makefiles? (ie Makefiles that are not reliant on sh.exe being present).

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

I'm saying studio creates the makefile based on the project structure that Dean describes in the extension. Dean also has a totally bonkers system of makefiles, which are the ones I linked above.

:: 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

Quote:

The problem is that it uses sh.exe

One alternative would be to write an alternative version of that running on CMD.

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]

Pages