Getting Started with Universal Serial Bus (USB)

[Supercap2F]

Hello Everyone!

Well for a while now I have been doing some studying on USB - I would really like to be able to let my computer communicate with some of my projects. I know it's going to be pretty hard, but I'm willing to take on the challenge!

So first of all, what would be the best language to program the computer side programs in? I asked a friend about it, and he recommended Visual Basic to get started in it with. But from reading some wikipedia articles, it appears that Visual Basic is out of date. I also couldn't find any resources in the form of internet or books that explain how to use USB and Visual Basic.

But from doing more research I did find a book on using C# and USB here. There seams to be more resources on line too for using USB with C#, so it might be the best route.

I also found a library on line for using USB with C/C++ and a bunch of other languages too that might work...

So really I'm just looking for any advice on where to go with this project...
Or maybe even any good/bad experiences with USB.

Thanks very much for your time!!
Dan

 

[Harald Kapp]

A common technique for using USB in hacker projects is using a USB-to-serial bridge chip (e.g. FTDI). This is the same technology that is employed in USB-to-serial (RS232) cables and you can buy off-the-shelf modules with a USB-receptacle on one side and a TTL UART interface on the other side. On the PC a driver is installed and you talk to your project essentiall via a UART connection, tunneled via USB (the PC driver installs a virtual COM port). This is an easy method and you don't have to worry about the details of the USB interface.

If you want to go for a full blown USB interface, you will need a USB identifier and you'll have to deal with the handling of the USB protocol yourself (here's an example for a software implementation for AVR microcontrollers). This is the way, however, you'lll have to go when using off-the-shelf USB products, but in that case you can use the drivers that come with these products.

Visual Basic may not be the most modern programming language, but it is easy to learn and the free visual studio edition by Microsoft is a well manageable development environment.
C# or C++ may be more modern, but the programming paradigm is diffferent. I don't want to start a flame war on programming languages and I advise you to avoid such yourself. The best programming language in my view is the one you most easily grasp. Also your prior knowledge of a programming language has an impact:

• If you already know BASIC, why learn a C-based language?
• On the other hand, if you already know BASIC, why not learn something new like a C-based language?

Since the visual studio editions by Microsoft a available with a free licence for personal use, you can give all of these languages a try at the cost of some time well spent in learning something.

You may also want to Google "USB learning kit". These kits give you a good start into mastering USB interfaces.

 

[Supercap2F]

Awesome, thanks Harald! This is just what I needed!!!

Give me a couple days to read over it and do some studying, and I will report back with what I come up with!
Dan

 

[Anon_LG]

I think there could be a rather useful resource on this topic.

Supercap, if you want a VERY easy project -> computer interface I would advise researching the teensy 3.1, the teensy 3.1 can control XY position of cursor, full mouse emulation, full keyboard emulation, joystick emulation. Of course, the only problem there is no link for computer -> project. If you need two way compatibility you probably want to go with the Harald's suggestion.

I hope this helps,

 

[Supercap2F]

A common technique for using USB in hacker projects is using a USB-to-serial bridge chip (e.g. FTDI). This is the same technology that is employed in USB-to-serial (RS232) cables and you can buy off-the-shelf modules with a USB-receptacle on one side and a TTL UART interface on the other side. On the PC a driver is installed and you talk to your project essentiall via a UART connection, tunneled via USB (the PC driver installs a virtual COM port). This is an easy method and you don't have to worry about the details of the USB interface.

Okay, I think this is the route I'm going to go down for now. Maybe when I get the FTDI chips working I can move on to actually using the raw USB signal.

Supercap, if you want a VERY easy project -> computer interface I would advise researching the teensy 3.1, the teensy 3.1 can control XY position of cursor, full mouse emulation, full keyboard emulation, joystick emulation. Of course, the only problem there is no link for computer -> project. If you need two way compatibility you probably want to go with the Harald's suggestion.

Well I have never really got into this arduino/teensy stuff. I have done some brief research on it, but it's just too easy. Also it requires you to buy or make another circuit board if you want any other circuitry, which not only increases weight but makes designs very untidy. For me, I always would just rather have a single PCB solution. I might one day do some work with the arduino/teensy stuff, but for now I think I will stay a way. Thanks very much for your suggestion anyway!
Dan

 

[Gryd3]

Pre-existing projects are your best friend here!

http://www.obdev.at/products/vusb/index.html
For AVR, although you can get the same thing for almost any other chip out there... it has all the groundwork complete already, so you just need to worry about Computer Drivers (possibly) and the higher end stuff on your micro.

 

[Harald Kapp]

Not to be nitpicking: but that's the same link I gave in #2

 

[Gryd3]

Not to be nitpicking: but that's the same link I gave in #2

Haha! It is too!
If I had checked the link I would have known

 

[Supercap2F]

Okay, I think I'll try and get back into this after a couple months break (sorry about that!).

So, from looking around on the FTDI website it looks like there are two different options for the drivers: One, use the D2XX drivers - Or two, use the Virtual COM Port drivers.
It looks like the D2XX drivers would be easier to use because it sounds like all you have to do is include a header and call different functions to operate the device. But from what I have read, the Virtual COM Port drivers sound a lot harder than that... Is that right?

Next, I don't really know what chip would be best to try and get started with. From looking at the different options, it looks like the FT201X might be pretty good since I²C is pretty easy and they have a nice development module for it... Or would it be better to go with something like the FT232R since it seams to be better supported?

And one last thing: It seams like the way this whole setup works is: Computer program calls function and sends data via the driver -> Data is stored in FTDI chip receive buffer -> Microcontroller reads data from FTDI receive buffer, and loads data to the FTDI transmit buffer -> Computer program calls function and reads data from the transmit buffer via the driver. --- Is that right, or am I way off track here?

Thanks again for your time guys!! I really appreciate it!
Dan

 

[Supercap2F]

I think I just answered all my questions - By reading the datasheet! Duh! Who would have thought?!?

It even said some stuff about how to chose the right driver! Oops!

Don't know why I didn't look their first. I guess at the time it just didn't seam like something that would be in there....
Oh-well, I'll try and keep you guys updated on my future progress.
Dan

 

[Supercap2F]

Well my UMFT201XA development module got here today, so for the last four hours I have been trying to get it going. So far I have hooked it up to my computer, and installed the drivers. But I'm having some troubles with a test program I made, here's the code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include "C:\Users\OPTIPLEX  960\AppData\Local\Temp\FTDI-Driver\ftd2xx.h" // address to the FTDI header

int main()
{
    FT_HANDLE ftHandle;
    FT_STATUS ftStatus;
  
    ftStatus = FT_Open(0,&ftHandle);
    if(ftStatus!=FT_OK)
    {
        printf("Error opening device!\n");
        return(1);
    }
  
    printf("Device opened successfully!\n");

    ftStatus = FT_Close(ftHandle);
    if(ftStatus!=FT_OK)
    {
        printf("Error closing device!\n");
        return(1);
    }
  
    printf("Device closed successfully!\n");
    return (0);
}

So I tried to compile with MinGW and got the following linker error (this was build through the NetBeans IDE):

build/Debug/MinGW-Windows/FT201X.o: In function `main':
C:\Users\OPTIPLEX  960\Documents\Electronics\Learn\FTDI\FT201X/FT201X.c:23: undefined reference to `_imp__FT_Open@8'
C:\Users\OPTIPLEX  960\Documents\Electronics\Learn\FTDI\FT201X/FT201X.c:32: undefined reference to `_imp__FT_Close@4'
collect2.exe: error: ld returned 1 exit status

I really don't have a clue about how to fix that kind of error... Could one you guys point me in the right direction? I did some googling and it appears that it has something to do with the ftd2xx.lib file being built by a different compiler than MinGW... But I really don't know.

Thanks a million guys!!
Dan

 

[Supercap2F]

Never mind! I got it working by myself again.

I post how I did it later, cause right now I'm kind of busy!
Dan

 

[Supercap2F]

Okay, so first I found out that I shouldn't be using the FTD2XX header file out of the driver folder. Instead I needed to have it in the same directory as my C source code was in. I also needed the FTD2XX.lib file which is the precompiled source code that goes with the FTD2XX header. I also found that I needed to include the stdarg, windef, winnt, and winbase header files in my source code. And after all of that, I compiled the whole thing at the command prompt using this command: gcc <C source code file name> -L./ -l<.lib file name> -o <final program name> And then it worked great!

Next I wanted to try out the Bit Bang mode before I dive deep into the I2C part. So after hours of trying to get it to work, and tons of googling, I successfully got it to work! Yay! Here it is:

#include <stdio.h>
#include <stdarg.h>
#include <windows.h>
#include <windef.h>
#include <winnt.h>
#include <winbase.h>
#include <string.h>
#include "ftd2xx.h"

#define CBUS0 0x01 // CBUS0's pin address
#define CBUS1 0x02 // CBUS1's pin address
#define MASK  0x30 // makes a pin a input or output
#define MODE  0x20 // set's the mode for FT_SetBitMode

int main()
{
    /*******************************************************
     * Variable Def                                        *
     *******************************************************/
    FT_HANDLE ftHandle;    // device handle
    FT_STATUS ftStatus;    // status holder
    unsigned char cbus[3]={0,0,0}; // create an array of chars
    int x;                 //         
    UCHAR pinvalue;        // variable that holds the pin states returned by FT_GetBitMode
 
 
    /******************************************************
     * Device setup and user prompt                       *
     ******************************************************/
    ftStatus = FT_Open(0,&ftHandle);       // open the FTDI device
    if(ftStatus!=FT_OK)                    // check if it opened
    {
        printf("Error opening device: %d\n",ftStatus); // if it isn't: print error
        return(1);                                     // and return
    }
 
    printf("Welcome to the UMFT201XA-02 module bit-bang wizard!\n"); // start up script
    printf("Press Q to quit at any time\n");                         //
     
 
    /******************************************************
     * Not so Endless loop - program quits when user      *
     * types a character                                  *
     ******************************************************/
    while(1)
    {
        puts("\nPlease enter the new state of the following I/O pins"); // user prompt
     
     
        for(x=0;x<2;x++) // this loop will spin twice
        {
            printf("CBUS%d: ",x);          // print what pin we're working with
            if(isalpha(cbus[x]=getchar())) //get the state the user entered and if it's a letter than
            {                              //
                FT_Close(ftHandle);        // close the device and
                return(0);                 // the quit program
            }
            fflush(stdin);                 // clear the input stream
     
            cbus[x]-=0x30;                 // subtract 0x30 from cbus[x] to get pure integer
            if(cbus[x]!=1 && cbus[x]!=0)   // if cbus[x] isn't a one or zero
            {                              //
                cbus[x]=0;                 // set it to zero
                printf("Cannot write CBUS%d's value to chip!\n",x); // and tell user
                puts("Writing zero instead");                       //
            }
            cbus[2]=cbus[0] | MASK | (cbus[1]<<1); // make I/O pin states acceptable to FT_SetBitMode
         
            ftStatus=FT_SetBitMode(ftHandle,cbus[2],MODE); // write I/O pin states to the device
            if(ftStatus!=FT_OK)                            // but if it didn't work
                printf("\nERROR! WRITE: %d\n",ftStatus);   // print error  
         
        }
    }
}

It asks you what you want the CBUS0 and CBUS1 pin state to be. Once you type in the states they switch to what you wanted. - I guess that's not to much, but it's a start!
Dan

 

[Fish4Fun]

SuperCap2F,

At the risk of making this too simple.....As has been pointed out by everyone so far, a simple USB to RS232-TTL interface is really cheap and easy....requires just 3 wires for Full Duplex comm to your projects (Rx, Tx, Gnd) and are cheap as dirt....Unless you are designing a Mass-market product, there is no good reason to build USB into your projects....just build-in an RS232-TTL header.....Or simply use one of the Arduinos if you like the AVR platform....

Now, on the PC side.....I am 100% certain there is a C/C++ solution to interfacing with your projects....but I have never penetrated C/C++ enough to suit my needs.....Visual Basic on the other-hand provides a Very Rapid Development Platform that is easy to use and requires very little "actual programming" to get up and running....There are also "scripting languages".....

I have been playing with a VB program I wrote for many years that allows me to interface with AVR based targets....The primary goal of the VB/AVR interface is to allow me to prototype various AVR Functions and Features....My program relies on "Instructions" hard-coded into the AVR....these include things like Reading/Writing Registers, SRAM, EEPROM and FLASH....Direct Vectoring, IRQ Vectoring, Timed Delays, etc, etc, The default mode on the AVR target is an idle loop that waits for a command or "program" from a Host PC.... This "Program" is a series of "Instructions" executed from SRAM....Different instructions have different parameters etc, etc...essentially it allows me full interactive control of the AVR w/o "FLASHING" a new "hex" file....I typically "prototype" a project using this interface...then if I need "new instructions" for the final version...after testing them interactively, I can "hard code" them into the ASM source....A good example was 1-wire comm for the DS18 series of temperature sensors....I started by bit-banging using the interface, then I wrote a library of "instructions" that are hard-coded into the ASM....When I have a project that uses a DS18, I simply include the requisite "instructions" in the source code for the project.....

Sadly, my approach is a bit antediluvian.....the more common approach (and almost certainly better...) for the AVR family is the Arduino IDE approach....where open-source libraries preclude the need for writing much code at all....But, as I said at the beginning...I simply haven't penetrated C enough to meet my needs...with ASM on the AVR side and VB on the PC side, generally I can solve the problem at hand fairly quickly....In any case, communicating with a uC is easily achieved via USB by utilizing existing USB to RS232-TTL interfaces and requires nearly zero effort.....What you use to on the PC side is simply a matter of preference....But if you use windows and want "easy" look at Visual Basic.

Fish

 

[Supercap2F]

At the risk of making this too simple.....As has been pointed out by everyone so far, a simple USB to RS232-TTL interface is really cheap and easy....requires just 3 wires for Full Duplex comm to your projects (Rx, Tx, Gnd) and are cheap as dirt....Unless you are designing a Mass-market product, there is no good reason to build USB into your projects....just build-in an RS232-TTL header.....Or simply use one of the Arduinos if you like the AVR platform....

Yeah, I know that the approach I'm taking to putting USB in my stuff isn't really the easiest way.. I just feel that I would learn more than if I used some off the shelf pre-built thing. I always try to be able to say about all my project that I know exactly how they work and how to fix them if something goes wrong. I really can't say it better than this though:

Now, on the PC side.....I am 100% certain there is a C/C++ solution to interfacing with your projects....but I have never penetrated C/C++ enough to suit my needs.....Visual Basic on the other-hand provides a Very Rapid Development Platform that is easy to use and requires very little "actual programming" to get up and running....There are also "scripting languages".....

Yeah, so far learning C has been pretty slow - After reading a 600 page book I can still only make programs that run off of the command prompt. If I want to make programs using the Win32 API I have to read a 1,500 page book to learn it! Which I just don't have the time for.

A friend did recommend that I learn Visual Basic for doing USB stuff, but I decided to just use C since I already knew it pretty good. But looking back, Visual Basic does look pretty easy to learn and I like the fact that it has a easy way to make GUI applications. What version of it are you using? VB 6.0 or VB.NET.
Dan

 

[Fish4Fun]

Hey Dan!

I personally use VB6 but if I were starting now I would go with .NET. I maintain the POS application that runs my business....I started writing it in DOS based BASIC back in the mid 1980's....eventually migrated//massively re-wrote to VB4/5/6 in the 90's.....The thought of once again re-writing it is not appealing to me, so I have not migrated to .NET, but if I were just starting I would absolutely start with .NET.

@C.....A primary advantage to C is that it is platform independent....A primary problem with C is that it is platform independent.....LOL. C is all about libraries.....if you can find the right library then most of the work is already done for you....In theory you can write a program and compile it for an 8-bit AVR and then re-compile it for a multi-core 64-bit Pentium....in reality this rarely works....and, for my purposes, leaves me feeling very out-of-control....Don't get me wrong, something like an AVR USB interface would be a nightmare to write from scratch in Assembler, Even in C it requires a prodigious effort....hence the suggestion you leave it to the canned solution.....That doesn't mean it is a waste of time to read/learn about the USB interface itself, but neither does that mean attempting to write one from scratch will be a good use of time....Using a word-processor application does not require the ability to write code, nor even a general understanding of code writing AND the ability to write a word-processor application is unlikely to improve your creative writing skills or even your diction....

In the video you linked the suggestion that basic electronics knowledge is important to the electronics hobby is spot-on....extending this metaphor to the USB interface only suggests to me that one should know HOW the USB interface works, I cannot imagine learning the intricacies of the code required to deploy it across multiple platforms is necessarily useful unless you have some reason to suspect you can improve upon it, or have some need to modify it. Understanding the electronic advantages of differential pair communications I would consider important...understanding the particular nuances of specialized communications protocols I would consider generally trivial. At the end of the day, for the vast majority of DIY uController projects RS232-TTL, I2C, SPi , and perhaps Dallas's 1-Wire are the protocols most commonly used....There are many other protocols each with their own merits, but 99.99% of DIY uC communications can be relegated to one of these standard protocols with acceptable performance.....The USB interface is designed to efficiently handle large data transfers...data transfers that are well beyond the capabilities of most DIY uController projects, so it makes perfect sense to use a "canned" USB to RS232-TTL interface to establish communication between a DIY uC project and a host PC w/o attempting to take control of the USB protocol....Obviously this is just my opinion....I would encourage you to explore the Code-Side of USB as far and in-depth as you desire, but I cannot fathom a way this might improve your electronic skills, nor how it might prove valuable to any DIY project.

By all means....carry on AND Good Luck!

Fish