UC3 ADC throughput 15ck vs 13ck

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

On a UC3A0512 rev.I, I have one ADC channel enabled, conversion is triggered by a timer channel, and PDCA is taking the data away. This basically works.

What I ran into is this in the datasheet:

Quote:
Converting a single analog value to a 10-bit digital data requires Sample and Hold Clock cycles as defined in the field SHTIM of the MR register and 10 ADC Clock cycles. The ADC Clock frequency is selected in the PRESCAL field of the MR register.

also,
Quote:
For performance and electrical characteristics of the ADC, see the DC Characteristics section.

So what does that hint at?
Quote:
384(1) kSPS Throughput Rate ADC Clock = 5 MHz
1. Corresponds to 13 clock cycles at 5 MHz: 3 clock cycles for track and hold acquisition time and 10 clock cycles for conversion.

With SHTIM=2 (3 cycle t/h), matching the stated 5MHz/384kps=13 adclock/sample throughput, I got the impression that I could do 384ksps throughput.

In reality, the ADC does not seem to accept triggers faster than 15 adclock, leading to a maximum single channel througput of 333kHz.

Has anyone else run into this, and/or this documented anywhere?

/Kasper

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

Hi,

I am not sure I can help .. but I have too run into some problems recently...

I am doing a 1ms trimer triggered conversion on AC0 to 5, so 6 channels. I have thus a buffer of 6 unsigned short which is setup to be pointed to by the PDCA mar register. transfer length is set to 6 and buffer pointer is reset upon interrupt of PDCA transfer complete.

Ideally I expected to see ADC0 result put into Buf[0] location, ADC1 result in Buf[1] location and so on.

However just once I have found my results to have shifted by one location. For instance ADC1 result was found in Buf[0] location ADC2 was found in Buf[1] location etc...

I wonder if anyone has seen this anomally...

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

@luvocean1: I had this problem once and I tracked down that it was due to writing to the FLASH user page while ADC conversions were running. Apparently, writing to FLASH ties up the bus matrix too long for the PDCA to do its thing.

@KKP: There is a minimum 3 clock cycles for track and hold. The number of t/h samples is SHTIM+3. So, to get 3 cycle t/h you have to set SHTIM to 0.

Edit: I think there might be a typo in the UC3A datasheet. The UC3B data sheet says that the t/h cycles is SHTIM+3. I have done what you are doing on a UC3B part and used SHTIM+3 to calculate the timing and got the expected results.

Letting the smoke out since 1978

 

 

 

 

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

Hhm.. thanks digitalDan...but I dont recall my instance had a FLASH user page update scenario tied up... I am now using the interrupt method. I only raise interrupt on the 6th conversion ie: ADC5. By that stage I assume all other lower ADC channels (0 to 4) were converted. So in this interrupt routine I read and save all the ADC values.