cloudy

Author Topic: Found a new way to handle the HID USB using API  (Read 966 times)

0 Members and 1 Guest are viewing this topic.

Offline Weather Display

  • Posts: 65,579
Found a new way to handle the HID USB using API
« on: November 25, 2011, 09:59:46 PM »
I found some sample code that uses the built in API routines for handling HID USB (e.g WMR100/200, Irox stations)
so I just now need to make some calls to those routines...
the routines get around the problem had previously where the Mac would take over control of the HID device (thinking it was a mouse or keyboard)
so if I get this to work, will not need to rely on weathersnoop to supply a data feed

Offline plex_dk

  • Posts: 288
  • Denmark
Re: Found a new way to handle the HID USB using API
« Reply #1 on: November 26, 2011, 07:43:59 AM »
Hi Windy

I'm really looking forward to this new improvement... 8)

I would like to return to the Mac version, but not before it's rock stable, and without weathersnoop.

Cheers

Offline Weather Display

  • Posts: 65,579
Re: Found a new way to handle the HID USB using API
« Reply #2 on: November 26, 2011, 04:43:53 PM »
reports are that the latests .zip updates are stable (unless you use FTP/real time ftp and you have an unstable internet or a ftp server that is slow or non responsive at times etc...the solution there would be to instead use scripts to ftp the needed files)

Offline ejeklint

  • Posts: 25
  • OS/Browser:
  • Mac OS X 10.7.3
  • Safari 5.1.3
Re: Found a new way to handle the HID USB using API
« Reply #3 on: January 05, 2012, 01:48:39 PM »
In case you're interested, here's working driver for Mac OS X HID manager. This particular implementation is for WMR100 or compatible devices.

https://github.com/ejeklint/Cloudya/blob/master/daemon/WMR100NDeviceController.m

Offline Weather Display

  • Posts: 65,579
  • OS/Browser:
  • Win 7/Srvr 2008R2
  • Firefox 9.0.1
Re: Found a new way to handle the HID USB using API
« Reply #4 on: January 06, 2012, 02:06:48 AM »
Hi
looks good
does it do the initialisation OK?
(i.e in testing of the one I found I still had to initialise on windows first)
Are you also good at windows HID API  calls?

Offline ejeklint

  • Posts: 25
  • OS/Browser:
  • Mac OS X 10.7.3
  • Safari 5.1.3
Re: Found a new way to handle the HID USB using API
« Reply #5 on: January 09, 2012, 12:46:59 PM »
Hi, sorry for long delay, I forgot to switch on the Mail notifications...

Yes the code initializes the Oregon Stations properly (I have WMR100 and WMRS200) and is very stable. It also should work as a basic driver with any HID-based USB station, just enter the proper vendor/device ID and replace the function that assembles the readings from the station.

Is the code you had available somewhere? I could take a look and see why it fails initializing. Shouldn't be too hard.

Unfortunately I'm completely newbie when it concerns Windows USB stuff so I can't help you with that. But I do know that there's a HID manager for C# that's supposedly rather easy to implement stuff with.

Offline Weather Display

  • Posts: 65,579
  • OS/Browser:
  • Mac OS X 10.5
  • Firefox 9.0.1
Re: Found a new way to handle the HID USB using API
« Reply #6 on: January 22, 2012, 09:26:36 PM »
Hi
just getting around to looking at this
https://github.com/ejeklint/Cloudya/blob/master/daemon/WMR100NDeviceController.m
do you have this compiled and working in xcode?
if so, could you send me that xcode project
or better yet are you able to compile it as a c++ shared library file?

I tried compiling, but its missing WMR100NDeviceController.h

thanks!

Offline Weather Display

  • Posts: 65,579
  • OS/Browser:
  • Mac OS X 10.5
  • Firefox 9.0.1
Re: Found a new way to handle the HID USB using API
« Reply #7 on: January 22, 2012, 09:31:29 PM »
I have found were you had made a xcode project available
http://lists.apple.com/archives/usb/2009/Aug/msg00029.html

looks like it requires OS 10.6
which I do not have

Offline ejeklint

  • Posts: 25
  • OS/Browser:
  • Mac OS X 10.7.3
  • Safari 5.1.3
Re: Found a new way to handle the HID USB using API
« Reply #8 on: January 22, 2012, 09:58:55 PM »
Hi
just getting around to looking at this
https://github.com/ejeklint/Cloudya/blob/master/daemon/WMR100NDeviceController.m
do you have this compiled and working in xcode?
if so, could you send me that xcode project
or better yet are you able to compile it as a c++ shared library file?

I tried compiling, but its missing WMR100NDeviceController.h

thanks!

Yes it compiles fine in Xcode, and the .h file is on Github too: https://github.com/ejeklint/Cloudya/tree/master/daemon

As for Mac OS version, I believe that the new HID manager was introduced in 10.5 so it really should work for 10.5 too. I'm not sure if I can set up a 10.5 compatible Xcode project since I'm on latest version myself, but I'll give it a go tomorrow. Otherwise a simple makefile should do the trick.

Offline Weather Display

  • Posts: 65,579
  • OS/Browser:
  • Win 7/Srvr 2008R2
  • Firefox 9.0.1
Re: Found a new way to handle the HID USB using API
« Reply #9 on: January 22, 2012, 10:04:04 PM »
Hi
I have tried compiling in xcode by get lots of errors
in NSobjCRuntime.h
I might be missing some development libraries

it would be really good if you could compile a .dylib where I can call that with some functon calls
e.g to open/close the USB port
and to get the raw data packets passed through


Offline ejeklint

  • Posts: 25
  • OS/Browser:
  • Mac OS X 10.7.3
  • Safari 5.1.3
Re: Found a new way to handle the HID USB using API
« Reply #10 on: January 23, 2012, 03:27:04 PM »
Hi
I have tried compiling in xcode by get lots of errors
in NSobjCRuntime.h
I might be missing some development libraries

it would be really good if you could compile a .dylib where I can call that with some functon calls
e.g to open/close the USB port
and to get the raw data packets passed through

I cleaned out the Objective-c stuff from the file and supply a simple Makefile to build a dylib. Note that while it compiles fine for me, I haven't actually tested it after the cleanup and I've only built it on Lion since that's what I have. But I hope it helps as an example.

Offline Weather Display

  • Posts: 65,579
  • OS/Browser:
  • Win 7/Srvr 2008R2
  • Firefox 9.0.1
Re: Found a new way to handle the HID USB using API
« Reply #11 on: January 23, 2012, 05:02:14 PM »
Hi
thanks very much, I was able to compile it OK (using make)
so now I will try callling the functions and see what happens :)

Offline Weather Display

  • Posts: 65,579
  • OS/Browser:
  • Mac OS X 10.5
  • Firefox 9.0.1
Re: Found a new way to handle the HID USB using API
« Reply #12 on: January 23, 2012, 06:43:45 PM »
Hi
before trying to call the .dylib, as a test,
I tried creating a xcode program using your code
and compiled in C as a command line ultility (tool)
but I get all these errors
Building target “hidtestnew” of project “hidtestnew” with configuration “Debug” — (22 errors, 3 warnings)
       cd /Users/mareehamilton/test/wmr100driver/hidtestnew
    /Developer/usr/bin/gcc-4.0 -x c -arch i386 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -isysroot /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue -mmacosx-version-min=10.5 -gdwarf-2 -iquote /Users/mareehamilton/test/wmr100driver/hidtestnew/build/hidtestnew.build/Debug/hidtestnew.build/hidtestnew-generated-files.hmap -I/Users/mareehamilton/test/wmr100driver/hidtestnew/build/hidtestnew.build/Debug/hidtestnew.build/hidtestnew-own-target-headers.hmap -I/Users/mareehamilton/test/wmr100driver/hidtestnew/build/hidtestnew.build/Debug/hidtestnew.build/hidtestnew-all-target-headers.hmap -iquote /Users/mareehamilton/test/wmr100driver/hidtestnew/build/hidtestnew.build/Debug/hidtestnew.build/hidtestnew-project-headers.hmap -F/Users/mareehamilton/test/wmr100driver/hidtestnew/build/Debug -I/Users/mareehamilton/test/wmr100driver/hidtestnew/build/Debug/include -I/Users/mareehamilton/test/wmr100driver/hidtestnew/build/hidtestnew.build/Debug/hidtestnew.build/DerivedSources/i386 -I/Users/mareehamilton/test/wmr100driver/hidtestnew/build/hidtestnew.build/Debug/hidtestnew.build/DerivedSources -c /Users/mareehamilton/test/wmr100driver/hidtestnew/main.c -o /Users/mareehamilton/test/wmr100driver/hidtestnew/build/hidtestnew.build/Debug/hidtestnew.build/Objects-normal/i386/main.o
/Users/mareehamilton/test/wmr100driver/hidtestnew/main.c: In function 'Setup_HIDManager':
/Users/mareehamilton/test/wmr100driver/hidtestnew/main.c:108: warning: initialization from incompatible pointer type
/Users/mareehamilton/test/wmr100driver/hidtestnew/main.c:110: warning: initialization from incompatible pointer type
/Users/mareehamilton/test/wmr100driver/hidtestnew/main.c: At top level:
/Users/mareehamilton/test/wmr100driver/hidtestnew/main.c:5: warning: 'gHidDeviceRef' defined but not used
      /Users/mareehamilton/test/wmr100driver/hidtestnew/main.c:108: warning: initialization from incompatible pointer type
      /Users/mareehamilton/test/wmr100driver/hidtestnew/main.c:110: warning: initialization from incompatible pointer type
      /Users/mareehamilton/test/wmr100driver/hidtestnew/main.c: At top level:
      /Users/mareehamilton/test/wmr100driver/hidtestnew/main.c:5: warning: 'gHidDeviceRef' defined but not used
       cd /Users/mareehamilton/test/wmr100driver/hidtestnew
    setenv MACOSX_DEPLOYMENT_TARGET 10.5
    /Developer/usr/bin/gcc-4.0 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -L/Users/mareehamilton/test/wmr100driver/hidtestnew/build/Debug -F/Users/mareehamilton/test/wmr100driver/hidtestnew/build/Debug -filelist /Users/mareehamilton/test/wmr100driver/hidtestnew/build/hidtestnew.build/Debug/hidtestnew.build/Objects-normal/i386/hidtestnew.LinkFileList -mmacosx-version-min=10.5 -o /Users/mareehamilton/test/wmr100driver/hidtestnew/build/Debug/hidtestnew
Undefined symbols:
  "_kCFTypeDictionaryValueCallBacks", referenced from:
      _kCFTypeDictionaryValueCallBacks$non_lazy_ptr in main.o
  "_CFRelease", referenced from:
      _Setup_HIDManager in main.o
  "_IOHIDDeviceGetProperty", referenced from:
      _IOHIDDevice_GetLongProperty in main.o
  "_kCFTypeDictionaryKeyCallBacks", referenced from:
      _kCFTypeDictionaryKeyCallBacks$non_lazy_ptr in main.o
  "_IOHIDDeviceRegisterInputReportCallback", referenced from:
      _Handle_DeviceMatchingCallback in main.o
  "_IOHIDManagerSetDeviceMatching", referenced from:
      _Setup_HIDManager in main.o
  "_IOHIDManagerOpen", referenced from:
      _Setup_HIDManager in main.o
  "___CFConstantStringClassReference", referenced from:
      cfstring=MaxInputReportSize in main.o
  "_CFNumberGetValue", referenced from:
      _IOHIDDevice_GetLongProperty in main.o
  "_CFDictionaryCreate", referenced from:
      _Setup_HIDManager in main.o
  "_IOHIDManagerCreate", referenced from:
      _Setup_HIDManager in main.o
  "_IOHIDManagerScheduleWithRunLoop", referenced from:
      _Setup_HIDManager in main.o
  "_IOHIDManagerRegisterDeviceRemovalCallback", referenced from:
      _Setup_HIDManager in main.o
  "_IOHIDManagerRegisterDeviceMatchingCallback", referenced from:
      _Setup_HIDManager in main.o
  "_CFRunLoopGetCurrent", referenced from:
      _Setup_HIDManager in main.o
  "_kCFRunLoopDefaultMode", referenced from:
      _kCFRunLoopDefaultMode$non_lazy_ptr in main.o
  "_CFNumberCreate", referenced from:
      _Setup_HIDManager in main.o
      _Setup_HIDManager in main.o
  "_CFGetTypeID", referenced from:
      _IOHIDDevice_GetLongProperty in main.o
      _IOHIDDevice_GetLongProperty in main.o
  "_CFNumberGetTypeID", referenced from:
      _IOHIDDevice_GetLongProperty in main.o
  "_kCFAllocatorDefault", referenced from:
      _kCFAllocatorDefault$non_lazy_ptr in main.o
  "_IOHIDDeviceGetTypeID", referenced from:
      _IOHIDDevice_GetLongProperty in main.o
  "_IOHIDDeviceSetReport", referenced from:
      _Handle_DeviceMatchingCallback in main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
        "_kCFTypeDictionaryValueCallBacks", referenced from:
            _kCFTypeDictionaryValueCallBacks$non_lazy_ptr in main.o
        "_CFRelease", referenced from:
            _Setup_HIDManager in main.o
        "_IOHIDDeviceGetProperty", referenced from:
            _IOHIDDevice_GetLongProperty in main.o
        "_kCFTypeDictionaryKeyCallBacks", referenced from:
            _kCFTypeDictionaryKeyCallBacks$non_lazy_ptr in main.o
        "_IOHIDDeviceRegisterInputReportCallback", referenced from:
            _Handle_DeviceMatchingCallback in main.o
        "_IOHIDManagerSetDeviceMatching", referenced from:
            _Setup_HIDManager in main.o
        "_IOHIDManagerOpen", referenced from:
            _Setup_HIDManager in main.o
        "___CFConstantStringClassReference", referenced from:
            cfstring=MaxInputReportSize in main.o
        "_CFNumberGetValue", referenced from:
            _IOHIDDevice_GetLongProperty in main.o
        "_CFDictionaryCreate", referenced from:
            _Setup_HIDManager in main.o
        "_IOHIDManagerCreate", referenced from:
            _Setup_HIDManager in main.o
        "_IOHIDManagerScheduleWithRunLoop", referenced from:
            _Setup_HIDManager in main.o
        "_IOHIDManagerRegisterDeviceRemovalCallback", referenced from:
            _Setup_HIDManager in main.o
        "_IOHIDManagerRegisterDeviceMatchingCallback", referenced from:
            _Setup_HIDManager in main.o
        "_CFRunLoopGetCurrent", referenced from:
            _Setup_HIDManager in main.o
        "_kCFRunLoopDefaultMode", referenced from:
            _kCFRunLoopDefaultMode$non_lazy_ptr in main.o
        "_CFNumberCreate", referenced from:
            _Setup_HIDManager in main.o
            _Setup_HIDManager in main.o
        "_CFGetTypeID", referenced from:
            _IOHIDDevice_GetLongProperty in main.o
            _IOHIDDevice_GetLongProperty in main.o
        "_CFNumberGetTypeID", referenced from:
            _IOHIDDevice_GetLongProperty in main.o
        "_kCFAllocatorDefault", referenced from:
            _kCFAllocatorDefault$non_lazy_ptr in main.o
        "_IOHIDDeviceGetTypeID", referenced from:
            _IOHIDDevice_GetLongProperty in main.o
        "_IOHIDDeviceSetReport", referenced from:
            _Handle_DeviceMatchingCallback in main.o
      ld: symbol(s) not found
      collect2: ld returned 1 exit status
Build failed (22 errors, 3 warnings)



any ideas?

Offline ejeklint

  • Posts: 25
  • OS/Browser:
  • Mac OS X 10.7.3
  • Safari 5.1.3
Re: Found a new way to handle the HID USB using API
« Reply #13 on: January 23, 2012, 07:20:48 PM »
Looks like link errors to me. You must add the libraries IOKit.framework and CoreFoundation.framework to your Xcode project.

Offline Weather Display

  • Posts: 65,579
  • OS/Browser:
  • Mac OS X 10.5
  • Firefox 9.0.1
Re: Found a new way to handle the HID USB using API
« Reply #14 on: January 23, 2012, 07:57:11 PM »
that worked, thanks
now I need to add some code to open and then get the data....

 

cumulus