Using Microchip's dsPIC33E USB Starter Kit

Question

I'm a student and I'm starting a project in which I'm working with the Microchip's dsPIC33E USB Starter Kit. I used some samples taken from this site for initiating, sending and receiving packets. There is no screen in this board, so I'm printing what I need on the computer screen with a terminal software IVT VT220.

My first problem is printing more then one line to the screen - if having 2 print commands in the same code, it'll print only the first, then will do the rest of the code, just without the second printing command. For example this code:

// some code
putrsUSBUSART("first print");
putrsUSBUSART("second print");
//the rest of the code

will print "first print", and then will do the rest of the code.

The second problem I have is sending and receiving messages in different modes. When I'm using loopback mode, I'm able to transmit a message and then receive it. By checking the rx register it looks like the message has been transferred correctly. However, when changing the mode to normal mode and doing exactly the same process, it still looks like the message I've received is valid (although working with one device only! So it suppose to work fine only in loopback, not in normal mode. or maybe it doesn't work at all in both modes?).

Any suggestions why this things happen???

Answer 1

I think the putrsUSBUSART(); function is probably non-blocking and has a check for the peripheral being busy. When you try to send the second string it checks and finds the peripheral is busy so simply skips.
I recall another "sendUSB" type function working in this way in the USB libraries.

For a quick test of the above, try adding a delay between the two function calls to see if it solves the issue (this is not a permanent solution - there is probably a function to check for this but this should do just to check)

From what I can see, the dsPIC33F starter kit relies on another PIC with a USB peripheral to do the USB comms (AFAIK none of the dsPICs have a USB peripheral)
It also looks like the demo firmware is set up to emulate a COM port for serial comms. I couldn't find any documentation for the code, but I did find this:

The instructions for this demo can be found at C:\dsPIC33E PIC24E USB Starter Kit Demo\Documentation\Getting Started\Getting Started - Running the Device - CDC - Basic Demo. See the Running the Demo section.

I'm assuming all the necessary documentation is going to be in the "Documentation" folder. It should have details of the functions used in the demo application, so you can check how they work. You could also just check the function code itself.

Answer 2

I know that this is an ages-old question, but in case anyone else comes by...

The problem is that the put*USBUSART() functions are non-blocking, and thus the USB stack is not yet ready to transmit the second string when the first function exits.

You can check whether it is ready or not via the USBUSARTIsTxTrfReady() function. Here is the way to create a blocking set of put[r]s functions:

// USB magic stuff
void usbPerformTasks(void)
{
    USBDeviceTasks();
    if(USBGetDeviceState() < CONFIGURED_STATE /*|| USBIsDeviceSuspended()*/)
        return;
    CDCTxService();
}
// blocking until we're ready to transmit
void usbBlockTx(void)
{
    while(!USBUSARTIsTxTrfReady())
        usbPerformTasks();
}

// ROM function
void usbBlockPutRS(const far rom char* str)
{
    usbBlockTx();
    putrsUSBUSART(str);

    /*
     * Also put this in if you want to wait for the Tx to finish,
     * but if you only use these two functions, you don't need it.
     */
    //usbBlockTx();
}
// RAM function
void usbBlockPutS(char* str)
{
    usbBlockTx();
    putsUSBUSART(str);

    /*
     * DO NOT COMMENT THIS OUT -- it is needed because putsUSBUSART()
     * does not copy the data, which means that `str` could possibly
     * get changed in mid-transmission. This is not required for the
     * ROM version of the function, since ROM data cannot change -- well,
     * unless you happen to be programming the uC, but then we wouldn't
     * be running this code here.
     */
    usbBlockTx();
}