Announcement

Collapse

New Sub-Forum

In an effort to help make sure there are appropriate categories for topics of discussion that are happening, there is now a sub-forum for databases and database programming under Special Interest groups. Please direct questions, etc., about this topic to that sub-forum moving forward. Thank you.
See more
See less

Let's talk about USB programming again

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Let's talk about USB programming again

    I have heard a few people state (including some PB folks) that have said
    something to the effect of "applications shoud not have to concern
    themselves with talking to USB ports" or something of that general idea.
    But applications talk to serial ports, and PB has good support for that. Since
    USB ports have been replacing serial ports on PC's, it sure makes sense that
    an application programmer should be able to program a USB port more easily
    that they now can.

    First of all, I believe you if you tell me that applications should not
    need to concern themselves with talking to to USB ports, so the question
    is, how does an application programmer do this? Who has the "missing link"?

    (By the way, please do not refer to the Jan Axelson Book "USB Complete".
    It is a good book, but does not answer these questions.)

    I will provide a good example. You know those large moving message LED
    signs? Now Adaptive Micro systems has a fairly new version called the
    BetaBrite "Prism", see www.betabrite.com.

    The version of the Prism can get at Sam's club has only a USB port. They
    provide messaging software to talk to it, and for those interested in
    programming it they (it seems reluctantly, and only if you ask for it) provide
    a (mostly undocumented) DLL and a small (undocumented) piece of Visual
    Basic code that kinda/sorta shows how to use the DLL. A few of us (that I
    have identified from those posting to forums and such) interested in the
    Prism have successfully sent messages to a Prism via the USB port.

    The Prism is a "USB Bulk" device using the Micrium USB stack in an NXP
    LPC2146 microcontroller. The functions I used were USBBULK_Open,
    USBBULK_Write, and USBBULK_Close.

    Well, someone wrote the DLL for the Prism called "betabriteusb.dll", and PB
    has been noted to be very good for writing DLL's, so how would one go
    about writing the equivalent functions in PB?

    (One answer might be that a person must purchase the Micrium USB stack
    and get the documentation, but if that is the answer for most USB devices
    then application programmers have little ability to use USB ports for a
    reasonable price.)

    And what about the more generic USB devices, like USB Flash Drives. Why
    shouldn't the application programmer be able to open a file on one of these,
    write to it, and close it?

    I have searched for API for USBBulk.sys, etc. and not found anything. It
    would seem like a list of API's would exist for the generic USB drivers.
    Gary Peek, Industrologic, Inc.

  • #2
    Depending on the device, you usually need to install the device's driver which should provide a COM port through which you can send/receive data using PB's COMM functions. I have communicated with many USB devices this way. I have also wrote code that calls USB.DLL to do the communication, so it' perfectly possible depending on the device and it's driver support.

    You will be stuck if you do not have a driver, as it is not possible to write device drivers using PB, as they are in a different format (VXD, SYS) to the win32 PE executables that PB generates.
    kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

    Comment


    • #3
      As Kevin states, many USB devices install themselves as 'Virtual Comm. Ports'.
      You communicate with them as if they were true serial ports using PB's COMM function.

      USB Flash drives are seen by the OS as virtual disk drives, so PB's OPEN, WRITE, PUT, etc. can be used.

      Just about anything else, you need access to the specific driver, usually through a DLL. If this isn't provided by the manufacturer, you may be SOL.

      BTW if the device in question uses FTDI USB chips, complete info is available from their web site (www.ftdichip.com).

      Comment


      • #4
        Virtual Comm Cort, yes I am familiar

        Kev:I have communicated with many USB devices this way. I have also wrote code that calls USB.DLL ...."

        Gary:
        Thank you, that is helpful. What is "USB.DLL"? Does it have a list of API functions? Do you have a few lines of code to show what you did?

        Kev and Bill, thank you, I know about the USB to virtual serial port chips, etc., those make it easy.
        Gary Peek, Industrologic, Inc.

        Comment


        • #5
          If I need software to connect to hardware through USB, and the data throughput is only small, I always try to use the HID class. This because it can use Windows built-in driver, so it's easy to install, and there is no problem with connecting and disconnecting at the USB bus.
          (I've seen some dedicated drivers that were poorly written and even would give you a BSOD when unplugging without stopping the device first...)
          Regards,
          Peter

          Comment


          • #6
            Gary forms a good point as I am working along the same lines as to the basics of USB....and yes USB complete from Jan Axelson I have to agree is the closest to the "Rosetta Stone" as I have gotten.

            Peter is right with
            If I need software to connect to hardware through USB, and the data throughput is only small, I always try to use the HID class. This because it can use Windows built-in driver, so it's easy to install, and there is no problem with connecting and disconnecting at the USB bus.
            Most (not all) devices have at least a HID class interface, (although I am still beginning, so this is only my best guess to date), but USB complete also shows other "Device Specific" classes, so I am not 100% yet.

            Roughly translated form Kev and Bill
            As Kevin states, many USB devices install themselves as 'Virtual Comm. Ports'.
            You communicate with them as if they were true serial ports using PB's COMM function.

            USB Flash drives are seen by the OS as virtual disk drives, so PB's OPEN, WRITE, PUT, etc. can be used.

            Just about anything else, you need access to the specific driver, usually through a DLL. If this isn't provided by the manufacturer, you may be SOL.
            SOL is close, but not quite in all cases.

            USB seems to be a bit of a "Secret Society" that everyone knows what it does, and use it, but hardly anyone is willing to fess up "HOW" to use it. The good part is most have some sort of HID interface, so there is always some sort of work-around, or have a Virtual COM so you can treat it as a serial port. The bad part is device specific ones that you are limited to the programmer that wrote the driver (dll) to interface the device if it is specific. (In most of my limited experience, the hardware is GREAT, and the software sucks so bad that it barely works)

            For example my USB Rocket Launcher I got a year ago for Xmas, the hardware worked great, but the software sucked so bad that it would crash constantly, and only aim in 4 directions, then a lil reverse engineering (watching the port) I took a few good guesses that I added up to 8 simultaneous directions (N,S,E,W, and the points between) to make it functional.

            Anyways back to point, Gary I think you mis-spoke when you said
            Well, someone wrote the DLL for the Prism called "betabriteusb.dll", and PB
            has been noted to be very good for writing DLL's
            NOT true...PB does EXCELLENT dll's, the only thing it does not do is low level machine level dlls (like accessing serial ports directly, rather than build on the Windows Kernel level)

            Gary I understand your comment of
            I have heard a few people state (including some PB folks) that have said
            something to the effect of "applications shoud not have to concern
            themselves with talking to USB ports" or something of that general idea.
            But applications talk to serial ports, and PB has good support for that. Since
            USB ports have been replacing serial ports on PC's, it sure makes sense that
            an application programmer should be able to program a USB port more easily
            that they now can.
            and my thought of "Only because of HID, or if you really delve into the complexity of USB. (I am working on it, but hitting the same sort of roadblocks myself) and since it was my idea that the next version of my software should include USB rather than just Virtual COM's or a USB to RS232 Adapter just because USB has been so widely accepted, now wondering what the heck I was smoking when I said USB was the way to go?
            Engineer's Motto: If it aint broke take it apart and fix it

            "If at 1st you don't succeed... call it version 1.0"

            "Half of Programming is coding"....."The other 90% is DEBUGGING"

            "Document my code????" .... "WHYYY??? do you think they call it CODE? "

            Comment


            • #7
              DLL, INF, HID, too many TLA's

              Cliff, I see you have thought a lot about this too, so thanks for your insights.

              "PB does EXCELLENT dll's, the only thing it does not do is low level machine
              level dlls"

              Yep, good way of putting it. I understand.

              "The good part is most have some sort of HID interface..."

              Do you know how I would go about finding out if the Prism has this,
              or what PB code I could use to even try it?

              Another thing I thought of later was that perhaps the low level DLL that
              is supplied (for example, betabriteusb.dll) uses the information in the
              .INF file to look only for a USB Bulk device with the Vendor ID of the
              Prism. I can't say that I know how this all works.


              And by the way, for anyone else following this thread, yes, if I were designing
              a USB only device, it would be with the FTDI FT232R, which is a Virtual Com
              Port chip. I prototyped one and it works as advertised, so I'm ready to go.
              Gary Peek, Industrologic, Inc.

              Comment


              • #8
                FWIW - I've designed several pieces of USB hardware using the FTDI 232 & 245 parts.

                I generally use the D2XX driver option for greater flexibility. You can obtain you very own range of PIDs from the manufacturer for a more custom device appearance (to the OS). A PB port of the D2XX functions can be found at somewhere here as well.

                Comment


                • #9
                  Gary,
                  Sounds like you are doing exactly the same thing I am doing. A USB to RS232 chip (but in my case Silicon Labs).
                  If you are doing what I think you are doing, then (Yes, about to reference USB complete and LVR again), what you want is P.302 of the USB complete book.

                  I am working on (Yet ANOTHER) port from code here, and USB complete for a generic code, but taking a lot longer than I 1st thought (learning curve).

                  If its of any help you may want to look at 2 codes I posted recently in the Source-Code forum. List USB info (VID, PID,Revision, etc) and Available Serial Ports

                  Hopefully my latest Port will be of even more help. but at the moment involves a table lookup of thousands of possible USB devices, so I need to find a way to trim down the data. (Or just post a snippet, and link the whole project to one of my webpages for the full source code?)

                  Hopefully done sometime this week, but like I said, its a heck of a learning curve
                  Engineer's Motto: If it aint broke take it apart and fix it

                  "If at 1st you don't succeed... call it version 1.0"

                  "Half of Programming is coding"....."The other 90% is DEBUGGING"

                  "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                  Comment


                  • #10
                    If you are referring to the Silicon Labs CP2101, well, I've been down that
                    road already and don't like it. It's a decent chip but the MLP-28 chip
                    package is unbearable.

                    I have also found that the FTDI VCP chips are more likely to work, while
                    some of the other chips have buffer and timing issues with some software.
                    I think this is because these chips are based on programmable logic (that is
                    more like straight hardware) rather than a microcontroller with a USB stack.

                    I saw your other posts and code and will look forward to anything else I see.

                    The excerpts of code in USB Complete may be wonderful for understanding
                    the details of USB but they just don't do much for me in getting something
                    written. A good example would be worth a lot.

                    If you want to call me to talk about any of this, (800) 435-1975, 9-5 central.
                    Gary Peek, Industrologic, Inc.

                    Comment


                    • #11
                      If you are referring to the Silicon Labs CP2101, well, I've been down that
                      road already and don't like it. It's a decent chip but the MLP-28 chip
                      package is unbearable.
                      Actually the CP2103, but same difference
                      The documentation I was able to get is sorely in need of being re-written for users that were not involved in the development of the chip
                      (Little things like "The answer is 42", "Ummmmmkayyyyy but WHY??? is the answer 42?, what does 42 mean?" kind of things)

                      Then I started noticing "Patterns" in the documentation depending on the API function I wanted to call, and realized most answers were some binary reply that could be multiple answers at once that I still need to break down to readable code.

                      I have also found that the FTDI VCP chips are more likely to work, while
                      some of the other chips have buffer and timing issues with some software.
                      Actually from my tests it is usually some bad implementation in the "Virtual Com" side with an advanced setting usually not used, but some devices use and can block your functions if not aware of the setting.

                      Over lunch I was re-reading some of the USB complete and noticed in the Acknowledgements was Dave Navarro from Powerbasic. So if he is around, may be able to help?

                      Currently I am working on porting examples from USB complete from VB to PB (or more specifically the "Finding a Device" functions) that I hope to piece together for a functional example of accessing a USB device. (Hopefully generic, and not vendor-specific)
                      Engineer's Motto: If it aint broke take it apart and fix it

                      "If at 1st you don't succeed... call it version 1.0"

                      "Half of Programming is coding"....."The other 90% is DEBUGGING"

                      "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                      Comment


                      • #12
                        Gary,
                        I got a mostly running example going. I still have some more "Database" cleanup, and more overcommenting to do, but this will give you a basic idea of what I am working on.

                        List Devices, Vid, Pid, Revision, etc

                        It is a work in progress, so I welcome any ideas, suggestions, errors I made etc, so that eventually I can make a INC to offer.

                        The "Database" of sorts is far from complete (as I learned today), but getting closer, so I welcome any VID,PID, and other info possible that anyone can offer on a device they have and this sample does not show "User Friendly" names for.

                        If you find it useful, or can offer some input, or have questions, let me know

                        And Yes, I am still working on the "Generic" access USB idea, but this gets me one step closer to the concept without having to be "Device Specific". (Although it is quickly becoming apparent to me, that once I can access the device, I still have to know how to talk to it, but that is a matter for the device's user-manual) :laugh:
                        Engineer's Motto: If it aint broke take it apart and fix it

                        "If at 1st you don't succeed... call it version 1.0"

                        "Half of Programming is coding"....."The other 90% is DEBUGGING"

                        "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                        Comment


                        • #13
                          RTFM'ing, yes!

                          Cliff, you've done a lot there. I ran it and took a look around.
                          I'll be studying it more later. Yes, we all have a lot of RTFM'ing
                          to do.
                          Gary Peek, Industrologic, Inc.

                          Comment

                          Working...
                          X