install-avr-tools

Working on 32-bit Windows 7 as well...

Ready for Beta test! Anyone want to give it a try?

New version uploaded. It searches Program Files, Program Files (x86), and bin (the latter being a good place to put installs of additional versions, especially if you use the "portable" feature, since Modern Windows won't like an application trying to write to the normal system app directories.

You wouldn't believe how many strange errors pop up when path names contain parenthesis! The windows commands scanner is text-based, and apparently if you have a code block (delimited by parens!), and it includes an expansion of a path variable (containing parens), you start getting mysterious errors about "xxx unexpected here", even though things appear to be working.

The solution to the other "early evaluation" problems is to have the "late evaluation" instantiation of the script write out a temporary .bat file, which the "early eval" instantiation then "calls"... Gross!

A new version (a bit cleaner, and fixing the comment-related bugs) has been committed.

Also, I tried testing with W8.1, and noticed that the current script won't work with 64bit Windows systems (probably W7, W8, or W10); all the previous W10 testing was done with a 32bit install. This is a simple matter of only searching in %ProgramFiles% and not %ProgramFile(x86)%, so it shouldn't be hard to fix.

I guess this is a known windows batch problem, but it took me WAY too long to figure out...

It turns out that windows batch has a comment command "REM" that is ugly, and a commonly used and documented convention where you precede comments with a double colon "::", which is a little bit prettier.

But double-colon comment have a bug. The following batch file will cause a "cannot find the drive" error!

if "%1"=="" (
  :: comment1
  ::  comment2
  echo foo
)

wiontinuing from previous log...

With "delayed evaluation", you replace your variable expansions "%A%" with "!A!", and they get expanded just as they are executed (when you'd expect!) But since this was a backward-incompatible enhancement to .bat files (at some time in the distant path, you have to actually turn this on explicitly for it to work.

The first way that I found to turn this on is to invoke cmd.exe with a "/V" switch. So if I have foo.bat with:

SET wholestring=AAAA
for %%s in (first second third forth) DO (
  SET wholestring=!wholestring! %%s
)
echo wholestring is %wholestring%

if !SystemDrive! NEQ %SystemDrive% (
  cmd.exe /v /c "%0"
) else (
  SET wholestring=AAAA
  for %%s in (first second third forth) DO (
    SET wholestring=!wholestring! %%s
  )
  echo wholestring is %wholestring%
)

BUT - you recall our goal eventually is to set the user environment PATH variable. It turns out that when you invoke cmd.exe like this, any changes the file makes to the PATH variable disappear when that sub-execution of cmd.exe exits. :-(

This is a problem that is probably familiar to anyone who has written any unix shell scripts. The ENVIRONMENT variables and the shell variables are separate - if your copy of the shell (cmd.exe in this case) creates a variable, you have to do something special to get that value "up" into the environment of the parent. All I needed to do was find the cmd.exe equivalent for "export" or "setenv."

Except, all the windows batch file tutorials/etc that I could find didn't seem to think that there was any problem changing the path in a .bat file script, and so there doesn't seem to be any equivalent for modifying the parent/global variables. It made a certain amount of sense that running a .bat file, and running cmd.exe to run a .bat file might be different, so I went off on a search to find a way to end up setting the path from the original .bat file instead of the sub-process.

I had thought I had found it with "SETLOCAL EnableDelayedExpansion" command. This turns on delayed expansion, just like running cmd with the "/V" switch. However, the original "SETLOCAL" command (no arguments) has the effect of making all variables used thereafter be local instead of global, including the PATH. Presumably, running "cmd /v" works exactly like stuffing a "SETLOCAL EnableDelayedExpansion" command in your .bat file as the first command.

There's an ENDLOCAL command as well, that lets you start modifying global variables again. Perhaps I can do what I need with local variables, then turn them off and put the results into global variables? Nope - it seems that ENDLOCAL deletes any local variables that you had, even if they didn't overlap any global variables. I guess that makes sense, since a variable that merely exists can change behavior, and you wouldn't want that to happen accidentally. But grrr - how do you pass information from your "locally careful" code to something that has to operate globally??

So... I'm not really a windows person, and this was supposed to a quick and rather brute-force execution of "find all the things that look like Arduino installs, ask the user to pick one, and set their paths to include the executables from the Arduino directory tree." Straightforward and dependent more on being familiar with the various hiding places and tree structures, than on any great windows programming expertise...

But apparently, Windows puts some "interesting" issues in the way of some pretty obvious usage, and I thought I'd explain some of them...

The biggest trouble-make was something that I'll call "Early Evaluation" that affects looping. If you write a loop like:

    set wholestring=AAAA
    for %%s in (first second third forth) do (
      set wholestring=%wholestring% %%s
    )

You might expect, once you get past the weird syntax, to get a final value of the "wholestring" variable as "AAAA first second third forth" (one word appended to the variable for each word in the "for" argument.)

Nope.

The way cmd.exe evaluates this is that the body of the loop (the set statement) has variable substitution done first (except for the loop variable.) So in effect it substitutes in the initial value of wholestring four times:

    set wholestring=AAAA first
    set wholestring=AAAA second
    set wholestring=AAAA third
    set wholestring=AAAA forth

and you wind up with "AAAA forth"

How does this affect my program? Well, one of the things I want to do is loop through the list of Arduino dirs, and ask whether to use each one, sort of like:

    FOR %%f IN (%ProgramFiles%\Arduino*) DO (
      SET /P confirm="Use %%f ? [y/n]>"
      if "%confirm%"=="y" (
        GOTO gotdir
      )
    )

But %confirm% gets evaluated early in that loop as well, so it doesn't ask for each file. Well, it ASKS for each file, but for the comparison it always uses the value that %confirm% had before the first loop. Not very helpful!

Fortunately, Microsoft added a feature that they call "Delayed Expansion" to address this problem...

Tested on WXP (MicroXP, actually) as well.

I had thought that 1.0.x and the latest versions had different directory structures for the binaries, but it turns out that that's NOT true for AVR. However, some of the intermediate versions (1.5.0 - 1.6.4, I think) DO put even the AVR compiler in %APPDATA%. Unless configured for "portable" operation, in which case things are different again... The script does not currently handle %APPDATA% possibility.

I suppose that once this is working to my satisfaction, I should think about having a similar tool that installs any other compiler that the Arduino Board Manager has fetched. OTOH, that may be disappointing, because (for example) the ARM compiler has limit chip support included, and might end up with really nasty include paths needed to fetch even those...

I'm trying to remember if any of my systems will run W7 without a disk swap... :-(

Added on Github: https://github.com/WestfW/Arduino-avr-tools-install

I've put the initial version on github.

Project hosting is "interesting." Github and version control and an issue-tracker, but isn't very good for discussions or blog-like history entry. Hackaday.io does some of those better, but doesn't have the features that github has...