Joe wrote:
>
> Has anyone ported the Atmel AT91 USB Framework to WinARM? (And would
> like to share?)  It looks the primary work is converting the NMAKE
> makefiles to WinARM-style makefiles.

If have ported the USB Core + HID example to GNU:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_at91.html#at91_usb1

As written on the page the port is preliminary and there are still some
small incompatibilites with the makefiles and the shell (sh.exe) as
included in WinARM 6/06 (I already use a different sh.exe which will be
part of the next WinARM) but most of the work should be done. Tests of
the keyboard- and mouse-emulation with an AT91SAM7S-EK Board (with
AT91SAM7S64) have been succesfull.

Martin Thomas

Martin Thomas wrote:
> As written on the page the port is preliminary and there are still some
> small incompatibilites with the makefiles and the shell (sh.exe) as
> included in WinARM 6/06


It's not sh.exe, it's make.exe that appears to be the problem.  The make
distributed with WinARM 6/06 is version 3.80.  Try substituting make
3.81 that came with OpenOCD re100.

- Joe


The process:

Building startup.o ...
/usr/bin/sh: line 2: syntax error: unexpected end of file
make: *** [startup.o] Error 258

Very strange.  What is calling sh?  Without modifying your makefiles,
when I take sh.exe out of the path, it compiles without error.

After some poking around, I noticed that using "SHELL = cmd" does not
work as described in the make manual.  If you check it with $(warning
shell= $(SHELL)), make outputs "shell= c:/winarm/utils/bin/sh.exe".
When the winarm sh.exe is removed or renamed, make sets SHELL to simply
"sh.exe".  Actually, under MS-DOS, SHELL shouldn't even have to be
specified, because make is supposed to use the MS-DOS environment
variable "COMSPEC".  But I tried this and it does not.

Specifying SHELL = cmd.exe sets shell to "C:/WINDOWS/system32/cmd.exe".
However, that does not work either.  It appears that make is calling
cmd.exe with the -c switch, when it should be /c.  So this seems more
like a make.exe issue than a sh.exe issue.

[At this point I looked at the version of make and tried a newer
version, et voila! ]

Joe wrote:
> Martin Thomas wrote:
>> As written on the page the port is preliminary and there are still some
>> small incompatibilites with the makefiles and the shell (sh.exe) as
>> included in WinARM 6/06
>
>
> It's not sh.exe, it's make.exe that appears to be the problem.  The make
> distributed with WinARM 6/06 is version 3.80.  Try substituting make

Thanks for the detailed explanation.

I should have given more details in my first answer - sorry. Yes, the
older version of make as in WinARM 6/06 is the main reason for the
problem with the current makefiles. This is because it calls a
"Unix-Shell" with "Window-Shell" commands in the makefile. I have
suggested the workaround to rename sh.exe on the web-page since the user
does not need additional software (like a new version of make). There
are only some lines left in the makefiles of the USB-framework GNU-port
with depend on "cmd.exe"-syntax/functions, the best solution would be to
rewrite those lines to be "Unix-Shell" (bash or zsh) compatible. Then
the code will be compatible with older versions of make and can also be
built on non-Microsoft-hosts.