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 not, I'll give it a go. The documentation and source for the framework is on this page: http://www.atmel.com/dyn/products/app_notes.asp?family_id=605 - Joe
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.