Announcement

Collapse
No announcement yet.

Let's talk about USB programming again

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

  • Gary Peek
    replied
    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.

    Leave a comment:


  • Cliff Nichols
    replied
    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)

    Leave a comment:


  • Cliff Nichols
    replied
    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)

    Leave a comment:


  • Gary Peek
    replied
    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.

    Leave a comment:


  • Cliff Nichols
    replied
    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

    Leave a comment:


  • Bill Eppler
    replied
    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.

    Leave a comment:


  • Gary Peek
    replied
    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.

    Leave a comment:


  • Cliff Nichols
    replied
    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?

    Leave a comment:


  • Peter Lameijn
    replied
    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...)

    Leave a comment:


  • Gary Peek
    replied
    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.

    Leave a comment:


  • Bill Eppler
    replied
    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).

    Leave a comment:


  • Kev Peel
    replied
    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.

    Leave a comment:


  • Gary Peek
    started a topic Let's talk about USB programming again

    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.
Working...
X