AVR-CDC Issues

General discussions about V-USB, our firmware-only implementation of a low speed USB device on Atmel's AVR microcontrollers
Post Reply
jimmieclark3@hotmail.com

AVR-CDC Issues

Post by jimmieclark3@hotmail.com » Tue Oct 02, 2007 6:04 pm

The AVR-CDC project seems to be running correctly on my micro (ATMega88).

Code: Select all

        /*    rs232c -> usb:  transmit char        */
        if( usbInterruptIsReady() ) {
            uchar bytesRead, *data;

         SETBIT(PORTC,1,1);  //I added

            bytesRead = uartRxBytesAvailable(&data);
            if(bytesRead > 0 || sendEmptyFrame){
                if(bytesRead >= HW_CDC_BULK_IN_SIZE) {
                    bytesRead = HW_CDC_BULK_IN_SIZE;
                   /* send an empty block after last data block to indicate transfer end */
                    sendEmptyFrame  = 1;
                }
                else
                    sendEmptyFrame  = 0;
                usbSetInterrupt(data, bytesRead);
                uartRxDidReadBytes(bytesRead);
            }
        }

      SETBIT(PORTC,1,0);  //I Added

this is a code snippet of the int main() in the AVR-CDC 2007-07-07 release.

The light will not come on. If I put the SETBIT on before the if statement it will come on.

I have another atmega88 hooked up to this one transmitting "Hello World\n". Shouldn't the usb interrupt become ready at some time? It is not. I know for a fact that the SETBIT macro works fine, it is not the issue, the only issue is why will it not see the data coming from the other micro. I also tried SnoopyPro to send the other way and I get some info that it looks like it is sending to the CDC micro, and it seems to send a response, but I don't get data out of the CDC micro from the pc.

I would appreciate your help.

christian
Objective Development
Objective Development
Posts: 1443
Joined: Thu Nov 09, 2006 11:46 am

Post by christian » Sun Oct 07, 2007 9:16 pm

Have you tried this on another operating system, e.g. Linux or Mac OS X?

The most likely cause for your problem is that Windows has stalled the bulk endpoint after an error. The error could be that an USB packet was lost due to high CPU load (and long interrupt disable time) on the AVR. Other operating systems don't stall the endpoint if an error occurs. If it works with (e.g.) Linux, this is the most likely cause.

Post Reply