Getting started with AVR-USB
Thanks for your reply, my MinGW doesnt have the header "hidsdi.h"
i read some of the comments and it does say to use the MinGW or the windows DDK version. I tried with the latter and it doesn't seem to make any major difference.
if you have it could you post the MinGW "hidsdi.h"
if anyone knows what reference it is in the usbcalls.c that is undefined could they point it out to me please?
Cheers
Rich
i read some of the comments and it does say to use the MinGW or the windows DDK version. I tried with the latter and it doesn't seem to make any major difference.
if you have it could you post the MinGW "hidsdi.h"
if anyone knows what reference it is in the usbcalls.c that is undefined could they point it out to me please?
Cheers
Rich
I just had a play around with it and managed to get it to compile. I commented "usbcalls.c" so that it includes "usb-libusb.c" rather than "usb-windows.c" , then placed "usb.h" from the libusb previously downloaded into the MinGW include directory. It seems to compile however the executable is twice the size of the supplied in the downloaded project. It opens up okay however i will not know if it works correctly until we build the hardware and test it on monday.
If it has compiled am i right in thinking it should work okay???
If it has compiled am i right in thinking it should work okay???
You modified usbcalls.c to use libusb instead of the Windows HID library. While this is the standard approach on Unix, it will probably not work on Windows.
It is easy to answer which reference is undefined, the compiler lists all those symbols. And it's also easy to answer where they should be defined: in libhid.a. The only question is why the compiler does not find them in this library.
Some other ideas:
What does
fltk-config --ldstaticflags
print when you type it in the command line?
If you change the line
LIBS= `fltk-config --ldstaticflags` $(USBLIBS)
in the Makefile to
LIBS= $(USBLIBS) `fltk-config --ldstaticflags`
does this change anything?
If you contact me through the support form by e-mail, I could mail you my version of libhid.a. Maybe you have a broken installation.
It is easy to answer which reference is undefined, the compiler lists all those symbols. And it's also easy to answer where they should be defined: in libhid.a. The only question is why the compiler does not find them in this library.
Some other ideas:
What does
fltk-config --ldstaticflags
print when you type it in the command line?
If you change the line
LIBS= `fltk-config --ldstaticflags` $(USBLIBS)
in the Makefile to
LIBS= $(USBLIBS) `fltk-config --ldstaticflags`
does this change anything?
If you contact me through the support form by e-mail, I could mail you my version of libhid.a. Maybe you have a broken installation.
entering in the command line
$ fltk-config --ldstaticflags
-mwindows -mno-cygwin -L/usr/local/lib /usr/local/lib/libfltk.a -lole32 -luuid - lcomctl32 -lwsock32
changing the makefile as u suggested did not make any difference to the output.
It is possible that there is something wrong with libhid.a as it was not present in my original installation of MinGW, which folder within my MinGW installation directory should it be present in?
$ fltk-config --ldstaticflags
-mwindows -mno-cygwin -L/usr/local/lib /usr/local/lib/libfltk.a -lole32 -luuid - lcomctl32 -lwsock32
changing the makefile as u suggested did not make any difference to the output.
It is possible that there is something wrong with libhid.a as it was not present in my original installation of MinGW, which folder within my MinGW installation directory should it be present in?
libhid.a MUST be present in your minGW installation. The compiler would complain about a missing library otherwise.
Maybe the compiler is confused by the -m flags generated by fltk-config. You could try to replace `fltk-config --ldstaticflags` with
-L/usr/local/lib /usr/local/lib/libfltk.a -lole32 -luuid - lcomctl32 -lwsock32
and if that does not help, even omit -L/usr/local/lib.
If even that does not help, please mail me your version of libhid.a. Use your operating system's Find feature to locate it if you can't find it.
Maybe the compiler is confused by the -m flags generated by fltk-config. You could try to replace `fltk-config --ldstaticflags` with
-L/usr/local/lib /usr/local/lib/libfltk.a -lole32 -luuid - lcomctl32 -lwsock32
and if that does not help, even omit -L/usr/local/lib.
If even that does not help, please mail me your version of libhid.a. Use your operating system's Find feature to locate it if you can't find it.
$ make
fluid -c gui.fl
g++ -O2 -Wall `fltk-config --cxxflags` -c automator.cpp -o automator.o
automator.cpp: In function `void mainSaveToFile()':
automator.cpp:150: warning: `fl_ask' is deprecated (declared at
C:/1.0/local/include/FL/fl_ask.H:59)
g++ -O2 -Wall `fltk-config --cxxflags` -c gui.cpp -o gui.o
gcc -O2 -Wall -c parser.c -o parser.o
gcc -O2 -Wall -c usbcalls.c -o usbcalls.o
g++ -O2 -Wall `fltk-config --cxxflags` -o Automator.exe automator.o gui.o parser.o usbcalls.o -lhid -lusb -lsetupapi -L/usr/local/lib /usr/local/lib/libfltk.a -lole32 -luuid - lcomctl32 -lwsock32
g++.exe: lcomctl32: No such file or directory
g++.exe: -E required when input is from standard input
make: *** [Automator.exe] Error 1
this is the output after both of your suggested changes, the command line does seem to chunder over the first line. Is there a possibility ive installed fltk wrongly?
see email for my library
fluid -c gui.fl
g++ -O2 -Wall `fltk-config --cxxflags` -c automator.cpp -o automator.o
automator.cpp: In function `void mainSaveToFile()':
automator.cpp:150: warning: `fl_ask' is deprecated (declared at
C:/1.0/local/include/FL/fl_ask.H:59)
g++ -O2 -Wall `fltk-config --cxxflags` -c gui.cpp -o gui.o
gcc -O2 -Wall -c parser.c -o parser.o
gcc -O2 -Wall -c usbcalls.c -o usbcalls.o
g++ -O2 -Wall `fltk-config --cxxflags` -o Automator.exe automator.o gui.o parser.o usbcalls.o -lhid -lusb -lsetupapi -L/usr/local/lib /usr/local/lib/libfltk.a -lole32 -luuid - lcomctl32 -lwsock32
g++.exe: lcomctl32: No such file or directory
g++.exe: -E required when input is from standard input
make: *** [Automator.exe] Error 1
this is the output after both of your suggested changes, the command line does seem to chunder over the first line. Is there a possibility ive installed fltk wrongly?
see email for my library
You have inserted a space character between the "-" and "lcomctl32". Please remove this space character.
Where did you send the library? Please use our web form at http://www.obdev.at/avrusb/feedback.html . This form opens a mailer window filled out with the destination address.
Where did you send the library? Please use our web form at http://www.obdev.at/avrusb/feedback.html . This form opens a mailer window filled out with the destination address.
sorry i think i was sending to the wrong place orignally, have sent an email now with libhid.a attached.
i've taken the space out of your suggested changes to the makefile. i am now receiving the same errors as before:
usbcalls.o(.text+0x50):usbcalls.c: undefined reference to `HidD_GetHidGuid@4'
usbcalls.o(.text+0x149):usbcalls.c: undefined reference to `HidD_GetAttributes@8 '
usbcalls.o(.text+0x1ad):usbcalls.c: undefined reference to `HidD_GetManufacturer String@12'
usbcalls.o(.text+0x1fd):usbcalls.c: undefined reference to `HidD_GetProductStrin g@12'
usbcalls.o(.text+0x2de):usbcalls.c: undefined reference to `HidD_SetFeature@12'
usbcalls.o(.text+0x36e):usbcalls.c: undefined reference to `HidD_GetFeature@12'
i've taken the space out of your suggested changes to the makefile. i am now receiving the same errors as before:
usbcalls.o(.text+0x50):usbcalls.c: undefined reference to `HidD_GetHidGuid@4'
usbcalls.o(.text+0x149):usbcalls.c: undefined reference to `HidD_GetAttributes@8 '
usbcalls.o(.text+0x1ad):usbcalls.c: undefined reference to `HidD_GetManufacturer String@12'
usbcalls.o(.text+0x1fd):usbcalls.c: undefined reference to `HidD_GetProductStrin g@12'
usbcalls.o(.text+0x2de):usbcalls.c: undefined reference to `HidD_SetFeature@12'
usbcalls.o(.text+0x36e):usbcalls.c: undefined reference to `HidD_GetFeature@12'
I've tried reinstalling all of the applications again. I dont think i mentionned it in this thread but the initial error i was getting is as follows:
$ make
fluid -c gui.fl
gui.fl:2: unknown version '1.0104'
g++ -O2 -Wall `fltk-config --cxxflags` -c automator.cpp -o automator.o
g++ -O2 -Wall `fltk-config --cxxflags` -c gui.cpp -o gui.o
gcc -O2 -Wall -c parser.c -o parser.o
gcc -O2 -Wall -c usbcalls.c -o usbcalls.o
g++ -O2 -Wall `fltk-config --cxxflags` -o Automator.exe automator.o gui.o parse r.o usbcalls.o `fltk-config --ldstaticflags` -lhid -lusb -lsetupapi
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe: cannot find -lusb
make: *** [Automator.exe] Error 1
i think i researched this error an found that its looking for libusb an not finding it. I think that i got around this by copying the libusb file across to mingw. Or maybe installing libusb. Ive been told i dont need to to install libusb? Maybe this could help suggest where im going wrong? My other thoughts are that maybe i should be linking to the WinAVR libraries somehow?
$ make
fluid -c gui.fl
gui.fl:2: unknown version '1.0104'
g++ -O2 -Wall `fltk-config --cxxflags` -c automator.cpp -o automator.o
g++ -O2 -Wall `fltk-config --cxxflags` -c gui.cpp -o gui.o
gcc -O2 -Wall -c parser.c -o parser.o
gcc -O2 -Wall -c usbcalls.c -o usbcalls.o
g++ -O2 -Wall `fltk-config --cxxflags` -o Automator.exe automator.o gui.o parse r.o usbcalls.o `fltk-config --ldstaticflags` -lhid -lusb -lsetupapi
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe: cannot find -lusb
make: *** [Automator.exe] Error 1
i think i researched this error an found that its looking for libusb an not finding it. I think that i got around this by copying the libusb file across to mingw. Or maybe installing libusb. Ive been told i dont need to to install libusb? Maybe this could help suggest where im going wrong? My other thoughts are that maybe i should be linking to the WinAVR libraries somehow?
This libusb is NOT the same as libusb-win32. The former is a standard Windows library and should ship with MinGW (at least my version has it), the latter is an abstraction library around the Windows USB functionality.
It looks as if your version of MinGW had been compiled without USB support. I can mail you libusb.a, but maybe other things are missing as well.
It looks as if your version of MinGW had been compiled without USB support. I can mail you libusb.a, but maybe other things are missing as well.
Compiling again
Hi,
I need to get the automator project to compile using Microsoft Visual studios 6.0. How feasable do you think this is? Other than aquiring to fluid libraries and the windows DDK what else might i have to do?
Regards
Rich
I need to get the automator project to compile using Microsoft Visual studios 6.0. How feasable do you think this is? Other than aquiring to fluid libraries and the windows DDK what else might i have to do?
Regards
Rich
Hi,
gave up on using Visual Studio's a while ago. We're encountering major problems with the automator. initially we had the device working to the extent we could write code to the eeprom and retrieve it. which is essentially what we are after for our application. no it randomly stopped working after a couple of weeks. we had swapped out all of the components in the circuit and had pretty much given up hope on it working again when it started working again a couple of nights ago. When in a lab earlier on it then stopped working again. We tested it on a couple of machines. However when returning home and plugging the device into another laptop it appeared to be working again. Is there any reason why the automator should enumerate on certain machines but not any others? and if so a way around it? we are basically getting the unrecognised usb device error when plugging the device in (what i mean by not working)
does the pc store a memory of previous devices maybe and could this be causing conflicts? if so can these be deleted?
regards
Rich
gave up on using Visual Studio's a while ago. We're encountering major problems with the automator. initially we had the device working to the extent we could write code to the eeprom and retrieve it. which is essentially what we are after for our application. no it randomly stopped working after a couple of weeks. we had swapped out all of the components in the circuit and had pretty much given up hope on it working again when it started working again a couple of nights ago. When in a lab earlier on it then stopped working again. We tested it on a couple of machines. However when returning home and plugging the device into another laptop it appeared to be working again. Is there any reason why the automator should enumerate on certain machines but not any others? and if so a way around it? we are basically getting the unrecognised usb device error when plugging the device in (what i mean by not working)
does the pc store a memory of previous devices maybe and could this be causing conflicts? if so can these be deleted?
regards
Rich