So I have been talking with the libusb folks and of course Lionel and I think I have a working libusb-1.0 based setup for TILP. This is not a final patch and is more of a hack so I can test code but I can work on more clean up later. What I really need to know is how stable it is and does it work with the Nspire, those are the two things that I can't really test myself.

For Arch Linux users here is a source package.

For everyone else you need this patch and to put this file link_usb1.c in libticables/src/linux. I will work in making a modified version of Lionels install_tilp.sh script in a few and edit this post with it once I am done.

Please post your results below stating which calc, cable and Linux distro you have tried it on and if you encountered any issues. Thanks for your help.

Also, if anyone with decent C experience wants to look through it to tell me where it could be improved be my guest, its still more or less PoC and still needs a lot of cleanup.

EDIT: here is a script based on Lionel's install_tilp.sh that should work for installing on Ubuntu and other distros, but I don't really have a way of testing it. install_tilp.sh and remember to post your results after testing it.
Umm, could you explain what I should do if I am running Ubuntu? (like how to install the .patch file, etc.)

Edit: Figured it out and installed, will test tomorrow.

Edit2: It works with a TI 84+SE on Ubuntu. Very Happy
Just a quick not to self on this.
Things to do before calling this done.
    1. Add a configure option to enable or disable this as well as check for libusb1.0 during configure.
    2. See if the asynchronous API will not be to difficult to implement and if not use that instead.
    3. Clean up gcc warnings
    4. Add a function to translate libusb return codes into readable error messages.
    5. See if using libusb-1.0 on Windows is practical, the code is at least a bit more maintainable in its current state.
    6. test test test test
Very cool Jonimus. Does TILP Mac make use of libusb by any chance?
Yes, it does nowadays.
Last week-end, I compiled libti* + gfm + tilp on MacOS X (with libusb 0.1.x) without a hitch.
Yeah macports has it all set to go, it worked great on my Dual G5 machine so you shouldn't have any issues.
TheStorm wrote:
Yeah macports has it all set to go, it worked great on my Dual G5 machine so you shouldn't have any issues.


I'm on Intel, which occasionally makes a difference, but good to hear. How would I go about interrupting the MacPorts build process to install and test your patch? I've only used it for building the official portfiles thus far.
MacPorts does some useful patches (GTK+ 2.18+ and 2.22+ compatibility) without notifying upstream, BTW Sad
And their tiemu package is 3.02.

As I wrote on #cemetech, to ease the testing and integration, I'll modify the autotools stuff for the purpose of providing the choice between libusb 0.1.x and libusb 1.x. I had found a link which shows how to do that, it should be mostly copy&paste.
Oh well, right now I'm not even sure if libusb-1.0 works on Mac OS X properly, I'll have to do some research and if I get it figured out I'll post a portfile for you, unless Lionel gets to it first.
Sounds good.
Lionel Debroux wrote:
MacPorts does some useful patches (GTK+ 2.18+ and 2.22+ compatibility) without notifying upstream, BTW Sad
And their tiemu package is 3.02.

As I wrote on #cemetech, to ease the testing and integration, I'll modify the autotools stuff for the purpose of providing the choice between libusb 0.1.x and libusb 1.x. I had found a link which shows how to do that, it should be mostly copy&paste.
On a related note the GTK dev's are saying 2.22 is now stable on windows again so we can now ship a newer version of that as well.
elfprince: I don't know how to interrupt ports to add a patch.
However, for building from SVN (which will bring you UI improvements already made by Jonimus, a number of bugfixes for crasher bugs, and several new features), I really suggest using http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh Smile

Jonimus: that's on the todo list Wink
Lionel Debroux wrote:
elfprince: I don't know how to interrupt ports to add a patch.
However, for building from SVN (which will bring you UI improvements already made by Jonimus, a number of bugfixes for crasher bugs, and several new features), I really suggest using http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh Smile

Jonimus: that's on the todo list Wink
You should be able to just put a url for the patch into the portfile and macports will do the rest but I'm not 100% on that.
Oh, if libusb works on Mac OS X, then Direct USB and the $10 Bridge will be nice and easy, but I digress. I'll definitely test this out on Ubuntu, since that's what I roll with. Smile Sounds like it works well so far, though.
KermMartian wrote:
Oh, if libusb works on Mac OS X, then Direct USB and the $10 Bridge will be nice and easy, but I digress. I'll definitely test this out on Ubuntu, since that's what I roll with. Smile Sounds like it works well so far, though.
The only major OS that libusb doesn't support is Solaris as far as I can see.
WIP patches for integrating libusb 1.0.x support alongside libusb 0.1.x support, which are meant to replace the "this patch" in the first post:
http://lpg.ticalc.org/prj_tilp/beta/0001-libticables-add-autotools-infrastructure-for-buildin.patch
http://lpg.ticalc.org/prj_tilp/beta/0002-WIP-libticables-add-glue-code-for-libusb-1.0-support.patch

Usage: apply them to SVN HEAD before putting the link_usb1.c file posted in the first post.

Thanks Jon for your work Wink
Nice work, Jonimus. Was my code helpful at all, or does libusbnet diverge too much?
Superb, then that's good for everyone, including TiLP. Smile Has anyone else tried this yet? I'm afraid I won't get a chance until this evening.
Merth your code was helpful to see if I was sane or not, but libusbdotnet abstracts things a lot more than the underlying library which makes sense for its uses.

Thanks Lionel for those patches I will update the original post with them as soon as I get a chance.

Also it appears libusd_strerror() will not be coming till 1.0.9 so we'll have to decide if we wish to use it or if we should just use our own hard coded error messages until most distros are shipping 1.0.9 or adding some ifdef's and checking for 1.0.9 in our configure but that makes the code a bit more messy than I'd like.
Well, Debian is shipping 1.0.8 and won't be changing for a while, probably even in backports (which are now officially part of the project)... Likewise for Ubuntu 10.04 LTS.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement