Getting started with AVR-USB

General discussions about V-USB, our firmware-only implementation of a low speed USB device on Atmel's AVR microcontrollers
Rich

Post by Rich » Sun Feb 11, 2007 2:32 pm

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

Rich

Post by Rich » Sun Feb 11, 2007 4:42 pm

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

christian
Objective Development
Objective Development
Posts: 1443
Joined: Thu Nov 09, 2006 11:46 am

Post by christian » Sun Feb 11, 2007 6:26 pm

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.

Rich

Post by Rich » Sun Feb 11, 2007 7:59 pm

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?

christian
Objective Development
Objective Development
Posts: 1443
Joined: Thu Nov 09, 2006 11:46 am

Post by christian » Sun Feb 11, 2007 11:58 pm

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.

Rich

Post by Rich » Mon Feb 12, 2007 1:39 am

$ 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

christian
Objective Development
Objective Development
Posts: 1443
Joined: Thu Nov 09, 2006 11:46 am

Post by christian » Mon Feb 12, 2007 11:20 am

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.

Rich

Post by Rich » Mon Feb 12, 2007 4:33 pm

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'

Rich

Post by Rich » Mon Feb 12, 2007 6:00 pm

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?

Rich

Post by Rich » Mon Feb 12, 2007 8:16 pm

Thank you for your help, replacing libhid.a with the file u sent has sorted it all out!

Cheers

christian
Objective Development
Objective Development
Posts: 1443
Joined: Thu Nov 09, 2006 11:46 am

Post by christian » Mon Feb 12, 2007 8:18 pm

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.

christian
Objective Development
Objective Development
Posts: 1443
Joined: Thu Nov 09, 2006 11:46 am

Post by christian » Mon Feb 12, 2007 8:22 pm

I'm glad to read that replacing libhid.a did the trick!

Rich

Compiling again

Post by Rich » Fri Feb 23, 2007 7:41 pm

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

christian
Objective Development
Objective Development
Posts: 1443
Joined: Thu Nov 09, 2006 11:46 am

Post by christian » Wed Mar 07, 2007 1:50 pm

I have never tried MS Visual Studio myself, so I can't comment...

Rich

Post by Rich » Tue Mar 20, 2007 6:13 pm

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

Post Reply