256 byte out endpoint with MyUSB

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How, if at all, do I use ping-pong mode with MyUSB?
I've modified the USBtoSerial demo to do USB to SPI.
Moving the out endpoint to 1 let me use 128 bytes,
but to use 256 bytes, the 1287 wants ping-pong mode.

BTW the At90USBKey is running at 5 volts,
so it can do SPI with an STK500 and other 5 volt things.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Enable the "dual-banked" mode, by using the ENDPOINT_BANK_DOUBLE constant as the bank mode in the call to Endpoint_ConfigureEndpoint().

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm still having trouble trying to get it to work.
I've modified USBtoSerial to make it USB to SPI,
so far one-way.
Trying to read registers to figure out what happened isn't working either.
Without the register test in the CDC task, I can get a throughput of 69,000 bytes/sec.
That includes copying the bytes to an STK500 with SPI.
With the register test, the USBKey fails it.
Variations on the failure display tell me that the EPSIZE bits are all 0.
I'm pretty sure that is wrong, but don't know how to do better.
Any ideas?
Here are the changes I made to Descriptors.h:

        #define CDC_NOTIFICATION_EPNUM         2
        #define CDC_TX_EPNUM                   3
        #define CDC_RX_EPNUM                   1
        #define CDC_NOTIFICATION_EPSIZE        8
        #define CDC_RX_EPSIZE                64
        #define CDC_TX_EPSIZE                64

Here is the the out endpoint's configuration:

    Endpoint_ConfigureEndpoint(CDC_RX_EPNUM, EP_TYPE_BULK,
                               ENDPOINT_DIR_OUT, CDC_RX_EPSIZE,
                               ENDPOINT_BANK_DOUBLE);

Here is the start of the CDC task:

TASK(CDC_Task)
{
    if (USB_IsConnected)
    {
        /* Select the Rx Endpoint */
        Endpoint_SelectEndpoint(CDC_RX_EPNUM);
        #if 1
        if(CDC_RX_EPSIZE != 8<<(UECFG1X>>4))
        {
            unsigned char colors=BICOLOUR_LED1_RED ;
            if(!(UECFG1X & 0xF0)) colors|=BICOLOUR_LED2_GREEN;
            //---DDR_XCK1 &= ~MASK_XCK1;  // leave SPI master mode
            DDRD |= 0xF0;
            UCSR1C = 0;
            while(1) {
                LEDs_SetAllLEDs(colors);
                colors^=    BICOLOUR_LED1_RED | BICOLOUR_LED1_GREEN |
                            BICOLOUR_LED2_RED | BICOLOUR_LED1_GREEN ;
                for(unsigned ms=1000; ms; --ms) _delay_ms(1);
            }
        }
        #end

Here are some #defines I am using.

#define BICOLOUR_LED1_GREEN LEDS_LED2
#define BICOLOUR_LED2_GREEN LEDS_LED4

#define BICOLOUR_LED1_RED LEDS_LED1
#define BICOLOUR_LED2_RED LEDS_LED3

Apparently I was wrong about using a 128 byte endpoint.
It would run so long as I didn't send it a chunk bigger than 64 bytes through the virtual serial port.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Apparently I was wrong about using a 128 byte endpoint.
It would run so long as I didn't send it a chunk bigger than 64 bytes through the virtual serial port.

It's a pity I had to leave when I quickly replied last time, or I could have saved you the trouble if I had read your post more carefully.

The USB specification doesn't allow any more than 64 bytes for a bulk endpoint when in Full Speed mode. The larger endpoint sizes are designed for interrupt endpoints, which can be a little over 1000 bytes in size maximum.

You will get your maximum throughput using 64-byte endpoints, double banked. You will also need software designed to send full USB packets to the device -- normal programs like Hyperterminal only send a byte and a time in each packet.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Quote:

Apparently I was wrong about using a 128 byte endpoint.
It would run so long as I didn't send it a chunk bigger than 64 bytes through the virtual serial port.

It's a pity I had to leave when I quickly replied last time, or I could have saved you the trouble if I had read your post more carefully.

The USB specification doesn't allow any more than 64 bytes for a bulk endpoint when in Full Speed mode. The larger endpoint sizes are designed for interrupt endpoints, which can be a little over 1000 bytes in size maximum.

Ah. So I should look a demo that uses interrupt endpoints.
Quote:
You will get your maximum throughput using 64-byte endpoints, double banked. You will also need software designed to send full USB packets to the device -- normal programs like Hyperterminal only send a byte and a time in each packet.
Not to worry, I'm using python.
90,000+ bytes/sec even with a 64-byte endpoint.

I don't, at the moment, need to read the above registers.
For future reference, how do I read them?
Who knows? I might make a mistake some day.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Ah. So I should look a demo that uses interrupt endpoints.

The CDC class has to use bulk endpoints for the virtual serial port mode - anything different and you'll have to make your own drivers.

Quote:

I don't, at the moment, need to read the above registers.
For future reference, how do I read them?
Who knows? I might make a mistake some day.

Which registers?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Quote:

I don't, at the moment, need to read the above registers.
For future reference, how do I read them?
Who knows? I might make a mistake some day.

Which registers?
I guess I only mentioned one.
This is the if that didn't do what I expected:
if(CDC_RX_EPSIZE != 8<<(UECFG1X>>4))

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's bizzare. I'd recommend you stick with the MyUSB accessors for those values, such as:

if(Endpoint_BytesInEndpoint() < CDC_RX_EPSIZE)

Take a look at MyUSB/Drivers/USB/LowLevel/Endpoint.h - it should contains accessors for all the endpoint attributes.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
That's bizzare. I'd recommend you stick with the MyUSB accessors for those values, such as:

if(Endpoint_BytesInEndpoint() < CDC_RX_EPSIZE)

Take a look at MyUSB/Drivers/USB/LowLevel/Endpoint.h - it should contains accessors for all the endpoint attributes.

In the general case, your code is really hard for me to read.
In this case (hard!=impossible), it wouldn't have done what I wanted.
I was trying to get the endpoint's capacity, not the size of its contents.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
Michael Hennebry
"normal programs like Hyperterminal" -- Dean Camera

Now that's a funny sig line. :lol:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

skeeve wrote:
Michael Hennebry
"normal programs like Hyperterminal" -- Dean Camera

Now that's a funny sig line.

Heh. Well, I wouldn't exactly call Hyperterminal "normal"...

Quote:

In the general case, your code is really hard for me to read.
In this case (hard!=impossible), it wouldn't have done what I wanted.
I was trying to get the endpoint's capacity, not the size of its contents.

Really?! I thought that giving symbollic names to the arbitrary register manipulations would increase code legibility.

In any case, I'll add macros to fetch the endpoint's size for the next version.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Quote:

skeeve wrote:
Michael Hennebry
"normal programs like Hyperterminal" -- Dean Camera

Now that's a funny sig line.

Heh. Well, I wouldn't exactly call Hyperterminal "normal"...

You've learned your lesson. Good.
Quote:
Quote:

In the general case, your code is really hard for me to read.
In this case (hard!=impossible), it wouldn't have done what I wanted.
I was trying to get the endpoint's capacity, not the size of its contents.

Really?! I thought that giving symbollic names to the arbitrary register manipulations would increase code legibility.[

Using Endpoint.h would increase code legiblity.
It's reading Endpoint.h and figuring out how to use it that is hard.
I get the impression that Endpoint.h isn't actually source code, that it is the output of some tool.
Quote:

In any case, I'll add macros to fetch the endpoint's size for the next version.

How about preceeding the first #ifdef with something like:
/* Endpoint_EndpointSize() returns the capacity of the current endpoint */

?
I had to look up a register to figure out that Endpoint_BytesInEndpoint() didn't do what I wanted.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm, well people do refer to me as a machine at times, but I assure you, it's all human made.

You should read the (also human made!) documentation at http://www.fourwalledcubicle.com... - it lists each of the Endpoint functions and their purpose.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!