Exact match. Not showing close matches.
PICList
Thread
'[PIC] help with adc on dspic30F4011'
2012\02\06@134629
by
Vicent Colomar Prats
|
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
|
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}>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@053218
by
alan.b.pearce
> 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
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
|
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
|
{Quote hidden}>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
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
|
Thanks for sharing.
2012/2/9 Electron <spam_OUTelectron2k4TakeThisOuT
infinito.it>
{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@152311
by
Electron
|
You're welcome!
At 20.52 2012.02.09, you wrote:
{Quote hidden}>Thanks for sharing.
>
>2012/2/9 Electron <
.....electron2k4KILLspam
@spam@infinito.it>
>
>> 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@181036
by
IVP
> 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
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
|
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...