Confusion over 32u4 USB end point 0 memory allocation

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

I hope someone could give me a definite answer. Say I have initialized EP0 as 64 byte one bank, does it have 8 bytes allocated for setup packet, then 64 bytes for IN and another 64 bytes for OUT? The reason I asked was I didn't find such information on the spec sheet. Maybe there's a better doc than 32u4 full spec sheet. I want to know this because I want to know if I don't clear the RXSTPI, does that prevent an OUT packet from being received or not, in case of control transfer with OUT data. If there's no separate memory allocated for SETUP and OUT, then not clearing RXSTPI would cause NAK on OUT packets, correct?

30+ yr in programming, 20+ years in experimental physics, 10+ yr in embedded system development
Experience across many industries

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

I think your answer can be found  by inspecting the Endpoint Config/Status pseudo registers. I've seen a layout of how that table resides in SRAM; those tables contained pointers to the actual FIFO. I must be going mad - I cannot find it again.

 

IIRC: There was a small table for Emdpoint IN and another very similar one for OUT.

 

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

Thanks. Could you be referencing a different MCU than 32u4? As far as I understand, for 32u4, all the FIFO registers are located exactly at the same location in SRAM address (UEDATX) and you must set which EP (UENUM) to access to "connect" or map that register's SRAM address to that particular FIFO in the USB controller.

30+ yr in programming, 20+ years in experimental physics, 10+ yr in embedded system development
Experience across many industries

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

Sorry for the confusion, I did remember that info from XMEGA (Where System SRAM is used for FIFO buffers) .That explains why I could find the detail.

 

My fight with the ATmega16U2 on Arduino MEGA 2560 resulted in failure, so take this with a pinch of salt.

I think from the USB hardware point-of-view each physical Endpoint 1-6 can only be either IN or OUT. The EPDIR bit seems to imply this.

 

Therefore if you need a bi-directional Endpoint then you must configure two hardware endpoints to achieve this. How the mapping to logical Endpoints happens - I don't know. Thinking about it again now; this may be actually be why my ATmega16U2 experiments failed.

 

PS: You might like to look over the LUFA code: https://github.com/abcminiuser/l...

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

I was asking about EP0 so it should be bidirectional. I think the information I seek should be described somewhere by hardware spec or documents, not software stack such as LUFA but thanks though. I've briefly read the LUFA code. It's good but difficult to digest due to the fact it covers many MCUs so lots of #define and templates and such to obscure the actual things it does. You have to dig several layers to understand what it's trying to do. IIUC, the EP other than EP0 don't have interrupt-driven code and must be polled. I thought that was not the best use of processor time if say an MCU acts as a keyboard and something else and has to keep polling a task() function to see if there's any IN requests. My read into the code is quite brief so maybe there is such interrupt-driven driver I just didn't see due to my very limited time reading LUFA.

30+ yr in programming, 20+ years in experimental physics, 10+ yr in embedded system development
Experience across many industries