NXT access via USB on OSX

[skoehler]

Hi,

I'm currently a leJOS developer. The fantom driver is not exactly the best piece of software, and it would be nice to bypass it using some native OSX USB API. However, I have no clue about OSX and any USB APIs that it might offer.
In the old nxtasy forums, somebody told me that there would be some piece of software which was using some native OSX USB API to access the NXT brick. However, I don't remember the name of the software or where I could get it.

So if anybody what I'm talking about, or if the developer is still around, please let me know.


Regards,
Sven

[tcwan]

Hi,

I'm currently a leJOS developer. The fantom driver is not exactly the best piece of software, and it would be nice to bypass it using some native OSX USB API. However, I have no clue about OSX and any USB APIs that it might offer.
In the old nxtasy forums, somebody told me that there would be some piece of software which was using some native OSX USB API to access the NXT brick. However, I don't remember the name of the software or where I could get it.

Regards,
Sven

Funny you should say that. I'm not sure when you refer to native OSX USB API, whether you meant using the Mac's USB Framework, or libusb?
Otherwise NI provides NI-VISA drivers to interface with the NXT, but that is a lower level interface (Fantom is built on NI-VISA), and you'd need to purchase the NI-VISA SDK ($$$) to really make use of it.

I've had zero success of using libusb on Mac OSX (via MacPorts: libusb-1.0.8.20101017, pyusb 1.0.0-a1, even libusb-legacy-0.1.12) to interface with the NXT. My testing was done using nxt-python (2.1.0) on Mac OSX 10.6.7 (Snow Leopard). Currently I'm working with Nicolas Schodet to interface the Fantom Drivers to Python http://git.ni.fr.eu.org/?p=pyfantom.git;a=summary since it is a lot more stable and reliable than libusb (or even lightaquablue for Bluetooth which only somewhat worked, but no longer after I upgraded to 10.6.7) on Mac OSX.

My testing of libusb on Windows XP with nxt-python was not successful either.

The only issue with Fantom drivers is that NI-VISA is 32-bit only, and no plans by NI to port VISA to 64-bit Mac OSX, so that may cause problems when Mac OSX Lion is shipped. I wonder if Fantom driver support in Lion would be an issue then (assuming that everything is going 64-bit in future).

[skoehler]

Funny you should say that. I'm not sure when you refer to native OSX USB API, whether you meant using the Mac's USB Framework, or libusb?

I'm refering to the usb API offered by OSX itself - that would the one that libusb is based on. Not sure, what the NI-VISA-USB layer is based on, but they may have writte their own driver to communicate with. However, the question is whether that driver can be bypassed by using some USB API that OSX offers.

Otherwise NI provides NI-VISA drivers to interface with the NXT, but that is a lower level interface (Fantom is built on NI-VISA), and you'd need to purchase the NI-VISA SDK ($$$) to really make use of it.

I see. But the Fantom driver doesn't seem to be ready for full duplex communication. From the other developers on the leJOS team I know, that you cannot have a read()-call and a write()-call at the same time. Imagine, that Thread 1 waits for data from the NXT via a blocking read()-call, while Thread 2 decides to send something to the NXT. As far as I've heard, either the read() or the write() will fail. (writing while reading is a very basic requirements for full-duplex.)

For typical LCP communication (you write a command, then you read the response, then you write the next command, and so forth), the Fantom driver is completely OK, but not for full duplex.

I've had zero success of using libusb on Mac OSX (via MacPorts: libusb-1.0.8.20101017, pyusb 1.0.0-a1, even libusb-legacy-0.1.12) to interface with the NXT. My testing was done using nxt-python (2.1.0) on Mac OSX 10.6.7 (Snow Leopard). Currently I'm working with Nicolas Schodet to interface the Fantom Drivers to Python http://git.ni.fr.eu.org/?p=pyfantom.git;a=summary since it is a lot more stable and reliable than libusb (or even lightaquablue for Bluetooth which only somewhat worked, but no longer after I upgraded to 10.6.7) on Mac OSX.

My testing of libusb on Windows XP with nxt-python was not successful either.

The only issue with Fantom drivers is that NI-VISA is 32-bit only, and no plans by NI to port VISA to 64-bit Mac OSX, so that may cause problems when Mac OSX Lion is shipped. I wonder if Fantom driver support in Lion would be an issue then (assuming that everything is going 64-bit in future).

Thanks for the info about libusb on OSX.

Note, that on Windows 32Bit, leJOS currently also uses the fantom driver, because using libusb didn't work out well (Windows doesn't really offer any good of bypassing the driver that is attached to an USB device, which kind of defeats the whole purpose of libusb). However, the Fantom driver for Windows 64 bit is based on a NI-VISA SDK which is based on winusb, which is a general purpose USB driver by Microsoft (it ships with all version of vista and above, and can be installed on Windows XP as well). Using winusb, one can in deed bypass the Fantom driver. However, Lego never updated the 32Bit Fantom driver to the winusb based version of the NI-VISA SDK. Installing the winusb-based NI-VISA layer on 32 Windows (and even on XP) is not a problem, theoretically. However, the installer for the winusb-based Fantom driver provided by Lego refuse to function on 32bit Windows.

Since the Fantom driver can only be used by 32bit software (no 64bit fantom.dll) we will most certainly switch to using winusb on Windows 64bit (since it allows our users to connect to the NXT from a 64 bit java virtual machine). On OSX, the same issue exists. As you said, the fantom driver only supports 32bit software, so in fact for connecting to the NXT from a 64bit java virtual machine on OSX, we would need to bypass the fantom driver. So that, and the full-duplex issue, is the reason I'm asking for alternative method of accessing the NXT.

[tcwan]

Sorry, your use case is much more advanced than mine. I'm just trying to get half-duplex raw-message USB communications to work reliably between the NXT and Mac OSX.

Currently I'm stumped by iNXT::read() which will throw an exception if the number of bytes to be read is greater than the number of available bytes coming from the NXT, whereas iNXT::pollAvailableLength() keeps giving me a "Command mismatch in firmware response" exception. (I'm assuming that I can use iNXT::pollAvailableLength() to check the length of the buffer return by iNXT::read())

[skoehler]

Currently I'm stumped by iNXT::read() which will throw an exception if the number of bytes to be read is greater than the number of available bytes coming from the NXT, whereas iNXT::pollAvailableLength() keeps giving me a "Command mismatch in firmware response" exception. (I'm assuming that I can use iNXT::pollAvailableLength() to check the length of the buffer return by iNXT::read())

Here's our wrapper around the fantom API:
http://lejos.svn.sourceforge.net/viewvc ... iew=markup

We don't use the C-only API, not the C++ API (I wouldn't do so if I were you - you get all sorts of problems when using C++ across binaries created by different compilers).

In particular we use nFANTOM100_iNXT_read instead of iNXT::read().

[tcwan]

Here's our wrapper around the fantom API:
http://lejos.svn.sourceforge.net/viewvc ... iew=markup

We don't use the C-only API, not the C++ API (I wouldn't do so if I were you - you get all sorts of problems when using C++ across binaries created by different compilers).

In particular we use nFANTOM100_iNXT_read instead of iNXT::read().

Actually pyfantom uses the C-interface nFANTOM100_iNXT_read(), I just wrote it out in C++ style for easy reading. Sorry for the confusion.

I see in your code that Java_lejos_pc_comm_NXTCommFantom_jfantom_1read_1data() passes the len as the size of the receiving array jdata, is the len set to be exactly the length of the expected reply from the NXT?

I find that in pyfantom if I set the length > actual pending message length, nFANTOM100_iNXT_read() would take a while to timeout and return an error status; so I can't just pass the max. size of the receive buffer to nFANTOM100_iNXT_read(), and it screws up subsequent USB communications after that.

Also, from playing with nFANTOM100_iNXT_pollAvailableLength() and nFANTOM100_iNXT_readBufferData() it seems to be for something else entirely, and not for raw data read? (I keep getting "Command mismatch in firmware response")

[gloomyandy]

Hi,
are you trying to use the fantom driver for USB or Bluetooth? I seem to remember (I wrote the original version of the leJOS Fantom interface), that the two do different things. we only use Fantom for USB and looking at our code (it has been a while since I worked on this), it seems to me that we do not try and issue exact length reads. However I seem to remember that for Bluetooth you do have to issue exact length reads (which is one of the reasons we chose not to use Fantom for Bluetooth)...

Andy

[tcwan]

Hi,
are you trying to use the fantom driver for USB or Bluetooth? I seem to remember (I wrote the original version of the leJOS Fantom interface), that the two do different things. we only use Fantom for USB and looking at our code (it has been a while since I worked on this), it seems to me that we do not try and issue exact length reads. However I seem to remember that for Bluetooth you do have to issue exact length reads (which is one of the reasons we chose not to use Fantom for Bluetooth)...

Andy

Hi Andy,

My plan is to use Fantom for either/both.
Currently I couldn't get BT to connect, possibly due to not invoking the pairing methods (I thought that Pairing is done at the device-OS level, not sure if I still need to use the iNXT functions).

When testing with USB over Fantom, I can only read up to the number of bytes present in the USB buffer (arising from a reply to a manually created Direct Command message, and transmitted using nFANTOM100_iNXT_write(). E.g., the reply has 7 bytes. I can read any combination of up to 7 bytes using nFANTOM100_iNXT_read() in multiple read operations, but if the new numberOfBytes parameter exceeds the remaining buffer length when reading, the driver will block (wait) and eventually time out with a status error.

I'm using Mac OSX to test, by the way. I'm not sure if the behavior is identical on Windows. I haven't tried nFANTOM100_iNXT_sendDirectCommand() to see if it allows for non-exact length reads, which I won't be using since I'm implementing a different low level protocol for GDB remote debugging.

[gloomyandy]

Hi,
That is very odd as I'm pretty sure we use the same code on Windows and Mac, and issue 64 bytes reads (the max size that a single USB packet can be) all of the time. Could that be your problem? Are you asking for more than 64 bytes? If you are still having problems then perhaps the way forward is to add a header byte that gives you then length and read that first which will then tell you how many bytes to actually read...

We don't use LCP for our general protocol, we simply use the connections to implement a byte stream style interface. One thing to watch out for is that on Windows at least you can not have a thread blocked on the read call and then issue a write from some other thread. Which makes the classic read/write thread pattern unusable and typically means you have to use a command/response style model if you need bi-directional comms...

Andy

[skoehler]

I added some debug statement in Java, right before we call the C code.
For example, we call read() with length 32, but only get 5 bytes in return.
Funny enough, we also call read() with length 33 and sometimes length 3.