UC3A vs UC3C

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

Which one is better? I have a design based on UC3A so far I have developed. But I am thinking I should upgrade it to UC3C....seems it has more IOs and the USB seems to allowe you variable endpoint sizes (flexible) and the memory is taken from the HSB 4K memory? So potentially bigger end point sizes possible...

Also UC3C seems to place more emphasis on 5V tolerant inputs. What do you say guys? What is your experience with UC3C? Is it much harder to setup its USB host?

I am not very happy with UC3A so far...the usb interrupt method doesnt seem to work well. I have to use polling method for sending and receiving.

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

I know the UC3C (which I'm using in my project) has 2M samples/s ADC, which was attractive to me. I haven't look at A to really know the big difference.

I'd suggest http://www.atmel.com/PFResults.a...(data:(area:'',category:'34864[33180[33080]]',pm:!((i:8238,v:!(0,16)),(i:8394,v:!(0,17)),(i:8362,v:!(0,27)),(i:8282,v:!(0,1,2,3,4,5,6,7))),view:table),sc:1) and see the differences yourself.

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

thank you... i was aware of the ADC difference. I was more concerned with getting the USB working as it seems to have different Endpoint buffer allocation mechanism. I wonder how much code change I would have to do to migrate...

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

I use USB on UC3A and it works quite well. I had some problems with dropping data, but that should be fixed now.

I have a sensor connected on the EBI and flow data from it to a PC using the USB interface. I get around 60MBit/s transfer rate.

I don't get what you man by "using pulling method for sending and receiving". You mean the uC pulls the USB interface for incomming and outdoing transmissions?

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

According to the datasheet the UC3C has a different USB module with somewhat peculiar memory management. However, when I tried to use it on a UC3C engineering sample, I discovered that the datasheet lied and the integrated USB module was actually exactly the same as in the UC3A3! I’m not sure whether this only applied to my engineering sample or to the final revision as well.

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

AgwanII wrote:
I use USB on UC3A and it works quite well. I had some problems with dropping data, but that should be fixed now.

I have a sensor connected on the EBI and flow data from it to a PC using the USB interface. I get around 60MBit/s transfer rate.

I don't get what you man by "using pulling method for sending and receiving". You mean the uC pulls the USB interface for incomming and outdoing transmissions?

that seems insane!!! 60Mbits/s??? I struggle to get 3KByte/s through my 3G usb modem dongle!

How did you do it?? Yes the micro polls the usb interface for incoming and outgoing instead of using interrupts. I was not successful in setting up the interrupt. Do you have any demo codes I could look at?

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

catweax wrote:
According to the datasheet the UC3C has a different USB module with somewhat peculiar memory management. However, when I tried to use it on a UC3C engineering sample, I discovered that the datasheet lied and the integrated USB module was actually exactly the same as in the UC3A3! I’m not sure whether this only applied to my engineering sample or to the final revision as well.

That is interesting....so sounds like there is no real gain with usb endpoint buffer sizes if I migrate to UC3C...

Looking at the peripheral it still seems like a better option...

I am hesitant to move to UC3A3xxx series even though the usb there is HS, it seems the endpoints have a total limit of about 2+Kbytes only...which is not a lot, when you are trying to talk to 3G usb modems...which these days have 512byte/endpoints and more than 3 interfaces....

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

Even with 256 byte endpoints you can achieve pretty good speeds with the DMA controller. I don’t think you need AgwanII’s 60 Mbit/s for a 3G modem.

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

I based my program on the ASF 1.7 demo for CDC. I do as catweax sais, use the USB DMA channel. I make a linked list of transfer descriptors pointing out the bits of memory I want to send. Then I point the DMA-thingie at the first transfer descriptor and swosch it goes out. The program I have now send with around 70-80 MBit/s and not just for short burts, I can send 100 MByte chunks with that speed.

I have asked some questions about transfer descriptors in this forum, so if you search about it you will find how I do it.

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

well i m basing my code on the asf code as well...and how can u get 60mb/s when the theoretical limit is around 8mb/s due to the speed being 12mb/s??

And how do you use dma? is that using interrupt instead of polling for send and receieve?

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

Theoretical is 480 Megabit/s. As I said above, I make a linked list pointing out the memory I want to transfer and then point the DMA on the first one. But it is still pulling between that.

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

for UC3C the supported USB speed is FS (12Mbps) not HS (480Mbps)!

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

Oh, that sucks. I would not change to UC3C then. Guess I don't have much more input to give you about this.

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

hhmm... I have been reading up on USB using DMA...but not much material out there :(

the speed seems attractive but I dono how to achieve it using dma...anyone can help?

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

luvocean, have a look at another post on Force Send USB

https://www.avrfreaks.net/index.p...

This has some good stuff on how to configure the USB and achieve very good throughput, its a long post, but there is a bit of a summary towards the end

Regards.

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

Thanks for that... well in my cdc_host_task() function I do as follows:

unsigned short sendLen;
if(host_tx_cnt == 0)
{
	sendLen = FifoUsedSize(&CDC_DataTxDesc);
	if(sendLen > CDC_DATA_OUT_SIZE)
		sendLen = CDC_DATA_OUT_SIZE;
	while(sendLen)
	{
		FifoPullByte(&CDC_DataTxDesc, &cdc_data_out_array[host_tx_cnt++]);
		sendLen--;
	}
	if(host_tx_cnt)
	{
		CDC_SendData(cdc_data_out_array, host_tx_cnt);
	}
}
if(host_tx_cnt == 0)
{
	Host_unfreeze_pipe(pipe_cdc_data_bulkin);
	if( (Is_host_in_received(pipe_cdc_data_bulkin)) && (Is_host_stall(pipe_cdc_data_bulkin)==false) )
	{				
		Host_reset_pipe_fifo_access(pipe_cdc_data_bulkin);
		while(/* (host_rx_cnt != CDC_STREAM_IN_SIZE) && */(Host_byte_count(pipe_cdc_data_bulkin) != 0) )
		{
			if(FifoFreeSize(&CDC_DataRxDesc) > 0)
			{
				FifoPushByte(&CDC_DataRxDesc, Host_read_pipe_data(pipe_cdc_data_bulkin, 8));
				//host_rx_cnt++;
				DataLED_Blink(1, 20);		//blink for incoming data						
			}						
			else
			{
				break;
			}						
		}
		if( Host_byte_count(pipe_cdc_data_bulkin) == 0 )
		{
			Host_ack_in_received(pipe_cdc_data_bulkin);    // pipe is empty
			Host_free_in(pipe_cdc_data_bulkin); 		   // ready to receive more data
		}
	}
	Host_freeze_pipe(pipe_cdc_data_bulkin);
}

where CDC_SendData() is defined as:

void CDC_SendData(void *buf, unsigned long len)
{
AVR32_USBB.uddma2_addr = (uint32_t)(buf); 
    AVR32_USBB.uddma2_control = ((len) << 16) |
							 AVR32_USBB_UXDMAX_CONTROL_DMAEND_EN_MASK |
							 AVR32_USBB_UXDMAX_CONTROL_BUFF_CLOSE_IN_EN_MASK	|
							 AVR32_USBB_UXDMAX_CONTROL_CH_EN_MASK;

while (AVR32_USBB.UDDMA2_STATUS.ch_en);

host_tx_cnt = 0;
}

I never get a reply back from the modem I am trying to send AT command to...

I can see the ch_en while check passes in the CDC_SendData function as I have placed print statements before and after and the function runs to completion...which may mean Sending is performed to completion??

Then why am I not receiving anything?? If I dont use DMA and use normal transmit based on the ASF code then I do get received data from mode.

Also I can see how you do the DMA on transmit..how do you do DMA on receive when you dont know the length of the incoming message?

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

Ok I have realised I was using the UDDMAX registers instead of UHDMAX registers.. I should be using UHDMAX register as I am the host...

But after fixed that I have now placed interrupts to be captured upon EOT of USB transfers, as well as EOBUFF (copying of HSB buffer to endpoint). It seems the interrupt for EOBUFF is raised but not the interrupt for EOT (End of transfer via the actual pipe).

I wonder why....so basically the data from SRAM buffer to USB pipe is being copied well but from pipe its not leaving to the device :( Why could this happen?

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

Wow this is very interesting!
the AVR32_USBB_UHDMA2_STATUS_EOT_STA never works...instead when AVR32_USBB_UHDMA2_STATUS_EOCH_BUFF_STA gets raised you do the following (inside the interrupt handler):

Host_ack_out_ready_send(pipe_cdc_data_bulkout);
host_tx_cnt = 0;
Host_freeze_pipe(pipe_cdc_data_bulkout); 

This transmits the 64byts buffer I am trying to transmit...I cant understand how thought? As far as I can see...EOBUFF interrupt should indicate that bytes were copied to Endpoint(pipe) and EOT interrupt should indicate that a transfer actually happened through the pipe...

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

No, EOT doesn’t mean that the transfer actually happened. EOT is only set under certain circumstances, as mentioned in the documentation:

AT32UC3A3 datasheet wrote:
Section 26.8.2.20
[...]
EOTSTA: End of USB Transfer Status
This bit is set when the completion of the usb data transfer has closed the dma transfer. It is valid only if UDDMAnCONTROL.BUFFCLOSEINEN is one. Note that for OUT endpoint, if the UECFGn.AUTOSW is set, any received zerolength-packet will be cancelled by the DMA, and the EOTSTA will be set whatever the UDDMAnCONTROL.CHEN bit is.

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

Ok I am using number of busy bank == 0 to catch whether all my data was transfered....
I call the following function:

void CDC_SendData(unsigned char pipe)
{	
	Pipes[pipe].LastTransactionOK = FALSE;		//Mark transaction not complete by default
	Host_ack_out_ready(pipe);
	Host_unfreeze_pipe(pipe);	
	//Host_reset_pipe_fifo_access(pipe);
	
	AVR32_USBB_UHDMAX_addr(pipe)    = (unsigned long)(Pipes[pipe].Buffer); 
    AVR32_USBB_UHDMAX_control(pipe) = (Pipes[pipe].Length << 16)						|
									  AVR32_USBB_UXDMAX_CONTROL_EOBUFF_IRQ_EN_MASK		|
									  //AVR32_USBB_UXDMAX_CONTROL_EOT_IRQ_EN_MASK			|
									  AVR32_USBB_UXDMAX_CONTROL_DMAEND_EN_MASK			|
									  AVR32_USBB_UXDMAX_CONTROL_BUFF_CLOSE_IN_EN_MASK	|
									  AVR32_USBB_UXDMAX_CONTROL_CH_EN_MASK;
	
}

Later on at EOBUFF interrupt handler I call:

void CDC_TxCompleteHandler(unsigned char pipe)
{
	//Host_ack_out_ready_send(pipe);
	Host_send_out(pipe);
	AVR32_USBB_UHDMAX_status(pipe);		//Clear the interrupt					
}

The impression I get is that the DMA only copies the data from SRAM buffer to the USB pipe buffer (host mode). So if my pipe size is 64 then my SRAM buffer the DMA sources data from must also be 64 bytes? Or can it be bigger? It seems the SRAM buffer size must also be the same size as the pipe.

Otherwise DMA will nto be able to copy eveyrthing into the pipe buffer and the raise EOBUFF interrupt.

Also why do I have to manually place those FIFOCON clearing and the pipe freezing? I would have thought you dont need them with DMA?

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

It looks like EOT interrupt is raised for IN pipes in host mode...
How do I know how much the buffer has written??? the Channel byte count is set to 0 and after DMA filling buffer the channel byte count in status remains 0...so it looks like that is used for OUT pipes..