DZX USB Workbench for WinUSB

From my brief investigation, it seems that the DZX USB Workbench only works with the DZX HID USB POR, and not the WinUSB class? The DZX USB Workbench seems like a very powerful tool. Would be nice to use with the WinUSB device.

Thanks so much!

Not sure on which features are being requested, but to be sure, the utility tools installation contains the USB Terminal application. It supports sending and receiving data with a WinUSB device. It can be downloaded from the Downloads page.

The USBWorkbench application is only for the original USBPort component that was built upon HID. It also had the ability to generate code (both PC and device software) based upon a defined message structure. The HID implementation contained an extra layer within the device that encoded messages (SLIP protocol), since the HID packets were all fixed sized transfers. With the WinUSB implementation, any size messages can be transferred and the message is terminated with a short packet. Thus, since everything is more simple, we didn't want to muddy up this new implementation or create any limitations.

Within the device, a message could be defined and received as follows:

/* Defines the maximum number of data bytes per message */
#define CFG_MAXUSBMSGSIZE            256

/* A common usb message */
typedef struct USBMSG {
    UINT32 cmd;
    BYTE data[CFG_MAXUSBMSGSIZE];
} USBMSG;


void APP_USBThread(void* arg)
{
    static USBMSG msg;
    UINT32 len;
    STATUS status;


    status = USBD_Read(&eprx,                 /* Receive a USB message */
                       &msg,                  /* Message to be filled */
                       CFG_MAXUSBMSGSIZE,     /* Max message size */   
                       &len,                  /* Variable to get num received */
                       INFINITE);             /* Wait until a message arrives */

    if (status == SUCCESS) {                  /* Received a message */

        assert(len == 4);                     /* A message should be at least 4-bytes */

        switch (msg.cmd) {                    /* Lookup by command number */

            case 0:
                break;

            case 1:
                break;

            default:
                break;
        }
    }
}

The code above blocks until a message is received. Upon receiption, it parses based upon the first 32-bit word, called cmd. There are several ways that the message data could be accessed per command, either using a union within the USBMSG structure, or by using a pointer with a custom type defintion.

The C# side works the same as the device. When a message arrives, it is the size that was sent by the device and can be parsed however it needs to be.

I hope that sheds some light.  I'm curious to know more about the functionality you would like to see that was within the original USBWorkbench.

-Tyler

Tyler,

Thanks for the quick reply. I'm able to use the terminal and am in the process of implementing a message/cmd scheme as you have suggested. I saw the messaging model and thought about how powerful that is.

I was under the assumption that for the DZX USB Workbench, once connected a person could communictate over the messaging model and not deal with the byte level information as in the terminal. It looks like the code generation on both the C# and the embedded side can still be leveraged in WinUSB, but without connecting through the DZX workbench I will still need to implement the C# code seperately.

For me, the power was apparent in the ability to tweak and excercise the message structure, while avoiding any byte level work (in software at least) without compiling any PC software.

I may have jumped the gun on the Feature Request but figured I'd post...

Thanks,

-Spencer

Spencer,

I don't think you jumped the gun, feedback is always welcome. You're correct that you could design messages and execute them just with the terminal and the device.  When this new software kit was released, I didn't want to do a copy-paste with the original message modeling as there are a few cumbersome details with it.

Some issues with the original implementation were that it was difficult to keep the auto-generated code seperate from the user code in the device. I never liked dealing with code that is sprinkled with "USER CODE START" and "USER CODE END" tags everywhere. I want the auto-generated code in a file all of its own so that it can be simply regenerated without any manual edits. Another issue was that the message definitions could get out-of-sync between the device and host. This could be easily rectified with a version/id tag that is changed upon any edits to the message definition.

At this point, I am convinced there is real value (time saving) with letting a tool do all the byte-level assembling and working with meaningful messages. The nice part is having a terminal that displays meaningful items rather than byte values. If I decide to add this to the terminal, it will be an optional layer to allow for direct transfers for those that need the full control. Also, there is no reason to limit it to USB. Such a tool could work over TCP or UART just as easily.

I cannot commit to this feature quite yet, but will continue to work through possible implementations. Feel free to provide further input or specific features you'd like to see.

-Tyler

Tyler,

Thanks again for the reply. Agreed with the "INSERT USER CODE HERE" stuff. I also never thought about it sitting on different protocols, very powerful.

Looking forward to what's next. So far so good from my end. Just the USB terminal and C# demo code give a tremendous jump on time to market.

Thanks,

-Spencer

Spencer,

We've officially decided to move forward and implement the auto code generation feature within a future update of the SDK. It will function similar to the USB Workbench. I am expecting to have the update, which will include support with the WinUSB, available within the next few weeks.

-Tyler

Tyler,

Wonderful. Will look forward to it.

-Spencer

Spencer,

FYI, version 16.3.1 has been released and contains the "Data Link" feature which is similar to the functionality provided by the original USB Workbench. There is a new tool, the Data Link Editor that provides the ability to define the messages and generate code for the link. The USB Terminal application has a new view that provides the ability to transfer these messages without having to build any custom software.

Also, there are demo data link projects for some of the supported evaluation boards that implement a simple data link. There is a new .NET demo application that shows how to use the data link to communicate with the devices using either a native USB, an FTDI USB-to-Serial, or a standard serial port connection.

Enjoy the new features and feel free to ask any questions or report any issues.

Best Regards,

-Tyler