Electronic – Using Microchip’s dsPIC33E USB Starter Kit

microchippicusb

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???

Best Answer

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.

Related Solutions

Electronic – SRAM which two chips can read/write

You don't need dual-port RAM or even a serial RAM with two interfaces; For SPI it's a little trickier, but I2C allows multiple masters "out of the box." Either way, your software will have to monitor the bus conditions to see if it lost the bus and if so, wait for another opportunity.

For SPI, the MOSI, CS and CLK lines must be tri-stated (or open-collector) with pull-up resistors to keep the lines from floating. You will also need some kind of bus arbitration. This can be as simple as a single GPIO between the two masters so that the one with higher priority signals the lower-priority master that the bus is unavailable, but a more elegant solution would be a single open-collector line between the masters. When the bus is idle, neither master is yanking the line down so it floats high with a pull-up. The logic is that if the line is high, the bus is available. The master that wants to use the memory would look at the "bus available" line and if it's high, drive the line low and wait a few ms to make sure the other master didn't grab the bus at the same time. If the RAM SPI CS line is still inactive, it can be safe to assume that the bus is yours. Do the transfer, tri-state your MOSI/CLK lines and let go of the "bus active" signal.

The "wait a few ms after yanking the bus request line low" is necessary since it is possible for both masters to grab the line at the same time.

If you are only ever using one shared device and that device does not require multiple transfers, you could use its CS line as the "bus available" signal, but this isn't quite as robust.

Programming dsPIC30F4011/13 on board dsPICDEM 2 with MPLAB ICD 2

You have to set the configuration bits. Near the end of the device's header file (line 5880 for dsPIC30F4013) is a listing of all the device's configuration bits that need to be set or cleared to ensure proper operation of the device, as well as code comments for how to do it.

For example:

_FOSC( XT & CSW_FSCM_OFF )  // Configure for external XT crystal oscillator, turn off clock switching and monitoring

The oscillator and watchdog timer configurations are very important.

EDIT: In your edited post you tried using the phase-locked loop option for the oscillator. You have to add the following code in your main routine in order to use an external oscillator + PLL:

/*
 *  Set up the PLL for full 60 MIPS operation (dsPIC33EP512MU810)
 *
 *  Fcy = Fin*K/2 --> 60MHz = 8MHz*K/2 --> K = 15
 *  K = M/(N2*N1) --> 15 = M/(N2*N1)   --> N2 = 2, N1 = 2, M = 60
 *  Fcy = 8MHz*15/2 = 60MHz
 *
 *  p. 164-171 datasheet
 */
void configPLL()
{
    PLLFBDbits.PLLDIV = 58; // M = 60
    CLKDIVbits.PLLPOST = 0; // N1 = 2
    CLKDIVbits.PLLPRE = 0;  // N2 = 2
    OSCTUN = 0;
    // Writing to the OSCCON register requires a special unlock sequence
    // Using a compiler built-in write instruction to handle this
    __builtin_write_OSCCONH(0x03);  // Select primary oscillator with PLL   
    __builtin_write_OSCCONL(0x01);  // Request oscillator switch
    while (OSCCONbits.COSC != 0x3); // Wait for the PLL to lock
}

Best Answer

Related Solutions

Electronic – SRAM which two chips can read/write

Programming dsPIC30F4011/13 on board dsPICDEM 2 with MPLAB ICD 2

Related Topic