Post by thread:[PIC] help with adc on dspic30F4011

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

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. >

> 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.

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

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

{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

Thanks for sharing. 2012/2/9 Electron <spam_OUTelectron2k4TakeThisOuTinfinito.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 > >

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 >> >> -

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