Atmel UC3 USB Terminal Interface

[selkathguy]

This is a question specifically pertaining to Atmel UC3B microcontroller configuration:

I recently bought an evaluation kit for Atmel's UC3 series 32-bit microcontrollers because I want to see if it will be useful for an upcoming project, and because I want to learn how to use micros outside of the Arduino world.  I know it's not for the faint of heart, but I am willing to learn. I also picked up an AVR Dragon for programming/debugging, and it seems to support breaking pretty well within Studio 6.

As a programmer (who isn't very used to C), I am trying to understand the structure of the system with regards to interrupts, data transfers, and the higher level program that is my application.  There is a whole lot of code that I have been sifting through and pouring over for the last 2 weeks, and while I do see what functions are doing (shutting off interrupts, writing to buffers, calling callback functions for receive events),  it is difficult for me to conceptualize the order in which things are taking place, even with breakpoints and debugging.

I want to create a simple application that will echo back to me the characters I enter in a USB virtual COM port fashion via something like Putty.  From there I can figure out a lot more.  However the closest example for the EVK1101 evaluation board that comes with AVR Studio 6 is a USB CDC Example which merely bridges a Serial COM port to a USB virtual COM port via things like a USART and DMA with components including a USB Device Driver and Device Interface and so on.  I do not see how these elements are all interacting, even when I do understand the concept of what each is supposed to do in general.  I can see calls from one component to another, but I can't tell if one is implementing the other, or they're different layers in some kind of logical hierarchy like a protocol stack, or what.

I've tried looking at the block diagram in the full documentation (page 4), located here:
http://www.atmel.com/Images/doc32059.pdf
(I have been reading a lot of that document)

However it has not helped me understand where I should be looking to change the USB CDC example to communicate ONLY over USB.  I want to remove any components that I don't need (does the UART only affect the serial port connection in the example?).  I essentially want to do all communication over USB to the virtual COM port that is already set up.  At some point in the code, I should be able to find the final, highest level function for receiving data and be able to follow it with a write of some kind.  I know it will require re-configuring some things at lower levels, but that is the goal.   Anyone familiar with the EVK1101 or Atmel 32-bit micros that can give me a few pointers?

The behavior I want to generate is this (with incredibly generalized names):

Code: [Select]

when we receive a character typed into virtual COM port
    acknowledge we received the character, so the terminal doesnt freeze up in long operations
    echo the character back out through the same COM port
    and do whatever else we want to do (handling text commands and such)

Additional Info:
  The uC is Atmel's AT32UC3B0256
  I can provide code, but it's spread across many source files.  I am curious if anyone is already familiar with this.

[selkathguy]

Bump?  All I want to do is create an example where I can talk to the micro over USB in Putty and have it respond.  The included example doesn't do that and there are too many dissimilarities for me to viably reverse-engineer all of the code.  has anyone used any of the AT32's before?

[Harvs]

Yeah I've got that board and bashed my head against it for a while a year or so ago.  Atmel's software framework documentation sucks donkey balls.


My first recommendation would be to drop dealing with the internal USB interface until you've thoroughly got the hang of the uC.


USB is a complicated topic with uCs that implement it internally.  And it sounds like your doing three things at once.  You've got to learn how Atmel have built their uC and software framework, understand USB communication (including the CDC class) and understand their USB drivers.


We've just been discussing how cryptic uC manufacturers code can be.


My suggesting is to build a few things that don't include USB first.  Get fluent with dealing with structs, function pointers, the DMA and the like, and the Atmel software framework.  Then come back to USB when you're just learning that, not a whole new set of things.

[amyk]

The USB communication can be divided into two parts, setup and operation. Setup is when the device enumerates, i.e. in response to requests by the host it supplies the device descriptor, sets its address, etc. Operation is actual transmitting/receiving of data; when the host wants to send characters to the port, it'll perform an OUT transfer, depositing the data in the buffer on the device for the appropriate endpoint and triggering an interrupt. Your interrupt routine can then examine that data and act appropriately, in the case of the echo example it should copy the data into the IN FIFO and then set/clear the appropriate bit to indicate that it is ready to be transferred to the host upon the next IN transfer. Note that since USB is host-directed, the device cannot just send the data, it has to wait for the host to request for it.

Also look at this document:
http://www.atmel.com/dyn/resources/prod_documents/doc4322.pdf