Couple USB questions for PIC18F

[Rusttree]

I'm attempting to write ground-up firmware for a simple USB device using a PIC18F14K50. After reading through the USB section of the datasheet a couple of times, I have a few questions that I don't think the datasheet explains thoroughly. For simplicity, I'll enumerate my questions.

1. My first cut will be the simplest device possible. As such, I've disabled any USB PIC feature that I interpreted as nonessential to make USB communication work. Here are the register values I chose. I only plan to use endpoint 0 at this time.

    // PING-POING disabled
    UCFGbits.PPB0 = 0;
    UCFGbits.PPB1 = 0;

    // Eye-pattern test disabled
    UCFGbits.UTEYE = 0;

    // Disable buffer stalls
    BD0STATbits.BSTALL = 0;

    // Disable data toggle synchronization
    BD0STATbits.DTSEN = 0;

    // Disable status interrupts. Flags will still be
    // set in UIR, but won't actually interrupt processor.
    UIEbits.URSTIE  = 0;
    UIEbits.UERRIE  = 0;
    UIEbits.ACTVIE  = 0;
    UIEbits.TRNIE   = 0;
    UIEbits.IDLEIE  = 0;
    UIEbits.STALLIE = 0;
    UIEbits.SOFIE   = 0;

    // Disable error interrupts. Flags will still be set
    // in UEIR, but won't actually interrupt processor.
    UEIEbits.PIDEE   = 0;
    UEIEbits.CRC5EE  = 0;
    UEIEbits.CRC16EE = 0;
    UEIEbits.DFN8EE  = 0;
    UEIEbits.BTOEE   = 0;
    UEIEbits.BTSEE   = 0;

    // On-chip pull-up enabled
    UCFGbits.UPUEN = 1;

    // Low speed device
    UCFGbits.FSEN = 0;

Are any of these values unreasonable? And are there any I've missed that I need to include?

2. I think I've got a handle on the buffer descriptor concept (BDnSTAT, BDnCNT, etc). However, I noticed in Fig 22-6 of the datasheet that separate IN and OUT buffer descriptors are used for endpoint 0. Nowhere else in the datasheet is this mentioned except for in that figure. I'm assuming this means that any transmissions coming from the host are associated with the OUT bd and any transmissions from the uC are associated with the IN bd. Is that correct?

3. Figure 22-5 gives an example of a buffer descriptor in memory. The values for BD0ADRL and BD0ADRH are 0x00 and 0x05, respectively, making a combined address of 0x0500. The figure then shows an arrow pointing to RAM address 0x280 as the beginning of the USB buffer. How does 0x0500 in any way correlate to 0x280? [EDIT: I just realized 0x500 is exactly twice 0x280. Still confused by the discrepancy, though.] [EDIT 2: Just confirmed this is a typo in the datasheet. The values of BD0ADRH and BD0ADRL in the figure should be 0x02 and 0x80]

4. Are BDnADRL, BDnADRH, and BDnCNT set automatically by the uC or are they chosen manually?

5. Does the program need to manually set the UOWN bit (of the BDnSTAT register) to received incoming transmissions from the host? Or is UOWN fully automatic?

Thanks,
Dan

 

[Pommie]

I've not played around with the USB module except for using the Microchip code as a black box. Maybe you can get answers from looking at the Microchip code. You might also find this site useful.

Mike.

 

[Rusttree]

I took one look at the Microchip code and I turned and ran. Not to say it's bad code, but they definitely employed an "everything-for-everyone" approach, which makes gleaning any basic information out of the code nearly impossible. Every feature, error checking, and option is fully implemented, so separating the stuff I need from the extra fluff I don't need is daunting.

I did manage to find some much simpler code written by someone else, and I'm getting pretty far with it, but my questions above still stand. It's always a little difficult to decipher someone else's code.