d2xx in visual basic 6

I'm on my 3rd day of googling the subject, now I post my first question looking for help. :)

I haven't found much about the direct interface api's, mostly just the official pdf's. I need a reliable class written in visual basic 6 to connect to the arduino without the com port. I think maybe I don't know what key words to search for to find what I'm looking for. there must be other people needing a similar class. is there anything out there before I start developing my own?

I need a reliable class written in visual basic 6 to connect to the arduino without the com port.

Can you explain why you need to communicate with an Arduino but not using a serial port? Hardware-wise, how would this be accomplished?

I google the item in his subject, it's an FTDI feature:

http://www.ftdichip.com/Drivers/D2XX.htm

Possibly you could transmit things faster using your own protocol.

Code examples are here: http://www.ftdichip.com/Projects/CodeExamples.htm

I have looked over everything on the ftdi website. the examples are, as to be expected, incomplete and not very useful. the example for visual basic communication, I couldn't get to work on it's own. I had to dig up some older code that I've worked with before to modify the example to make it work. on my 3rd day of messing with it and not getting any successful communication, I finally realized, I've used this api before with the uChameleon device!

yes, I believe you're right. you can get slightly faster transfer rates/better performance by using the direct interface driver, as apposed to the virtual com port. I was surprised more people didn't use it, then I remembered, most arduino projects are only temporary hobby projects, not something that would have thousands of hours put into the code.

Can you explain why you need to communicate with an Arduino but not using a serial port? Hardware-wise, how would this be accomplished?

I suspect most arduino users are unaware that it does come with both a virtual com port driver and a direct interface driver on windows. nothing at all needs to be changed on the arduino side of things, but you do need to know the right api's and how to use them properly in the computer program.

maybe this is actually something I can contribute to the community, a usable d2xx class/api wrapper. anyone care to help me write up a quick tutorial after a class is put together?

I don't know why there's not more information about this topic on the internet or this forum. I think it's a great driver to use, and it's already installed on the users system along side the virtual com driver without the slightest notice.

what it really does is take an extra layer out of the communication path. it gives you direct control of the device identification, instead of assigning it a port number and hoping the correct device is assigned to that port. the way it works, you first call a function that returns the number of supported devices are currently connected. the next function you call returns a list of serial numbers for each device. you can then call a function to open a connection to the device over the d2xx driver, calling on it by serial number. there are functions for calling read or write, and the other serial port settings being accessed from the chip. when you're done, you close it. (example serial number from one of my devices: A600bMwu)

I'm starting work on the class this weekend, as I have a need for it.

all the good news out of the way, here's the bad. I melted my keyboard again with a solder iron. someone cover my keyboard with their hand to protect it for me please, I'll give you 5 bucks.

You know you could get a soldering iron holder for not much more than $5. http://www.radioshack.com/product/index.jsp?productId=2062740

You know you could get a soldering iron holder for not much more than $5. http://www.radioshack.com/product/index.jsp?productId=2062740

I have a weller station. I did it while holding the tip up and trying to adjust something. it's fine.. just yell so I know I'm burning something.

Now I understand why you want to use it. The thing with the serial number can be verry handy.

Now I understand why you want to use it. The thing with the serial number can be verry handy.

Unfortunately, it seems to be a "windows only" thing...

:(

I’m not sure if it’s Windows only:

Instructions for installing the d2xx shared lib
As Linux distributions vary these instructions are a guide to installation and use.
This setup works with Mandrake 9.2 but may require some investigation on other distributions.

This library has been tested using kernel 2.4.25. 

D2XX documentation is available for the Windows dll - some variations may occur between linux and 
windows implementation. We have endevoured to make the APIs appear the same on both platforms however some
issues may slip and we would appreciate that you contact support if you observe this.

D2XX for linux was primarily developed to aid porting windows applications written with D2XX to linux.
Unfortunately the source code for D2XX is not freely available - however if you prefer to have the 
source and are starting a project from scratch you can try libftdi from Thomas Jarosch. 
Details of this library are on the ftdi web site. 



libftd2xx uses an unmodified version of libusb (http://libusb.wiki.sourceforge.net/).  
Source code for libusb is included in the driver distribution in the libusb-0.1.12 directory.

This is taken from the readme file for linux

sadly, linux is often left behind. there is a driver available on their website, but it hasn’t been updated since 2008. I have a hard enough time finding anyone who uses the d2xx driver on windows, let alone linux.

do the arduino’s reset with the dtr pin on linux like they do on windows? that is another great side effect of using the d2xx driver, I found the arduino doesn’t reset when you connect to it, and I can call setdtr and clrdtr to send a reset signal to the arduino from my program. on my windows xp system, if you plug in a new arduino, all the other arduino’s already connected to usb all still reset, so it’s only a partial fix to the problem of unwanted resets. I like the idea of cutting the reset-en point and using a small jumper between a pin on the x3 header and the icsp header. it’s the closest we can currently get to having a jumper or small switch right on the board.

hey, question here. this schematic has a reset lead going to rts also. why? http://mlab.taik.fi/paja/wp-content/uploads/2009/04/arduino_ng_diecimila_schematic.jpg

as an update, I do have a working class put together and working well. I’m happy with it so far. the only thing not done is the read function. I don’t have much to go off with this part.

Success! I have an arduino plugged into a windows machine by usb. I can connect to the device and plug other arduino's in to the same hub without a reset and without modifying the hardware!!

my d2xx class is almost finished, just putting final touches on it and finishing a test program for it. using the class prevents the arduino from resetting automatically when you connect to it. unfortunately, the only way to prevent it from also resetting when other devices are plugged in, is to disable the com port associated with it. I haven't found a way to do this in code yet, but I'll be looking into it, if even possible.

I know this information will be useful to people, I think they just haven't found it yet. any ideas on that?

I know this information will be useful to people, I think they just haven't found it yet. any ideas on that?

I think people found out that VB6 was superseeded by VB.NET close to a decade ago. The serial driver in VB.NET (which is basically a class wrapper on the core Windows API) does not suffer from any of the limitations in VB6 and works very well not only with FTDI, but also with all other USB/serial flavors, such as drivers from Prolific.

There is no performance/speed gain from using D2XX compared to using the Windows serial drivers. Speed is limited by physical media only (serial baudrate). Even for an experienced developer, it would be very hard to even match the current performance (e.g. CPU overhead) and feature set of the Windows serial driver with a D2XX implementation.

When VB6 was a popular choice for Windows GUI development, it was already common to implement serial communication in a C/C++ DLL (using the Windows core API) and use this from VB6 whenver the native implementaion imposed limitations. This allowed full control of RS232 signaling (including DTR/RTS), hardware and software flow control, input and output buffer handling, non standard baudrates etc. With VB.NET however, there is no longer a need for this, thanks to its comprehensive class wrapper. The D2XX shares this heritage and is more a relic of the past than a base for new development on Windows.

there are still die-hard vb6 fans out there. I'm a fan of what works well for me. I have my reasons for still using vb6, but I wont go into a rant. I use it, if anyone else wants to, they are welcome to my code.