Main Site Documentation

Question about using USB-Serial SP vs USB-Serial Modules


#1

Relative newcomer to Gadgeteer modules.

I’d like to set up my next .NET Gadgeteer project to be connected to a PC as a virtual serial port for data communication. I know I can do this using the USB-Serial module. But I’d like to also power the project from that same USB port, and that led me to looking at the USB-Serial SP module. If that’s how the mainboard gets its power, but it looks to the PC like a virtual serial port, I’m confused about how I would download/debug during the development phase…through this module?

Would I need to use a USB Client SP module (for download/debug) and a separate USB-Serial module during development, and then go into Visual Studio and switch the .gadgeteer diagram to use the USB-Serial SP module (removing the USB-Serial and USB Client SP modules)? But once I make that change, can I download the new version to the mainboard through the USB-Serial SP module? Or do I need the USB-Client module attached to do this? But I can’t attach more than one power (red) module at a time…

It seems like a catch-22, but I suspect I’m missing something or I’m overthinking it.

Thanks.


#2

Read the following document: https://www.ghielectronics.com/docs/20/usb-client

You are interested in CDC communications. You did not say what board you are using. CDC requires a board that has USB client support.


#3

When you use the USB Client module for communication to PC, you have to Switch to Serial Debugging (usually a pin you pull down to ground, If you use Cobra II with Extender, there are two Jumper pads on the extender you conn connect).
Then you connect an additional USB Serial module to COM1 on your board, by which you can deploy and debug then.
In fact you have two USB Connections to your board while Debugging.
The USB Serial module on COM1 does not Need to be added to the designer, and can be disconnected for normal Operation.
The downside of serial debugging is that deploying and debugging is a bit slower as over USB Client.


#4

@ Mike -

Thanks for the link. This really helps. The mainboard will be FEZ Spider, which appears to have this “extended” USB Client support.


#5

@ Reinhard Ostermeier -

Thanks for the information.


#6

Having read the USB Client document (thanks again), I want to make sure I get together the correct components and understand the workflow.

Using the FEZ Spider, let’s say I use the USB Client SP Module (USBSP-GM-330) for both power and deploy/debug. While the embedded application is running, I want to use that same module via CDC for a small amount of periodic bi-directional communication with the attached PC (a PC application talking to the virtual serial port). That would be the normal state of the device in the field - chatting occasionally with the PC using CDC and drawing power through that same USB Client module.

I see that the example code waits for the USB controller’s state to be not running before sending data via CDC. But there’s nothing done after that in the code, so I’m not clear on whether we can just go back to normal USB communication (e.g., for continued debug/deploy) after that serial communication has taken place.

During development, once the application operates the USB Client module in CDC mode, will I be able to then deploy/debug in USB client mode again, or will I need to switch the Visual Studio project’s deployment transport from USB to Serial? Or, does the device appear to the PC as two devices - the USB client (for deploy/debug) and the virtual serial port, so that I can switch back and forth between them without worrying?

If the USB Client SP Module (USBSP-GM-330) doesn’t support this type of use, which module(s) would support it? USB Client DP Module (USBDP-GM-280), USB-Serial SP Module (USBSR-GM-437), or something else?

Thanks for your patience.


#7

@ kgcode - You will be able to debug and use the CDC at the same time. The board looks like two devices. The DP and SP power modules will support.


#8

@ Mike -

Thanks for confirming that.

Just one last follow-up question. How does the USB-Serial SP Module (USBSR-GM-437) fit into all of this? Is it purely a virtual serial port (from the PC’s perspective), looking like just one device and not two?

(Okay, that was two follow-up questions.)

Thanks.


#9

@ kgcode - THE USB-Serial SP Module module does not support debugging. It looks like one serial port to the PC.


#10

@ Mike - Thanks very much for clearing that up. You have been a great help.


#11

I’m having a bit of trouble figuring out exactly how to get a USB Client SP module configured properly under Windows using the CDC driver to make it look like a virtual COM port to the PC. What I’m looking for is a detailed step-by-step outline of all that’s required to get the USB Client SP module to be seen as a working virtual COM port.

I have carefully gone over the CDC info at https://www.ghielectronics.com/docs/20/usb-client#106 , and looked through a number of forum posts mentioning CDC. I’ve also scanned some other discussions that seem to touch on this process, but the links to other documents/pages in some of these posts no longer work (HTML 404).

I have the CDC Driver INF file, and have tried to follow the advice of replacing/updating the GHI NETMF Interface driver (the only thing that shows up in Device Manager when the USB Client SP module is connected). Windows responds that the GHI driver is already up to date, so it does nothing. No additional COM port appears. (Note: The PC already has one physical COM port.) I’ve tried removing the device, and installing the CDC driver directly, without success.

So, starting a PC with Windows 7 Pro 32-bit and the 4.3 SDK installed, the CDC Driver INF in hand, a FEZ Spider (running 4.3) with the application already deployed to it, and a USB Client SP module connected to the PC (showing up as GHI NETMF Interface in Device Manager), what are the actual individual steps to get to the point of the PC recognizing the USB Client SP module as a virtual COM port, over which the FEX Spider can send small amounts of data to the PC?

Pretend I’m new at this…which I am.

My goal is to have my device (FEZ Spider and modules) draw its power from the USB port, but only communicate with the PC through the USB Client SP module via the CDC virtual COM port.

Thanks.


#12

@ kgcode -

The document page should be updated

Here is correct one

using System.Threading;
using GHI.Usb;
using GHI.Usb.Client;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware.UsbClient;


public class Program
{
    public static void Main()
    {
        // Start Cdc
        Cdc vsp = new Cdc(0x1B9F, 0xF001, 0x100, 250, "xxxx", "CDC VCOM", null, "CDC VCOM");


        Controller.ActiveDevice = vsp ;    // you are missing this line
        // Send "Hello world!" to PC every second. (Append a new line too)
        byte[] bytes = System.Text.Encoding.UTF8.GetBytes("Hello world!\r\n");
        while (true)
        {
            // Check if connected to PC
            if (Controller.State !=
                UsbController.PortState.Running)
            {
                Debug.Print("Waiting to connect to PC...");
            }
            else
            {
                vsp.Stream.Write(bytes, 0, bytes.Length);
            }
            Thread.Sleep(1000);
        }
    }
}

#13

@ Dat -

Thank you for posting the code. What I’m looking for at this point, though, is the step-by-step instructions to get the USB Client SP module to even show up on the PC as a virtual COM port. I have not yet been able to install the CDC driver using the instructions on the USB Client document page, so I am trying to find the details of the actual steps required just to get a usable virtual COM port on the PC using the USB Client SP module.

Or, are you saying that by running the code you provided on the Spider, it will suddenly cause the module to be recognized as a virtual COM port by the PC?

Again, I’m new at this, so please bear with my apparent (and actual) ignorance.

Thanks.


#14

@ kgcode -

  • Your spider must be in Serial debug mode. This can be done by pushing switch 4th to ON, then reset the board
  • You need a Serial USB module connect to socket 11 (or socket 8, I don’t remember exactly).
  • Deploy that application into your spider through Serial port.

All done, if the driver was installed correctly, you will see new COM Port under Device Manager.


#15

@ Dat -

Thanks for these details. I will give it a try.

For future reference, where would I have been able to fine these details?


#16

@ Dat -

In case you don’t have Serial USB module, it is fine.

What you need to do for this case is, keep the switch 4th if off (normal state). The spider will run in USB debug mode.

Deploy that application as normal way (through USB port).
once this step is done, your application is loaded into the device, then push the switch 4th to ON, reset the board. A new VCOM will be shown under your DM.

Without USB Serial module, you can not debug in VS,

Just remember that:

Once you are using USB debug port as USB Client (VCOM, Keyboard, moise…) the switch 4th must be ON to turn Serial debug port ON, and disable USB Serial debug port.


#17

@ Dat -

Right, I don’t have a USB Serial module…I just have the USB Client SP module. So, thanks for the additional information. I will give it a try.

Again, where would I have found this information? Is there a document that provides these details? (I’m trying to be more independent.)

Thanks.


#18

@ Dat -

I followed your instructions with the USB Client SP module (changing it to serial mode by flipping switch 4 to ON on the Spider), and resetting the board. Unfortunately, Windows Device Manager doesn’t see any device - no new COM port, no Unknown Device, nothing. I tried scanning for hardware changes, but still nothing. I tried disconnecting and reconnecting the USB Client SP from the powered hub, but still nothing. There are no messages indicating that anything has been attached.

At least if there were an “unknown device” entry, I could attempt to install the CDC driver. But the device in this mode doesn’t show up at all anywhere in Device Manager.

Any hints on what to try next would be appreciated.

Thanks.


#19

@ kgcode -

Did you load your code to the device?

If you did, is it this line added yet?



If you don't have USB Serial module to debug in serial mode, you can use led on spider (pin 47), depends on the led status, you can know where we are.

```cs

OutputPort led = new OutputPort((Cpu.Pin)(47), true);

#20

@ Dat -

Thanks for your reply. I took your advice, and I’m consistently getting an InvalidOperation exception on the line:


Controller.ActiveDevice = vsp;

where the vsp was created as you showed in an earlier post to this thread. Call stack on the exception is:

GHI.Usb.Client.Controller::set_ActiveDevice
GHI.Usb.Client.RawDevice::Activate
GHI.Usb.Client.RawDevice::NativeInitialize

The client module is the USB Client SP module, and the Spider is running 4.3. No other modules are attached to the mainboard. I’m using Mainboard.SetDebugLED as an indicator of where the code is executing. I do not have a USB Serial device.

Any idea what might be causing the InvalidOperation exception?