Searching \ for '[PIC] help with adc on dspic30F4011' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=adc
Search entire site for: 'help with adc on dspic30F4011'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] help with adc on dspic30F4011'
2012\02\06@134629 by Vicent Colomar Prats

picon face
I'm used to program in C but not in ASM. I usually do not take care how
long takes to do a full ADC cycle, but now I have to.

I'm working in an application that reads 6 analog inputs (an0 - an5),
sequentialy or and it must be done fast, the fastest possible. The pic
(dspic30f4011) works at its maximal Fosc (117,92 MHz with internal 7,37 and
PLLx16). I've read datasheet of dspic30f4011/4012 chapter 20 "10-BIT,
HIGH-SPEED ANALOGTO-DIGITAL CONVERTER (ADC) MODULE" and dspic30f Family
Reference Manual section 17 "10-bit A/D Converter", but it is not clear to
me.

I wil continue working in C, but my wish is to configure ADC operation thru
accessing registers (ADCON1, ADCON2, ADCON3, ADCHS, any more?)

First of all, i'm not sure which is the max speed I can obtain for a 6
diferent inputs, 1 Msps? 750 ksps? 600 ksps? Less? If 1 Msps is possible,
then every read I've to reconfigure multiplexers to set a different input
channel, how is it done? According to figure 20-1, for AN0
How do I configure channels?
I think there are automatic modes for up to 4 channels, but what about six?
How do I configure registers to do that?
Where do I read values from conversions, ADCBUF0 everytime? or ADCBUF0 - 5
for each channel?

As you can see, I'm a bit (a lot), confused about manually configuring ADC,
any light on this will be apreciated

2012\02\07@043652 by Electron

flavicon
face

I have never worked with the dsPIC30F4011 specifically (although I worked
with the 5013 and 6012 and 6014), but I have to tell you this anyway:

The effective max speed you can use will not only depend on the data sheet
(integrated by THE ERRATA!!! which MUST ALWAYS BE READ), but also by other
factors, not last (but often understimated) is the sampling time necessary,
which strongly depends by the output impedance of your source signal..

So it may be necessary to buffer with an OpAmp your input signal, if you want
to reach the full speed "guaranteed" in the datasheet+ERRATA docs.

Greets,
Mario


At 19.46 2012.02.06, you wrote:
{Quote hidden}

>

2012\02\07@053218 by alan.b.pearce

face picon face
> I'm working in an application that reads 6 analog inputs (an0 - an5), sequentialy or
> and it must be done fast, the fastest possible. The pic
> (dspic30f4011) works at its maximal Fosc (117,92 MHz with internal 7,37 and PLLx16).
> I've read datasheet of dspic30f4011/4012 chapter 20 "10-BIT, HIGH-SPEED ANALOGTO-
> DIGITAL CONVERTER (ADC) MODULE" and dspic30f Family Reference Manual section 17 "10-
> bit A/D Converter", but it is not clear to me.

There are some PIC devices that can be set up to have the ADC scan a set of channels on its own, putting the resultant data into an array that the program can read out once they have all been read. I don't know if this particular chip has the scanning capability, but it may well be worth considering one that does, if this one doesn't.

Then you get one interrupt once all the channels have been scanned.

-- Scanned by iCritical.

2012\02\08@121221 by Vicent Colomar Prats

picon face
Thank you both, Mario and Alan.

I checked errata for 30f4011 and discovered it has "lots" of "bugs", my
next micro will be a 33F or 33EP (I love 33EP256MU806 specs for a 64 pin
micro).

It is not possible to do AD conversions at 1 Msps due to bugs, max is 750
ksps.

After inspection of assembly output from my C compiler, I discovered it was
setting SAMC and ADCS in ADCON3 register at its maximum values (SAMC=11111
"31 Tad" and ADCS=111111 "32 Tcy"). That was the reason of its slow speed..
Now, lowering this values I speeded it up a lot. I have to check for
integrity of data at that speed, but looks promissing and more acceptable.

I still have a lot of doubts, but the increase of speed makes me happy and
do not need to dig more into the question by the moment.

Thanks again

2012\02\09@061801 by Electron
flavicon
face
At 18.12 2012.02.08, you wrote:
>Thank you both, Mario and Alan.
>
>I checked errata for 30f4011 and discovered it has "lots" of "bugs", my
>next micro will be a 33F or 33EP (I love 33EP256MU806 specs for a 64 pin
>micro).
>
>It is not possible to do AD conversions at 1 Msps due to bugs, max is 750
>ksps.
>
>After inspection of assembly output from my C compiler, I discovered it was
>setting SAMC and ADCS in ADCON3 register at its maximum values (SAMC=11111
>"31 Tad" and ADCS=111111 "32 Tcy"). That was the reason of its slow speed.
>Now, lowering this values I speeded it up a lot. I have to check for
>integrity of data at that speed, but looks promissing and more acceptable.
>
>I still have a lot of doubts, but the increase of speed makes me happy and
>do not need to dig more into the question by the moment.
>
>Thanks again.

You're welcome.

I just stumbled upon another problem, but on a PIC32MX1XX: when I enabled
compiler optimizations, the ADC results looked buggy. In the end, as I am
using autosampling, I had to put at least a NOP or a DONE=0 between the line
with SAMP=1 and the loop where I check if DONE became 1. I found the "bug"
as I had suspected in the past that this would be necessary, however the
documentation didn't specify it was, so I omitted the extra code. Now I
know it was due.. it happens very rarely that the loop get skipped as it
finds DONE at 1 because of the previous conversion and SAMP=1 didn't clear
it in time (however I am now going to disassemble it do see if it's the
compiler that maybe reordered the instructions!), but as it was for a buck
SMPS converter loop, it caused some visible (smoky) problems. :D

Cheers,
Mario

2012\02\09@101232 by Electron

flavicon
face
{Quote hidden}

PS: no, the compiler is behaving correctly, it must be an hardware issue.

Specifically this looks like trouble:

     sw    a1,-28672(v1)   ; SAMP=1
loop: lw    v1,-28672(a2)   ; while (!AD1CON1bits.DONE);
     andi  v1,v1,0x1
     beq   v1,zero,loop

insert a nop between the first and second instructions, and the bug is gone..

I was aware of such issues only when writing '0' to the ON bit of a module,
in fact every time I disable a module, I add a nop. But I wasn't aware (and
the documentation would exclude it) that a store immediately followed by a
load from the same register would cause corruption, or maybe it's just the
ADC module that (sometimes!) doesn't have enough time to clear DONE after
SAMP is set.

Please note that PB=1 of course (peripheral bus clock is same as CPU clock).

In any case, that wasted 5 hours of my life.. and bughunting is not really
my favourite sport, but every such situation has something to teach.. and I
wanted to share this with you all ADC-weirdly-behaving frustrated fellows.

With kind regards,
Mario

2012\02\09@145216 by Vicent Colomar Prats

picon face
Thanks for sharing.

2012/2/9 Electron <spam_OUTelectron2k4TakeThisOuTspaminfinito.it>

{Quote hidden}

>

2012\02\09@152311 by Electron

flavicon
face

You're welcome!


At 20.52 2012.02.09, you wrote:
{Quote hidden}

>> -

2012\02\09@181036 by IVP

face picon face

> In any case, that wasted 5 hours of my life.. and bughunting is not
> really my favourite sport

Sad to say, when something doesn't work as expected I more often
these days suspect the silicon. And it unfortunately that turns out to
be exactly the cause too many times. Point it out to Microchip, with
proof, and they don't (or choose not to) believe yo

2012\02\09@183156 by John Gardner

picon face
There's something to be said for bringing up the rear.

If not fumigated, at least a census often exists..

2012\02\10@050643 by Electron

flavicon
face
At 00.10 2012.02.10, you wrote:
>
>> In any case, that wasted 5 hours of my life.. and bughunting is not
>> really my favourite sport
>
>Sad to say, when something doesn't work as expected I more often
>these days suspect the silicon. And it unfortunately that turns out to
>be exactly the cause too many times. Point it out to Microchip, with
>proof, and they don't (or choose not to) believe you

Another thing that may happen (and it happened to me in the last months
3 times!) is that I damaged inadvertently the MPU, and then it didn't work
well (I had one misbehaving dsPIC2011 which I didn't even know how I broke
it, and two PIC32MX120F032B which both gave bad analog readings on a pin, I
strongly hypotize that was because at a certain time my code maybe was
turning that pin to output fighting electrons with a low impedance analog
circuit supposedly driving the same pin).

What I mean is that in any case, be it a silicon bug (after all Microchip
can't know them in advance: we users point the bugs out, and they (maybe,
as You say, not listening enough to single users.. but when they get many
reports they sure do) verify it and put it in the errata sheet), or a
possibly damaged IC, one of the first things I do when some code doesn't
behave as I think it should, and the frustration begins, is to swap the
physical chip with a fresh new unused one. Of course this works best with
socketed DIP parts, as sockets on SMD parts are rare, and soldering/desoldering
them is very stressful at least on hand made PCB's.

Cheers,
Mario

More... (looser matching)
- Last day of these posts
- In 2012 , 2013 only
- Today
- New search...